I’ve been using tools like SASS and Compass for a while now, and recently started to dive into bower for doing front-end package management. Let’s take a look at how to integrate Grunt in a very simple workflow.

Be forwarned, I’m quite new to Grunt in general. Some of the things that are done below can and probably should be optimized. I’d love to hear your feedback!

Why Grunt?

Honest answer? Because it seems like everyone under the sun is using it for doing anything from simple workflow enhancements, to complete production build systems. There’s an extremely active plugin development community, and people involved in the project seem more than willing to help out in answering your questions. There may be other Javascript task runner solutions, but I don’t know of any at the moment that are worth taking a look at.

Our goal

Let’s setup grunt to do the following:

• monitor our project for changes to SASS files, and use Compass to compile them into CSS.
• monitor our project for changes to HTML and JS files, and use LiveReload to refresh our page.
• look into how we can use Grunt to minify and concatenate our Javascript using uglify JS.

The basic grunt setup

Grunt has some basic documentation on their website about setting up your project. First and foremost, Grunt uses Node.js and is installed via npm – node’s package manager. Once you’ve got those installed, you’re ready to install the Grunt CLI globally.

npm install -g grunt-cli

If we were to run a grunt in our project directory, we’d get a message something like this:

A valid Gruntfile could not be found. Please see the getting started guide for more information on how to configure grunt: http://gruntjs.com/getting-started Fatal error: Unable to find Gruntfile.

We expected that. Let’s create a package.json and a Gruntfile.js in the root of our project.

touch package.json Gruntfile.js

package.json

Here are the contents of my very basic package.json file:

{
  "name": "my-project",
  "version": "1.0.0",
  "devDependencies": {
    "grunt": "~0.4.1",
    "grunt-contrib-compass": "~0.2.0",
    "grunt-contrib-watch": "~0.4.3",
    "grunt-contrib-uglify": "~0.2.0",
    "matchdep": "~0.1.2"
  }
}

So what exactly does this file do? This tells NPM which dependencies we want to install for our project. The advantages of this are fairly simple. Anyone who collaborates on our project can always be up to date on dependencies and keep our environments in sync. I won’t go into too much detail on these right now. There are plenty of other properties you can place in this file. You can also run npm init to create a boilerplate package file.

Run npm install, and NPM will go fetch these for us and place them in a node_modules folder.

• grunt-contrib-compass
• grunt-contrib-watch
• grunt-contrib-uglify

Fantastic! We’ve got packages! Unfortunately they don’t do anything yet, because we haven’t told Grunt what to do with them.

Gruntfile.js

This is where the magic begins to happen. We’ll open up by declaring the “wrapper” function. All Grunt related tasks happen inside of this function.

module.exports = function(grunt) {
  // Do grunt-related things in here
};

Let’s get started by have the Compass plugin start watching for changes to our SASS files.

module.exports = function(grunt) {

  // load all grunt tasks
  require('matchdep').filterDev('grunt-*').forEach(grunt.loadNpmTasks);

  grunt.initConfig({

    compass: {
      dev: {
        options: {
          config: 'config.rb',
          force: true
        }
      }
    }

  });
}

First, we’re loading all of our NPM tasks that we specified in our package.json. We’re using the matchdep package to help us do this by iterating over the devDepencies in our json file.

We begin configuring your tasks inside the grunt.initConfig({}) block. You’ll see that we define a compass task, and we’re telling Grunt to just load the settings from our compass configuration file – config.rb.

You can specify multiple ways to run compass by adding another object. For example, you could have a “production” object in which you would output compressed CSS, or output the CSS to a different folder, etc.

Let’see what happens when we run grunt!

Warning: Task "default" not found. Use --force to continue.
Aborted due to warnings.

Grunt looks for a default task called “default”, which we haven’t specified. Let’s go ahead and do that now using the grunt.registerTask() function.

This function takes the name of the task you’d like to register, along with an array (or single string) of tasks you want run. Let’s register the default task to run compass and compile our SASS. Add the following after the grunt.initConfig block.

grunt.registerTask('default', 'compass');

