While I was first designing this website I knew I wanted to have the ability to display excerpts from various posts/writings. There isn’t any built-in functionality for doing this, but Hugo does contain all of the necessary tools to build this feature yourself.

I have found that time and time again, having good logging can be one of the most essential tools for developing and/or debugging something. It gives you a better insight into what is actually happening in your program. It lets you keep a history of how your program has been performing. It can give valuable debugging data in live environments where editing the code is generally a bad idea. Because of all of this, I try to log as much as I can.

One of the easiest things to do for logging is to simply log every function and/or method call. I’ll leave the details of creating an actual logging system for another time, but this often means going into each and every one of your method calls and adding something like Debug::log(); at the very least. Obviously, this can get very tedious and makes it very easy to simply forget to add in your logging call.

Javascript is inherently a classless object-oriented language, so performing a lot of the things we’re used to in say, PHP, doesn’t work the same way. This doesn’t mean that these things are impossible though. In fact, Javascript is extremely open-ended and very fluid in how it implements OOP. So what if we need to extend the existing functionality of a function of an object, effectively replicating method inheritance?

A while back, I was working on creating an installer for an in-house project using the Nullsoft installer (NSIS). It’s an interesting system but it’s a bit flaky in a couple of areas. One of these areas is installing and/or removing entire directory structures. It appears that the system is generally designed for explicit definitions of all directories and files. While this may often be a perfectly acceptable solution, I wanted a more dynamic system. Because I’ve been developing the installer externally to the actual development of the project, I don’t keep track of what files or directories need to be included, nor do those files and directories remain stable.

A lot of PHP frameworks have something called “collections” (though, I’m sure some of them use a different term). Basically, these are special classes whose sole purpose is to hold a bunch of the same type of objects within them. They usually provide some extra functions for working with those objects and also a bit of data protection by making the contained objects themselves private or otherwise unavailable. A lot of this intrinsic functionality is provided by using magic methods.

With version 5.4.0 of PHP, came something called traits. Granted, this is a fairly new version of PHP so there’s a good chance most developers won’t be using it on a live server for at least another 25 years, but it’s still good to learn about these kinds of things.

Similar to extending classes with child classes, traits allow you to share code, functionality, and variables between objects. The difference here is that sharing code via classes only allows you to share vertically. That is, you have to create and use a strict hierarchy of classes if you want to share code with all of them. This often creates “pyramids” of classes where every class is based on some highly basic originating class. This structure can be fine, but it’s not always appropriate from a taxonomical perspective. Traits, on the other hand, allow you to share code horizontally, meaning that there doesn’t need to be any explicit relationship between the objects.