Today’s idea isn’t directly technical, but by the end it should hopefully be clear how it can apply to programming and software development in general.
Recently I’ve been caught up in watching chess videos on Youtube. I’ve never been particularly interested in chess, but a handful of videos have made it really interesting.
At some point I ended up being curious about a weird old chess rule I remembered called “en passant” (a French word, so pronounced very roughly like “ahn passahn.”)
Whenever I’ve read about en passant before, it’s been a list of rather arbitrary-sounding rules like this:
What makes learning vim worthwhile? While I’m far from a vim guru, and it often gets in the way, it speeds up editing code to the point where I think it’s definitely worthwhile. And with most modern editors supporting some form of vim emulation, it really becomes a skill that you can take anywhere you want to work.
For example, in another editor we might have the keyboard…
A couple of months ago, we ran into a tricky race condition with the way we were handling temporary files. It took a while to track down, but ended up being a good example of how C#’s garbage collection (GC) works, so I wanted to turn it into a blog post.
First, a quick bit of terminology. We say C# is a ‘managed’ language since it will generally manage all your memory for you. ‘Managed objects’ are those objects that the GC knows about and can clean up when no longer needed. …
There are plenty of CLI parser libraries out there for pretty much every programming language under the sun. However, sometimes you might not find one with the right combination of features you want, or maybe you just want to understand what makes them tick. Building a CLI parser is probably much easier than you think!
To begin with, we're going to assume we're passed some arguments as a string array, and we don't have to worry about any complicated shell escaping rules! This makes our life much easier already.
Quick note: I’ll try to stick to the convention of talking…
A quick one today: just a common thread between a bunch of different ideas.
Metasyntactic variables (foo, bar, baz, etc) are an obvious example of being deliberately meaningless. Using them generally communicates to the reader that the code is an example, and the reader is expected to fill in the gaps.
When these variables work well, they avoid providing distracting detail, and let the user spot what is important. This works best when the example is talking about the structure of some code, rather than specific implementation details.
Some people have criticized the use of these “standard” meaningless variables as…
First, a quick story:
Recently I’ve been reworking a Redgate-internal chatbot I wrote a few years ago. It’s done pretty well over the years, but I wanted to take it off the random VM it was running on and make it cloud-hostable.
The biggest change required was to rewrite the storage layer. I’d been playing rather fast and loose with the original designs, and needed to throw together some storage so that the bot could save data. …
React is pretty fast in general, but it can have trouble when repeatedly rendering thousands of elements. This is true even if only a few of the elements are visible at once! UI “virtualization” is a technique for emulating a list with many elements while only rendering as few as possible to make the screen look correct.
Of course, there are plenty of virtualization libraries already available. The most popular is
react-virtualized, which implements just about any layout you could think of and has a ton of customization available. …
I’ve been writing code professionally for almost a decade now, and yet when people ask how to write code properly I don’t really have a good idea. This job is weird.
A worrying amount of the time, I find myself relying on instinct or “experience” to try and figure out which solution to a given problem is going to cause maintenance problems and pain down the line. Really, it’s nothing more than an accumulated set of biases based on the problems of previous projects, and trying to distill it into actual advice is annoyingly tricky.
Let’s say we have an api object we want to inject into our code. We also want to test this code, so we need to define the interface for our api object so that we can create appropriately-shaped mock objects. We want the compiler to check that our mock object at least implements the same methods as the real api.
Coming from C#, my first attempt at this looks like a traditional interface with two different classes to implement it:
We don’t actually need a class here, though, so we can eliminate a bit of boilerplate syntax with an…
Let’s take a toy problem, and use it to explore how the features available in different programming languages influence the way we write object-oriented code.
The problem itself is basic: we have a set of possible pet types (dog, cat, etc) and a set of possible operations on pets (feed, pet, etc). We’d like a solution which scales nicely as we add more pets or operations.
We’ve got our domain object, “Pet,” and two subclasses for cats and dogs. We’ll implement the operations we want directly on the relevant classes, so everything is nice and simple.
For a toy example…