Fusioncube

The online journey of a technophile, by Steve Brownlee

I joined Lonely Planet in March 2014 to help with the transition from being a traditional book publisher to a digital content powerhouse. It was a tremendous risk for me because there are technologies here that I’ve never used before, and I’d be back in the business of producing code for a public site that is visited by millions of people. I’d spent so many years producing business applications for much smaller sets of customers

After speaking with the leadership team in place at the time, we agreed that we could help each other and I joined the team as a senior technologist. I’ll admit that it was a rocky start as the roiling changes to people and processes that were happening made it hard to get my bearings on how best I could help the team. Luckily, after speaking again with the leadership team, goals and plans were developed to steady the ship quickly and start moving forward as a coherent team.

Now, I didn’t join to manage a team. In fact, I wrote at the time that I didn’t want an official management position. I joined to mentor other teammates. I wanted to help other developers advance their skills without any kind of imaginary boundary between myself and them.

Then the day came when it was suggested that I become The Manager, and the other developers Report To Me. I thought about it almost constantly for two days, and had many discussions with my wife about it. Then, I agreed, and I haven’t regretted a single minute

Here’s why.

I realized that there isn’t, and shouldn’t be, a distinction between a mentor and a manager. With the way I’ve approached it, the only “manager” thing I do is approve time sheets. Everything else I’ve done with my teammates had the goal of making them better developers, more engaged and excited with the work we’re doing, and opening the door for them to become leaders themselves.

My singular goal, in fact, is to support them and be their advocate.

  • Make sure they have no obstacles in their work
  • Make sure they work together well as a team
  • Be a sounding board for their frustrations and aspirations, and help where I can with both
  • Protect them from useless/distracting information
  • Increase their skills so that they can excel, not only on our team, but in all their future jobs
  • Encourage them to get involved in the community, if they wish to do so
  • Teach them how manage time and research information

It’s a responsibility that I take very seriously, but I also try to have some fun while doing it. To borrow a quote from one of my favorite philosophers, I’d like to think that this is my ultimate goal.

“When the best leader’s work is done the people say: We did it ourselves.” – Lao Tzu

Published on Wednesday, Sep 10,2014 | 2 Comments

For the TL;DR version (which skips my long winded trip down memory lane) go directly to the Future section below.

We’ve had this dream since 1997

Fragmentation.

It’s the dirty word of the web application and services development community. We’ve got plenty of it. Now that doesn’t mean that companies and OSS communities haven’t tried to help us out. They really have. Sun, Adobe, Microsoft, and Google have all put massive resources and weight behind trying to be the One True Platform of the web.

The problem always was the money keeps getting in the way. Every vendor keeps trying to lock in the developer community to their own opinionated platform because, of course, their ideas are the best (and in many cases, just so happens to support corporate profits).

Let’s take a look back and see where we’ve been and how we’ve tried to accomplish the dream of a common platform for the web.

Java Applet (1996-1999)

Ah, the language that everyone loves to hate, right? Well, not everyone hates it but web application developers who have more than a few years experience tend to have a deep-seeded loathing of the language.

Why is that?

Well, it may have something to do with Java Applets. Now, for those who weren’t around in 1995 when the Java applet was introduced to the language, you won’t have any context for the rise and fall of this very first attempt at a common platform for the web.

Many of you have likely never even seen the <applet> tag in an HTML document before, and you might want to count yourselves as lucky.

In fact, even before that – before web application development I mean – there was Windows development. Now before the World Wide Web came along and first started its disruption of the desktop OS, Windows developers were battling (and continued to battle for at least 5 more years) something called DLL Hell. Oh, I think back on it with sentimentality now, but I still remember how frustrating it was.

Well, Java Applets became their own version of DLL Hell as some browsers would support them, and others wouldn’t. Then only certain versions of certain JVMs would be supported on certain browsers. Then, as always with a new technology, the scum of the earth found out how to exploit it for nefarious purposes, so you can stack security issues onto the pile.

