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.
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.
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 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.
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!
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.
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.
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.
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?
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.
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!