-
The REPL: Issue 65 - January 2020
The No-Code Delusion
Alex Hudson writes a post tackles the idea that soon, we will be able to produce software with significant functionality that doesn’t require coding. I agree with author’s conclusions: The goal is probably a pipe-dream that has been oversold. I’ll add that I’ve been the block a few times, and seen that software generated without change control quickly becomes unmaintainable. Back in the day, MS Access allowed power users to deal with data in a much better fashion than excel files. However, evolving them was very painful.
3 ways Webpack surprises web developers
I wish I had read Ross Kaffenberger’s post 2 or 3 months ago, when trying to use Webpack in a brand new Rails 6 application for the first time. I was especially confused how Webpack expects css dependency declarations in javascript.
A forty year career
In is an inspiring post by Will Larson, discusses career growth in software engineering. He divides the area of focus into Pace, People, Prestige, Profit, and Learning. Growth in different areas comes at different times. Like in finance, investing early brings compounding gains.
-
Book Review: SQL Performance Explained
SQL Performance Explained
by Markus Winand
-
Abstractions With Database Views
Wikipedia defines a software abstraction as:
In software engineering and computer science, abstraction is… the process of removing physical, spatial, or temporal details or attributes in the study of objects or systems to focus attention on details of greater importance; it is similar in nature to the process of generalization;
A database view can provide a useful abstraction; a concept that represents something in a domain. Recently, I had the opportunity to do use a view to create an abstraction, to represent data that is missing from the database.
-
Deployments With Schema Migrations
Deploying code that depends on database schema migrations successfully requires putting some thought into when to run them during the deployment. This post develops a framework to reason about it, through analysis of a specific code example and multiple kinds of deployments. While the example is specific to Ruby on Rails, the lesson carries over to any similar web framework. -
The REPL: Issue 64 - December 2019
Git from the inside out
In this essay, Mary Rose Cook explains how
git
works, focusing on the graph structure that underpins it and governs its behavior.git
is a powerful piece of software, and digging into how it’s designed thought me a lot.Code less, Engineer more
Liz Fong-Jones writes about how effective software engineering teams become more effective: Writing less software. The premise is that the focus should be on the impact of the work, not how much code we write. Build what you must, buy what you can, and write it all down. Custom software should be a last, rather than first, resort.
A lot of this article resonates with me, especially the part about writing everything down. I’ve come to believe that documenting how and why you made a decision is as important as the decision itself. There will come a time when another engineer will ask, “Did you consider X or Y?”. The decision record will answer that question, and eliminate much bike-shedding.
Your Makefiles are wrong
Jacob Davis-Hansson shares his strong opinions on writing Makefiles.
make
was obscure to me for a long time. Its not common knowledge among rubyists, but I’ve come to appreciate it more as a generic build system, especially for file-oriented tasks. In this post, Jacob explains his preferred defaults. I found the use of sentinel files particularly useful.