Last night, while attempting unsuccessfully to acquire sleepytimes, I heard a loud bang. This was quickly followed by the fomf of the power going out, and a short while later by the beeping of battery backups now without power.

Naturally, the first thing I did was go to shut down my computers. My first hint that this was more than a nearby transformer blowing is that my internet was out. My end is, naturally, well powered, but apparently my ISP does not provide battery power at their end, and their end was also without power.

Computers safely shut down, I wandered outside to see how widespread the problem was. The neighbors were without power. The streetlights, without power. I look up and down the street, and the neighboring blocks are, you guessed it, without power.

This can only mean one thing: something at the nearby substation blew.

So, naturally, I wander in the direction of the substation. On my way, I run into a police patrol. They don't stop me, but they pause briefly as they drive by to think about it. It's been maybe ten minutes, and they're already patrolling the neighborhood—a pretty impressive response time, though it seems weird that they'd respond to that at all.

A little bit later, I see some firetrucks. Nothing was on fire, so I have no idea what they were responding to, but okay. I guess they're out for the power outage as well? Well, that or they're breaking into the auto-parts store. I can't really tell.

The power company isn't at the substation yet, but that's not surprising: in all likelihood, some poor lineman has to wake up first.

So I wander around the neighborhood, to explore it in its unlit, silent glory. And it was awesome! No streetlights burning bright (the city has been slowly replacing the yellow lamps with bright blue LEDs, and if the yellow ones weren't bad enough the blue LEDs are awful). The usual ever-present hum of air conditioners was gone. And in spite of the streetlights being out, there was plenty of light to see by—though the moon being only a day or two off from full certainly helped with that.

Still no power company at the substation. But I do notice something: the nearby stoplight is blinking red. It was affected by the power loss, and has degraded itself to a four-way stop. Fascinating!

I turn around to head home, and am struck with an idea. So I wander several blocks over to the retail shops, and explore an unlit street, full of shops lit only by their emergency lights. Once in a while, I'll pass a building emitting the slow beep beep beep of a battery backup. Interestingly, the collision repair shop has plenty of lights on, and emits the unmistakable hum of a generator. I can only assume it kicked on automatically, since few people would be around so early to start it.

I head home, with a quick detour to the substation, where a pickup is just arriving. A few hours later, we finally got power again.

Losing power confirmed something I've long thought: getting rid of streetlights would be awesome! Particularly on the residential streets, where they're just not needed. Particularly that freshly installed bright blue LED two houses down that casts the glow of cheap office lighting across the entire gorram block.

It also confirms that several hours without A/C is several hours too many. Ugh.

And that my ISP needs to get on the ball, and make sure internet continues to function during a power outage. You're a phone company, making sure things continue to work should be second nature!

A few years ago, my friend Sparky got married. I took a ton of pictures, but until now, never actually did anything with them. So let's reminisce.

All aboard the wedding train! )

While I am ostensibly a "full-stack" web developer, it's no secret that I'm not particulary fond of the front-end. In large part, this may be because the world seems to be full of bad front-end developers, who by and large are fantastic at building crappy versions of desktop apps inside a browser, but are incredibly bad at building things which are truly of the web.

What makes a good front-end developer? I asked @janiukjf this after her presentation at the ExperiencingUX meetup last night, and she says part of it is a willingness to stay up to date with the constantly-popping-up front end frameworks. And certainly, the front-end changes quickly and it's hard to keep up.

But do we need to keep up? I'm not convinced we do.

After all: a regular form post has worked since the 90s. It's not going to stop working! We built websites without CSS for years―CSS is a wonderful addition, but if your website is nonsensical without CSS, it'll be nonsensical in a text-only browser. It will potentially be less useful to a screen-reader (an h1 and a div with an enlarged font are likely to be expressed differently) or other assistive technology. But even with CSS, you don't have to be on the cutting edge to do useful, beautiful things. In fact it probably helps to avoid being on the forefront: older CSS tends to work better and in more browsers.

And then there's JavaScript: the easiest way to turn a browser into a fragile, distributed computing environment. We built websites without JS for over a decade, and eschewing megabytes of JavaScript to display basic text would greatly improve the speed of the web. Properly applied, JavaScript can be used to do amazing things, but there's no shame in making a simple line-of-business CRUD app out of plain ol' 90s-era forms if that's all it really needs.

So what makes a good front-end developer? I think it's embracing the limitations of the web. It's understanding that the web isn't a pixel-perfect medium; that sometimes your images or fonts or styles or scripts won't load and you have to handle that; it's understanding that the web is populated not just by developers with the latest Macbook and ten-year-olds with iPhones, but also little old ladies with dusty old Gateway computers and cheap faded monitors, and the web should work for all of them. It's understanding that the browser is a hostile computing environment in which anything we tell it to do is a mere suggestion and if we break when it doesn't that is our fault and we need to handle it.

And quite frankly, that's really hard.

A while back I made an attempt to use healthcare.gov to acquire health insurance. The experience was … unpleasant. Here are some things that irked me:

JavaScript

It's broken without JS. While this is incredibly common, it will always garner a complaint from me. If I am in a browser I do not want an "app-like" experience, I want a web-like experience.

