Skip to main content

Posts

Showing posts from January, 2015

Why Technical Blogging?

Given this is my fifth year of blogging I figured it would be worth while answering "Why bother with technical blogging?".Get WritingWrite about anything. Just get started, providing it fits your core focus. This blog focuses on programming and software development related topics, so anything that falls within this category is fair game. Take a single idea and from this one blog post you can generate many more ideas. This is where my upcoming list comes from. A single post can spawn many others and the process will repeat itself. Honest posts, that focus on your experiences tend to be the most well received. Quality over quantity also factors. I try to focus posts, rather than going for length or in depth topics. My early posts are very rough around the edges, they will continue to improve as time goes by. Ultimately the more you blog, the better you'll become at it.ScheduleFinding the time to create posts is quite difficult. Making and sticking to a schedule can help im…

Abstract Data Use Not Data Access

Common data access abstractions I've come across and been guilty of implementing myself are the likes of:IDatabaseIPersistentStoreIConnectionIDataStoreIRepositoryThe problem is, these are not really abstractions. If anything they add an extra layer of indirection. One such benefit of this level of indirection is each concrete implementation can be substituted. This makes testing easy. Other than this, such generic solutions introduce a whole host of problems.ProblemsAbstractionSuch examples are said to be at the wrong level of abstraction. This indirection forces developers to work at the wrong level of abstraction. For example, a controller has no right to be directly querying your data store directly. If the same query is required somewhere else you introduce duplication. Big Bang UpgradeGiven such indirection offers a poor abstraction, upgrading to use a different implementation is tricky. If we assume one hundred usages of IDatabase, all of these code paths need to be migrated…

Caching

The naive approach to implement caching is to just store everything in an in memory collection such as a hashtable. After all it works on my machine.I've worked on systems in the past that used this technique but:Bring in two processes and this falls apartNo Time to Live (TTL)No cache eviction, memory will grow until it crashes the processThis sort of caching meant the system needed daily restarts due to each worker process starting to eat up more and more RAM. At the time I didn't realise this was the problem as to why daily restarts were required. These were automated so the team just sort of forgot about the problem after a while. This never felt right."Improper use of caching is the major cause of memory leaks, which turn into horrors like daily server restarts" - @mtnygard in Release It!.Scale this system up, and daily becomes twice daily and so on. In a global market where software shouldn't be constrained by time zones or "working hours" this is …