Friday, July 29, 2016

There are two kinds of programming experiences.

One is where you find yourself having gone off on tangent after tangent, each time seeing and learning something super cool that you want to get around to adding/using in your development. You feel smarter, more powerful, unleashed, ready to build anything.

The other is where you find yourself having gone off on tangent after tangent, each time trying to figure out how to get something to work at all, something that should have worked out of the box, or at least had documentation that didn't suck. Like, x doesn't work so then you read about it and somebody says use y to solve that problem so then you try to get y to work but then etc. ad nauseum. You feel like a whipped dog, you want to quit and become anything but a programmer in life.

You can probably guess which category I'd put JavaScript in.
Of all the horrible things about the JavaScript ecosystem, one of the most glaring wtfs to me is that, apparently, even the ES6 module spec tells me I have to hard code the paths to libraries I want to include.

Thursday, July 28, 2016

I don't generally live in the world of JavaScript, but one cannot get away from it so I do try to catch up and dabble now and then. I have to say that to date I have never seen a JavaScript environment that was actually really any good by my predilections/standards. The core language is really crap (who cares if it was crap because it was created under extreme duress, the fact is it is crap) and the lack of a controlling centralizing body with sufficient sway means that anything layered on top of it just leads to a living hell in my opinion e.g. https://duckduckgo.com/?q=browserify+flow+import+export+"may+appear+only" as one random example I am wasting my precious life on this evening. There seems to be a lot of good intention out there in the JS community, but the sum total of it all is a minefield of vaguely in/compatible, under documented, rapidly changing, overly complex, overly flexible, overly fragile stuff. I personally have yet to see any way to manage JavaScript in any way that isn't junk.

There's no particular answer anybody can come up with that I can see, either. It is a horrible situation and the lock-in is just insanity. Gosh, maybe if we actually cared about software development we would all agree that JavaScript must not cannot never ever not ever be used for anything. We would disable it and delete it everywhere. We would demand that all browsers and all web sites use... something else. Oh, uh, but what would that something else be? Yeah, inevitably it wouldn't work out well because nobody could agree, and whatever it was would suck too and not be at all what I prefer in programming languages and ecosystems.

Do you really wonder why the aliens are staying the hell away from making contact with us?
I hereby claim a "citizen's patent" (like a citizen's arrest) on the concept of having not just a simple boring mere touchscreen device, but having a lickscreen (or uh tonguescreen) device. It won't respond to finger or stylus swipes at all, only to tongue lick swipes. (Yes, kicks the Tinder a different experience around.)

Ok, I hereby also put the idea into the public domain.

So there.

Saturday, July 16, 2016

news flash: shopping online at bricks and mortar companies still sucks absolute feces.

even at tech store web sites.

Wednesday, July 13, 2016

Reading about airliner incidents and accidents, I have a few humble suggestions for shoring up the problems that are still encountered.


  1. hypoxia
    1. In-cockpit cameras recording pilot's use of oxygen masks when required by rules/regs/laws. It is human not to don the mask, I get it. But it needs to be done. Review the video after every flight (and I do mean every flight) and if somebody didn't do it right then gently reprimand/teach/demote/remind/urge them to do it. Over time we can hopefully train everybody to really truly don the masks when it is right to do so. (Of course, the masks and tubing and valves and all that can have trouble too, so there should be pre-flight checks for them where the pilots actually use them during taxiing.)
    2. The autopilot should be able to bring a plane down to a less depressurized altitude if it detects a bad pressure situation. This feature should possibly be something that ground control can remotely invoke. Yes, I grok the security concerns.
    3. The autopilot should be able to land the plane at an airport if need be: if it doesn't get input from pilots that makes sense (the pilots should be quizzed every 25 minutes with a random question that a non-hypoxia-impaired person could easily answer); if the pressure goes wrong; if told to by ground control.
  2. data
    1. There is apparently an issue where airplanes don't really automatically report in often enough. It is expensive. It can be thwarted by the plane's satellite antenna being blocked (e.g. if things have gotten so bad the plane is inverted). It can be turned off (it should not be able to be turned off ever for pete's sake). So I suggest that a peer-to-peer system be implemented to complement the satellite one. Each plane will more frequently broadcast a minimal squirt of useful telemetry about itself. All other planes that can pick it up will record it. All that data will be automatically uploaded over WiFi as soon as the planes land.