Then, the first inklings of a community for the web became aware and thoughts such as, “we shouldn’t be depending on third-party plugins,” and “the web should be open and not running binary applications where you can’t see the source code” started to enter our collective consciousness.

As quickly as it burst onto the scene, the Java applet quickly withered as the savior of the web.

AJAX (2005-Present)

With the applet gone, we trudged along the wastelands of the web for a few years, making incremental advances, but nothing really revolutionary happened. Then, in February of 2005, an article was published by Jesse James Garrett titled “Ajax: A New Approach to Web Applications”. I remember the first time I read it. I was working in Pittsburgh at the time for EFI, building ColdFusion and Java applications, with JavaScript powered front ends.

We take it for granted now, but when we were first introduced to it, it was exhilarating. The dream of building true applications became a reality in our imaginations, as we were tired of the multi page paradigm we’d been handcuffed with all these years. Yes, we used frames and iframes to get around it, but XMLHttpRequest (XHR) put an end to all that. All our code could run in the same page without a secret hack we hid from the users.

Then Google Maps came out, and that started the revolution that’s still going on today. It showed the true power of the AJAX promise. AJAX continues to be one of the underpinnings of moden web application development. However, perhaps its days are finally numbered with the WebSockets API Specification rapidly gaining hold in the community and full modern browser support.

Personally, I am entranced by the Meteor framework, and my current application, stackd.io, was originally built in it. Alas I had to migrate away, but in hindsight, I might have been better served staying with it.

Flex (2008-2012)

Man, I loved Flex. For as much as it completely went against everything that I stood for – open web, open standards, and open source – it really was freaking awesome. Finally, FINALLY, we could write desktop quality applications and use the web and browser as the delivery platform.

Of course, it was Java applets all over again, but those same arguments we made to kill to applet, we conveniently forgot when Flex came along. It was oh so pretty… and shiny… and new… and we could build even prettier, shinier things with it. If we had all been 12-year-old girls, the world would have been drowned in one big squeal of delight emanating from the dungeons where they kept the programmers.

However, there were islands of light still fighting the good fight. The W3C, Apache, Mozilla, and other organizations were still pressing on to make specifications that browser vendors could implement, so that we would, once again, be freed of the shackles of corporate underwriting.

Flex is still alive under the guidance of the Apache Foundation, but it, like the applet, has been quickly shuffled off to the fringes of web application development.

Silverlight

As a quick footnote on the whole embedded vector graphics plugin era, Microsoft was late to game (seems to be their calling card since the Era of the Desktop) and released their competitor to Flex, called Silverlight. It arrived on the scene just in time to see the entire platform be disrupted and marginalized.

The JavaScript Boom (2010-Present)

I wrote an article on my old blog back in June 2011 entitled “The World is Changing – The New Landscape for Application Development”. In it, I described a fundmental change that I saw emerging; a change where everything would be powered by JavaScript on the web platform; a platform on which I was betting and still am. Three years my prior, Jeff Atwood proposed a corollary to the Rule Of Least Power, self-named Atwood’s Law, that proposes that “any application that can be written in JavaScript, will eventually be written in JavaScript.”

Even when I wrote my article 3 years ago, people poo-pooed the idea that any and all applications would be written in JavaScript. I believe that many of those applications have since been written in JavaScript and the list will continue to grow. It could be partly because we just aren’t able to see what advances will be made in the future, particularly if we think those changes are threatening.

Now with tools like LLVM, Emscripten, and asm.js, application developers can take traditional desktop applications, and compile them down to highly optimized JavaScript for delivery in the browser.

I’m betting on the web.

HTML5

There are many parts that make up the all-encompassing HTML5 specification, but for web application development, there are a handful that will make a significant impact once adopted across all modern browsers (and many of them already are).

All these new features of web browsers will allow app developers to make richer user interfaces without having to jump through all the hoops we’ve been using for years, and will reduce traffic and memory usage.

Mobile Revolution

