Posts

A Thanksgiving Yam Story

Image
As difficult as 2020 was, and still is, for many of us, I think we can all find something to be thankful for. We might just have to look a little harder. And do it apart. Below is an old Yam joke circulating on the internet. Those who like bad puns will enjoy it most, but I hope it brings a smile to every reader.   A girl potato and boy potato had eyes for each other. They eventually got married and had a little sweet potato, who they called "Yam." Of course, they wanted the best for Yam, and when it was time, they told her about the facts of life. They warned her about going out and getting half-baked, so she wouldn't accidentally get mashed, be called "Hot Potato," and end up with a bunch of tater tots. Yam said not to worry; no spud would get her into the sack and make a rotten potato out of her! But she wouldn't stay home and become a couch potato either. She would get plenty of exercise doing potato rolls as she was determined not to be skinny like her

Beauty In The Eye of the Coder

Image
In the book Beautiful Code, Jon Bentley describes beautiful code in a Zen-like way , where the most beautiful programs are sometimes, not there at all . In a YouTube interview with Lex Fridman -- Bjarne Stroustrup: Recognizing Beautiful Code -- Stroustrup is less paradoxical, but equally thoughtful: It's easier to recognize ugly than to recognize beauty in code. . . sometimes beauty comes from something that is innovative and unusual, and you have to sometimes think reasonably hard to appreciate that. On the other hand, the messes have things in common. I've always endeavored to write neatly indented, correct code with intelligent defaults and consistent return values, but in terms of beauty, that is a low bar. Code that runs wickedly fast can be beautiful, but perhaps that is more of a measure of cleverness. A better indicator of beauty, however, might be how well the code stands up to time. Requirements change, database fields are added, code is refactored by multiple author

Save and Restore Instance States in Kotlin

Image
When you rotate an Apple device, the internal state is maintained. When you rotate an Android device, however, the internal state is reset. To create the illusion of continuity, the developer needs to save the state before rotation, and restore the state after. That's not difficult to do, as Android provides two aptly named overrides: onSaveInstanceState() and onRestoreInstanceState(). But this does introduce a wrinkle in how to maintain design portability between the two platforms. How many other hidden differences might there be? Exploring the overrides, I found various helper functions to put and get native types such as boolean, int, double, strings, and more. The values are assigned to a key in the form of a string label. The code fragments below -- extracted from my app LuldCalc -- show examples, with special handling for enumerations because they are classes in Kotlin. Since I can't put  a class object, I extract the ordinal value -- an int -- and save that instead. S

Apple's 30% Dilemma

Image
Back in the day when Palm handhelds ruled , the major app stores were PalmGear and  Handango . While it's become common knowledge the cut Apple takes from its App Store , the cut taken by PalmGear and Handango wasn't as well known. Regardless, we developers weren't exactly happy then either. Comparing Apple to Palm risks comparing apples to oranges, but there are insights to be had. While the App Store is part of Apple, PalmGear and Handango were simply online software stores, and were not affiliated with the device makers Palm and HandSpring. Developers were free to sell elsewhere online, but PalmGear and Handango pulled in the majority of clicks. Unfortunately, these stores were as entrepreneurial as the developers and behaved like a startup -- that is, they spent aggressively for rapid growth. As a result, what started as a 30% cut slowly rose to 35% to 40%, with talk of 50%. And to make matters more painful, some developers were paid late. I soon set up my ow

Bookshelf Classic: Peter Norton's "Inside the IBM PC"

Image
I'll take hexadecimal addresses for $200. Answer: Hex B000 Question: What is the starting video address for the IBM monochrome display. I'll take hexadecimal addresses for $400. Answer: Hex B800 Question: What is the starting video address for the IBM graphics display. August 12th marks the 39th anniversary of the IBM PC , making it a good time for a nostalgic look at Peter Norton's book, Inside the IBM PC . Before computers became personal, they were large machines housed in refrigerated rooms and guarded by stern, but good wizards in the tradition of Gandalf or Dumbledore. The PC, in contrast, sat on my desk, and without a gatekeeper, allowed me to explore, experiment, and crash the machine to my heart's content. Norton served as an excellent guide, and while the contents are mostly the stuff of trivia today, the book opened up a new world for me back then. Of course there were other personal computers from that era, such as the Timex Sinclair , the

Bookshelf: The Deficit Myth

Image
Before the personal computer, there were minicomputers and mainframes. I understood them as large machines housed in refrigerated rooms and guarded by stern, but good, wizards (system administrators). The personal computer changed that. With a PC at home and sitting on my desk, the internals -- cpu, memory, graphics card, and disk drive -- became accessible. It was a revelation. Reading The Deficit Myth gave me that same revelatory feeling, although in the field of economics. Before Dr. Stephanie Kelton's book, I understood that deficits were bad, while balanced budgets were good. That is, the government should manage its money like a household: spend only what you can afford, and avoid debt. The household budget approach was relatable, and sounded right. But there were nagging inconsistencies that a household budget approach could not explain. If deficits were bad, how did they successfully fund the space race to put a man on the moon? Or pay for wars (necessary or not)? How

Post Processing: Dark Mode Reconsidered, Inefficiency Revisited, and a Linked List Reversed

Image
I first shared my enthusiasm for dark mode in the post Automate Dark Mode in Apple OS Mojave .  Not everyone likes dark mode though, and Victoria Song of Gizmodo recently wrote a light hearted essay to Stop Using Dark Mode . She made some fair points.  Color themes for light mode have been around longer and their designs have had more time to evolve; the result is superior contrast and better readability than their dark mode counterparts. I've also found dark mode limitations in Apple's Mail App. While Mail is dark mode capable, html email is rendered in light mode and the harsh contrast is painful to the eyes. Where dark mode shines is when I'm using one application exclusively such as Xcode or Android Studio. The colors are consistent, and free of competing themes, the experience is immersive and harmonious. Discussions of inefficiency continue to trend. I contributed with the post  The Hidden Cost Of Efficiency , where resiliency is inversely proportional to eff