When we run grunt again, you’ll see our SASS is compiling!

Running "compass:dev" (compass) task
unchanged sass/app.scss
unchanged sass/normalize.scss

Sweet deal! However, this isn’t really all that useful. We could have gotten the same results by just running a simple compass compile. Let’s keep pushing forward and add a watch task that will monitor changes very similarly to compass watch, but that we can extend to a variety of different plugins.

Go ahead and add a new object that defines our watch task:

module.exports = function(grunt) {

  // load all grunt tasks
  require('matchdep').filterDev('grunt-*').forEach(grunt.loadNpmTasks);

  grunt.initConfig({

    compass: {
      dev: {
        options: {
          config: 'config.rb',
          force: true
        }
      }
    },

    watch: {
      sass: {
        files: ['assets/sass/**/*.scss'],
        tasks: ['compass:dev']
      },
      /* watch and see if our javascript files change, or new packages are installed */
      js: {
        files: ['assets/js/main.js', 'components/**/*.js'],
        tasks: ['uglify']
      },
      /* watch our files for change, reload */
      livereload: {
        files: ['*.html', 'assets/css/*.css', 'assets/images/*', 'assets/js/{main.min.js, plugins.min.js}'],
        options: {
          livereload: true
        }
      },
    }

  });

  grunt.registerTask('default', 'watch');

}

You’ll see that we’ve added a list of files types for Grunt to look for. We’ve also defined the tasks to run – one for now, but this can be an array of many tasks – when a file has been changed. We’ve modified the default task to run watch instead of compass. Additionally, we’ve added LiveReload functionality with a single line of code.

Note: You will need to install the LiveReload extension for this to easily work without having to include another file in your project. Find the extension for Chrome here.

Let’s re-run grunt and see what we have now.

Running "watch" task
Waiting...

Grunt waits patiently for us to change a file, and when we do, we get successful compilation and a browser reload! Pretty cool.

Only the surface

I’ve only scratched the very surface of what’s possible with Grunt. Check out the vast array of Grunt plguins and start doing everything from compressing javascript to running Jasmine unit tests through Phantom JS.

Overview

Wuberizer is an audio synthesizer and step sequencer in one. It works off a 16 x 16 cell grid. Each cell results in a different tone at time. You can modify the frequency, adjust the filters, and change the oscillator waveform in real time, as well as set the speed of the sequencer in BPM (beats per minute). Wuberizer also allows you to export your creations into an audio file (WAV).

Background

The app was inspired by a musical instrument released by Yamaha in 2005 called the Tenori-on.

Technology

Web Audio API

The Web Audio API allows you to generate and manipulate sounds in a variety of manners. This includes the creation of sound via oscillators which are manipulated via changes in frequency, applying new filters and changing the waveform, among many others. While Wuberizer focuses on mainly the generation of sounds, the Web Audio API also allows you to manipulate existing, prebuilt sound streams to do a variety of things like build audio players, or play sounds in games.

Canvas

To render the 16×16 grid we leveraged the HTML5 Canvas element. The canvas element is used to render shapes, images, graphs, or text dynamically. The element exposes a JavaScript API that allows for drawing paths, basic shapes, images and text. We leveraged the canvas with the help of EaselJS. EaselJS is a fantastic abstraction layer over the Canvas element. It provides helper classes for drawing, buffered rendering, user interaction support and many more.

Sencha Touch 2.2

The application itself, as well as the surrounding UI is written in Sencha Touch 2.2. We followed the MVC paradigm and leveraged the new Pictos icon font.

More Info

Here you can see our presentation deck:

You can also check out the code itself here: GitHub Repo

Here are some takeaways:

Facebook wants to be the one and only social platform

There are over one billion Facebook users and Facebook’s goal is to help you reach all of them. Facebook launched 3 new tools to support this, currently inside the new iOS SDK (v3.5):

Open Graph Mobile API

Facebook is allowing developers to leverage their cloud to create and host Open Graph Objects. Previously this required web servers to host the tags. This allows for richer and structured content in the news feed.

Native Login Dialog

