The majority of this week focused on Swarmize/Lewesdon: writing automatic deployment scripts and spelunking code.

I did spend a morning this week with PAN exploring some work they’ve got on the horizon – some discussion of how to approach development, as well as a good table discussion on the design of the project. Always pleasant to work with one’s studiomates, and I’m looking forward to seeing where the project we talked about goes.

Mainly, though it was Abberley/Swarmize this week. Lots of movement here. A lot of that was moving forward a stub of a web application that’s going to be the primary user front-end to it.

I’m not building that application yet, though. I’m building a tiny Sinatra app that talks directly to our ElasticSearch instance to get a feel for the materials: what queries I’m going to need, how to abstract away from a hard-coded single UI, how to get the whole stack up and running.

I took my hard-coded demo and abstracted just enough to make it easy to build a second demonstration on this app. I think that’s the final goal of this code: beyond that, I may as well work on the real thing. I extracted a lot of classes from the big tangle of code, to see where the boundaries between persisted objects for the front-end app, and interfaces to ElasticSearch (and other APIs) would lie.

I also worked on writing deployment code for the app. I’m deploying onto Amazon Elastic Beanstalk, because the whole stack is running on Amazon instances, and I want to play ball with the other developers – and stay inside their security group.

Rather than using the magic of auto-deployment out of git, I’ve been writing deployment code by hand. In part, to understand what’s actually happening – but also because I’m deploying out of a subdirectory, and Amazon’s “magic” code doesn’t play ball with subtrees.

My first pass at this code was a bash script that bundled up a zipfile of the app, pushed it to S3, created a version of the app with that package, and then applied that version to the live environment. I then rewrote it entirely, using the Ruby Fog library, and abstracting out lots of hardcoded variables, the goal being to make it more configurable and adaptable. It also would save time: Fog made it easy to interrogate the existing environments, so the code wouldn’t re-upload a version if it was already on S3, or make a deployment if one wasn’t necessary (which would throw an error, normally).

This took some time, and I began to doubt the utility of it. My doubts went away on Friday, when, with the aid of a few new configuration variables, I pushed the whole lot straight onto the Swarmize AWS account in no time at all. Time spent up-front to save time throughout. And: as a result of that work, I now understand much more about EB as a stack, and how I’ll go on to use it.

As part of that work, I submitted a patch back to Fog – the tiniest, simplest patch – but the pull request was accepted. It’s nice when open source works like everybody tells you it does.

By the end of the week, the end-to-end demo was out of the “rough and ready” version and feeling a lot more polished. I wrapped up the week by researching some Javascript techniques and libraries for Abberley’s front-end, which I’m going to break ground on next week: a Rails app, with its own persistence layer, that’s slowly going to replicate the crude functionality I already have. But to begin with, I’m going to be working out how to make the UI I’ve designed work within it, which I’m rather looking forward to. Week 92 will be a meaty week of HTML and Javascript.