Monday, April 18, 2011

Why did I write a microframework?

I've always been passionate about tools that allow developers makes their lives easier and makes things more fun. Speaking from my agency experience, I've taken the time to do health checks of current developers and analyzed their tool sets. It become clear that there was too much fragmentation between what libraries, APIs, and development approaches -- It's not their fault as each project was being run like a separate silo. To a developer that is being tossed around on to different projects, this is a nightmare. Furthermore, I had this heroic goal of dispelling that nightmare and building a shared vision of a converging toolbox to make us (front-end engineers) faster, more efficient, and reduce the ramp-up time when swapping between different projects/accounts.

At that point, Blast Mojo Framework (v2 rewrite based on jQuery and plugin injection) emerged. We needed a better tool that could provide front-end engineers clear functional separation through implementation silos (controllers). My idea was that all controllers should load asynchronously, never be dependent on each other, as well as, only be mounted when specific contextual elements were on the page (componentized approach to software development). If developers wanted to concatenate all their controllers, they would have the freedom to do so in 'production' mode to indoctrinate a 1-javascript-http-request approach for performance reasons.

In agencies, deployment platforms can be different: sometimes .NET, ATG (Java), PHP, or Python. We needed a way to simply be agnostic to any development environment, which led me to creating a very simple template at the bottom your page:

<script src="js/lib/jquery-1.5.2.min.js"></script>
<script src="../dist/mojo.js"></script>  
<script src="js/app.js"></script>

After taking in many opinions from developers across the company about preferred JavaScript libraries, we crystallized the de-facto groundwork library as jQuery. This was more in line with business decision as most of our developers already attuned to its API, as well as, there were many well-tested plugins that could easily be integrated (carousel, modal dialog). Retraining would've caused some serious concerns, as well as, buy-in from a project management standpoint wouldn't have happened including when their projects are already built on top of jQuery.

Inside app.js, you would find the following:

var app = MOJO.create({ baseSrc: 'js/' });

  .configure('pluginSrc', 'js/lib/plugins/')  
  .configure('plugins', ['jqmodal', 'jcarousel', 'pubsub', 'tmpl'])

  .map('#login-example', [{ controller: "ExampleApp.LoginController" }])

It is highly inspired by Sinatra, Express, and SammyJS. MOJO.create() would return you a new Mojo Application instance. configure() allows you to configure your application. In this particular example, we are telling our application to inject "jqmodal", "jcarousel", and "pubsub" -- All three are well respected jQuery plugins and widely used. This approach provides us with more agility over handling plugin dependencies, you won't need to add new script tags or work with a build script to compile everything (but you certainly can, if you want, it's mainly for convenience).

In the next part we are calling map(), which takes a CSS selector as its first argument (which DOM element do you want to map controllers to?) and an array of controllers in the second argument. This will allow to bind multiple controllers to a particular DOM element, useful for sharing functionality, such as, you could map LoginController as well as CarouselController if they have functional commonality.

The next step would be write your controller:
 * @class   Login Controller
 * @author  Jaime Bueza
MOJO.define('ExampleApp.LoginController', {
  events: [
      ['context', '.btn-login', 'click', 'Login']
    , ['context', '.btn-logout', 'click', 'Logout']    
  methods: {
    Login: function(requestObj) {
      var context = requestObj.getContextElement();
      alert("Logged in from " + this.controllerClass);
    Logout: function(requestObj) {
      alert("Logged out from " + this.controllerClass);
  after: {
    Start: function() {
      console.log("Oh hai! I've initialized myself as Login Controller!");

In the above code piece LoginController, developers can quickly see how structured they are. The first thing they can see is an events array, which tells them which events are binded to which elements within its context. In this case, the context is the DOM element $("#login-example"). Blast Mojo will instinctively use event delegation so if your controller blows away its child elements, you won't have to worry about rebinding.

I will be writing more about my adventures in building better developer tools and developing better approaches that will hopefully make developers' lives easier. Agencies can be a rough place and if we start rethinking our tool-chains and educate each other on more mature software engineering paradigms, we can react quicker to changes and make things easier in the long-run.

In conclusion, while I understand the Blast Mojo is more suited towards agency-style deployments, it primarily focuses on distributed software development teams (for web, mobile, tablet) that want to leverage common software engineering patterns: implementation silos, dependency injection, aspect-oriented programming, as well as, publish subscribe (messaging). It is indeed a more mature approach to front-end engineering and provides structure for your JavaScript so that when you have teammates swapping in and out of different projects, they'll be able to identify where controllers are and how to fix/implement features instinctively -- And best of all, it is built on top of everyone's favourite library, jQuery!

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Starbucks, Bacardi, Nike, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Sunday, April 3, 2011

Stirring The Hearts of Your Teammates

Remember, our line has always ruled with wisdom and strength. And I know you will show restraint when exercising your great power. But the truest victory, my son, is stirring the hearts of your people. I tell you this, for when my days have come to an end, you shall be King.

In the world of agencies and corporate software development, there are ladders. These ladders place you where "they" think you belong in terms of rank, power, and responsibility. Being at the bottom of the ladder can have an impact on your teammate(s) -- They feel like they're powerless and that their actions have no overall effect on the product you're trying to build. That said, this causes a snowball effect which is poisonous and will eventually affect the rest of the team. When teammates accept the fact that they're not tightly integrated with the decisions being made, we have ourselves rogue behaviour including low quality of work, less communication, and less contributions. The most obvious answer that most people will tell me is "fire them"; however, I'll explain a few things I implement for a better, sustainable solution for your team. That is, "to inspire them".

While I am borderline focusing on a well known corporate learning disability, such as, "I am my position", I'm going to try and explain my approach to genuinely motivate and inspire my teammates to commit themselves to the same shared vision.

First thing is respecting them as a human-being through selflessness and honour. Even the smallest question, such as, 'What do you think about ____? Could we possibly try your solution but with this ____?' can have a ripple effect on how they perceive themselves as part of the team. Another strategy is to always have eye contact -- it proves to them that your attention is 100% on their opinion. Additionally, you should always give them credit when credit is due. From the smallest bug fix to refactoring a ton of groundwork, giving them praise for their effort and dedication is always required. When things are going well, genuinely let them know that the project wouldn't be successful without them being onboard. Make them know they're worth a million dollars.

Diving deeper, if their mental models are skewed in such that they don't want to contribute work that benefits the company itself; show them that his/her work is what helps the rest of the team whether or not it benefits the company or the budgets. It is very easy to be blinded by death march projects (timelines, changes, budgets, compensation). Let them know that we're all on the same boat and when you are on the battlefield, your team is all you have to finish it -- You need everyone on the front lines to push forward.

These things may seem like basic actions in social dynamics; however, they are easy to neglect. It is the frequent, small actions that have the largest overall impact at the end of the project, much like, the parable of the boiling frog. Often times we forget that we're all human-beings (we are not super heroes) and face the same category of challenges along the way. Getting to the end of the tunnel of a death march project is only possible if you inspire your team to be helpful and committed to each other.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Starbucks, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.