naildrivin5.com

In the imagined Timeline Programming Language, there are some unusual restrictions on the type of code you can write. I thought might be worth seeing if they can help us with real code. I find that when you apply constraints to your work, you often get forced into novel solutions, and occasionally even superior ones. So let’s take Timeline’s restrictions on expressions. In Timeline, you cannot have a compound or nested expression, and the only thing you can do with an expression is assign it to a variable. You cannot use them in control structures, return statements, or method invocations.

I gave a talk at Pittsburgh Tech Fest that I’d been wanting to do for a while, which is a talk about how to program a time machine and what the programming language for it might look like. I re-recorded the talk.

Rails Conf just posted my talk from the conference on Database Design for Beginners. If you want a 40 minute intro to database normalization with practical examples and almost no mathematical notation, this is the talk for you.

Brutalist Web Design Guidelines now support dark mode! If you are using a system that supports dark mode (e.g. MacOS) then the site will show you a different theme with less sun-blasting white background (see image below). I’m viewing this as an accessibility issue, so right in line with the ethos of Brutalist Web Design. Some users need a darker theme or want to have a less bright experience on their computer.

This is likely only supported in Safari on later MacOS, but it’s activated by the media query prefers-color-scheme: dark. Since the site uses Tachyons, I chose to override Tachyons’ color styles rather than create meta styles like “background” and “text color”.

@media (prefers-color-scheme: dark) {
  .bg-near-black { background-color: #eeeeee; }
  .bg-near-white { background-color: #111111; }
  .black { color: #ffffff; }
  .dark-gray { color: #CCCCCC; }

  /* and so forth... */
}

I’m speaking at RailsConf, and the beta of the next verison of the seminal Agile Web Development with Rails is now out in beta.

My contribution thusfar was a chapter on ActionMailbox and ActionText, which I enjoyed learning about and would likely use on a new Rails app if I were building it today. If you want a great intro to Rails, buy this book!

I’ve updated Webpack from Nothing to use Webpack 4. I also ditched Karma for Jest, and I’m not sure if that was the right call, but my opinions of Webpack haven’t change, really. While it does work, it has terrible ergonomics and its behavior is still just as opaque and unpredictable as it has been.

I firmly believe the JavaScript community would be better served by small interoperable tools that communicate over a well-defined protocol, instead of the half-monolithic, plugin-ridden systems that exist now. Webpack isn’t unique here. That all said, the docs for Webpack have gotten better and most of what’s documented does work as advertised.

Most websites are a mess of decoration, hijacking, dark-UX, and general chaos. Few designs serve the needs of the user. One way to do that is to embrace websites for what they are, by adopting a form of brutalism for web design:

• Content is readable on all reasonable screens and devices.
• Only hyperlinks and buttons respond to clicks.
• Hyperlinks are underlined and buttons look like buttons.
• The back button works as expected.
• View content by scrolling.
• Decoration when needed and no unrelated content.
• Performance is a feature.

If every website adopted these guidelines, the web would be fast and readable, our batteries would have much power at the end of the day, and we’d all be a lot happier.

While I was not the first technical hire at Stitch Fix, I was early enough to make a lot of technical decisions that have had long-reaching effects on what is now a large engineering team of over 100 developers at a public, profitable company. Over that time, the good decisions were almost always about being consistent, and the bad ones where the introduction of arbitrary inconsistencies.

Curious about Bitcoin and blockchains, I read the original paper, and documented what problem a blockchain solves, and if it’s of any use outside decentralized digital currency.

At its core, the blockchain concept described in the Bitcoin whitepaper serves as an immutable trustworthy ledger.

The site walks you through this problem step by step, then applies it to a non-currency use-case.

As I mentioned previously, non-SSL sites are heading toward being marked as security issues by browsers. If you want SSL and full control over your website, including a top-notch CDN, AWS provides the tools you need, and it’s not too hairy to get going. Considering what a nightmare anything SSL usually is, AWS makes it as painless as can be, as long as you are willing to get your feet wet with some infrastructure, and do a bit of manual scripting.