Your leaking thatched hut during the restoration of a pre-Enlightenment state.


Hello, my name is Judas Gutenberg and this is my blaag (pronounced as you would the vomit noise "hyroop-bleuach").


decay & ruin
Biosphere II
dead malls
Irving housing

got that wrong

appropriate tech
Arduino μcontrollers
Backwoods Home
Fractal antenna

fun social media stuff

(nobody does!)

Like my brownhouse:
   changing landscape of potholes
Wednesday, April 10 2019
One thing about a 25 minute commute over generally lightly-traveled highways is that I tend to know the route in surprising detail. I've mentioned how the roadkill suddenly appears, rots for a week or more, and then vanishes. Right now, for example, there looks to be a dead beaver on Route 209 near the railroad crossing. But the height of roadkill season is the Fall, not the Spring. At this time of year, the lingering temporary changes in the landscape mostly take the form of potholes. Like roadkill, they suddenly appear and then gradually change, though (unlike roadkill) they often grow until a highway crew comes along to do something about them. I know with precision where they all are. Right now there is a mess of shallow ones under the Route 28 overpass on Route 209 in the southbound lanes, and there are some to be avoided at the crest of the hill on Route 209 northbound between Route 28 and Sawkill Road. On the south edge of Red Hook, I swerved to avoid a patch of deep potholes that suddenly opened up across from the Stewarts on US 9 northbound. My colleague Joe was less lucky on his drive into work. He hit that very patch in his white BMW and blew out a tire, and then had to spend most of the day dealing with that headache.

Speaking of headaches: software frameworks. The whole idea behind them is to make it so us developers don't have to keep reinventing the wheel. But all of them are hampered by the vision of their builders, who were trying to solve their particular problems. But in the real world, our problems are different, sometimes subtly. A lot of my specific needs often, when described, are the kinds of things that people less familiar with them would, on hearing about, respond to by asking, "why would anyone ever want to do that?" Consequently, my use-cases don't often map very well on someone else's framework. The closest match to my needs and a framework I've had to work with was the proprietary framework made by Jonathan Skinner for Mercy For Animals. The technology was old (hell, it wasn't even object-oriented) but it was infinitely flexible. and I could make it do pretty much anything I wanted without resorting to ugly workarounds. Working with Angular, with its ugly syntax and baroque internal communication style gives me a background level of malaise that I don't often get when working in a programming language. As I've said before, it solves the easy problems that don't really need to be solved while making anything truly interesting impossible (or, short of that, extremely difficult). A good example of this was demonstrated when it came time to implement more of the esoteric features from the Python-based app that I am migrating to Electrron (which, in my app, uses an Angular frontend and a Node.js backend). The original Python had some class methods that acted to override methods in unrelated classes under certain circumstances. This may or may not be the same thing as "monkey patching," which itself may or may not be an acceptable programming practice. All I know is that this method overriding was not happening in the normal object-oriented manner involving class inheritance. That form of method overriding is like evolutionary descent-with-modification. The kind the Python app was doing was more like one species performing genetic engineering on another. Though I needed things to work the same way in the Electron app, Angular (or perhaps Typescript, the fancy form of Javascript Angular uses) absolutely wouldn't allow it. When I would try to use a method in one class to replace a method in an unrelated class, I'd get errors telling me that the method to be overridden was not a property of the parent. And when I dumped the parent class to the console, it was presented as nothing more than its constructor method. Well, that sucked, but I didn't have the time to figure out how to make this work in proper Angular. Fortunately, my app has a whole library of functions that are still in Javascript and that Angular is happy to use. These functions, it turned out, could be dynamically overridden by Angular code. So what I ended up having to do was make the Angular methods to be overridden into wrapper functions that actually called other functions in that Javascript library. Then, when I needed to override the functionality in the Pythonic way, I would just have Angular override the function being called in that Javascript library. All of this made a mockery of object-oriented best practices, but it was what I had to do to get the job done. This (and other) experiences give me the feeling that Angular (and other frameworks) are the cause of more hackish workarounds and unreadable code than they are preventing.

At some point this evening I transitioned from ephedra tea (which I drink only rarely) to kratom tea (which I now drink several times a week). The two have almost completely opposite effects on sex drive and appetite. Fortunately, I had a great appetite when Gretchen came home from the bookstore and made vegan ravioli with asparagus. That was what we ate as that repellant James Holzhauer Jeopardy champion won a record $110,914 in one game. After seeing his toothy grin one too many times, I told Gretchen that if my teeth looked like that I'd go to a dentist to see if they could be darkened somehow.

For linking purposes this article's URL is:

previous | next