Seb De Deyne
During his lightning talk at Full Stack EU, Bram Van Damme mentioned the rule of least power.
The rule of least power was described in an essay by Tim Berners-Lee back in 2006.
When designing computer systems, one is often faced with a choice between using a more or less powerful language for publishing information, for expressing constraints, or for solving some problem. This finding explores tradeoffs relating the choice of language to reusability of information. The “Rule of Least Power” suggests choosing the least powerful language suitable for a given purpose.
This is a useful principle to follow for the web because less powerful languages fail better.
Forgot a closing tag in HTML? There’s a fair chance the browser will just fix it for you.
Did you write an invalid or unsupported CSS rule? The browser will ignore the statement and parse the rest as intended.
Read the full essay on w3.org.
Back in 2003 when I was still in elementary school, Dave Akins wrote a list of laws to abide when building a spacecraft. I’m not planning to build one of those any time soon, but there seem to be many similarities with web development. A few examples:
- Engineering is done with numbers. Analysis without numbers is only an opinion
- Design is based on requirements. There’s no justification for designing something one bit “better” than the requirements dictate
- Don’t do nuthin’ dumb
Here’s a good one te keep next to your desk, and consider yourself lucky next time you ship a bug to production.
- Space is a completely unforgiving environment. If you screw up the engineering, somebody dies
Read all 44 laws at their home on spacecraft.ssl.umd.edu.
This was originally a lightning talk at Full Stack Europe 2019. You can watch the video on their YouTube channel.
In the 4.5 years I’ve been a developer at Spatie, over 200 packages have been built and released by our team. I’ve done quite some authoring and maintenance over the years, and I’d like to share 8 actionable tips on writing and maintaining open source software without going insane.
When I write a library that’s going to be used by others, I strive for a gentle learning curve. When someone reads code that uses my library, I want them to understand what’s happening without reading a bunch of documentation first. I tend to keep my API’s as explicit as possible, and try to stay away from odd or foreign notations.
My colleague Brent is writing a library to deal with date & time periods in PHP. There was a discussion whether a period’s boundaries should be included in the range or not.
Maintaining a number of open source projects comes with a number of issues. Reporting a good issue will result in a more engaged approach from project maintainers. Don’t forget: there’s a human behind every project.
In a recent Design Details podcast, Guillermo Rauch (@rauchg) shares his thoughts on the web, design, the value of code, type systems, cryptocurrencies and much much more.
I have a lot of respect for Guillermo’s philosophies, and what he’s building with Zeit. An early quote from the interview (paraphrased):
I’ve always had this passion for the hyperlink. My whole thesis is everything that has not yet been hyperlinked, will be hyperlinked. If we step back and take that thesis a little further—you look at GitHub and they but a hyperlink on everything. They put a hyperlink on every per-character diff of your codebase. Every line of code. Every changeset. Everything.
Listen to the full podcast on Spec.fm.
One of the hardest (and sometimes frustrating) tasks in a programmer’s day-to-day workload is naming things. When I have a hard time finding that perfect word, I generally wind up in one of two situations:
- I have a plausible name in mind, but I’m not entirely satisfied with it
- I have no idea what I could possibly name it
Luckily, there are tools out there that can be of help.
We just open sourced our company guidelines site! We previously kept the contents in a private wiki on GitHub, but I’m glad we finally put the time in giving the contents a real home.
Like our docs site, the content is stored in markdown files, which can directly be edited on GitHub. The site deploys whenever something’s pushed to the master branch.
As for why we decided to open source it all…
This site contains a set of guidelines we use to bring our projects to a good end. We decided to document our workflow because consistency is one of the most valuable traits of maintainable software.
The contents of this site exist for ourselves—more importantly, our future selves—and for giving future collegues a reference to our way of doing things and their quirks. The guidelines cover workflow, code style, and other little things we consider worth documenting.
The guidelines are available on guidelines.spatie.be.
In a recent Twitter thread, Sebastian McKenzie (Yarn and Babel author) shared his thoughts on the current state of open source. This tweet stood out for me (and he later ironically dubbed it his “most thoughtleader tweet ever”):
Revel in fragmentation and duplication because without it there’s stagnation and it stifles innovation.
When someone shares their latest pet project library, it’s often met with responses like “What a waste of time, you can already do this with library X!”.
There’s no need for justification here. Maybe the author wants something that fully matches their use case instead of the 80% that library X does, maybe they want a different internal architecture. Maybe they have bigger future plans in mind, or most importantly, maybe they just want to experiment, learn, and have fun.
Read the entire thread on @sebmck’s Twitter.
Dynamic languages allow us to pass anything as a parameter without requiring a specific type. In turn, this means we often need to handle some extra validation for the data that comes in to our objects.
This is a lightweight post on handling your incoming values effectively by normalizing them as soon as possible. It’s a simple guideline worth keeping in mind which will help you keep your code easier to reason about.