This serves to be a replacement for the Native iOS Login dialog by leveraging the installed Facebook App. This allows for developers to display a customized and more performant Facebook login screen. The developer can now customize the text displayed on the login, as well as have more control over permission and privacy requests.

Native Share Dialog

Facebook is getting users to move away from the simple text-based sharing to rich context aware meaningful news feed items.

The ultimate goal with these new features is to promote app discovery and increase user engagement with the given app. Often during the talks the use case of a cross platform game (Candy Crush) was used. In this scenario, an iPhone user can acquire some achievement, share it on his news feed. Then his Facebook friend, on an Android will tap the news feed item and it will open the game (or the Google Play store if the app is not installed).

Notable Sessions

Facebook iOS SDK

This talk covered the new SDK release that includes the Native Login, Share Dialog (iOS only for now), Friend and Places Tagging, App Graph. The result is to create more engaging stories with much less effort (read: less code).

Beautiful Stories > Better Engagement > Discovery

Integrating Games with Facebook

This talk discussed how to leverage all the things you can do with the new SDK to promote your game. Some interesting facts from the talk:

• 32% of time spent on Mobile Devices is playing Games
• 18% of time is spent on Facebook
• 72% of the Top 400 Grossing iOS Apps are Games
• 78% of the Top 400 Grossing Android Apps are Games
• ~150 New Games are released on the App Store Monthly

Facebook is looking to solve the issue of promoting the game with things like Game Requests, Sharing, Scores & Achievements (Scores API) and Custom Open Graph Actions. In my opinion, Facebook wants to be the Mobile Xbox Live.

Building Facebook for iOS

This talk focused on Facebook’s development processes in their Native iOS app. It opened with the reasons for moving to native from HTML5 including: performance problems, lack of multithreading, memory management issues, lack of debugging tools. A large part of the reason for this, admittedly, was that they began the app early; before better practices were defined and frameworks like Sencha Touch existed.

For the Native App Facebook adopted Mozilla’s release model for Firefox with their own twist. They try to ship an update every X weeks and include a stabilization period as well as a “soak” period. Furthermore, all features are built with the ability to be disabled (either compile-time or runtime). They use a continuous delivery process with code reviews, automated unit tests, code validation, and various other tools to assure a high level code quality.

Some Pictures from the Event

I’m going to be going through some of the basic steps, including the new theming system. The following was done on a Mac using OSX 10.8 – your mileage may vary!

Sencha has released a fairly comprehensive guide for setting up an ExtJS project that you can find here. There is also a new barebones “bootstrapping” guide for Sencha Touch 2.2 you can find here. We’re going to be following both of these with some slight tweaks along the way.

Download the SDK and Sencha Cmd

Follow this link and download the Sencha Touch SDK, and the newest version of Sencha Cmd. Once installed, you’ll know you have a proper installation if you can type the sencha command into your shell and return something like this:

Unzip the framework into any directory you’d like. We’ll be referencing the path later on.

Most OS X users use BASH (the default) shell, but I use ZSH. Sencha Cmd currently only updates your BASH resource file ~/.bashrc, but being that I use ZSH, i had to manually update my shell’s resource file manually ~/.zshrc. In any case, it’s always best to ensure that your $PATH variable is set up properly after installing Sencha Cmd. Here’s what my $PATH variable looks like.

export PATH=$PATH:/Users/dave/bin/Sencha/Cmd/3.1.1.270: ...

Generate your workspace

Sencha Cmd has a new concept of workspaces. A workspace is simply a place where multiple Sencha Touch or ExtJS apps can live, with their appropriate source folders being there as well.

I’m going to create a Touch specific workspace. Generate your workspace using the following.

sencha -sdk ./touch-2.2.0 generate workspace ./touch-workspace

This will create a touch-workspace folder, and copy the Sencha Touch SDK into that folder. You should have a file structure similar to this at this point:

Generate your app

This step hasn’t changed significantly from previous version of Sencha Touch/Cmd. Run the following to bootstrap your app inside your workspace.

sencha -sdk touch-2.2.0 generate app MyNewApp ./my-app