Not since the introduction of the World Wide Web to the average consumer has there been such a fundamental disruption to our daily lives, and the life of an application developer. The fact that we all carry powerful computers around in our pockets that take pictures, record HD videos, let us deposit checks, play good games to pass the time, keep up with our friends, provide GPS directions when we’re lost, hold every bit of information we have about our friends and family, check the weather, find a restaurant, read the news, and the million other things we can do with a computer is still astounding to me.

In fact, why we still call them “mobile phones” is beyond me. They should be called “pocket computers”, if anything. I rarely use mine for making phone calls anymore.

One thing that you might not have considered is that the recent advances in application development for the web have been driven by the mobile revolution. Responsive designs, media queries, local storage, location data… all these things are being driven by mobile revolution. I doubt many of us would have cared about those things without the existence of pocket computers.

With HTML5 and mobile development still in its infancy, we’ve yet to see the amazing things that will come out of them, and there will be amazing things; I just don’t know what they are, but I’m excited nonetheless.

What does the future hold for us?

The Future

I’m excited about the next few years of application development for the web. I’m not even talking about native mobile app development, because I still believe that the web will win. Native mobile applications will always be needed, much the same as native desktop applications will always be needed, but over the next decade, the tools and infrastructure will continue to be built to make the web the main platform of distribution for applications.

It may not seem like it now, but there’s a massive community of very bright people working very hard to make it a reality. Just because it doesn’t exist now, don’t let it limit your imagination.

Web Component Platform

I really want the web to be an open and cohesive development platform. A lot of other really dedicated and smart people want the web to be an open and cohesive development platform. But what does that really mean? Here’s what I’d like it to mean.

  • I want to as easily include and use UI components as a Node.js developer would include and use the file system – var fs = require('fs');.
  • I want there to be one component repository and management tool that handles publishing and consuming components (ok maybe there’s two to be realistic, but I’m dreaming here). Think of npm for Node developers, and bower for packages.
  • I want these components to be as granular as possible, without dependencies on any other component, parser, or generator, but still have the flexibility to have logically grouped components be available as packages. For example, if I want to include the entirety of the Angular library in my project, I should be able to do so, but if I just want to use the data binding, but not all the other features, I should be able to do that as well.
  • The components should be written in a way that they can be easily used by a build system, or task runner, for concatenation and compression.
  • The components should not include custom styling by default, but can provide some, if requested.

Why don’t we have this already? Well, the answer is simple. We just haven’t gotten there yet, but we are getting there. For me, the most important aspect of the HTML5 specification is the Custom Elements. The point of this feature is to allow web application developers to build custom, self-contained components that will be rendered right in the DOM of an HTML page.

For an example, this would be valid syntax and would render a list of bananas.

<html>
   <head>
      <link rel="import" href="lib/bananaWorld/bananalist.html">
      <link rel="import" href="lib/bananaWorld/bananatype.html">
      <link rel="import" href="lib/bananaWorld/bananaorigin.html">
   </head>
   <body>
      <bananalist>
         <bananatype></bananatype>
         <bananaorigin></bananaorigin>
      </bananalist>
   </body>
</html>

Polymer

One of the first projects that I found that is trying to tackle this new frontier is Google Polymer. It provides a large library of already-built components that you can try out. On top of that, Polymer is intended to be a next generation framework, by implementing all of the specifications from HTML5 that it can, while having polyfills for those that it can’t.

It’s a truly ambitious project, and, if combined with some other tooling (which I’ll discuss below), my dream workflow will be a reality.

Brick

Now Mozilla, who I’m a huge fan of, has also started their own project called Brick which, while not as ambitious as Polymer, is also tackling the challenge of creating a library of custom elements for use in web applications. The reason I really like Brick is because of Firefox OS which shares my belief of betting on the web.

We’re getting very close to having a complete development environment in the browser, supporting web applications built on a common, core set of UI components that are reusable, interoperable, and composable.

It currently has components like:

