Browsed by
Category: Technical

Shibuya Halloween 2021 is Virtual

Shibuya Halloween 2021 is Virtual

Shibuya is trying something interesting to deal with the annual gathering of Halloween revelers during COVID. They’re making the event, concerts, fan groups, color pages, and lots of other activities free online.

You can attend events for free online and even attend the festivities in VR:

Japan has never traditionally celebrated Halloween. During the 1990’s, a bunch of Halloween loving foreigners started wearing costumes and riding the ring trains around Tokyo. Unfortunately, drunken behavior cause the police to ask the riders to disembark (please don’t be one of these ugly tourists – I don’t care how cool you think you are. It’s rude to go to another country and act like that).

Revelers soon started gathering in the neighborhoods around the train stations and the street parties grew and grew. Shibuya soon became one of the major stops for these festivities – and has grown to be the focal point. Unfortunately large amounts of trash, drunken disturbances and destruction have become all too common. Which is really unfortunate since it could be such a good chance for people to have fun and share some cross-cultural exchange.

More links:

Tengami and foldable geometry

Tengami and foldable geometry

Whenever I have free time and am looking for some inspiration, I love going over to the GDC Vault and watching the countless amazing presentations. Back in the day, one had to pay hundreds of dollars to see videos in the vault, but now they have their own free youtube channel.

In doing some research into visual styles, I ran the game Tengami from Nyamyam. I then found Jennifer Schneidereit’s GDC presentation describing how she created a engine that uses geometry to mimic the mechanical folding of pop-up books.

The geometry of fair dice

The geometry of fair dice

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.

Black Unicorn Horn Dice
Make a Netflix documentary on $70

Make a Netflix documentary on $70

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

Split-flap displays

Split-flap displays

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:

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

Magnetically Levitating Power Generation

Magnetically Levitating Power Generation

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.

8GB vs 16gb Mac M1

8GB vs 16gb Mac M1

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

Things you should never do #42

Things you should never do #42

#42 – Never re-write your software from scratch.

I have referred this article to many a developer – especially young developers – that become enamored with the idea of ‘scrapping it all and re-writing 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, however, is almost always the answer.

As Joel tells us, re-writing from scratch is one of the worst strategic mistakes, and likely one of the larger technical ones, 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 on 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. People now realize that simply 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 re-write when you can simply write one emulator and statistically end up with far few bugs, far better scaling, 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 un-patchable 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.

For 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 re-write/replacement of key functionality.

If you find out you have to do the re-write, his points about re-writing 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 re-written 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 when facing a re-write.