Literate-programming-style docs with rake-pipeline

July 18, 2012 by rob-harper comments

Using rake-pipeline as part of the build process for your JavaScript project?  Add literate-programming-style documentation to your project using Rocco (the Ruby Docco port) with this simple web filter:

http://gist.github.com/2875876

…use the filter in your Assetfile like so:

http://gist.github.com/2875925

…use Markdown syntax in your source comments and you’ll have documentation for every .js file automatically updated whenever the pipeline runs.

—@rdharper

ProTip: PV aka Pipe Viewer

May 25, 2012 by nickmulder comments

Today I was completely blown away by this insanely useful command-line tool called pv. It isn’t new and I’m definitely not the first to do a write up in a blog. I’m just stunned by the fact that I have never come across it before.

What is PV?

Its purpose is simple and clear, it measures the progress of data flying through a pipeline. It tells you how long it has been running, how fast the data is going through, it lets you know what the ETA is and best of all it shows you what percent of the data has made it through the pipe!

How to use it

In its simplest form you can use it like you would cat, the main difference being if you cat a sql file and pipe it into mysql it won’t give you a progress bar. Need to bunzip or gunzip? No problem.

http://gist.github.com/2787758

Multiple Bars

You can also use it multiple times resulting in multiple progress bars. The -cN bit simply gives your bars friendly names.

http://gist.github.com/2787775

How to get it

It is only a few keystrokes away.

http://gist.github.com/2787761

More info on the official site: http://www.ivarch.com/programs/pv.shtml

@nickmulder

Building simple JavaScript libraries with Rake-Pipeline

May 18, 2012 by rob-harper comments

At Nulayer we try to write very modular JavaScript, which allows us to be flexible and re-use those libraries in other projects. But we’ve had difficulty structuring a build process for these small- to medium-sized JavaScript library projects, while meeting the following objectives:

1. Break it up: While it’s common to write smaller libraries as one big file, we like the mental separation provided by dividing the source into multiple files.
2. Inline dependency management: We’d rather define each file’s dependencies right in the code than define the concatenation order in some sort of makefile.
3. Keep files separate while debugging: When we’re setting breakpoints and stepping through code in the debugger we want to see our individual source files, not have to wade through one big file.
4. A transparent solution: We need the production library to be free from dependency management code.

A year ago, I tried to satisfy our objectives using @jrburke’s require.js. It gave me the multiple source files with dependency management and excellent seamless development (with separate files) and production (combined and minified) environments that I was looking for. Unfortunately at the time, and things may have changed in a year, compiling requirejs out for the production build was not easy. I could get it down to a bare-bones set of require and define functions but it was still there. Requirejs is excellent for large JS projects and I ended up using it extensively for other work but it wasn’t quite the right fit for making a smaller library.

Via the Ember.js project I was introduced to livingsocal’s rake-pipeline with @wycats’ rake-pipeline-web-filters and minispade. With this combination I can prefix my source files with minispade “require” calls and satisfy objectives #1 and #2. The minispade filter for rake-pipeline can optionally encode and your source as strings, add a @sourceURL annotation and eval at run-time. In Webkit and Firefox the script debugger will show each eval’d block as a separate file, satisfying objective #3. But minispade is still required.

@wagenet’s addition of the neuter filter goes a long way to satisfying all four requirements. Neuter will determine the correct ordering of all source files and concatenate them into a single file. This is great for a production build as it means minispade is not required. So by using minispade in development and neuter in production, I can meet all four of our project organization objectives… almost.

One of the side-effects of using minispade is that all modules are evaluated within their own closure. This is great if everything that the module needs to share with other modules is exposed through a common global namespace (as in Ember.js) but it’s problematic if I want to define library-wide functions and variables that I don’t want to expose publicly. In my case, I had some helper functions that I put in a common module that was required by a number of other modules in my library. In the neutered production output everything is fine since all modules are appended as-is and can be wrapped in one big shared closure. But in development I was out of luck.

My solution was to use a modified version of the neuter filter that either outputs the raw code (in production) or outputs eval’d strings of the code with @sourceURL annotations (in development). This simple change allows me to satisfy all four of my requirements with very little work.

Here is a snippet of a rake-pipeline Assetfile that can be switched between production vs. development followed by the modified neuter filter (my changes mostly in output_source):

http://gist.github.com/2712617

Using rake-pipeline with a modified neuter filter makes it easy to structure, build, and debug JS projects that use multiple source files with dependencies specified right in the code.

Nulayer launch night 2011!!

November 30, 2011 by peterkieltyka comments

It’s hard to believe that in 2008 we were just two guys in an office the size of a broom closet in Liberty Village. Today, two offices later (but still in the village), we are a team of more than 20 creators filled with passion and big dreams.

Since we launched Crowdreel in 2009, we’ve been flying under the radar, putting our hearts and souls into two products I couldn’t be more proud to say we made. Our best work ever: Pressly and ScoreMobile.

They are the culmination of a year’s worth of hard work by the Nulayer team. Well done everyone!

Thank you to Score Media and the Toronto Star for believing and trusting our team in the midst of many unknowns. Innovation is a leap of faith.

This leads us to November 24th, the day ScoreMobile app for iPhone hit the stores. Since the day we launched, we’ve already topped 400k users, and now sitting at #1 in Canada and #2 in US for Sports! Crazy. We have lots more planned and can’t wait to continue to innovate with the good people at The Score.

The Toronto Star’s web app, the first ever tablet experience powered by Pressly, launched a few days earlier on November 14^th. So far, the most amazing result to surface is the proof we are making a difference in the way people read on the Web. Without giving up too much info, The Star increased user engagement by well over 10x. And users on all devices, from PlayBook to iPad, have been tweeting and emailing us with glowing reviews. People love the reading experience – its working!

The Star was the first step in our vision to revolutionize the way people read and discover content. As a Toronto based company, we couldn’t be more proud than to have taken that step with a great Canadian publisher.

This is just the beginning, we’re going to light it up in 2012.

Thank you to all of our friends, family and colleagues who celebrated these two major achievements with us at our Launch Night party. The next day, we roll into the office around 11am (pretty good), and Will says to me “Pete, we gotta launch more products so we can throw more parties!” …  Agreed! That’s the plan.

Also, thank you to Esther Kim for planning the party, it was a hit! And thanks to Janick Laurent for the beautiful photography.

Cheers!