A brief, painful attempt to understand JSA

JSA is “JavaScript for Automation”, aka Apples attempt to embed JavaScriptCore into their Apple Event model.

The use case here is, roughly, “I know JavaScript and [love|like|tolerate] it, but I cannot under any circumstances be arsed to do anything useful in AppleScript, because AppleScript is easily one of the worst software platforms ever created by man”.

Seriously, AppleScript is extremely bad. I have in my life encountered a few people who loved it; and nearly 100% of them are not work-a-day programmers. AppleScript is purpose-built to confuse, annoy, and frustrate people who can chew through languages like Swift with little effort.

(I’m not trying to start a “you’re not a real programmer” thing; if you write a program – any program – you’re a real programmer! I’m just saying that the norms AppleScript adheres to are typically diametrically opposed the stuff we work-a-day programmers have deeply, deeply internalized as “normal”.)

Anyway! I decided rather than replace a bunch of light switches my wife has decided are no logner aesthetically pleasing, I thought I’d spend the morning trying to hack on some JSA. After all: how hard can it be? It’s JavaScript and I know JavaScript, and I have once or twice managed to fumble around with AppleScript until I accomplished something useful.

I can sum up the morning with the phrase, “Oh, for fuck’s sake”.

Continue reading “A brief, painful attempt to understand JSA”

vt100 development

With the exception of the web browser, every single piece of my job could be accomplished with a vt100.

I don’t want to go into too many details, but suffice it to say that we are running on a very specific platform, with extremely specific hardware and software requirements. Historically, developers were not provided with machines that could easily run lots of local VMs, preferring instead to build a server farm that resembled production and eventually parcelling out VMs to devs from that. There are also other reasons to eschew the “just run it all in Vagrant+Virtualbox” mode, involving database resources and other considerations.

I discuss (and overshare!) this here, if you’re curious. At the time – for the first year and change I have worked at $SALT_MINE, I’ve been strugging with this mode of remote mounts, sync, SFTP, etc.

In short, it sucks. I have managed to get a couple of Vim configs that work, and now I run basically 2 programs: iTerm 2 and a web browser.

All that hardware – we get nearly top-of-the-line Macbooks – is used to run 2 programs. I could do my job on a vt100, and I hate that.

As I’ve said elsewhere, this has almost always been the case, too! At $LASTJOB the core work required an actual goddamn computer, you couldn’t even use a VM (don’t ask, it was complicated). At the job before that, there was no reasonable way to run one of our products on anything but a real computer of a very specific make, model, and OS (although in fairness that involved licenses as much as bytes).

Every now and then I look at companies like JetBrains and wonder, who actually gets to use those tools? Who gets to do, I dunno, some sort of Java or .NET dev with a fancy IDE that pushes to the cloud, or something? Who gets to use fancy database admin tools? We have to hide our production DBs behind 100 layers of security (a very fancy logging proxy, among other things).

I have managed to get a working Linux config that does the same thing without any distractions: it’s just OpenBox and Terminator. There’s not much else. I’m missing a few nice tools – LaunchBar and TextExpander are the most strongly felt, but I’m sure there’s replacements.

I’m still using a glorified vt100 to this day. I hate it. Is this all there is?

The lock-in we choose

Hackernews had a link to a piece about someone moving to a password locker called Bitwarden.

It’s interesting because it illustrates the weird state we’re in with platforms today.

First, this bit:

Meanwhile, AgileBits, the 80-person company developing 1Password, has been pushing their new hosted, subscription-based model for 1Password going forward. Instead of users being in control of their data files, 1Password will store them on AgileBits’ servers and users pay a monthly subscription fee for the privilege, forever.

I fail to see how the staff size of AgileBits has anything to do with anything. It feels ad-hom; how DARE they not be a scrappy little 2-man startup! How dare they have a support staff, enough junior sysadmins to have 24/7 coverage for their new web service, a full-time graphics and design team to cover all the platforms they support, and whatever else it takes to run their company the way their principals want.

Anyway, yes, the subscription-and-stored-on-our-servers model was, and is, very concerning. I am still using iCloud sync, because it has worked very well for me and I did not want to be an early adopter of stuff with my passwords.

What gets me, though, is this:

… there is an issue of lock-in and now having to make my OpenBSD hacks work …

My dude.

AgileBits was, as I recall, founded as a company whose primary platform was the Mac. They don’t even mention Knox or other apps anymore. For a long time, even Android was a second-class citizen; I haven’t used Android in a while but when I last did, it didn’t even have proper 1Password support; it had some read-only nonsense.

Think about that: Android installs outnumber iPhone by rather a large margin and they didn’t bother with it.

In short, my dude, you chose to drive a car that needs leaded gas and you’re mad Pep Boys isn’t going to sell you the right additive.

