Lautan Coding

Everyone knows how important caching is in computing. We are surrounded by caching managers here, there and everywhere. You've got your CPU caching in the form of L1 and L2 cache which stores the next bit of data the CPU needs. GPUs have a cache. All hard drives come equipped with an on-board cache. Database servers heavily cache your most used queries and query plans, web servers cache the most used data and web clients (browsers) cache client side data. Basically, caching is everywhere. Why am I mentioning this? Well, recently I have been redesigning a framework that plans to make use of cached data to save trips to the database and Redis looks very enticing. But what's the cost/impact of not using a cache? Well, I found this great link "Latency Numbers Every Programmer Should Know" , which orders the latency numbers of accessing the "CPU cache" all the way up to connecting to a computer over the open internet. The numbers shouldn't s

Do you listen to music when you code? I do. For me, there is no better experience of falling into a code-hole while being wisked away by a backing track of your liking. I find the two compliment each other. If you have a sufficiently meaty problem and an inkling of how you're going to solve it, music can sweep away time. You tumble down that code-hole and before you know it, you look up and a couple of hours have passed. Something happens in our brains, where your logic and reasoning about a problem develops to the point where you get a nice flow going. It's hard to explain but it happens. I am in no way precious about what type of music I listen to. In fact I listen to a lot of different genres but I find nothing compliments coding better than a DJ set. I love music (who doesn't). I collect music. I grew up being fed and watered on all types of dance music genres and back in the day, listening to the BBC Essential Mix was a staple! - In today's landscape

Show me an application that doesn't log anything and i'll show you an application which is hard to debug. Every application we write should have a healthy sprinkling of diagnostic logging embedded throughout its logic. A trace to show us what's happening on the inside from the outside. In the past, I've hand-rolled my own bespoke logging classes to output either to file, database or simply console. Not any more! The problem has been solved. It's been done. There are libraries out there like Log4Net or Nlog But from now on, I intend to standardise all my C# code to use SeriLog . SeriLog is an example of a library where so many developers have poured in so much time that any home grown library cannot compete. Why waste your time? Just "nuget" it into your project and be done. Move on. Why is it so cool? Because it's simple. And because it supports many, many outputs. They call them sinks and there is a sink for everything as you ca