Herein you’ll find articles on a very wide variety of topics about technology in the consumer space (mostly) and items of personal interest to me.
If you’d like to read my professional engineering articles and whitepapers, they can be found at Control System Space
Being that it’s the middle of summer in my hemisphere, after a hard days work in the yard a nice cold frozen drink is always well received. Recently the pricing war between McDonalds, Hungry Jacks and the old-faithful 7-11 has led us to an over-supply and low prices of frozen drinks. All that’s lovely for consumers, and if you’re keenly interested in the zilch-sugar (sugar-free) options then 7-11 is the way to go (or if large amounts of sugar don’t worry you, I still think 7-11’s Slurpees have more/nicer syrups)
They offer three primary sizes, but if you actually measure the cost per volume it shows how 7-11 are making their money: they want you to upgrade to the bigger drink.
Based on the above therefore I’d suggest that if you’re REALLY thirsty, getting x2 Large drinks is the clear winner. Otherwise stick to the $1 size and save your money.
Oh yeah, and don’t drink it too quickly either…
Originally Drafted 13th October, 2016
We’re lazy creatures. That and things cost money. When things take too much effort or cost too much money, we don’t take advantage of them. Only those people with enough spare time or money can do them. I first came across this phenomenon when studying traffic engineering. Widen a freeway and the amount of traffic it conveys will increase to utilise that new capacity. The newly accessible capacity of the road becomes quickly known by local residents that previously took public transport, rode bicycles, walked or just didn’t travel at all, and then they decided to utilise this additional capacity. The opportunity to travel either more directly, in more comfort or more quickly than the alternative drives the opportunistic behaviour to utilise that additional capacity. Theoretically it should be possible to build a freeway with an extremely large number of lanes that has capacity that far outstrips the physical quantity of vehicles that could ever use that route between two set locations, even including for external visitors. The sheer cost of doing so generally precludes this from ever happening on a macro scale but the limit still exists. Hence there’s a point at which increasing accessibility reaches a point of diminished potential such that it is unlikely to ever be exceeded.
A more popular example I came across recently relates to watch bands on an Apple Watch. The watch itself is quite expensive, however unlike many other watches in the world, it may have its bands easily replaced in less than a minute when the wearer needs to exercise, change to a dressier outfit or go off to work. Changing the band changes the appearance, feel and usefulness of the watch without having to have a second watch as was previously the tradition: two watches, one for normal day use and one as a dress watch. Replacing bands on a traditional watch is a cumbersome, frustrating exercise but with this watch in particular that’s no longer the case. As changing the bands becomes more accessible, the possibility of changing bands becomes easier. As cheaper alternative bands become available, this further drives accessible choices for more people. Of course people will eventually reach a limit whereby they have more than enough bands to cater for every circumstance they personally desire, at which point the maximum potential is exceeded once again.
A final example is changing code in mass-deployed devices. When I was starting out my career software updates were handled by physical ROM ICs, that were attached by sockets to the motherboards of the control cards in the field. Changing out the firmware was a manual, slow, annoying task that was very expensive. Many locations didn’t have a network connection of any kind and wireless was very uncommon and even less common for data connectivity so this was just accepted as reality. At time progressed and the internet became what it is today, with mobile data networks becoming wide-spread, there was a more and more accessible data path to end devices for manufacturers. Over the air updates then became the preferred method of fixing problems and this accessibility drove opportunistic updating of end devices. This seems like a good thing at first with manufacturers able to correct problems even ofter their devices had left the factory, however it drove manufacturers and engineering companies down another route: minimally tested software. As the speed to fixing bugs after the device shipped improved, management circles pushed the key features (heavily tested we hope) out the door with the devices quickly, leading to many features being far less tested and requiring future OTA updates to be applied. Provided these were low-impact bugs then that’s probably a good trade off but end users don’t always see it that way.
As always no one complains about good software, they only complain when it breaks and just because you can ship something today less tested with the aim of “fixing it later” doesn’t mean that you should. The opportunity to quickly fix problems is tempting but rigorous testing and qualification will generally save time and money in the long run. The only question to ask to ponder is whether the availability has driven opportunistic thinking and if it has, what opportunistic cost will you incur for it? Opportunity cost cuts both ways.
After a lot of deliberation and consideration I’ve decided it’s time to refine (slightly) where I keep what on my sites. In the past I’ve maintained two primary web-presences: TechDistortion and TEN. The problem was that I didn’t feel like grouping all of my podcasts together under a single site in 2015 made sense, so I kept older pre-TEN episodes of shows under TechDistortion, with only newer episodes kept on TEN. The other problem was that TD had blog posts on a wide variety of topics including Statamic guides, cartooning (it was a brief fancy for a while), tech-related blog posts and engineering-related blog posts.
Under this grouping, someone visiting TD would find podcasts, articles/posts on a huge variety of topics and a few references to TEN, and someone visiting TEN would find podcasts and the occasional TEN-specific post, but miss some back-catalogues of shows. Based on years of feedback and with the excuse of migrating away from Statamic, I’ve finally finished re-organising my online web miscellaney as follows…
The Engineered Network TEN will now be the sole repository for all podcasts I’ve ever made, past and present with a new archived section that contains all past episodes of shows long since ended. The hosts and guests list has been extended to include all shows, past and present. I intend to do more with TEN in the future including transcriptions and transcription search which I am determined to complete. (For those receiving the NewsLetter, you already know the sad story there…)
Control System Space
A new site launched in August this year, it’s focus is completely engineering-specific articles called Control System Space. (I’m going through a ‘space’ phase clearly…) In truth it was my first real attempt at a Hugo website and since then I’ve learned a lot. I’ll probably revisit/tweak/refine it in coming months but the intentions behind it are three-fold:
- Be a repository for professional White-Papers, supporting independent knowledge-sharing in Control Systems Engineering
- Remove J-O-B “job” related posts from TechDistortion and keep them together in a single place
- Be a professional-facing outlet that I can direct those to with whom I work with or the greater CSE industry
As a litmus test I posted two articles on LinkedIn, and distributed links within the organisation both in and beyond the Automation Systems Team at work and they were well visited and very well received. In this way engineers that are less interested on my thoughts on Apple or Microsoft will see the most heavily polished, relevant articles for them.
TD will remain for blog posts however there will be no podcast episodes and no engineering-specific articles there any more. In addition the whole site has been completely redone in a newer darker-high contrast view with all articles merged into a common article feed.
It’s been an interesting journey from Static (1996) to Dynamic (WordPress 2000s) to Statmic (2013-2018) to Static again (Hugo 2018-?) but with everything I’ve learned along the way, the tools we use aren’t always as important as the content, but with Hugo my life is easier, site maintenance is easier, sites are more responsive and reliable and that should leave more time for content. And now with the content hopefully more logically grouped by type and audience, anyone visiting will be more likely to find exactly what they’re looking for.