Attached is a handy site for creating templates for boxes and other containers. There are numerous of these. But this one is pretty nicely done.

The attached article takes a fairly contrarian view, basically advocating that all ruby methods should be public unless they have side effects. I can't say I agree with this, but his analysis is a good read and has some good insights.

Attached another huge collection of resources relating to robotics. There are some other libraries like this. This makes it difficult when you are searching for one thing or another. Still I thought I would include this here because this is a goldmine!

You might find something useful in the attached article. The big one for me is the explanation of what the -m flag does.

Attached is an insightful article showing the craziness of the government using apple messenger as the basis for going after apple for anticompetitive behavior. Put in historical context, it makes no sense!

The attached essay by Paul Graham gives his views on how someone can think about finding the right project to work on. Not a job but work that is their own. I love this quote: “What are you excessively curious about — curious to a degree that would bore most other people? That's what you're looking for”. I’m personally familiar with “a degree that would bore most other people”.

Quick glance at this site gives me the impression that this is a plausible alternative Wikipedia for less exhaustive explanations for how stuff works.

The attached article has some good advice regarding goal setting, strategy and prioritization.

The attached article describes an org structure apparently originated at Amazon, called “single threaded owner” or STO. In a company with multiple products, one common setup is to have separate dev, pm and design groups each covering all products. STO says to have a separate, single manager for each product, the STO. Interesting idea.

The linked article is most interesting to me because I know Jim Storer. He’s a colleague at Brandeis University.

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.

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...

This is for you #astronomy geeks out there. A package containing a bunch of technical algorithms used in astronomy. If you’re writing the next best solar eclipse automation app, this is for you!

Look at this interesting graph showing code “survival” over time. It reflects an almost too “textbook” pattern, with older code getting refactored out of existence. The chart comes from the tool linked here.

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!

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.

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:

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.

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!

The attached article shows nice code examples on how to put arrows pointing at specific points in your graph