Thursday, December 29, 2011

Windows Azure and NodeJS

When starting at my new home at RESAAS about 6 months ago, I was determined to become a better developer in a Windows environment. Developing in a *nix environment for about 10 years made it so I had to change my way of thinking (package dependencies, scripts, paths, keybindings) which is why RESAAS was a perfect learning environment for me.

RESAAS is a social network for Real Estate Professionals -- we're building a platform that lets them be more open and connected with their colleagues and clients -- and then we build tooling around that to make their everyday lives easier and more simple. That said, the whole platform is built on Windows Azure -- from Blob storage to Compute instances to SQL Azure.

Thinking back now from when I was still at Blast Radius, I've come to realize that I've come a long way in learning about Windows tooling (BACPACs, DACPACs, Visual Studio, MSBuild, SQL Azure, Windows Azure Portal, and much much more). To go even farther that just learning some of the tooling, I stepped up to the plate and gave a talk at the first Vancouver Windows Azure group about developing and deploying NodeJS applications to Windows Azure.

In this meetup, I talked about how seamless it felt going from a *nix environment to a Windows environment when writing NodeJS applications. I also showed the crowd how fast you could deploy a NodeJS WebRole (literally in 6-9 minutes). Furthermore, to end it off, I demo'd a quick URL Shortener application built with NodeJS and Azure Table Storage (Microsoft's NoSQL Solution).

When hacking together that URL Shortener, I was finding that Microsoft's NodeJS SDK for Azure felt like being in a *nix environment -- using Cmdlets in PowerShell felt like any other Heroku-style deployment.

I'm really astonished at the effort that Microsoft is putting into NodeJS -- They've done an amazing job of making it easy to develop, deploy NodeJS apps to Windows Azure.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software engineer 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 writing open source software and creating tutorial videos for aspiring front-end developers.

Thursday, December 8, 2011

New technical direction on this blog!

I've got a few awesome technical posts on Windows Azure and NodeJS coming down the pipeline.

Jaime Bueza is a software engineer 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 writing open source software andcreating tutorial videos for aspiring front-end developers.

Friday, October 21, 2011

Small Thought on A Fearless Flag Bearer

After being on several teams where we've had to ship projects on ridiculously tight timelines, I've come to realize that there is no amount of technical or creative skill that can replace bravery, conviction, and integrity. Sometimes, the only reason why Death Marches get completed is because of the three attributes of a person (bravery, conviction, and integrity). What I do find is that the people out there, on the battlefield, shipping these whirlwind projects and trying their best to nurture these fractured client relationships are the only reason why great companies exist. It's the heroes that keep them alive. It's the heroes that set the bar. It's the heroes that inspire their teammates with confidence about the overall vision.

When people write articles about how the world doesn't need heroes due to the unsustainable nature of a fearless flag bearer, one can argue the opposite. Teams always need heroes -- someone to look up to. Someone who treats his or her underlings like gold and mentors them to his or her level of tactical, strategic, business, technical, and creative mastery. Someone who sacrifices everything they have to ensure that the team meets their goals. Someone who is fearless in the face of despair but knows how to show kindness, empathy and stewardship to his/her teammates. Someone who is able to listen and heal their teammates' attitudes and mental focus. Lastly, a hero is someone who never gives up even when people have told them that it's hopeless.

I was once told that leadership isn't what you do -- it is who you are. It's how you carry yourself into battle and how you treat others. All leaders have a guiding set of principles that they follow and they understand it's an eternal practice -- a life-time discipline.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software engineer 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 writing open source software andcreating tutorial videos for aspiring front-end developers.

Tuesday, July 26, 2011

JavaScript is the assembly language of the Web



