Monthly Archives: February 2012

100 Percent Hipster Command Prompt

Haven’t you heard? GUI’s are out. All the cool kids are going command line. Remember the first time you threw on those skinny jeans? Well maybe not… However, you can get the same feeling from your NEW 100% hipster, no filler terminal window.

If you need help defining a hipster, play a few rounds of bingo.

Ditching terminal

OS X comes with a terminal app. But look. This is almost anti-hipster. No flare.

iTerm2

Now that we have decided to upgrade we can started. We are going to use iTerm2, so go ahead and install it. www.iTerm2.com

Zsh upgrade

With iTerm2 installed we need to change our shell. Zsh offers more features than a standard bash shell. To enable zsh in iTerm2 goto Profiles-> Open Profile -> Edit Profiles. Change the command like so.

Restart iTerm2 and hopefully at this point you have a working zsh shell.

Customize our colors

Great, now you are thinking… we have installed a new application and configured a new shell and our terminal still sucks… Be patient. First we need to change our colors. We will use a neat theme to do this. Solarized. ★ Get it here.Install instructions here

Now those colors look hipster!

Oh My ZSH!@

Oh my zsh is a handful of functions, helpers and themes for your zsh shell. The GitHub repo is here. Once oh my zsh is installed we can theme our prompt. Once we setup a theme our prompt will be transformed into…



Notice that our command prompt is now a star. Hipster! Notice that our current directory is hilighted in yellow. Hipster! Notice that if we are in a git or svn enabled folder we get info on the right! Current branch name. Hipster. We even get a + symbol if we have modified files to commit. NOW that is 100% hipster.

Changing Themes

I have added the theme above to download here. It includes svn and git support. To install the theme copy the file into your homedirectory/.oh-my-zsh/themes folder.

To change your theme you will need to find your .zshrc file in your home directory. To change your theme and plugins modify the lines below.


Congratulations

Now you can go update your wardrobe.

Underscore.js template revealed!

Underscore has a powerful feature that can compile JavaScript templates into functions that can be evaluated for rendering. While there are many different templating engines out there, underscore uses ERB style delimiters which is a bit different. In this post we will explore some of the ways in which templating could be used to render html on the client.

Creating a template

To create a template in underscore is very similiar if you have used templating engines in the past. To get started you call one function. _.template. The parameters are a string containing your template and any data you need to pass in.

ERB Delimiters

Now that we know how to create a generic template let’s look at some ERB delimiters.

  • <%= item.name %> – Outputs value
  • <% for(){ %> <% } %> – Executes JavaScript.

The first example <%= will output the value within. In the case above it will output the value of item.name. The second example <% will execute a for loop within your template.

Putting it together

In this simple example above we are setting a for loop to execute 10 times. Each time we loop we are executing a console.log statement to print to the console. Hopefully even with this simple example you can see the power we now have to control how our template renders.

Real world example

Let’s look at one more example. Let’s say we want to populate a drop down with a series of date values. We can use an approach similar to the one above. First thing we need is a data structure to pass in. We will be creating an array of week objects like below.

Next, we will need to define our template. In this example we are defining it within an external script block. We can use the id to retrieve it later. With each loop we will use a <% block to set the current week as a variable. The week variable can then be used to print out our week start and week end dates.

Finally, we can render out our template.

And our final template output.

Conclusion

If you are using Backbone within your site already why not give underscore template a try? With it’s ERB style templates it may be a bit different than other templating solutions, however after using it for a while I think it is more intuitive for developers that are used to php or ruby style templates.

Adding require.js to HTML5 boilerplate build

HTML5 boilerplate has a really nice build script. It get’s your website in tip top and minified shape in no time. However what happens when you want to use require.js on a big project and don’t need the scripts.js file that is provided? In a few steps we can get your website in tip top shape with require.js as well!

Getting started

For the sake of simplicity we will assume you already have h5bp in your project. Now that is settled we can get started.

First off we are going to need a way to differentiate our require.js stuff from the rest of our site. H5bp already has a good mechanism for doing this with external libraries via the libs & mylibs folders. From what I can gather libs & mylibs are where you stick generic libraries that the project may need. (jQuery, Backbone, etc)