Not a whole lot right now, but we are just getting started.

component.io

Back in 2012 T.J. Holowaychuk published an article about JavaScript components in which he proposed a detailed vision for delivering encapsulated components that can be used, and reused, in any JavaScript application. He elucidates how current package managers like npm and bower aren’t really fulfilling this need, and are simply buckets that hold everything from single libraries to entire frameworks that can be included in projects.

I urge you to read his entire article, but my own TL;DR version is this; stop publishing opinionated libraries and components. Make things as composable as possible, with the minimal styling possible, and as encapsulated as possible. If you want to publish a framework, it should be comprised of standard components itself that can easily be pulled out piecemeal, if needed, and included in another project.

This is a completely new way of thinking about front end development. Those who have experience in “backend” development are familiar with this style of writing software. The tenet of writing composable classes and functions that do one thing, one thing only, and do it completely independent of any other class or function is exactly what we should be doing with components.

Both npm and bower moved the entire front end software industry forward, and are integral parts of our development and ops workflows, but we can’t divert our eyes from the real goal.

Based on the vision from T.J.’s article, there are now two tools that are the move in this new direction. First is component, which is the CLI tool you can use to pull and publish CommonJS components. There’s also the component.io web site that let’s you search and browse currently available components.

This kind of tooling is what is needed, in conjunction with libraries like Polymer and Brick, to make web development more standardized, more cohesive, and more understandable. Then will come the arduous task of creating editors and IDEs that pull all this together for developers.

We still have a long road ahead of us, but at least we’re on the right road now and driving along.

customelements.io

There are now some sites like customelements.io that are trying to aggregate components that are being published so that front end developers can get their feet wet building application on top of them.

WebComponents

Another great aggregation site is WebComponents.org where you can read the specs, browse articles about custom elements, watch presentations, keep up with current browser support, and see links to libraries that are being created to leverage these new technologies.

sweet.js for those non-web type developers

If you haven’t yet, you really need to check out sweet.js. To prime you, think of CoffeeScript or TypeScript. Those syntaxes are sugar on top of JavaScript that allow you to write code in a more concise way, but then compile down to pure JavaScript for deployment.

Now, I’m not a huge fan of learning a completely new syntax for writing an entire JavaScript application because I feel it’s a level of abstraction that is too large to make up for the conciseness of the syntax. That said, I do believe that using sweet.js macros to make some parts of JavaScript application more standards compliant would be a good thing.

Let me explain that in more detail.

There are two competing standards for how to build modular applications right now – AMD and CommonJS. Now, I prefer AMD because of its pervasiveness, but I also like CommonJS because of its cleanliness. For those developers who are used to Python, or Java, or {name language here} that are used to a syntax like…

import os  
import sys  

or

import java.io.*;  
import java.util.*;  

We can use a sweet.js macro to write JavaScript code like this

import twitter.bootstrap.form;  
import twitter.bootstrap.button;  
import knockout;  
import sockets;  
import express.router;  
import box.DataStore;

var init = function () {  
   var CloudStore = DataStore.createCollection("cloud");
   CloudStore.populate();
};

and have this produced from it

define([  
  'twitter/bootstrap/form',
  'twitter/bootstrap/button',
  'knockout',
  'sockets',
  'express/router',
  'box/DataStore'
],
function (form, button, knockout, sockets, router, DataStore) {  
   var init = function () {
      var CloudStore = DataStore.createCollection("cloud");
      CloudStore.populate();
   };
});

In this specific case, the macro would convert those import statements into AMD style module definitions, but could also produce CommonJS style composition – whichever you use in your applications – and now the source code looks more comfortable developers from other languages, thus making it easier to understand, without having to learn a completely new language syntax on top of JavaScript. The rest of your application would be written in native JavaScript.

Betting on the web

