Since Chrome is marking non-SSL sites as insecure soon, I finally got around to moving my site’s hosting from GitHub Pages to AWS. Setting up a static website using CloudFront and S3 is surprisingly easy. I’ll write up how to do it in a future post, but for now, enjoy the sweet security of SSL :)
Python famously holds as a value “Explicit is better than implicit”. This is not something Rubyists (or many functional programmers) value, instead favoring compactness or “elegance”. I believe senior developers undervalue explicit code that uses fewer features than it could. Compact code that uses many language, library, and framework features excludes people from understanding and contributing to it, and I believe this is a serious consideration when writing code. What better judge of a codebase’s maintainability could there be than “fewest concepts needed to understand it”?
I’ve been traveling to San Francisco every two months (more or less) for the last five years as part of my job. The hardest part used to be the traveling and staying in hotels (now it’s that I pack so much activity into such a small amount of time, I barely see any of my San Francisco friends any more). This is about how to make the travel and hotels suck less, and if you are currently working remotely, or planning to, reducing travel anxiety and hassle should be something you actively address.
Engineers often deride anything that’s not writing code as being not “real” work. While this diminishes the contributions of others, and is generally an unhealthy bravado, it is critical to understand the difference between activities that directly solve a problem and those that organize said activities. The later, I call “meta-work” and engineers should be very conscious of spending too much time on it.
I’ve added another “problem” to “What problem does it solve?” about serverless architectures, which I think are the future of distributed systems (though that future isn’t here yet):
The less code you are responsible for running in production, the better. Running an actual server means it’s all on you. Using virtual servers delegates some to your hosting provider. Using a platform-as-a-service like Heroku delegates yet more. A serverless architecture reduces this to what might be the absolute minimum - you are responsible for your code, and everything else is handled by the provider.
There are three big challenges: deployment, vendor lock-in, and testing.
In this month’s issue of PragPub, I have an article about Rails, and how it’s still as relevant today as it was when it came out:
What Rails taught us about agility in 2005 is still applicable today. Rails has also kept up with the times, baking in more conventions around common problems, but also adding more technology to help solve them.
At its core, Rails is still an MVC framework serving up server-rendered pages. This core supports features that developers need today, either to capitalize on new techniques in front-end development, or to allow applications to scale as needs change and become complex. Do you need to run code in a background job? Rails has ActiveJob. Do you need to push changes from the server to your users’ browsers via WebSockets? Rails has ActionCable. Do you need to have a fully-interactive front-end, using the latest CSS processors and JavaScript frameworks? Rails has Webpacker, which simplifies Webpack, which makes all that possible and easy.
And there is testing support for all of it, from unit tests to browser-based system tests, so you can confidently ship your entire app, fully tested, whenever you need to make a change.
Read more about the entire issue here.
A few people on Twitter were talking about developers that run their entire test suite only on their continuous integration (CI) server. The idea was that this was a sign of low quality tests, low quality code, or an otherwise bad process. In the past, I felt this way, and “breaking the build” (by checking in code that had failing tests) was viewed as bad. I don’t believe this any longer, and now feel like it’s a critical ability for a high-functioning team to have. Not that it isn’t important to identify low quality tests or code, but what exactly is the value of having a fast test suite?
One of my biggest learnings creating Webpack from Nothing was just how poorly the tools of the JavaScript ecosystem interact and interoperate. Many popular tools are impenetrable monolithic systems that only do half of what you need and are extensible only through dense plugin mechanisms.
The last chapter is an attempt to describe this problem in detail and offer some solutions.
I was surprised at how counter-intuitive each step ended up being—I can totally see why there are so many blog posts describing how to set it up. From a test runner that can’t run tests, to a system that supports presets, but includes none of them, I was faced with many choices along the way, but also faced with completely opaque systems whose behavior and failure modes were unpredictable.
It focuses on Webpack and Karma, which I found very difficult to make work together:
Webpack and Karma’s interoperability is completely opaque to the user. This means that you have no way to know how the tools are working or even observe them working together without debugging into the source code.
If you didn’t make it all the way through the entire Webpack site, this last chapter is worth a read.
In writing my latest book, I struggled with the JavaScript module bundler ecosystem, in particular Webpack. There are many (many) blog posts telling you how to set it up that all amount to “Don’t ask questions, just put this JSON in your project.” I hate that. I need to know why things work and what is required to get something to function.
So, I started from nothing, and added Webpack and its various friends only when my project had a real problem to solve. I was surprised just how little configuration was required, but also how painful it was, how broken the abstractions, and how terribly integrated the tools in the JavaScript ecosystem are.
Join me on the journey and you will learn a lot about Webpack, JavaScript, and why it can be so frustrating to live in this ecosystem.
During your journey through this site, you’ll use Webpack, Karma, Jasmine, Babel, and many different plugins and extensions, all to get a very basic development environment working. There will be little handwaving. We’ll add tools and configuration only when needed to solve a specific problem.
I’m not obsessed with typography, but I have a healthy respect for it. I talked about typography and source code a while back and I’d like to revisit the subject, but focus on dreaded stack traces. Stack traces happen when your code hits a situation it can’t handle, and most programming languages give you a giant vomit of files and locations that are nigh unreadable. Can we apply typographic principals to them to help us better understand why our code fails?