Building and Deploying Static Resources Using Grunt.js [Video]

At LevelEleven, we are doing some very heavy client-side applications on the platform. While the applications are served up on Visualforce Pages, most of the application is run on the client-side in Javascript, CSS, and HTML5. Because of this, the front-end code base was getting large. Along with the mass of Javascript that we were accumulating, we were also getting some very large CSS files and image directories. But as painful as managing this large code base is, the biggest pain is managing the deployment to and from the platform. We needed a way where we could easily make changes to our front-end assets, compile them to optimized files, then quickly deploy back to the platform in an iterative fashion. It was time to implement a “build” solution to automate this. We had several goal that we wanted to achieve:

  1. Iterate and deploy changes faster
  2. Make the code more stable
  3. Make the code more performant

Solution Needs

We were already starting to use a lot of pre-processors. For javascript, we were running jshint and uglify to get clean, compact, production-ready javascript. For CSS, we were leveraging Sass/SCSS for many of the same reasons. For deployment to, we were using the migration tool.

Boiling it down, I was in need of  a solution that automated the following:

  1. Run jshint on the Javascript files to check for errors.
  2. Concatenate multiple javascript files together.
  3. Minify and compress the concatenated javascript file(s) using uglify.
  4. Compile/minify Sass/SCSS files into CSS.
  5. Copied all compiled assets and other resources into a temporary directory
  6. Easily zip up the contents of the temp directory into a .resource file
  7. Deploy the .resource file to using the migration tool


Grunt.js is a task-based, configuration-based, build tool. While this is still a relatively new technology, grunt already hava a vast community built around the tool and plugins to do just about whatever you want to do. I selected grunt for my needs because of its “configuration vs scripting” approach to project builds. It allows me to quickly make major changes to my build steps with minimal tweaks to my Gruntfile configuration.

We chose grunt because it took care of steps 1-6 above with a combination of plugins and configurations. For the deployment step(s), I wrote my own plugin to satisfy step 7.


I wrote this plugin last week to allow for deployments as grunt tasks. I plan to expand this to also manage other metadata api operations such as retrieves but for now, the only task in there is antdeploy. For more information on the plugin, check out the project on Github. I’m also looking for some contributors on it so fork away!

Demo video

Here is a video I did showing how this all works together.

Files from the Demo

And the files that I used…


If you are new to grunt, check out these links to get you started:

Learning to type at 31

Early last year, I decided to severely impact my productivity in the hopes that it would provide benefits in the long term. Here is my story.

I am a programmer and I have been since I was a kid. I wrote my first line of BASIC code, sitting with my Grandpa in Walled Lake, MI when I was about 12. I quickly got hooked. I became deeply fascinated by computers and programming. There was something awe-inspiring about being able to tell a computer to do something, then watch it happen before my eyes. I wrote lots of little BASIC programs. My favorite was the infinite-loop, screen color flash program. On several occasions while in middle school, I would deploy it to a bunch of computers at school and watch the teachers scramble to figure out why all hell was breaking loose in the lab. I found that quite entertaining.

From there I branched out to C++ and HTML in my high-school years. I was quick to pick up new languages and enjoyed learning as much as I could. It was during this time that I realized that programming would be a significant part of my life. Soon after, I was in college at Western Michigan University studying in the Computer Information Systems program and learning Java, Visual Basic, and further refining my web development skills. After college and to present day, I’ve studied technologies and languages like PHP,, Ruby, Linux, C, Haskell and Node.js. This has been lots and lots of programming…and typing.

While in school, I had several keyboard (typing) classes. I don’t remember them well, but I remember that I found them boring. I already knew computers by the time I took these classes and since typewriters ceased to exist at this point, “Keyboarding” was a computer class. I probably felt that the subject matter was below me. I did what I needed to do to get a passing grade, but I had already taught myself to type through my programming adventures. I continued to type the way I taught myself. After all, I was typing faster than most of the other kids in the class. Why would I care about things like the “home row” and why would I ever need to look at the screen?

This turned out to cause me huge problems down the road.

After college and as my career progressed, I began to work with a lot of talented programmers. As part of my continued learning, I make a point to observe the behaviors and patterns of those that are highly skilled to try to understand what makes them great at what they do. One observation that I have made  is that not all, but a lot of these people all seemed to type faster than me. I don’t think this is what made them great programmers, but it sure made them more productive. Either way, I took note.

I began to examine the way that I typed.

Despite what would probably be deemed as poor technique, I could type at a fair pace. I had been typing for so long that my homegrown typing style wasn’t holding me back too much. I’d mastered it. I wouldn’t call it a “hunt and peck” method, but my hands moved around a lot. They were almost never on the keyboard. My eyes were also never on the screen. That was probably the most concerning trait. I would make mistakes in my typing but would miss them and continue typing on. This led to extra proofreading and review after I had finished typing.