-sdk is referring to the path to your Touch 2 SDK folder. The last parameter is the path for your generated app. If you don’t have this folder already created, Cmd will create it for you.

Perform an initial build

In your shell, change your current working directory to your my-app directory and create a build via the following command:

sencha app build

This will generate a build folder in your workspace. Inside it you should see a folder with the name of your app. Inside that there should be a production folder which contains production versions of your code, minified JS, and minified CSS.

Generate your custom theme

Sencha Touch 2.2 ships with an all new base-theme. This base-theme is designed as the absolute bare minimum to get your app up and running, and contains no styling beyond what is required for making the framework operate. If any of you out there have previous experience theming Sencha Touch apps, this should come as a huge step in right direction. No longer will we have to override existing styles with !important. Generating your SASS for your apps should be more trivial.

To use the new base theme with your application, open the my-app/resources/sass/app.scss file. This should have been auto generated for you with Sencha Cmd.

Replace the existing imports:

@import 'sencha-touch/default';
@import 'sencha-touch/default/all';

with:

@import 'sencha-touch/base';
@import 'sencha-touch/base/all';

Change to your sass directory and start watching for changes.

$ cd my-app/resources/sass
$ compass watch

Compass should compile. If you are having issues, make sure you’re running the compass watch command from the directory that contains the config.rb (the Compass configuration file). The Sencha Base theme on the left, versus the standard theme on the right.

Start customizing

As before, all of the SASS variables exposed by the Touch Framework are still available, but many of them may not act as expected due to the way that the base theme is implemented. The base-theme is fantastic for experienced developers who are familiar with the Sencha Touch DOM structure, but is also a step in the right direction for newcomers that were once scared away by the amount of DOM output that the Touch framework generates.

For most of my projects, I like to start off with individual SASS files for each component. Take buttons for example – I’d create an include directory under the sass directory, and then create a _buttons.scss file that would be importeted into the root app.scss file.

Here’s an example of my app.scss:

/* you would set your SASS variables here. many will have no effect on the base theme */
// $button-height: 40px;

/* import the sencha defaults */
@import 'sencha-touch/base';
@import 'sencha-touch/base/all';

/* our custom imports */
@import 'include/buttons';

/* examples of other, structured styling */
// @import 'include/tab';
// @import 'include/form';
// @import 'include/panel';
// @import 'include/panel';

/* other custom css */

Styling a component

As mentioned in the Theming article at the top of this post, all Sencha Touch components always have a baseCls that matches the name of the component. Let’s style a button.

I’ve added a couple of buttons to the sample application that is generated by Cmd by modifying the items[] array to the following:

items : [
    {
        docked : 'top',
        xtype  : 'titlebar',
        title  : 'Welcome to Sencha Touch 2',
    },
    {
        xtype : 'button',
        cls   : 'modus-button default',
        text  : 'Default Button'
    },
    {
        xtype : 'button',
        cls   : 'modus-button primary',
        text  : 'Success Button'
    },
    {
        xtype : 'button',
        cls   : 'modus-button info',
        text  : 'Info Button'
    },
    {
        xtype : 'button',
        cls   : 'modus-button danger',
        text  : 'Danger Button'
    }
]

You can see that I’ve chosen to go with the cls definition versus defining a new ui using the sencha-button-ui mixin. I’ve found that this will give us greater flexibility using our own classes that we create. Compilation seems speedier as well when you avoid using heavy mixins. We’ll create lightweight classes that reduce code redundancy.

Here’s what I’ve got for the _buttons.scss file:

@mixin modus-button($color) {
  @include transition(all .25s ease);
  @include border-radius(6px);
  margin-bottom: 15px;
  font-size: 15px;
  background: $color;
  border: none;
  color: white;
  text-decoration: none;
  .x-button-label {
    padding: 10px 0;
  }
  &.x-button-pressing {
    background: darken($color, 10);
  }
}

.default {
  @include modus-button($baseColor);
}

.primary {
  @include modus-button($primaryColor);
}

