Jerome Covington: Dev

Creating a Jasmine Test Runner in JSBin

Just a quick update here.

A typical set up for testing front end code using Jasmine involves creating a test runner page with CSS and JS assets.

To quickly set up a test runner using JSBin, I decided to write the CSS asset into the HTML using JavaScript, for a quick one line script include in the JSBin HTML.

So I created jasmine-css.js and concatenated that with all of the other Jasmine assets to create jasmine-all.js, which can be linked to here: http://jeromecovington.github.io/jasmine-all/jasmine-all.js

I borrowed the idea from: http://sukima.github.com/jasmine-all/jasmine-all-min.js which uses Jasmine 1.3.1.

However, my version uses Jasmine 2.0.0.

Here’s an example JSBin.


A Long Time Ago in an Associative Array

Underscore has been making my life easier, and I’ve been explaining the Star Wars pantheon to my son so often, that it was unavoidable that the two should at some point intersect. So I thought I’d give a few simple examples of Underscore in action. I’d like to make it through every method, but here we’re starting simple.

Each, wraps the native forEach Array method, if supported.


  var rebels = ['Luke', 'Leia', 'Han']; 
  
  _.each(rebels, function(rebel){
    console.log(rebel + ' resists the evil Empire.');
  });
  
  // Luke resists the evil Empire.
  // Leia resists the evil Empire.
  // Han resists the evil Empire.

Map, returns the results of operating on the passed in Object/Array.


  var jedis = ['Luke', 'Obi Won', 'Qui Gon'];
  
  var result = _.map(jedis, function(jedi){
    return jedi + ' is skilled with a lightsaber.';
  });
  
  console.log(result);
  
  /*
    [ 'Luke is skilled with a lightsaber.',
      'Obi Won is skilled with a lightsaber.',
      'Qui Gon is skilled with a lightsaber.' ]
  */

Reduce, here we pass in an empty array as the context, to which we push our results.


  var characters = {
    Luke: 'good guy',
    Han: 'good guy',
    Darth: 'bad guy',
    Tarkin: 'bad guy'
  }
  
  var goodGuys = _.reduce(characters, function(memo, val, key){
    if (val === 'good guy') {
      memo.push(key);
    }
    return memo;
  }, []);
  
  console.log(goodGuys);
  
  // [ 'Luke', 'Han' ]

Find, returns the first match in the list.


  var droids = ['R2-D2', 'C-3P0', 'R5-D4'];
  
  var astromech = _.find(droids, function(droid){
    return droid.match(/^R\d-D\d/);
  });
  
  console.log(astromech);
  
  // R2-D2

Filter, here we return all matches within the original list.


  var droids = ['R2-D2', 'C-3P0', 'R5-D4'];
  
  var astromechs = _.filter(droids, function(droid){
    return droid.match(/^R\d-D\d/);
  });
  
  console.log(astromechs);
  
  // [ 'R2-D2', 'R5-D4' ]


Head in the Clouds

Although I’m not ready to make the project public yet, I’ve been working on something I’m calling CZR (Caesar), which is a script that you can include on your page that allows fellow developers, designers or other site stakeholders to up-vote, down-vote and comment on modules that you are adding to a site during a redesign. These stats are then saved as simple key value pairs for review by the design and development team as the site is iterated upon.

I have experimented with a new approach, which has increased my developer productivity a lot. I couldn’t have imagined this workflow a year ago, and it is great to have discovered these tools. I am using Codio as my cloud based IDE, and I am using Parse to handle the database tasks.

Codio uses the Code Mirror project as the basis of its IDE, but there are a ton of other goodies, including their idea of “boxes”, Codio’s way of managing your backend with a wide variety of server side configurations. For example, although my CZR project is entirely Front End (with a simple key value store system managed by Parse), I have another personal project running a full Drupal stack, which is also hosted and edited through Codio. Codio integrates fully with my Github account. It is quickly becoming a go to tool for fast development in the cloud.

As for Parse, I have only just begun to scratch the surface of what is possible on this platform, but so far, their JavaScript SDK has been a seamless drop-in replacement for my Backbone JavaScript code, allowing me to store and sort through my user data with great ease.

It may be an impossible dream to follow this workflow end to end for more complicated projects, but for my work on this smaller sized personal project, it has been a treat. If anybody is using this or a similar set up on midsize to large projects, please let me know. I’d like to know what your experience has been like.


Code Not Code

It seems that a barrier for developers that do not add increasing value to business is a misread of the meaning of the word “code”. Code brings with it a heritage steeped in military computer usage and encryption, so the craft of coding can attract developers who may make evasion and obfuscation their priority. When really we should be using the tools that allow us to talk to computer systems to, as clearly as possible, communicate the intent of the business to the systems needed to carry out the goals of the business.

I’m not entirely eloquent when describing this misalignment in some developers’ motivations, but I still think that it is valid.


Lessons in Jugaad

This article from the New York Times is great.

Here are a few takeaways which translate from the world of space exploration on the cheap, to web development.

1. “Ours is a contrasting, inexpensive and innovative approach to the very complex mission…Yet it is a technically well-conceived and designed mission.” : Doing things quickly and cheaply does not have to sacrifice forethought and careful planning.

2. “If necessity is the mother of invention, constraint is the mother of frugal innovation.” : To what extent is it possible to look at the limitations imposed by the project timeline as a catalyst for creative problem solving?

3. “India’s ‘late beginner’ advantage was that it could learn from earlier mission failures.” : When others have tried and failed, we can look to those experiences as lessons. Where others have succeeded, we can also leverage those existing Open Source code bases.