It includes JS from third parties. Look, maybe you trust Google, MxPnl, or Optimizely, but I sure don't. On the bright side, it worked even without running JS from those companies—though I don't know whether the credit goes to NoScript's surrogates or the HC.gov developers.

Laggy

It felt very sluggish while I was attempting to use it. When I entered my zip code, it would miss keystrokes. E.g., if I keyed in "90210", what appeared in the field would be more like "91". Clearly it's doing a network request to give me a list of cities, but is it doing it synchronously or something? Because wow is that a terrible experience.

Poor Name Handling

It told me my first name was invalid. I'm used to systems mucking up other parts of my name, but that was a new one. Unfortunately, I don't remember what I originally tried to enter. (Probably my initials, since that's what I go by.)

The name suffix is a select. It contains Sr., Jr., III, IV, and sometimes V. So much for Henry VIII. Or me, for that matter, because I'm a II (NB: Jr. and II are not equivalent). I think in the end I made the suffix part of my last name.

Notice that sometimes V? That's because I came across two name selects. The second was missing the V, which means the two selects aren't even pulling from the same source. (For that matter, why am I entering this data multiple times? Last I checked computers were really good at copying. Just ask the MPAA.)

Lousy Identity Verification

Identity verification systems are pretty much always terrible because they pretend public information is a shared secret, and this is no exception. My name and address are both public, and my SSN might as well be given the number of organizations that have it on file. The credit bureaus they use to verify my identity, for example, are companies I have never directly interacted with or provided any information to, and yet they have all this information. When third parties have your data through no fault of your own, that's pretty much the definition of non-private data.

The follow-up identity verification questions are at least as terrible. One of them was "County for the provided address". What is that even verifying? That I know what address I just gave you?

Multiple Paper Forms, Now Online

I think I accepted the privacy policy something like half a dozen times. And had to enter my personal information—address, e-mail, etc.—multiple times as well. Did they just do a direct translation of the various paper forms to the web or something? Because that's awful.

Even some of Q&A walkthrough steps felt like paper forms directly copied to the web. "Did you recently lose coverage?" "Yes." "Are you losing coverage in the next 60 days?" … I'm pretty sure the answer to the first question makes the second one not applicable!

Unnecessary Info Required

As far as I can tell, insurance rates must be the same regardless of sex, so why does it require me to specify that? Also, the error for failure to fill out the sex field is hilarious: "select at least one item". Naturally, it enforces a gender binary and doesn't allow you to pick both.

It requires a phone number. So what do people without phones do? Or people who just plain don't like phones. Alas, I did not attempt to enter an invalid number like 555-0123, so maybe it takes those? I used a voicemail-only number I maintain specifically for such forms.

Unclear Results

So when I finally got all the way through, what are the results of my application? It says "Eligible to purchase health coverage through the Marketplace", and I think "Yay, I can finally move on to the thing I was actually trying to accomplish!". So I keep reading in the "What should I do next?" section and it tells me "You cannot choose or change plans at this time…".

Have I been mistaken about the meaning of eligible all these years? Because I thought it meant you can do something, and it's telling me the opposite. I get what it's telling me now—I could, if only some other conditions were met—but wow is that ever confusing.

Suspicious Goodbye

Defeated, stressed, and missing hours of my life I'll never get back, I log out. That takes me to cuidadodesalud.gov, whereupon I am presented with a blank page. (JS is not enabled for that domain because I've never been there, obvs.) I guess that's the Spanish version of healthcare.gov? Not sure why it decided to send me there, but after a long frustrating experience, being dumped onto a suspicious letter salad domain is a fitting cherry on top.

Final Thoughts

I guess on the upside all my complaints are about details, which means at some level it's at least functional. But I think I'd rather pay the fine for not having health insurance than put myself through that a second time, which pretty much defeats the entire point of the site.

CL-FTP Bugs Squashed

2015-Jun-03, Wednesday 06:28

One of the perks of being unemployed are that I have a reasonable amount of downtime again, so I've been spending some of it updating libraries which are under my care.

CL-FTP, which is pretty stable and incredibly niche (who uses FTP anymore, anyway?), has recently had a flurry of activity. Thanks to Kambiz Darabi for finding and fixing a bug related to :if-exists nil. Thanks also to Rafael Jesús Alcántara Pérez for improving ABCL compatibility.

CL-FTP is now at version 1.6, and includes both the above-mentioned bug fixes as well as:

  • Now available via the ASDF system name "CL-FTP", in addition to "FTP". The inconsistency between library name and system name bothered me, so now they're consistent.
  • No more docs hidden away in an LML file. The method docs have been moved into docstrings, which hopefully puts things a little closer to where they should be. (And hey, maybe they'll be picked up by quickdocs in the future.)
  • "active" FTP should actually work now. Turns out it's been broken for, uh, entirely too many years. It may or may not work depending on NATs and firewalls in between the client and the server, but the library itself should no longer be an issue.

In related news, a big thanks to Mariano Montone for his patches to burgled-batteries. You may be interested to check out his burgled-batteries.syntax project, which helps bridge the gap between what burgled-batteries actually is and the ambitious goals I have yet to get anywhere near.

June 2016

S M T W T F S
   1234
567891011
12131415161718
1920 2122232425
2627282930  

Syndicate

RSS Atom

Most Popular Tags