As software developers in the present day, we hear about all different kinds of approaches to writing code which end in “DD”. You’ve got TDD, BDD, DDD, FDD, ATDD and probably more. While each of these philosophies has merits of it’s own, in this article, I want to outline yet another approach for writing code that ends in DD which I’m dubbing SDD (Scalability Driven Development).
SDD is a mindset that should be used while working out the implementation details for a given problem. Simply put, as you think through a specific approach ask yourself…
The image above is used ironically in a post titled 10 Tricks To Appear Smart In Meetings, but as a developer, it really is a good question to be asking.
SDD and doesn’t prevent you from using TDD, BDD or any other approach you currently employ when writing code.
Let’s take a look at real life example and demonstrate how an SDD mindset can be utilized to implement a more resilient solution to a given problem.
I’m currently in the process of paring down a 60 minute talk to fit into a 30 minute time slot. Going in, I had a pretty good idea of what needed to be cut, but one challenge I wasn’t sure how to tackle was how to manage multiple versions of a single deck.
how do you manage 30 minute and 60 minute version of a deck for the same talk?— Max Chadwick (@maxpchadwick) September 2, 2016
Aside from my co-worker Gil’s “insightful” idea I didn’t get much of a response on Twitter nor did I find much on Google. I did, however, come up with a solution for this that I think it pretty sweet. I figured I’d write up a quick blog post to outline what I did.
I want to talk to you about tags in git. If you’re already using them great! You may not need to read this post (although you’re of course welcome to). I’m guessing, however, that there are a good number of you who aren’t. If you fall into the latter category, read through the below to find out what you’re missing out on.
I recently gave a talk on monitoring and improving your full page cache hit rate with
Enterprise_PageCache at NomadMage. The talk dives deep into the internal’s of
Enterprise_PageCache, investigating how requests are saved to and loaded from cache. In this post, I wanted to highlight 5 key aspects of FPC that are revealed in the talk.
When commenting code, the most important thing to do is explain why the code exists. Anyone can figure out what the code does, but, other than the individuals involved in the decision that lead to the implementation, no one else will know the reason.
When reviewing historical data in tools such as InfluxDb, it’s typically useful to overlay a timeline of key events. For example, Google Analytics features a simple GUI for adding annotations and New Relic offers an API for marking deployments. In this post we’ll look at creating annotations for your InfluxDb powered Grafana visualizations.