Pivot

It's been about three months at the new job now, which makes it a good time for a quick update.

The next quarter will be focused on a couple of critical issues, professionally:

JavaScript

JavaScript is widely used in our environments, and the last couple of sprints I've spent with a homegrown Node/Express app that is essentially a pretty front-end to a MySQL server. The past couple days have involved ensuring the server doesn't crack under scale (9 million rows means: make sure your indexes are set up correctly, and you're using them!) as well as a large amount of futility setting up unit testing for code.

One of the issues is that sinon is an excellent stub/mock/spy library, but doesn't seem to have a way to mock the more complex parts of libraries. This is a simplified version of the problem:

pool.getConnection(function(err, connection) {

  connection.query('SELECT * from foo', function(err, rows) {

      // Do stuff here

  });

});

As it turns out, it's remarkably difficult to mock connection. The object is hidden within a library, making it (apparently) impossible to stub out.

Still, JavaScript has shown enough utility that I'm going to be taking a deep dive into it, hopefully with an in-depth tour of what's coming up. With a focus on Polymer.

Seven Languages in Seven Weeks

In addition we have a book club at work. This time I've decided to participate in it, because the material is pretty compelling.

Seven Languages in Seven Weeks is a good way to get started on a habit that most programmers should get into: learn a language a year. This book is a deep dive into Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby. Which means it'll be good for catching up! Each language has a specific way of thinking about how to solve problems, and even if I don't end up deploying Erlang in my career, it would still be good to know what philosophy underlies Erlang, and how I can use that to program in JavaScript better.

So it should be an exciting three months!

New Tools

With a new job comes 35-45 minutes on a train either direction, and some time to reflect on the day and write for the blog. So here’s my beginner’s attempt to lay out the tools we use at the new job.

It’s always good for a craftsman to get to know his/her tools better, but with so many new tools that’s just going to take a while. Consider this a start!

I’ll also contrast it the tools from the old job, based on all of 5 days of experience.

Mercurial

Old: Subversion

Mercurial is a distributed version control system. It’s similar to, but has slightly different internals from, Git… but the word is that Mercurial is used here because the lead developer preferred it. Maybe he prefers James Bond to McGuyver. Whatever works.

It is far and away better than Subversion, for reasons best explained in this Joel Spolsky post: the short version is that even though one of the advantages of SVN was that fugly merges would go away, in practice they haven’t. With Mercurial, they just might.

Vagrant on VirtualBox

Old: None

Virtualbox is a virtual machine the emulates an x86 environment on any given piece of hardware. Vagrant manages most everything else that’s built on top of the machine; operating system, databases, web servers, environment and dependencies.

When managing many web applications (or, really, any software applications at all) it’s inevitable that the dependencies and requirements from one application to the next will change. Deploying a virutal machine for each application, with the requirements for that application built into the machine, allows developers to iterate through changes rapidly on their local box without worrying about local-box issues that inevitably cause shared working areas to break.

Atlassian JIRA

Old: Intervals Timetask

It’s not enough to know how much time was spent on a given task. It’s more important to know the current status of the task, especially when coordinating with a team of up to a dozen people.

A scrum board helps do this. Important tasks are at the top. Less-important tasks are on the bottom. The journey of each task is monitored on a scrum board, as it flows from backlog to design, to development, to QA, then back to development to push. Tasks are never lost, because they’re right there, on the board.

It integrates well with commit hooks that tie every commit to a particular task. Since I’m a serial committer, it subtly influences me to commit less than I would, but that’s not a bad thing; a commit should be defined by a proper unit of work.

Ruby Version Manager, Node Version Manager

Old: N/A

In the same way that Vagrant keeps the service layer clean, versions managers keep the application layer clean. Some of our applications were built with Ruby 1.9.3, some were built with 2.0.0. Until there’s development time to migrate each application to the most updated version, project-level declarations of application versions keep developers happy.

Grunt

Old: Framework-level hooks, sort of

Not much experience with this so far, but we use it to compile our CSS from SASS and minify JS before deploying to production. This is better done automatically than manually.

Jasmine

Old: None

Jasmine is a JS-based framework for unit tests. A large chunk of our business logic is written in JavaScript, and in the future we’ll only be writing more in it, so bringing code coverage for those scripts up to at least 80% would be ideal.

I thought that trying to test complex JavaScript would be an absolute PITA when I first scanned the code, but Jasmine has the concept of spies, so you can do this…

  it("tracks that the spy was called", function() {
    expect(foo.getBar).toHaveBeenCalled();
  });

And what if you’re testing class A and want to make sure the functionality of class B doesn’t get in the way? Well, JavaScript is a prototypal language, {so you can override B really easily}(3):

spyOn(obj, 'method').andReturn('Pow!')

:-D

From the top: Ruby and Frameworks: Divvy Neighborhoods

I want to create a Ruby web app, just to become familiar with the syntax
and to see what my options are out there. Every framework has its own approach
to web apps.

I have minmal, old experience with Ruby on Rails, so for now I’m going to look past
it. An outline of what I want to do goes something like this…

Divvy Neighborhoods

Summary Page

• Aggregates station information
• Associates it with neighborhoods
• Displays overall availability on a per-neighborhood basis

It would be nice if the aggregation took place at the server level, so that the only thing
passed to the front-end was some JSON that looks like this…

someDebugging: {},
neighborhoodSummary: [
    {
        neighborhood: 'River North',
        stations: 12,
        availableBikes: 100,
        totalBikes: 150,
    },
    ...
    {
        ...
    }
]

Since stations appear and disappear all the time, it would be nice to have a way to associate
stations with neighborhoods that didn’t require keeping a file up-to-date in the git repository.

History Page

A big goal of this is to track neighborhood-level changes in station availability over time. This
seems to call for a conventional transactional database.

With the historical changes, you can do some interesting stuff.

• Track the broad availability of bicycles
• Track the average availability (available / total bikes) of bikes
• Compare the changes of availability in a given neighborhood, versus the changes in average income in a neighborhood.

Timeline

I don’t have the faintest idea when this will be done, but I do plan on having the code open-sourced
and available on GitHub. Suggestions would be appreciated!

Adding graphs to the Chicago Crash Browser

Pull request #3 (of, hopefully, 5) is to add graphs to the Chicago Crash Browser.

I’m a fan of data visualizations, but I haven’t been able to work with that during my day
job. So this will do. :-)

