In object oriented design, the decorator pattern is commonly used to extend and enhance classes so they perform some new or more refined functionality. In functional programming it is possible to decorate functions as well. The decoration must follow a few rules, but the result is a very powerful technique to enhance functions statically and at run time.

I have spent the last several months writing two blog posts per week. I have really enjoyed writing both the Mainstay Monday and the regular Wednesday posts, but time is a limited resource. I have started a new writing project which will consume a considerable amount of time, so I had to make a choice: I could either continue writing two blog posts a week, or I could pursue my new project.

Recently in my Mainstay Monday posts I’ve talked about creating linked lists and queues in Javascript. Each of those topics is so dense that just writing about the basics of creating and using them took full blog posts. Really all of that was the lead up to today’s post.

If you’re reading this you’re likely already a programmer. This means you have likely used [].sort() in your code many times. I honestly can’t remember how many times I’ve sorted data one way or another. Just because you’ve called sort on an array doesn’t mean you’re necessarily doing the best way you can. Does the following code look familiar to you?

I see lots of discussion around new frameworks, libraries and other odds and ends, which claim to make your code better, cleaner, easier to maintain, etc. Although frameworks are definitely useful for avoiding reinventing the wheel and libraries help clear out boilerplate you would have to litter your code with, the cake they offer of better code is a lie.

A couple weeks ago, we looked into linked lists. Sadly linked lists are kind of a standalone topic that don’t use much more than basic objects in order to function as designed. Queues, on the other hand can easily spring forward from linked lists, and they are a way of working with data as you might with generators!

A friend of mine and I have discussed code generation on several occasions. We both agree that any enterprise development process should involve code generation, without exception. Though it is possible for development from scratch may not provide enough identifiable boilerplate to justify building templates for your code, the moment a framework is in use, you will, undoubtedly, have a certain amount of boilerplate introduced which must be set up repeatedly for each new file you create.

I’ll open up by saying I am a mathematician by education. I’m not one of the mathematical great minds and I am unlikely to ever win a Fields medal, but I have a degree in applied math and it’s what I know. The reason I share this is because it helps define the way I think about problems I work on. Regardless of whether I am working on a problem at work or working on something in my spare time, my math background helps to define the approach I take to solving many of the problems I encounter.

Javascript developers notoriously say unit testing in hard. I think the problem is actually more specific than that. Unit testing pure functions and business logic actually pretty easy.You put a value in, you get a value out. If the value you get back is what you expected, your test passes. Something that is hard to unit test is asynchronous logic.

Dear data structures, which of you is most useful? I don’t know, but linked lists are pretty awesome. Linked lists are great for any number of things, a list of data that can be grown without bound, a data structure that can be incrementally increased, a queue or a stack. There are even more things that can be done with linked lists, but before we can dig into what can be done with a linked list, we need to understand what it even is.