For our require.js code we are going to create a separate folder called “app”. This way we can isolate those files from the h5bp build script. By default h5bp will copy & minify everything from the js folder when executed. This not what we want since we need to trace the require.js files for dependancies first. Your default js folder structure should be like below.

Cleaning up after scripts.js

Since we are no longer using the default scripts.js file we will need to modify the build script accordingly. Again, by default h5bp will try to run the -js.scripts.concat target when building. This will fail the checksum since we don’t have a scripts.js file. To remedy this problem remove any references to the ‘-js.scripts.concat’ target in the build targets. Doesn’t make sense? See below.

And… So close. One last modification is needed. When building, the ‘-usemin’ target is ran before any other minification/concat targets. Currently, it has a dependency on the ‘-js.scripts.contact’ target. We will need to get rid of this. However, this would be a good spot to trace our require module dependancies since it will run before any copying, minifying, etc. Go ahead and change the depends attribute to “-r.js,-css”. In the next section we will create the -r.js target.

Creating the -r.js target

<!-- Require.js target, run separately -->
<target name="-r.js" description="Concatenates JS files using require.js dependencies">
    <java classname="org.mozilla.javascript.tools.shell.Main">
        <classpath>
            <pathelement location="./${dir.build.tools}/${tool.rhino}" />
        </classpath>
        <arg value="tools/${tool.require}" />
        <arg value="-o" />
        <arg value="${require.build}" />
    </java>
    <echo message="optimized ${require.build}">
</target>
view raw r.js.xml This Gist is brought to you using Simple Gist Embed.

Let’s break this down a bit. First, it invokes Java. Next, it adds rhino to the java classpath. Finally, it sets three arguments.

If you notice there are three variables within the target. tool.rhino, tool.require, and require.build. The convention when defining variables within h5bp is to define them in the project.properties file. These variables override the default.properties file with your project specific variables. This is a good thing since if you update html5 boilerplate it won’t break your already defined variables with a later build. But what are these variables? The are simply string variables defined in our project.properties file.

${tool.rhino}

tool.rhino is defined in many places within the h5bp build.xml file. It is the string variable representing the rhino jar file.

${tool.require}

tool.require is a custom variable which represents the path to the r.js file that comes with the require.js optimizer. r.js will trace your javascript files written in require.js AMD format for dependencies, then concatenate them together and finally minify them with uglify. You will need to download this file and drop it in the tools directory within the build folder.

${require.build}

require.build is another custom variable that links to our require.js build file. As described above r.js will preform a build on your javascript files. However, it needs to know how and where to build from. This is where a custom build file comes in. Require.js can build your site based on this custom build file which is represented in json format. In the example below we have set the require.build variable to point to a file name app.build.js. This file contains the instructions on how to build our require.js modules.

app.build.js

To get the full rundown of what can be done in a require build file visit http://requirejs.org/docs/optimization.html

A simple example of a build file is below. In this example we define our base url in the app folder, then we define the name of our module we want to traverse and finally, the location where we want to publish out the generated file(s).

Note: we are publishing out to the intermediate folder created by the h5bp build script.

Putting it all together

Now that we have defined the variables above the -r.js target should make a bit more sense. Again, all it is doing is reading our require build file and tracing the module dependancies. It does this using the rhino shell to execute the r.js optimizer script that comes with require.js.

${dir.js.app}

Almost done. I promise! We will need to exclude our app folder from any processes that might get run by h5bp internally. We can do this in three steps.

  • Create a custom variable to our app path in project.properties.
  • Add ${dir.js.app} to the list of files/folders to ignore in project.properties.
  • Add an exclude statement to the -js.all.minify target. This will prevent h5bp from minifiying and copying the app folder. See below.

Conclusion

Ok, maybe that was more complicated that I thought! Anywhooo, if you had trouble following along I have attached the modified build folder below. Hopefully this helps development teams that are looking to incorporate require.js into their current build processes. Please feel free to post suggestions or enhancements.

build.zip

1 2