.info {
  @include modus-button(#2c97de);
}

.danger {
  @include modus-button(#e94b35);
}

Simple, right? The output is fairly dramatic based on the amount of code we had to write.

Buttons are pretty simple. What if we wanted to do something like the tabbed control at the bottom, or the titlebar on the top? Let’s start by creating a _tabs.scss and _titlebar.scss files and go from there.

Here’s _tabs.scss.

.x-toolbar {
  border: none;
  background: $baseColor;
  .x-innerhtml {
    color: white;
    font-size: 16px;
  }
}

Here’s the contents for _titlebar.scss.

.x-tabbar {
  border: none;
  background: $baseColor;
  .x-tab {
    background: none;
    border: none;
    .x-button-label {
      color: white;
      padding: 10px 15px;
      text-align: center;
      font-size: 13px
    }
    &.x-tab-active {
      .x-button-label {
        color: #02b99a;
      }
    }
  }
}

Wrapping up

There is so much more to theming Sencha Touch than what was described above. My upcoming posts will detail how to integrate custom icon fonts, write and style custom components (a big part of what we do here at Modus), and how to use the new config driven system in ST 2.2 to deploy custom CSS for multiple platforms.

Make sure to follow me on twitter @dmackerman for future blog posts!

Sencha Touch 2.2 has been officially released. Read the blog post here.

The Sencha Touch Refcard introduces the Sencha Touch 2 framework and its core concepts. For each concept there are source code snippets showing it in action. It is targeted for Sencha Touch developers of all experiences, it can serve as a starting point as well a quick reference for the experienced developer.

The Reference Card covers the following:

• Introduction to Sencha Touch 2
• Class System
• Component System
• Event System
• Selectors
• Data Package
• XTemplate
• MVC
• Application Theming
• Packaging and Deploying
• Common Pitfalls

Preview

About

The Refcard was written for DZone by Stan Bershadskiy (@stan229) and edited by Grgur Grisogono (@ggrgur) and Jay Garcia (@modusjesus). Stan has been working with Sencha frameworks for the greater part of the last five years, particularly with Sencha Touch. You can see some of his Sencha Touch work here: Time Inc. Digital Storefront and Diablo 3 Mobile Companion

We hope you enjoy it and don’t forget to share it with your friends and colleagues!

Get the Sencha Touch Refcard here:

Geoff previously served as Director, Audience Products at Public Broadcasting Service, where he was responsible for General Audience digital products, a portfolio that included pbs.org, video.pbs.org, and the award winning (and 5-star rated) PBS Video Apps. At PBS Geoff focused on emerging distribution channels of Responsive Web, Hybrid Apps, and Over-The-Top Television offerings.

Geoff will be responsible for leading the product development of Modus’ white-label HTML5 publishing platform. Modus Create has deep experience building HTML5 iPad apps for clients such as Fortune Magazine, The Atlantic Wire and their own Discover Music digital magazine for Amazon’s Kindle Store.

To learn more about this, click here

For example:

• Delegates, Events
• JSON
• Function Patterns
• Closures
• Loose Typing
• Dynamic invocation – obj_msgSend() vs. Function.apply()
• Objects – Key/Value coding vs. Hash table

These can all be taken advantage of in Objective-C. There are certainly some nuances here but it’s nice to see some familiar techniques when diving into a new language. There were some negatives mentioned such as memory management, “wordy” method/property names and funky syntax. Avoiding memory leaks was possibly the only serious fault I heard. I think the wordiness and funky syntax would be pretty easy to get used to. In fact, take a look at this:

(void)staticMethod:(int)foo

    { NSFileManager *mgr = [NSFileManager defaultManager]; NSError *myError;
    
    BOOL ok = [mgr createDirectoryAtURL : myURL withIntermediateDirectories : YES attributes : nil error : &myError]; }

Sure, its a bit wordy but as Andrew said, it’s not that far from this:

    JSFile.getDefaultManager().createDirectory({
        url: myURL,
        withIntermediateDirectories: true,
            attributes: null
    }); 

The Objective-C editor will even line up your colons (if you’re into that sort of thing).

So, if you like to code in JavaScript and were thinking about trying Objective-C, give it a shot. You may just find it a little bit familiar. Also, if you’re in the Providence area, stop by ProvJS and join us for a meetup!

1 – Know Your Map

Identifying and building your funnel can mean life and death. Every map has a choke point or ‘funnel’ that give the maximum advantage to the defender (you). Positioning sentries and selecting the right cover leads to massive kill streaks and cash bonuses. Picking a defense position equidistant from the Ammo, Air Support, and Explosives stores enables efficient resupply of resources.

Startup Lesson
Identifying advantageous market conditions matters as much, and sometimes more, than business model. Modus was founded two years before we expected HTML5 to be ready. This affected how we positioned the company AND the offers we rolled out as market conditions matured and HTML5 apps became a more viable solutions for enterprises.

2 – Conserve Cash and Ammo

Exploit the Funnel
Once your funnel is setup, the choke point on attackers leads to massive kill streaks and rampage cash bonuses.

Conserve Ammo
Saving the $750 on ammo refills is a huge advantage. Scavenging and exhausting all free attacker dropped ammo is a clear sign of a pro. Clearing as many waves as possible with dropped weapons positions you to have massive reserves when you need them against the real heavy competition.

Build a Juggernaut Warchest
Predator missiles cost $2,500 and do the job for sure, but why waste the dough when two flashbangs and $750 in ammo will also do the job? Saving money and heavy weapons for later rounds is key when attack choppers and juggernauts make expensive predator missiles a must have.

Startup Lesson
Revenue is water but cash is air. You can survive without revenue but will die quickly without operating cash. You don’t need the best office chairs or expensive PR firm to succeed. Spend your money on the things that matter. As a bootstrapped, “customer financed” business, Modus has been able to self fund growth by continually reinvesting in our business and building a war chest of cash reserves.

3 – Over Communicate

Unrecoverable distance
In the midst of battle the last thing you want to hear is, “Help me out, I’m down over here!” Allowing an unrecoverable amount of distance between yourself and a teammate has ended many a good run. The more waves you survive, the less time you have to reach and revive a downed teammate.

Playing without a headset
Playing on XBox Live without a headset can be like flying blind when the going gets tough. Knowing where someone is on the map is not as valuable as knowing what help they need.

Startup Lesson
Your team cannot read your mind. Add distance with a distributed team, add communication overhead or suffer the consequences. Lack of “shared understanding” is the biggest reason why software projects fail.

4 – Pick Perks Wisely

Match Perks to Maps
“Sleight of hand” or “Steady Aim” can make all the difference based on the map and the wave. They are expensive and offer significant advantages, but incorrectly chosen perks are a huge waste of money and offer little return.

Startup Lesson
Useless optimization kills products and businesses. Build feedback loops with your customers and practice a “near real-time” LeanUX approach to validate features and “delighters” on your product roadmap match to actual user needs.

5 – Triple Juggernaut Strategy

Single, Double, and Triple Juggernauts
By the time you are facing triple Juggernauts with riot shields, you realize you thinking has to change to survive. You can no longer use a ‘hold your ground’ approach and must find creative ways to lure Juggernauts into positions that give you the kill advantages. Multiple Juggernauts will actively move to kill your defenses before coming for you. Knowing this is not good enough, you have to act on it to survive.

Startup Lesson
“Pre-Success” and “Post-Success” strategies differ. Once you are taken seriously as a competitive threat, your should expect to face offensive and defensive moves by the incumbents you are attempting to disrupt.

Image credits:
http://images.wikia.com/callofduty/images/8/89/Map_Underground_MW3.png http://www.imodernwarfare3.com/wp-content/uploads/2011/08/Airsupport-armory-443×371.jpg http://images.wikia.com/callofduty/images/3/38/Reviving_downed_Osprey_survivor_Special_Delivery_MW3.png http://gametechx.com/wp-content/uploads/2012/05/modernwarfare3perksscre-300×164.jpg http://images4.wikia.nocookie.net/__cb20111021012661/callofduty/images/7/73/Juggernaut_MW3.jpg

Thanks to our new and existing clients and talented team members who’ve joined us over the past twelve months.

Here’s to amazing things in 2013!

Checkout the presentation, and watch the video: