Jerome Covington: Dev

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.

An Open Stack, from Top to Bottom

What would it mean for all of us to use an open stack, from top to bottom? Once we loose our paranoid grasp on straws made up of proprietary systems, what is left for us to hold? Would we float free for a moment, suddenly disoriented, then newly stable as we found our sure footing? Would we stand tall, knowing that the systems that we employed were not snares or traps? And then: as long as these questions are unanswered for a single one of us, how can any of us rest?

Tend to the Garden

There’s really only one thing that will doom the codebase, and that is neglect. As you know, there is an abundance of tools and libraries out there, especially in the JavaScript community. Sometimes you’re locked into using older versions for any number of reasons, some internal. Ultimately the most important thing you can do is remain attentive to how the codebase is growing and take any and all opportunities to prune and shape the plants in the garden. There’s endless work to be done. Don’t push back against the urge to nurture. As with life, code can only grow better and more workable with positive attention.

System76 and Ubuntu Have Been a Wonderful Experience

I haven’t spent too much time crowing about it to my friends, but earlier this Winter I purchased a laptop from System76.

I could go on and on about specs and performance, etc. etc. but suffice it to say that I bought the Pangolin Performance model with slightly more than standard RAM. The laptop has performed extremely well for my development tasks. I am continuing to run Ubuntu 12.10, and the OS has proved to be a pleasant environment to work in.

I use this laptop, and a small netbook running Ubuntu 12.04 for all of my personal projects, which center around JavaScript and some side explorations into Python.

An unexpected side effect of the laptop and OS design has been a removal of clutter from my personal development workflow. My process is now more streamlined and focused. Thanks System76 and the Ubuntu OS community. You’ve won an avid enthusiast and supporter!