Matt's Homepage

It turns out that the geometry behind fair dice is more interesting and complex than you might first guess.

Professor Persi Diaconis discusses all kinds of interesting properties of fair dice as well as his interesting paper on the topic.

Getting fair dice for any number is very hard, if not impossible. But it turns out level-up dice have a unique ‘unicorn dice’ that you change the end cap and then roll in a circle. They’re pretty overpriced at $110 for a whole set – when a regular set will cost you $5, but a dice in this configuration can get you a fair roll for any value range.

Paul E.T. shows us how easy it is for anyone to make a Netflix quality documentary. How cheap and how easy? Using just a few basic photography tools, some stock footage, and basic editing skills on software available to almost everyone – Paul shows us how you can make your own documentary that rivals anything you’ll see out of Hollywood and Netflix.

With such a low bar of entry one should be very critical of documentaries as a information source – no matter how slick it looks.

I’ve sure notice more documentaries – is it because they’re becoming the reality shows of today? One of the biggest reasons reality shows caught on may be the same reasons you are seeing more and more documentaries. Namely, they’re now super cheap and super easy to make (orders of magnitude cheaper than a regular TV show).

Some of my fondest early foreign traveling memories were going to places in Europe and traveling from city to city where the train and airport arrivals/departures boards used these amazing electro-mechanical split-flap display boards. The last place I saw one still in use was at Frankfurt airport in Germany a year or so before covid (and I believe it’s still there):

Scottbez1 walks us through how they work with a demonstration of his single-digit Arduino-controlled display.

Even better, all the parts, software, 3D print resources, and information you need to make your own can be found on his github page: https://github.com/scottbez1/splitflap

But be forewarned, his estimates run around $200 to make only 4 of these wonderful digits.

Also, there are now companies around that will make these displays for you:

• https://www.oatfoundry.com/split-flap
• https://www.vestaboard.com/

But be ready to pay $2800 for even a basic model. This guy does a decent job summarizing the current offerings.

Tom Stanton, maybe unintentionally, walks us through the entire industrial revolution’s worth of power generation technology in under 15 minutes as he demonstrates his desktop toy sized magnetically levitated flywheel. He then uses it to generate AC power for some LED’s and motors. Again, maybe unintentionally, he educates people on how power is generated today from turbines. The technology is the same whether it is a hand crank, steam from a nuclear reactor, or a spinning windmill.

Bonus points for the most clear explaination of a full bridge rectifier I have ever seen.

I dabble around in Mac development semi-regularly, and was recently looking to update my Mac Mini to an M1 mac. Finding real data on whether you should buy the 8gb or 16gb version has been difficult. Despite many articles, very few do this kind of excellent side-by-side comparison.

I will say that some of the comparisons done early in this side-by-side video aren’t quite representative. Just opening an app and switching tabs isn’t super representative of performance since a good stack will just cache the image. To do a real test requires you make the app render something: scroll, select a dialog, or do a minimal interaction with the app to see if it snaps back to life or is just showing a static cached image (like the iPhone often does).

#42 – Never rewrite your software from scratch.

I have referred this article to many a developer that has become enamored with the idea of ‘scrapping it all and rewrite from scratch’. It’s a phase that almost every young developer goes through when they come into an existing codebase. Senior engineers have a duty to explain why re-writing isn’t always an option and how to make that choice. Refactoring, or a organized series of refactor stories, however, is almost always a better answer.

As Joel tells us, rewriting from scratch is one of the worst strategic mistakes and likely one of the larger technical mistakes you can make. He wrote this in the first dot-com boom in 2000, but it’s even MORE relevant today in the fast paced entrepreneurial world where time to market is one of the critical factors to the success of your idea. Even to the point that speed is the ONLY critical factor and the only requirement is that you just need to get it working once.

Joel Spolsky knows his stuff. He’s a chairman, founder, developer and entrepreneur that created Trello, Glitch, FogBugz, worked at Stack Overflow, Microsoft Excel, and numerous other accolades.

Give his excellent article a read.

Further musings

Are there legitimate times you need to re-write from scratch? Possibly, but I think they are rare and getting rarer – refactoring is almost always a better solution unless you are radically changing the direction of a product. A good lead should take a step back from the desire for the cleanest code and ask what’s the right decision given the entirety of my engineering and business constraints.

Legitimate cases I can think of: radical change of direction in your product, dependent hardware/OS goes end of life, security issue in component you can’t update, or due to licensing issues. Then you are likely facing a legitimate re-write – MAYBE. And that maybe gets bigger each year.

In the case of end-of-life hardware, one notices that compute overhead is increasing every year. Many realize now that simply virtualizing and/or emulating old hardware is MUCH better, faster, and cheaper than re-writing/porting. Apple is demonstrating this with Rosetta 2 on their new M1 chips. Intel did this with it’s mobile emulator. There’s literally hundreds of game console emulators. Why rewrite when you can simply write one emulator and statistically end up with far few bugs, far better scaling of impact, and hugely faster time to market for a whole product line?

Virtualization has also become a first class solution for OS/software stacks that no longer have support. One should ask if they can simply slap the component into a virtual machine. This might work if the system has an issue like an unpatchable security hole or you need new functionality on a system with no more support. You might be able to wrap the component in a virtual machine and solve the security or feature issue in the host and pass through existing behavior. This keeps production going and you can replace the system at your leisure.

Licensing issues can be the one real killer. This is why it’s so critical to evaluate usage licenses strategically before you first pick up a SDK/piece of software and use it. Properly evaluating the IP and licensing of your core packages is a critical first architecture task. There is no greater disaster than finding out a critical package has a business model breaking licensing requirement right before you ship – and this is one case in which you almost guarantee a painful rewrite/replacement of key functionality.

If you find out you have to do the rewrite, his points about rewriting are true for these forced cases too. You’re going to spending a TON of time and money to get back to where you already are today. Strategically, this is going to crater all forward momentum of your business and opens you to now being in a race with any competitor also starting from scratch. Even worse, once you have your rewritten solution, you’re also going to have to fix bugs and edge cases you had already solved, or never even knew about since they were covered by the old architecture’s inherent properties (this is another reason why people that argue “the code is the documentation” are patently wrong).

So, to add to his article, I’d add emulation and virtualization as further solutions to avoid a rewrite.

3D printed houses aren’t anything new; but still on the cusps of practicality. Hadrian X has created a robot that can cut and lay the bricks of a 3 bedroom 2 bath house in 2 days; working around the clock and in all weather conditions. Limitations still appear to be that this just places bricks – it doesn’t seem to do electrical, plumbing, ducts, initial foundation/etc. But this is just one more step forward into complete automation of construction. Likely something we’ll see by the end of our lifetimes.