In my last blog post, I outlined how clever developers are starting to use CoffeeScript as a way of moving forward with Harmony (JavaScript's newest spec that improves the lexicon to be more productive) without breaking current browser implementations of ECMAScript by leveraging transpiling techniques. Concordantly, there are other transpiling tools now for C# (JSIL) and Python (Skulpt). Furthermore, I've come to realize now that based on these initiatives, JavaScript is now the assembly language of the web platform. It is fundamentally and ultimately a compilation target.

ChromeOS is a Linux-based operating system but makes heavy use of their V8 JavaScript engine. Additionally, Mozilla has stepped up and announced that there are plans to create a web operating system to compete with Chrome OS and Windows 8. I've compiled a list of technologies that have indoctrinated the HTML5 family including WebGL, WebSockets, JavaScript, CSS, HTML:

Palm Pre: HTML/CSS/JavaScript with Mojo application framework
Apple iOS through WebView: HTML/CSS/JavaScript
Apple iOS iAd: WebGL/HTML/CSS/JavaScript
Android WebView: HTML/CSS/JavaScript
Chrome OS: HTML/CSS/JavaScript with File API for File I/O
Windows 8: HTML/CSS/JavaScript for application development
Windows 7: Using Chrome/Firefox/IE10 for HTML/JavaScript/CSS -- almost full support, perhaps no WebGL implementation for Internet Explorer.
Mac OS X: Same as above

Four years ago, there was the war of the JavaScript libraries including jQuery, MooTools, YUI, and Dojo. While it does seem like jQuery has triumphed over the other libraries in terms of popularity, will jQuery be used a de-facto Application development library (or perhaps an application framework built on top of jQuery like Backbone.js or Blast Mojo) in the upcoming Operating System war?

Now is the time to start thinking about more abstraction on top of JavaScript. In our current state, we've got SASS for CSS, which again, improves productivity by providing developers capabilities of mixins and mathematical functions, CoffeeScript for JavaScript, which aims to sweep away the bad parts of JavaScript and allow for higher levels of productivity, and then we have Haml/Jade/Razor for HTML to make writing structured content easier.

Winter is coming. There's going to be another exciting paradigm shift in how we write and organize our applications in JavaScript when Windows 8, Chrome OS, and Mozilla OS become more widely used for several reasons: File I/O, Audio, Video, Capture (WebCam, Microphone), Network (XHR or WebSockets), Games with OpenGL (WebGL), and Graphics (SVG/Canvas). My only hope is that in the future, developers will be given the avenues to write code in their favourite language whether its C#, Python, Ruby, Java, and have it safely transpile to JavaScript because sustainable productivity is only achievable if you really enjoy what you're building or designing.

Jaime Bueza is a software engineer 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 writing open source software andcreating tutorial videos for aspiring front-end developers.

Sunday, July 24, 2011

CoffeeScript and the future of JavaScript



We're in an age where there are several ways of "transpiling" languages. If you're not familiar with transpiling, it essentially allows you to write in one programming language and have that converted into another programming language. Ultimately, the primary goals of writing code in higher level programming languages is to achieve productivity. A great example of this is CoffeeScript, Skulpt, and JSIL. CoffeeScript's initiative is to ensure the developer stays within the bounds of JavaScript's "good parts" and pushing forward a Ruby/Python-like syntax where we lose flower brackets({}) and "function" and we get extensive use of "->". Here's an example of writing a class in CoffeeScript:

This is the transpiled JavaScript:

One thing to note is that web browsers of today won't jump on board with upgrading their JavaScript engines to support newer versions of JavaScript (Harmony) due to backwards compatibility. This seems like a path that can't be traversed. In order to evolve and move forward with JavaScript, the only way to do so is to transpile it that way you can still keep backwards compatibility, as well as, leverage new language features that make the language more productive in writing complex client-side web applications.

CoffeeScript is an amazing project that also encompasses a "roll your own language" feature. It essentially allows you to define your own programming language that will transpile to JavaScript by changing the tokenization settings and returning the abstract syntax tree.

As we move forward, I undoubtedly think that developers will finally be able to write applications in their favourite language whether it is C#, Python, Ruby, or Java and then have that code get transpiled to a target platform whether its for web (JavaScript), iOS (Objective-C), or Android (Java/C++). The main thing is that developers shouldn't have to relearn a new programming language in order to be productive -- They should be able to write it into their language of choice, the language they find the most fun. Additionally, one of CoffeeScript's initiatives is to be a compilation target so you could essentially write a language on top of CoffeeScript (so you go to the side from JavaScript to CoffeeScript, then go up from CoffeeScript to a more human readable language).

Jaime Bueza is a software engineer 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 writing open source software on github and creating tutorial videos for aspiring front-end developers.

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:

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

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/' });

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

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

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() {
      //Initialization
      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.

Saturday, January 29, 2011

Shaping Great Teams on Bad Projects

Ever since I read "The World's Most Powerful Leadership Principle: Servant Leadership", I've felt invigorated about corporate software development. This book has made me change my mental models and perspectives on building great teams on bad projects.

One of the key things I learned from this book was that there is an undeniable difference between managers and leaders. As James C. Hunter says it best, "Management is what you do: planning, budgeting, estimating, organizing, problem solving, and strategizing. Leadership is who we are." Leadership can be defined as something simple as knowing how to inspire your teammates to become better than they think they are. Incidentally, I look at this much like the military. A skilled leader of a unit (usually a Captain or Major, I believe) has the commanding ability to inspire his men to become more courageous and more heroic while in the heat of battle.

"The Heat of Battle" can be applied to software Death March projects: you're in a situation where your team's confidence is deteriorating and their determination to finish the project is fading. From demanding clients, to features that aren't even possible to implement, to teammates giving up on you--these are all products of an environment where "all odds are against you". This is where the servant leadership characteristic needs to be implemented. It is a characteristic and discipline that needs to be practiced over time.

Ultimately, your team members need to understand that they are leaders as well. There is no "lead" the pack. Everyone puts in 100%. Externally to the unit (your production team), there are titles like "Lead Software Architect", "Lead Software Engineer", or "Project Manager"; however, internally they must all understand that they are all equal in value, opportunity, and mentorship. Everyone on the team has a voice and you have to hear them out.

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.