I’ve used this catch phrase a couple of times in this article, and I’m not even sure where I picked it up, but I’m a firm believer in it. There’s a whole lot of passionate, articulate, talented, intelligent and motivated people who see the web winning for application development. Progress continues despite the naysayers. New tooling is being developed despite the short sighted. It’s the long play, and having a shared, common vision that includes making standards, fighting fragmentation, and resisting corporate self-interest will make that play successful.

It’s the long play that’s currently in its 17th year of strategy rollout. It’s had its ups and downs, but over time, the final goal has remained consistently in sight.

The future is in your hands

The future of the web is in your hands now – you front end developers who are just starting your journey. Front end development will be entering its Golden Age soon (heck, it may have already started). More companies are realizing that they need people who can make cohesive, high-performing, scalable, resilient web applications that can serve multiple delivery platforms (desktop/mobile/TV) and engage with customers.

My time will be ending sooner than later. I’ve been doing this for over 20 years now, and I’ve been spending a lot of my time lately passing down skills and wisdom to the next generation of developers. I still am deeply passionate about keeping my finger on the pulse of what’s currently available, but lately I’ve been shifting my efforts towards helping out with what may come.

It’s time to start thinking about how we, as a community, can further the goals of the World Wide Web as the greatest development platform ever conceived. It may not seem like it on a daily basis, but the choices you make today may have a deeply profound impact on how the web platform evolves. Are you going to help it or hinder it?

Choose wisely, my young padawans.

Published on Monday, Mar 3,2014 | 4 Comments

I stumbled across a great article today that described how we can customize our Chrome Dev Tools interface. Since dev tools is all HTML, CSS, and JavaScript, then all we need to do is apply some new CSS in a particular file (see article for details).

I love the Solarized Dark theme, and have both my terminal and my Sublime Text editor in tha, but for Chrome, I chose to go with the Solarized Light theme.

So here’s what my dev tools interface looks like now.
Styled Dev Tools

Published on Thursday, Aug 29,2013 | 1 Comment

No Higher Form of Praise

When people call me a geek, I take the moniker with pride and own it. I can think of nothing nobler than having a passion towards science, technology, engineering or mathematics (STEM). These are the fields upon which all of modern society is built, and all other fields obtain their advances.

I feel it is one of my core duties as a father to install that passion in my girls. I am exposing them to science, and technology at every opportunity. I also am proudly watching my oldest daughter obtain a healthy, natural talent for mathematics. My bubbly, glittery, overly-talkative 7 year old girl who was talking full sentences at 1 year old has been doing basic multiplication and division while she struggles with writing and reading. The complete opposite of what I envisioned her skillset to be.

She is well ahead of what they are teaching in class. I have been teaching her at home, and it’s a lot of fun watching her skills blossom.

Why Are Leaves Green in the Summer, but not in the Fall?

So today, we a starting the experiment that will teach them about chlorophyll and why leaves change colors in the fall.

Setup

2013-08-25_15-43-40_981

Mashing and Cutting

2013-08-25_15-42-36_47
2013-08-25_15-42-45_473
2013-08-25_15-59-27_115-MOTION
2013-08-25_16-00-05_967-MOTION

Cooking

2013-08-25_15-43-00_450

Outcome

Ok, it ended in total failure, and I have no idea why. I remember doing this experiment as a child and it working perfectly. I set the jars out to let the alcohol dry, but when it was all said and done, all that was on the coffee filter strips was a thin green line. No yellow, no red… nothing else.

So we’ll try again next weekend and perhaps do a better job of mashing up the leaves. I just let the girls rip the leaves apart into tiny shards, but this time I’ll get them to mash it all up into a paste.

Regardless, they both had fun with the experiment and I at least got to explain to them why the coffee filter absorbed the green chlorophyll via the alcohol.

Published on Tuesday, Aug 27,2013 | 2 Comments

Saturday

Keynote

Paul Jones did the keynote this year, and while the content wasn’t particularly new, I will say that it was curated and presented in a way that was exciting, inspiring and thought provoking.

He did a fantastic job.