They are a Mac software company, who also makes a port to Windows; they are an iPhone app company who ported their app to Android. They give 0 fucks about OpenBSD on the desktop, because supporting all 9 OpenBSD desktop users will not help pay their mortgages.

The point, here, is that we all chose a kind of lock-in. Every choice we make in software and hardware platforms ties us to an ecosystem. There is this pervasive myth that F/OSS will free us from lock-in.

Bullshit. It frees us from the woes of decisions made in boardrooms based on spreadsheet calculations for 3 fiscal quarters from now; but it locks us into the whims of hobby projects, volunteer support, trends, and more. Just about everyone in a Mac uses 1Password, but with my office as a small sample set (plus the Hackernews comment section) all the F/OSS community gets is the paradox of choice.


To save Twitter, we must destroy it.

So many people had an experience like this. Twitter was fun, fast, easy to use; and brevity is the soul of wit. If you were a programmer, you’d often learn a new platform or language by writing a simple Twitter client; and tons of really smart people were writing interesting software that took advantage of all the new toys in our toy box, with Twitter as the base.

Fun times.

It got even better, for a while. Twitter replaced RSS, for many; a scan of your feed let you know where your friends were, what important software updates were released, and everything else you could want.

Yeah, there was the Fail Whale and porno bots but it wasn’t any worse than we’d seen already. And we had the Arab Spring! People got work by telling jokes on Twitter. We had Weird Twitter and Scottish Twitter and …

But then came GamerGate, followed shortly by their brothers in arms the Alt-Right, and Russian trolls, and now the dullard in the Oval Office.

Fuck Twitter.

The best thing to do to “fix” Twitter is to leave. It’s a white supremacist web site. It’s not getting better.

The solution is already there. RSS is still good, and usable. You can support independent media, like many good podcasts, instead of supporting a company that thinks that giving more characters for racist bile is the solution.

Everyone bitches and moans about walled gardens and “closed platforms” and “you are not the customer, you’re the product”. So take the air out of their sails. Stop “microblogging” and write real thoughts. Read long-form journalism. The internet has given us the tools. Use them.

On Process, and software development

Today I had a chat with a coworker about the process we use at work; the method by which we develop software, from conception (“The site should be blue”), to doing the work (filing a ticket, writing the code to make the site blue, ensuring it is the expected share of blue), to various legal and compliance requirements (“it must be documented that on such-and-such a date, so-and-so did change the site to blue, signed by someone other than so-and-so”).

In short, we hate the process.

On the one hand, it’s cumbersome. Most processes are. They are build from small parts to a Big Thing, because one time, something REALLY fucked us, and That Must Never Happen Again. So layers got added, workflows got created, and before you know it, you need knowledge of the inner workings of a complicated state machine to make the site blue.

There was a time when you could just do it, man. It was great. But now it really optimizes for the common case, and we all know what happens then.

Anyway, what got me thinking was, what’s really at fault, here.

I think there’s a couple of big problems.

As an industry, we aren’t entirely sure what the hell it is we’re doing. There is a wing of the software industry that thinks we’re some kind of code-poet-ninja-rockstar who makes these beautiful and amazing things because it’s what drives us.

Me? I think we’re just skilled labor in an information economy. We’re assembly-line workers. And that’s good: skilled labor built this country. We should reward it! We should revel in it! That used to be a fucking awesome job, that people aspired to.

But the thing about those industries was, for a long time the pace of chance was slow. Carpenters had the hammer thing settled long before most of my ancestors came about. No one showed up with a tack hammer expecting it to be useful to build a building.

Our processes don’t protect us from outside interference. They don’t give us certainty about what it is we’re doing and why.

Building codes let every tradesman building a building know, to some degree of certainty, that when followed the pipes won’t burst, the sockets won’t catch on fire, and the support beams will hold. They’re why flood walls work and why buildings survive earthquakes.

It’s a process no one likes to follow, but it moves at a pace people understand; can be comprehended and relied upon for the duration of one’s career; and has visible results.

Today a bunch of code broke because our fragile human meat made mistakes that, in retrospect, may have been impossible in the common case to prevent. A couple of jobs ago, we changed fundamental pieces of our software at least twice; last job, we went tripled the number of languages you needed to do things at work in the space of a month.

It’s madness.

We are not wizards, ninjas, rock stars, or artisans. We are the skilled labor of an information economy; a noble profession, and one that benefits from a slower pace of change.

Our processes should reflect that. They should not just protect us from lawsuits or pass a perfunctory compliance inspection, they should provide a bedrock upon which to make solid decisions when tired, or confused, or hurried, or unsure.

MongoDB and FUD

The Problem:

Our data set consists of gigabytes upon gigabytes of pickled Python dictionaries, CSV files, and plain text, with the odd bit of Excel or Word. I have three goals:

  • Maintain this monstrosity
  • Create a searchable index
  • Build a new version for the future.

