Monday, May 7, 2012

Visual Studio Keybinds Front-End Engineers Use


After being in Microsoft land for the past year (I joined RESAAS, primarily a .NET shop), I've grown attached to Visual Studio. It's an amazing IDE. In the last 5 years, I was primarily on Mac OS X with TextMate/Vim so I grew used to using keybindings to increase productivity. With Visual Studio, I realized that the only way to be productive is to use keybinds! Visual Studio without keybindings can make it almost impossible to use as the menus are nested beyond 2 levels. That said, I use Visual Studio for JavaScript and HTML. Everything else like SASS, CoffeeScript, and NodeJS, I use Sublime Text 2.

Below are a few different keybinds I use on a regular basis. I'm sure that these will change in the future once Windows 8 launches and every developer will have Visual Studio 2011 in their hands!

Key Bind Description
Control + , Go To File - When you're working on a large code base, it's easier to just navigate to the file.
Control + Shift + F Search Solution - Quickly find any string in the solution or project
Control + M -> L Expand all braces - When opening up certain files that have collapsed views
Control + Shift + B Build Solution
Control + Pause/Break Stop Build
Control + W (custom keybind) Close currently opened file
Control + K -> D Format document (braces, alignment, etc)
Control + Shift + S Save all documents in solution

With the above, I'm sure there's more keybinds that can be integrated, such as, binding JSLint/JSHint, or auto-running Chutzpah (JavaScript test runner), or getting the current directory's git status.

I thought I'd share out a few of the keybindings I use on a day-to-day basis in Visual Studio that help me be productive.

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 helping developers in the Windows Azure NodeJS community.

Sunday, May 6, 2012

The Cost of Continuous Delivery


Continuous delivery is a process in which developers can land features on master (or trunk if you're on subversion), have it run through continuous integration (unit tests, user interface tests, service layer tests), have it propagate through the various stages of your deployment pipeline and have it on production in short matter of time. It sounds great because you'll never really need an ops team anymore and really dispels the need to have iterations (in 2 weeks, a feature lands, instead, a feature lands when it lands).

A build pipeline like that saves money for the company in that respect and makes it so that engineers can react more quickly to problems without having to go through layers of communication; however, it surfaces many more issues. As a software engineer on a fast pipeline that is continuously delivering to customers, it is increasingly more important to have test coverage. Below is a list of aspects of testing that need to be seriously thought of
  • Unit Testing
  • Web Service Testing
  • User Interface Testing
Taking a step back, in order to really take continuous delivery seriously, we should always look at the true value of having automated tests. Here are some of the core principles of automation testing:
  • To protect our users from misbehaviours in the system (never cause distrust between the product and the customer)
  • To be vigilant on any changes to the source tree (new and legacy code can be fractured easily)
  • To be able to verify functionality in an automated fashion without increasing engineering manpower (reducing costs -- people are the most expensive aspect of running a business)
With the above, automated tests in a continuous delivery model should now a part of the feature itself. Without tests, it is not a feature and it should not be able to land on production as it would be too much of a risk to the product and the customers. The most difficult part of absorbing the cost of continuous delivery is convincing the stakeholders that the new model is faster but needs more checks along the pipeline. This cost of continuous delivery (Jidoka) includes

  • spending time writing unit tests
  • spending time writing service layer tests (assuming your platform follows SOA, validating inputs/outputs of data)
  • spending time writing user interface tests that detect defective user flows (registration, updating profile, etc)

In the end, following the guiding set of principles of Jidoka allows your engineering teams to produce high quality features by detecting defects along the pipeline and ensuring there's fixes in place to keep the pipeline pushing forward.

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 helping developers in the Windows Azure NodeJS community.

Saturday, May 5, 2012

Front-End Release Management: Unit Testing


This is a small part of a series of "Front-End Release Management" blogposts I'll be writing.

Unit testing allows your developers to protect pieces of functionality in the application from misbehaviours. It is extremely important on groundwork (analytics and frameworks).

Before diving into the tools that we're using at RESAAS to achieve continuous integration with our JavaScript unit tests, let's go over some of the core goals:

  • Easy to write tests
  • Fast to execute tests
  • Easy to integrate into Jenkins (CI)

Our front-end engineers are extremely talented and experienced with JavaScript, CSS, HTML5 -- that said, if we introduce a tool, we need to keep the toolchain as streamlined as possible and in alignment with their skill-sets. JavaScript is natural to any software engineer. It is fast (based on V8, Chakra, and Nitro), it is easy to understand, and it is very easy to pick up if you're coming from a designer background or from a purely back-end background.

In part of the testing initiatives, we investigated different test frameworks, such as, qunit and Jasmine BDD. In the end, we decided on Jasmine BDD partly because of its expressiveness (using a business-centric lexicon/vocabulary). Here's an example of what Jasmine BDD has to offer in regards to readability and ease of use in writing a few specs:


As you can see above, things are simple. Jasmine BDD is so simple that it's rather easy to start doing targeted code generation (partly because of its nesting describes). For example, our analytics library called Arbiter has roughly 700 generated specs to ensure that event tracking behaves the way it is supposed to depending on the user interactions being specified.

In continuous integration, we've hooked up our roughly 2,000 unit tests to Jenkins. The guts of the test runner is just a C# test class, which talks directly to the Chutzpah executable. Chutzpah then runs all the specs and returns the output to the C# Test class, which ensures that all tests pass. Additionally, Chutzpah is very easy-to-use within Visual Studio. It lets you right click a folder of specs and executes them and streams the results to the Visual Studio console. Below is a diagram of how it works.



It's that easy. We've benchmarked our specs and so far we're seeing a few thousand unit tests run in less than 10 seconds. At the start of the blogpost, I outlined "fast to execute tests" as part of our core design goals. Ultimately, development and testing tools need to be fast and the faster we can react to misbehaviours in the code, the faster we can fix it.


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 helping developers in the Windows Azure NodeJS community.