The general theme of the talk was for technologists to understand the power they have, and to teach other people how to treat them. I’ve done this for many years and I try to pass on my wisdom to as many people as I can. Unfortunately, not everyone is ready to listen. So many technologists work untenable hours, say yes when they know they should say no, don’t demand to be part of the planning of work. Basically, see themselves as just employees who should accept the arbitrary whims of “management” as if they hold superior power in the relationship.

It’s an equal partnership and you should expect to be treated with that respect. You are trading your highly desirable skills for money. Pure and simple. Project managers, vice presidents and directors can’t create the foundation of the company (meaning the software being sold), just as technologists can’t go out and perform the tasks of marketing the product, selling the product, establishing business partnerships, and accounting. Neither can survive without the other.

If you are constantly allowing someone else to dictate how much work you can, or cannot, perform in chunk of time without giving your input, then you have some choices.

  1. Keep doing it and hope that it changes – which it won’t. That’s called insanity.
  2. Teach everyone in your organization how to treat you.
  3. Leave.

And if you are fearful of losing your job, then approach the situation from a position of strength. If you find that others are not receptive to you changing the relationship, go find other people who are willing. One of Paul’s points was a quote from a book/movie that I can’t remember was “you need a job, but not this job.”

As technologists, we can always find work. Every day, the world is more and more reliant upon the software that we create.

Session Reviews

I sat through several sessions before I gave my presentation on mobile web app development.

First up, was a talk on Salt. I’ve had plenty of experience since I’ve now built two products on it, and I wanted to see a lively discussion and hopefully share some experiences. Unfortunately, I spent more time working on my own presentation than listening because I still wasn’t happy with it, but what I heard was good. He covered the basics of how to configure minions from the master and handled managed files.

Next up was a talk on JavaScript testing. A very well done presentation on many easy things developers can do to ease automated testing of dynamic JavaScript code – a notoriously hard thing to do. Kudos to Jordan.

After lunch, I sat in on a talk about establishing trust in your work relationships. It was a somewhat interesting topic, but nothing of any real substance was discussed. A lot of common sense topics about how to be a professional and treat everyone you work with with respect.

Then I did my presentation, and for as dubious as I was about how it was all going to flow, I was surprised how it ended up fitting together. I was also concerned with the fact that I was covering four different frameworks. While I hit my time perfectly, I didn’t feel satisfied that I gave the code part of the presentation enough focus, and I was right, as one commenter noted in his feedback.

I want to give the presentation in a couple more venues and I’ll do some moderate reconfiguring to show more code and talk about building an app with more focus for the next time.

Last up, I attended a really cool talk about gadgeteering. A wooden puppet was manipulated via the laptop with a microprocessor attached to the back and all the limbs. It was a lot of fun.

The People

As always, I saw a lot of old friends, and made a couple new ones. I’m always amazed to learn the ideas and projects that people are working on. It’s very humbling because just when I think I’m doing something cool, someone tells me about something that makes me jealous.

And though I didn’t get to talk to him, Cal Evans pulled off another fantastic event. Everything went smoothly, he adroitly handled some last minute speaker changes, and made sure everyone was happy and had everything they needed. Thank you, Cal, for stepping up in such a big way to make Nashville that much better for its technology community.

Can’t wait ’til next year.

Addendum:

Many thanks for Jacques Woodcock and Kathy Evans, for they are the eyes, ears, and arms for Cal and made the weekend successful.

Published on Monday, Aug 19,2013 | 2 Comments

About Steve

I am a technologist, and have been ever since 1980 when I got my very first TRS-80 and programmed it to do my math homework. I love to share the gift of technology with others and show them the wonderful things it can do for them, and how they should not fear it, but embrace it.
Find out more about me at Vizify....

Subscribe

Entries (RSS)
Comments (RSS)
beats by dr dre monster beats cuffie beats fitflop italia scarpe fitflop fitflop online ray ban wayfarer occhiali ray ban occhiali da sole ray ban scarpe louboutin louboutin scarpe louboutin prezzi peuterey peuterey outlet