I utilized Highcharts, and after a few hours of wrestling with JavaScript
objects, I’m happy with the result:

What Web Development Means

…to me.

The big news today is that beginning Monday, February 3, I will be starting a new position
with GoHealth, a company that sells health insurance to consumers. I’ll be working on both
consumer-facing and intra-company web applications, utilizing Ruby, JavaScript, or whatever
works best for the task at hand.

This comes at the end (or should I say, beginning!) of a process in which I thought more about
web development, and more specifically: what it means to me.

Front end, back end

Recently I had considered myself strictly a back-end developer. That is, I saw our web development
stack as this…

• Browser (HTML, CSS/LESS)
• Server (PHP, XSLT)
• Remote APIs

There was, I felt, a pretty clear delineation of responsibilities there. Browser is front-end. Server is back-end.

As I dug into enterprise web development, the picture started to get a little blurrier.

• Browser (HTML, vanilla JavaScript)
• JavaScript Frameworks (jQuery, Angular.js, Backbone.js, etc.)
• Server-side Frameworks / API consumers (node.js, Django / web.py, Ruby on Rails)
• API Implementors (can be enterprise Java or C# but it really just depends)
• Databases and other data sources

I haven’t worked on anything on the other side of the API wall… which probably meant I wouldn’t
pick be able to take on authentic back-end roles (i.e., server-side business logic). That leaves focusing
on web development over non-web development.

A better web developer

Going into this new phase, I have a couple of goals.

1. Increase my exposure to different web technologies. This is particularly important with reference to transferable skills. I’m very good when it comes to working with the Tessitura API, but to be a full-stack developer, I’m going to have to step into the full spectrum of web technologies.
2. Speak at meetups about these technologies. They could be OpenGov Hack Nights or meetups downtown. But nothing guarantees knowing your technology more than having to publicly speak about it. :-D

Goals for 2014

My new year’s resolution for this year is to have goals.

A stretch, I know. For this blog I prefer to keep things professional,
though if something sneaks in about me wanting to run in a
half-marathon, don’t be surprised.

Learn JavaScript

In other words, be a full-stack developer.

Which can be a bit misleading. Currently I work in PHP/XSLT, which
can arguably be full-stack or back-end, depending on how you look
at things.

And don’t ask me to design anybody’s website.

But. The structure of data on a page. Managing how data is displayed
on a page. Data binding through models. AJAX-y stuff.

That’s more up my alley, and with the amount of frameworks that
are sprouting up daily to address this problem, it’s a good time to
see what types of client-side solutions are being used throughout
the web.

Do Good Things

I have a goal to put in 5 pull requests to some project(s) on GitHub
by the end of the month. I’m not sure if I’m going to make it, but
the broader point applies: the more I work with other people’s code,
the more I learn about codiing as a whole.

Make the Chicago Crash Browser awesome

Chicago Crash Browser

This could be a really handy tool throughout all of Illinois, not just Chicago,
so I’d be very happy to help make this a fast, functional tool for bicycle
and pedestrian advocates like me.

Find a project in Python or Ruby to contribute to

There’s a lot of options at Open Gov Hack Night. Which one sounds interesting to me? Which one can help people the most?

Spend time with the wife and family

Because they’re important too. :-D

Weekly for January 12, 2014

New Resources
* Programming with Asserts

Existing Resources
* PHP: The Right Way

Interesting Posts
* How To Be A Great Developer

On My Bookshelf
* Learning Python. (Returned library book. Page 1,024)
* Node.js In Action, borrowed from a colleague (20%)
* Getting Started with NoSQL (70%)
* Programming Python, 4th Edition (not started)
* PHP Objects, Patterns and Practice (page 65)

Summarize later
* The Art of Agile Development
* 97 Things Every Programmer Should Know
* PHP Web Services

Wish List
* JavaScript: The Good Parts

This week I continue my search for a Python (or, dare I say, Ruby) open source project to work with. I also have a couple of good suggestions on Facebook to work in the jQuery library.