4. “The building blocks are kept the same so we don’t have to tailor-make for each mission…Also, we have a ready backup if a system fails.” : Similar to number 3 above, how do plugins, modules, etc. that already exist, benefit developers as re-usable components? This probably seems obvious.


The DOM Platform and the Demise of HTML5

About a week ago, this commit was made to the WHATWG DOM Platform spec.

For some developers, the sounding of HTML5′s death knell may come not a moment too soon. HTML5, with the native browser functionality and semantics that it brought, was also accompanied by pretty silly levels of misinterpretation, “buzz-wordiness” and jingoism on the part of misinformed executives and dev shops looking to cash in on “HTML5 fever”.

The DOM is what we work with, and whether we’re using a section tag or *gasp* a div, the point is that it is the basic framework that drives the web apps that we have come to take for granted, and for the foreseeable future, will be the skeleton that give structure to most web experiences. So call it like it is: it is the API, it is the platform, it is the work horse of our apps.

I look to the living standard with optimism.


Turn Up the Signal, Wipe Out the Noise

Too many people working with code neglect the “I” in “IT”. The tenets of Information Science hold true in our profession. Signal vs. noise is the name of the game.

Is it insignificant that a project like Sass provides us the option to eliminate “noisy” curly braces? I don’t think so.

Even in crazy-gigantic open source codebases, there is the opportunity to turn up the signal.

There’s a lot of noise out there, kiddos. Keep your ears open and your code focused and simple.


Ubuntu and System76 Over the Past Year

I thought it might be cool to share my experiences with my System76 laptop over the past year.

First off, I thought battery life might be a problem but it really hasn’t been, so that’s turned out to be a baseless fear. No worries there.

What has been spectacular for me is continuing my work as a developer using primarily open source JavaScript libraries and PHP, but doing that on top of an open source operating system. I’ve done a lot of thinking about it and it seems to me that if you are leveraging and committing to open source projects it makes sense to take the next step and move to a fully open source work flow, down to the operating system that you run day-to-day.

Now how does that fit into my workflow of my job as a developer in an enterprise environment? In a word the experience is nearly seamless. I ran into one hiccup one morning while away at a conference when I tried to join a remote screen cast from on the West Coast for a meeting that was taking place back at the office on the East Coast. Any other work I’ve needed to do during that sojourn on the road was great. My go to IDE for my work (IDEA’s PHPStorm) works great on Ubuntu.

My only non-open source install has been the Oracle Java SDK, which I have needed for a particular browser plugin that I need for my work, but that was easy to install from the command line.

I have started a thread on AskUbuntu about the seemingly buggy integration of AIM into Empathy, but I’ve been using Pidgin instead, and that’s fine with me.

For my personal development work, it is great working on an OS that is not only open source, but seems to me to have one of the best package management solutions available. The Debian apt-get tool has been pain free and a joy to work with. And being able to work with a POSIX style OS after having cut my teeth on the MacOSX command line is awesome.

So working in Ubuntu on a System76 laptop gives me the opportunity to do real work for my job, extend my professional knowledge during my personal development time and feel good about learning more about the open source world in the process. It’s been a winning scenario.

Finally, the responsiveness of the System76 customer service team and the rapport on the Ubuntu forums has only made the journey sweeter!


You Can’t Force Open Source

I’ve been inadvertently living off of the progress made by the open source community for my entire career as a web developer. And while I haven’t given back nearly as much as I should, I have been spending a lot of time thinking about “what it all means”.

For me, when I have reflected on my most productive time spent working with any new technology or code base, it boils down to being directly proportionate to the degree to which that technology is open source.

I am so convinced of the effectiveness of open source solutions over closed technologies that I consciously seek out opportunities to introduce open source into my work as an end to itself. Switching to Linux as my main operating system for my personal work, as well as for some of my “day gig” work has also been eye opening.

It is a journey that reached a water mark this year, and has me resolving to give back as much as I have taken over the years.


This Front End Ops Animal

Up front, this blog post would not exist without the amazing work and progress towards pushing the Front End Ops agenda by such trailblazers as Wesley Hales and Ryan Bridges, who gave a cool talk at the Velocity 2013 conference in Santa Clara, California. Of course there are countless awesome developers committing to the projects associated with this trend.

That brings us to an interesting point made during this talk, which is how do we serve our assets in a logical way, to take advantage of caching and minification as best we can. That is, why would we minify all of our CSS or JavaScript assets into one CSS or one JavaScript file with every build, when logic would dictate that there have only been some incremental changes to some of the discrete files that make up the larger, compounded, minified file. For example, why minify everything into one file if the source of our baseline libraries (CSS boilerplate and resets, JavaScript libraries such as jQuery and associated plugins) does not change? If we minify all of this and redeploy to one CSS file and one JS file with each deploy, we are invalidating the caching mechanism and effectively forcing new downloads or our new minified assets to all users after each deploy.

Once we have sorted out how we plan to manage our assets, only minifying and redeploying the essentials with each build, how can we baseline our progress? There’s a great tool called LoadreportJS (GitHub repo is here). Additionally SpeedreportJS gives us some additional visualization tools. Both of these JS options rely on PhantomJS (which gives us a headless WebKit instance, scriptable for automated client side web page testing).

When it comes down to it, these tools give us the opportunity to get a baseline on our specific web application, and that is an essential point. Each application is its own unique animal, and we need to establish that unique point of reference, rather than compare it to other reports or trying to establish some sort of generic target performance metric, which would be neither here nor there. So a concrete, individualized zero state and target end state needs to be established for each unique application. That is essential.

So that’s an interpretation of the break-neck pace of the evolving front-end ops role from here on the ground. I’m fascinated by the fast moving rate of progress in this space. I’ll be doing my honest best to integrate these learnings in an effort to merge ops tasks into my more traditional front end developer work-flow.