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. …

Image for post
Image for post

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 about “parameters” for the various options we define, and “arguments” for the actual values passed to those…

A quick one today: just a common thread between a bunch of different ideas.

…in examples

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 being too abstract, and I think they often have a good point. Consider other conventions which are meaningless in a programming context, but meaningful to the reader. Some examples are Monty Python references in the python docs, cats and dogs in various OO tutorials, and even Shakespeare scripts in the XMPP…

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.

I’ve been trying to figure out how to get away from high-level principles (“SRP”, “KISS”, “easy to delete”, etc). Even though they’re good ideas, coming up with actual techniques for writing good code seems harder. …

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 object literal and a plain factory…

Image for post
Image for post

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.

Approach 1: “Naive” OOP

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 like this, and indeed for many simpler programs, this approach works pretty…

While electron’s main node process provides a complete standard library, and npm packages are available to implement all sorts of features that your desktop app might want to implement, sometimes you’ll need to call out to a separate commandline to get the behavior you want. …

In the previous part we started building the actual interactive part of the application with React. However, it didn’t look particularly impressive:

Image for post
Image for post

If we want to build a full application, we need a set of layout conventions and UI widgets to build with. While HTML5 itself gives us plenty of tools, a toolkit like Semantic UI can significantly accelerate the process of putting together a good-looking and usable UI. …

Mark Jordan

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store