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.
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:
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.
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
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.
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.
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.
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.
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.
- The Basic Problem
- The Method
- Inheritance Is… Uh… Missing?
- Subjective Comparisons
- Available For Work
Before my now-previous employer folded, we were being courted by a buyer (boy, was that time period an emotional roller-coaster!). This would have changed our development direction somewhat, and so at the behest of my boss I spent a couple of weeks exploring language options for our upcoming greenfield projects.
I was asked to explore Clojure and Go, and compare them to our existing language, PHP. I decided to evaluate the languages by porting a fairly stand-alone portion of our existing app into both Go and Clojure, and comparing it to the PHP version.
That relatively stand-alone portion of our app was our recipe importer. It would allow users to import recipes from external sites, for use within our system.
There are a number of standards for recipe formats: the hRecipe microformat, schema.org's Recipe format, RDF, data-vocabulary.org's Recipe format, and probably a few others. In addition, most of the sites we explicitly supported either fail to mark up the entire recipe, interpreted the spec they purported to follow in strange ways, or merely referenced a recipe from another site, requiring us to follow the link chain to a parsable source.
In other words: it's a real (non-toy) problem, it's sufficiently complicated to get a reasonable feel for a language, and it's simple enough it can be ported within a relatively short timeframe.
I spent a week in each of Clojure and Go. This was not enough time for a full feature-parity port with the PHP version, but sufficiently long to present most of the complexity of the problem (inheritance, parser registration, and so forth).
Neither Go nor Clojure support "classical" OO inheritance. It may be my brain is broken through years of shoehorning things into inheritance hierarchies, but it seems to me this particular problem happens to be a pretty good fit for classic OO. "Site X uses format Y, with these overrides."
So the biggest stumbling block in both languages was simply coming up with a way to model the problem. To be perfectly honest, the solution I ended up in both languages looks pretty much like classic OO shoehorned into whatever the language does support (embedded structs in Go, multimethods in Clojure), and would almost certainly not be considered idiomatic by people with more experience in each language. (But then, neither would my PHP, and I've been doing that for a very long time.)
As a lisper bent on proving that a lisp was a viable option, I started with Clojure.
I spent approximately three days figuring out how to even model the problem without classic OO inheritance, and the following two building three generic parsers and two site-specific ones.
It was one of the most enjoyable weeks of my tenure. Clojure is as flexible as you'd expect a Lisp to be, the code was compact, reasonably fast, and I was reminded of how much I'd been missing interactive development.
When I presented it alongside the PHP it was a port of, reactions were mixed. Some developers remarked that they had a very difficult time understanding it, and that it would likely prevent the developers who worked on other codebases (e.g., our mobile developers) from swooping in to make a quick fix. My boss, who had apparently spent a significant amount of time attempting to do something useful in Clojure without much success, remarked that the comparison made Clojure much easier to understand for him than it had been previously.
Next I tried Go. Having already faced a lack of inheritance, and presented with Go's much smaller field of options to choose from, I was able to jump right in, and hit parity with the Clojure version in short order.
I did not particularly enjoy programming in Go. While Go is strongly opinionated in surprisingly good ways, the edit, compile, debug cycle is obnoxious and slow (goauto may have helped reduce this pain), the code ends up verbose and repetitive, and there are little to no facilities for abstracting out patterns.
The Go code received less objection when presented. The lines were significantly longer than either the PHP or Clojure versions, and vertically it was very slightly less dense than the PHP version due to all the error checks.
- Code Feel
PHP Clojure Go
Is it any wonder I prefer lisps? So much meatier.
- Learning Curve / Programmer Effectiveness
- Go was the easiest to pick up, but there isn't really anywhere left to go once you do. Clojure is definitely harder to become proficient with, but you can leverage that into increased programmer efficiency later. PHP has so many pitfalls that anyone starting out is likely to end up negatively productive at first, writing a horribly insecure buggy mess.
- Developer Emotions
- Clojure inspired a mixture of enthusiasm and curiosity, with strong concerns for the practicality of finding and training developers in a language which is so different from mainstream ones. Go had an enthusiastic champion in my boss, but was largely met with ennuitic "meh"s by other developers (golang is basically boring-by-design). PHP was loved by none and hated by some, with the only argument for it being "we've already got a bunch of code written in PHP".
I liked Clojure. It's fun to write in, it feels very productive, and the power lisps provide to build your own abstractions is unparalleled. But as varied as the quality of code was in our PHP, providing room for even more variability is a hard case to argue. While I would have loved to recommend Clojure, asking a team of devs who think in terms of C++ to make the transition was more than I could have sold.
Go, on the other hand, solves a lot of problems that we had with PHP. Stuff the
wrong type? Go would have caught that. Inconsistently-formatted code?
would have fixed that. Bugs because PHP did something unexpected unless you
thoroughly read and retained every aspect of the documentation? Go's house
is not built from bundles of thorns.
So while Go may not be the language for me, it would have been the right call for our team.
As you may have guessed by the mention of my previous employer folding, I am presently available for work. Feel free to contact me if you have something you think I may be interested in.