Skip to content

Index

  • 1 min read

The design decisions and evolution of a method definition - Ruby case study

Link: The design decisions and evolution of a method definition - Ruby case study: "Episode 01 of studying Ruby programming language design decisions, how they evolved with time, and how they look in a wider context."

Attached is a great article that dissects subtle Ruby design decisions, the trade offs made, the decisions, comparison with other languages. Here the focus is just on method arguments.

  • 1 min read

How Alexa Dropped the Ball on Being the Top Conversational System on the Planet

Link: How Alexa Dropped the Ball on Being the Top Conversational System on the Planet: "I discuss why Alexa missed the opportunity to take the lead and become the dominant player in the conversational AI market."

Here is a very interesting retrospective on Alexa's AI features and how essentially they blew their lead. Same can be said of Siri. The differnce is that it looks like Apple is doubling down and Amazon? When I say they blew the lead: Alexa was the unchallenged dominant product in the space of home voice activated assistants. There was no other. Read the story...

  • 1 min read

System tests have failed

Link: System tests have failed: "When we introduced a default setup for system tests in Rails 5.1 back in 2016, I had high hopes. In theory, system tests, which drive a headless browser through your actual interface, offer greater confidence that the entire machine is working as it ought. And because it runs in a black-box fashion, it should be more resilient to imple..."

DHH declares system tests to be a failed experiment in the attached document. This is surprising to me but then not surprising. Surprised because intuitively it seems that system tests should be better for the stated reasons. And politically because it seems that the Ruby world had accepted that unit tests are easy to write but too brittle. And system tests were more real-life and robust. But not surprised because I have always found system tests a pain to write. But I don’t have large scale experience with that so I tended to agree with the world that system tests (aka end-to-end tests) were better. So here comes #DHH to argue that system tests have failed!

  • 1 min read

Smooth Concurrent Updates with Hotwire Stimulus - Blog - Visuality

Link: Smooth Concurrent Updates with Hotwire Stimulus - Blog - Visuality: "It's time to get familiar with another part of Hotwire: Stimulus! In this article, I'll demonstrate using Stimulus to handle more complex frontend logic."

I admit I get confused by the various packages in this family of related low or no JavaScript goodies released by DHH. Hotwire, Stimulus, Hotwire Stimulus (something different, I guess). Some come with rails, some compete with each other. No matter, I love them all. I love the idea of not having to write and debug JavaScript. Here’s an article with code that shows a great use case.

  • 1 min read

Don’t Refactor Like Uncle Bob. Please

Link: Don’t Refactor Like Uncle Bob. Please: "Correction: Throughout this article, I attribute Chapter 2 of Clean Code to Robert Martin, however I was recently informed that this particular chapter was actually authored by Tim Ottinger. That s…"

A nice deconstruction of a refactoring gone bad. The article makes good points and I agree that Uncle Bob’s (tm) refactoring is not great. Oh but apparently a ghost writer wrote that chapter. Now in defense of the book, it was written many years ago and we’ve all gotten a lot smarter about what it means to write Clean Code (tm). Here’s the article:

  • 1 min read

Silicon Valley’s Best Kept Secret: Founder Liquidity

Link: Silicon Valley’s Best Kept Secret: Founder Liquidity: "Ask most venture-backed founders why they get 10x more equity than employee #1, 100x more equity than employee #5, and 1000x more equity than employee #15, and you'll get the same answer: "I'M TAKING SO MUCH RISK, IT'S SO HARD TO START A COMPANY, I MADE A BIG MOVE!!!" And"

Another reason why I believe being the founder of a well funded startup is not risky. If the startup is indeed well funded then you as a founder or employee can count on your salary for say between one and three years. No matter what revenue or earnings are, because they are not expected at the very start. Compare that with a job at an established company where layoffs can come out of nowhere and affect anyone. Not sure which is riskier … it depends … but in my opinion the startup is not clearly riskier. See the attached article for an explanation of one factor, but not the only factor.

  • 1 min read

TEO

Link: TEO: "TEO is the schema-driven web server framework native to Rust, Node.js and Python. It reduces developing time and improves developers' life experience."

Wow a brand new web framework! Where did this spring from, apparently fully formed, out of nowhere? Or am I not hanging out in the right neighborhood? Take a look at the attached site!