The entire app is a single monolithic Python app: there is no such thing as a “front end” or a “back end” or “middleware”. It’s a web app but there’s no templates; it generates HTML via print statements. The same Python file may include standalone logic,or  shared logic to be used by other components. It’s a bit of a mess. Lastly the framework it uses is basically abandonware; I haven’t tried to see if it runs under any Python after 2.4, and you can be sure it won’t work under 3.

My first task was the search problem. I started with Whoosh but after about a year, it started to run into performance problems, and I’d also learned enough about information retrieval that I wanted some more features. The Whoosh guy is awesome and he’s done a hell of a thing, though; I cannot recommend it enough for smaller projects, but I needed more. I’d attended a talk at Pycon about Elasticsearch, so I switched to that, and it’s been awesome. 

My strategy was pretty simple: a cron job to regenerate the world. Since Elasticsearch is really, really fast, it took perhaps 30 minutes to reindex the entire data set, and since it’s not a 24/7 use case running it at night is no big deal. (I’d like to provide real-time search but my users rarely need it; they’re content to have today’s new data appear tomorrow)

This worked so well for 2 reasons. First, I’d learned enough about the “common data set” that I could make the custom indexer pretty easy to work with since I knew enough about my users search needs that I could ignore 99.9% of the data. And second, Python dictionaries map really well to JSON, which Elasticsearch uses as its input and output.

In building the regenerate-the-world scripts, I had written a huge amount of code to 1)walk the entire flat-file “database” and 2)make lots and lots of sense of it all. I did stuff like, “ensure that every disparate part of the app always refers to a Project by the faux-primary-key ‘projectid’ instead of ‘pj’ and ‘projid’ and whatever else”. My indexer did a pretty decent job of cleaning up this semi-schemaless data; so now what?

Since our app uses CouchDB, it was my first choice, and very quickly abandoned. I loathe CouchDB. It makes a lot of sense in our app, but not for a general-purpose data store. 

Up next was “any ol’ RDBMS”, which means MySQL. Attempts to hammer the semi-schemaless data into relational format resulted in a data model so complex and byzantine, it was practically recursive. Instead of 3rd normal form I made a wormhole into a hell-dimension. So, no.

Despondent and generally upset, I tried MongoDB. And it worked! Experiments worked really well! 

  • As I said, Python dictionaries map very well to JSON/BSON so the amount of friction in import/export was minimal.
  • Ad-hoc queries
  • easy blob storage for stuff like Word documents
  • It’s fast (importing the world took perhaps 20 minutes)
  • It’s easy to set up (compile and go, basically)
  • Support for every language and platform I could think of
  • Has some replication capability in case I ever need it

I wasn’t really sure about a couple things, mainly backup-and-restore, but that was really my only concern, and the Mongo docs on the topic seemed straightforward enough; my users can tolerate an hour of downtime.

And now, the point of my little story: I think Mongo DB is picked on more than just about any platform save PHP. There is so much fear, uncertainty, and doubt spread about it, it’s started to leak into my world and freak me out.

Consider the most recent thing, the “randomly log stuff” bit in the Java driver. Places like /r/shittyprogramming were all over it with digital brickbats. Every thread was then a free-for-all of “here’s now MongoDB screwed me over/Here’s why MongoDB sucks” stories from all over the internets.

Panic set in. This data is mission-critical; while my users can tolerate small amounts of downtime and don’t need OTP-type features, it’s still mission-critical data. Have I fucked up royally here? Have I set myself up for epic fail? Or am I just giving in to the sort of FUD that pervades every goddamn internet discussion about any sort of technology? Let’s face it: people pile on and rarely are they anywhere nearly as awesome as they think they are. 

At this point I’m not entirely sure what to do. My thought was to return to the cold comfort of MySQL, using a Friendfeed-style schemaless system. It’s a huge orthogonal step but I’ve recovered horribly fucked MySQL databases after three-too-many bottles of Tequila, so it’s safe and well-understood. It puts the impetus on me to write the entire friggin’ access layer, but whatever. I know about Postgres and JSON, but I don’t know Postgres at all.

Am I giving in to FUD? Do I stay the course, trusting that my proven, real-world positives outweigh potential negatives?

A little Coda 2 plugin

I made a little Coda 2 plugin for fun: wrapping js-beautify. You can download it here

Pay close attention to the documentation; the script environment doesn’t do what you think it does, and so you’ll be very grouchy.

I want to love Coda a lot; as I mentioned in my review of Komodo IDE, I mention as one of its downsides it’s so very not-native. Coda is extremely, wonderfully, beautifully native. So there’s that.

But it’s ultimately an app for cranking out WordPress plugins, not doing serious work. If you want to build serious, production web applications – and especially in something other than PHP – look elsewhere.