Do We Always Need The Elite?

I read a piece today entitled Functional Programmers are Better Programmers and it got under my skin.  I don’t disagree with the points around the nature of functional programming and those that do it.  They were well stated. It’s a rigorous paradigm, requiring smart, intense, mathematically minded folks, and it can produce robust efficient systems.

What bothered me was the assertion that “FP is always a good choice.”  That’s overly simplistic.  It’s like saying every military task is best staffed by special forces.  It’s serious overkill and brings with it a bunch of issues.

I’m a dedicated software engineer and have earned my living doing it, and managing folks doing it for a long time. I always bring energy and intensity to my solutions.  But a great many of the projects I’ve earned a living at over the years have been pretty mundane: not too complex problems, with not too demanding requirements.  More often than not what was needed most was a good clean solution that could be squared away quickly and maintained for years after, and all of it affordably.  Getting average projects done right with basic tools can be very satisfying.

Building and maintaining an elite team is expensive.  They’re harder to find, want challenging work and won’t stick around for the long tail of the maintenance phase.  Applying that solution to a straightforward problem is going to cause problems.  You’ll end up, if you even get a complete initial solution, with something that’s going to require the same quality folks for years, or suffer from insane entropy as people who aren’t up to the task get thrown into the mix more and more.

FP is a great tool, but not every task requires it… sometime the problem is a nail, and a hammer will suffice.

Persona Alternative

Mozilla will be shutting down Persona in November 2016.  It’s a shame as it was a nice simple way to add authorization to web projects.  I used it on my Snippets Web App. The integration was very simple, low impact, and worked well.

So What’s to do Now?

The app that used Persona was for my personal consumption, and intentionally kept simple. I use it daily, and test a lot of new code practices and kits in it but It’s not something I want to put a lot of effort into.  I need authorization, and want it basically secured, but I’m not going to spin up my own OAuth implementation or the like.  Since I used my gmail account with Persona I decided to look into Googles authentication offerings.

Resistance is Futile

So once I decided to assimilate into the Borg Collective (aka Google), I started looking for examples. There is plenty out there on how to used Google to authenticate your app, but largely it has one of two issues, it’s geared towards Android, or out of date.  I just needed to know:

1. How to get my JavaScript UI to kick off authentication
2. How to get my RESTful server to verify the Google response
3. How to log the session out

As it turned out each of these steps was, increasingly in order, more difficult to figure out.

Kicking Off Authentication From JavaScript

This was fairly straight forward.  Following Google Sign-In for Websites documentation basically verbatim worked.  The info on setting up your Client Id was out off date, the developer console layout has changed, but it wasn’t too hard to figure out how to follow the old instructions on the new UI.

Verifying The Token on the Server Side

This was incrementally harder. The backend auth documentation was basically functional but it doesn’t explain how to create the transport or JSON factory needed.  Figuring out what jars I needed on the server side, and boiling it down to working code was a bit of a pain. In the end I needed the following two dependencies:

'com.google.api-client:google-api-client:1.21.0',
'com.google.http-client:google-http-client:1.21.0'

And with those in place and a bit of prep the code pretty much worked.

Logging the Session Out

This was by far the hardest to work out. Particularly because I offer a logout button on every page of the app, as opposed to a unified login/logout page.  Google’s notes here just plain did not work.  The auth2 instance was not defined for me. This Stack Overflow post tuned out to be the key to the solution!

In the End…

I got it all working. No where near as easily as Persona.  If you want to see my implementation take a look at my index.html, index.js and GoogleIdTokenUtil.java in my snippets project.

JavaScript’s “this” Foils an OO Guy

There are a lot of good posts on this topic, but I wasn’t paying attention apparently – so JavaScript folks can stop reading now unless you want to mock me.

Most of my real development has been in object oriented languages, C++, Objective-C and Java primarily, so when I decided to tidy up some JavaScript I’d written I tried to OO it up a bit.  Not the wisest path, but it’s my comfort zone…

Anyway here’s what tripped me up.  The following is a contrived example for discussions sake:

function Enabler () {
    // Instance variables
    this.username = $('#username');
    this.loginButon = $('#loginButton');

    // Event handlers
    this.enableLogin = function () {
        $(this.loginButton).prop('disabled',
            $(this.username).val().length <= 8 );
    }

    // Binding
    $(this.username).bind('keyup', this.enableLogin);
}

$(document).ready(function () {
    var enabler = new Enabler();
}

Looked good to me. But the enableLogin function caused an “Uncaught TypeError: Cannot read property ‘length’ of undefined” the first character I typed. The JavaScript folks are probably laughing at this point. Poking around I determined that this was not my instance of Enabler but input#username!

But of course…. because this in JavaScript is the owner of the function being called, and functions can change ownership. Above I bound the function to the text field which changed its owner to that. That’s a gross simplification, for the whole story you can read a post like Understanding JavaScript’s This With Clarity and Master It and also learn about Arrow Functions. Either way, there are a couple simple fixes to just insure the correct owner. One is using bind as follows:

// Event handlers
this.enableLogin = function () {
    $(this.loginButton).prop('disabled',
       $(this.username).val().length <= 8 );
}
// Binding
$(this.username).bind('keyup',
                    this.enableLogin.bind(this));

Another, that works with ECMAScript 6 browsers (not IE or Safari at time of publish) is by using an Arrow Function which uses a lexical bind of this:

// Event handlers
this.enableLogin = () => {
    $(this.loginButton).prop('disabled',
       $(this.username).val().length <= 8 );
}
// Binding
$(this.username).bind('keyup', this.enableLogin);

But the real solution is, I shouldn’t try and force my JavaScript square peg into an OO round hole.

The Basic Why of TDD

I’ve worked projects with good testing cultures and those with none, and I’ll say without hesitation a good testing culture is well worth the effort, and the longer you put off testing the higher the cost it is to incorporate and the less likely you are to reap it’s rewards fully.  Consistent testing will:

• Test your every assumption you make as you code
• Force your code to be cleaner and compartmentalized
• Document in the purest form how you expect your code to be used
• Fix problems before you have to resort to the debugger
• Insure incremental changes can be made quickly and with confidence
• Allow for safe code cleaning and dependency migrations

If you ignore these truths you end up with the opposite, code rot and technical debt that insure the entropy of  project steadily increases.

So, am I advocating the early involvement of a QA team/process?  No, because QA is already too late.  If you depend on another team to test things after the fact you lose most of the benefits above.

Testing early means as early as possible. As you code, or if you follow Test Driven Development (TDD), then before you code.

The core tenant of TDD is to write the failing test first, and then code to get the test to pass.  There’s a lot more to it, about how to best approach it, and how to get the most from it, but at its heart it’s that simple.

Do I use TDD? Yes, mostly. Even zealot TDD advocates acknowledge that there are times TDD isn’t appropriate, where you’re discovering the solutions by muddling around. But mostly it’s applicable. And too, at times I’ll be lazy, but I know what I’m sacrificing when I am.  By and large, if the code is at all challenging and will be around for more than a few days, I lean on TDD as much as is realistic.  Take a look at my open source stuff – my coverage is usually 70%+ out of the gate and 90%+ as the code settles out.

Who are the TDD luminaries I respect and follow?  My favorite Martins: Robert Martin, Martin Fowler.  They are great software engineering resources in general but for TDD you’ll want to start by watching one of Bob Martin’s keynotes or read Martin Fowler’s recent discussions on TDD.