What finally made me take action was the day that I realized that the speed in which I could type using this style had hit a max…probably a long time ago. The way in which my hands moved and the fact that I couldn’t type without looking at the keyboard prevented me from getting any faster. I wanted to get faster. Getting faster meant that I would be more a more productive programmer. I am a total perfectionist and the moment that I realized that I was allowing myself to remain so inefficient, I knew it had to be fixed.

So right then and there, some time last January, I made the commitment to teach myself how to properly type. I knew it was going to be painful. After all, I had been doing it my way for close to 20 years. This was going to be a long road. It was also going to be a huge risk. I was willingly cutting my typing productivity in half in hopes that I would be able to eventually type faster than I currently could. I had no idea how long it was going to take either.

I jumped right in. I found a couple of really nice websites that had online tutorials that taught me the basics. I probably typed “the quick brown fox jumped over the lazy dog” a hundred times. I practiced as much as I could. I forced myself to type my emails using proper technique no matter how slow I was going. I began programming this way. It was very frustrating especially since I knew that I could jump right back into my old habits and be cranking out emails and programs just like I used to. I thought about quitting several times. I’d catch myself slipping back into my old ways, feeling how much more natural it felt, and wonder why I was doing this to myself and whether it was really going to be worth it.

Instead of allowing myself to fail, I stuck with the plan.

Its now been a year and I have to say it was one of the best decisions of my professional life. I feel that I am pretty close to my original speed and I’m still getting faster every day. With as much as I type, in a couple of months, I’m guessing that I will surpass my previous typing speed. This was the ultimate goal. On top of that, I’ve even found that there were some unintentional benefits. I’m noticing that my posture is improved and that my neck and back feel better after 10-hour coding benders. It has turned out to be a great decision.

I guess there is a 2-part moral to this story: It’s never too late to change something about yourself that you don’t like. It may not be easy, but things that are worth doing usually aren’t.

My programmer resolutions for 2013

2013A new year is upon us and it’s time for us to commit to our resolutions. I’ve been told that it’s best to share your resolutions so that you stick to them. I guess that’s the reason why you are reading this post. Unlike a lot people, I don’t have just one list. I actually have two. I have one for my personal life and one for my tech/programmer life. This post will just be the latter.

And with that, here is my 2013 programmer resolution list (in no particular order)…

1. Really learn a functional programming language

Like a lot of programmers, I am a dabbler. I’ve dipped my toes into so many languages and technologies that I can’t even count them at this point. While this experimenting can be fun, I’ve found that I get the most satisfaction when I narrow my focus to studying one new thing. I’ve dabbled in many functional languages but haven’t really gotten that far. It’s time to focus on one and truly get some benefit out of learning it.

I’m not looking to replace the imperative languages I use today with functional languages. I can’t. I’m also not looking to become a functional programming master. I’m simply looking to expand the ways in which I approach programming problems by learning new programming concepts, new ways of structuring programs, etc. Right now, I’m starting down the Haskell path and it’s been quite fun and quite eye-opening. I’m already starting to see where some of these concepts can be applied in the non-functional worlds in which I live day-to-day.

2. Devote more time to open source

I do quite a bit in open source but I allow distractions, like unnecessary side projects, divert my attention from OSS. My goal this year is to devote more of my “play” time to getting involved with some projects that I follow on Github. I also want to open-source some of the pieces of projects that I have previously developed. I’ve always had the intentions to do so, but ADD is a bitch.

3. Get more BASH proficient

I’m pretty solid with BASH. I could be better. Scripting skills are invaluable so honing them are a top priority for me. I just spent the weekend practicing some awk one-liners and some complex pipe chains. I think that’s a good start. This isn’t really a new area for me. It’s just an area where I feel that a little practice will serve me well.

4. Explore teaching opportunities in the Detroit technology community

2011 was an awesome year for technology in Detroit. Our node.js meetup group, Detnode, gained its first 150 members and had an awesome schedule of events. I also just helped launch a developer meetup which will have it’s first meetup very soon. Tons of other interesting groups formed in the area and the technical community as a whole grew by leaps an bounds.

The explosive growth in the meetup groups in Detroit has proven one thing…people are eager to learn. I’m looking to get involved in creating educational opportunities for others. I enjoy teaching and will look to do so in the coming year.

Google shit from the command line

This is a really dumb BASH script but I wanted a simple way to google something from the command line in Mac OSX. To use this script, just copy this file from the Gist and make it executable. Then we’ll copy it into /usr/local/bin so that we can put it in our PATH…

$ chmod a+x
$ cp ./ /usr/local/bin/google

Then you can google stuff…

$ google "Grumpy Cat"

This will launch a new tab/window in your default browser. Here is the Gist.