I love static websites. And that love has only grown over time. I started my career building dynamic websites with database backends and those are great, but they require a lot more mental energy to build and secure. Static website, on the other hand, require very little effort and are very resilient to being attacked. So this article explains how I build static websites these days. It may not be what you use and that’s fine, we can both celebrate our differences. ...
As you can probably tell, the site has been redesigned for 2020. It has been 7 years since I made the initial design and I felt it was time for it to be refreshed, as well as provide a better experience for readers on mobile devices. I used Bulma for the CSS framework and VueJS for interactivity. I really like working with Bulma, I find it has a more simple grammar than Bootstrap and is more tweakable as well. The elements and components that can be made aren’t as feature-rich as Bootstrap, but overall I find that I don’t need them for what I do. I used Bulma first on my resume and since that was a breeze, I have started using it on other projects as well. But I held off on using it on this website as the original design wasn’t my best work, so I had to first bush-whack through bad Sass and HTML. Thankfully, ripping out Bootstrap and replacing it with Bulma was so easy that I got it done in 4 hours. ...
One of the things that I dislike seeing in an application’s database architecture is the use of booleans. They do not convey enough information to any party to be meaningful, other than to ask a question that expects a yes/no answer. Often, questions such as those as a follow-up question that the field cannot answer. For example, in many databases I see the following fields on a User model: User ==== id primary key username the user's username credential password_encrypted authenticates the username ... other fields ... enabled true if the user is active, false otherwise When a user has been banned for doing something inappropriate, an application simply sends this query: ...
Not enough people give careful thought about ensuring uniqueness across systems when they design a solution. This goes doubly so for off-the-shelf (OTS) software packages. And if the design isn’t well thought out, it is going to be difficult to ensure uniqueness when doing any data migrations. Granted, data migrations are an art more than they are a science. There are always edge cases and invariably something goes wrong that nobody thought about. This is why testing a data migration multiple times should be built into any project plan (and given an extremely large buffer in the budget). ...