Let’s just say it was a crazy October, and we’ll leave it at that. There are big things afoot for November, though. I’m headed west for a multi-stop tour of Northern California with my wife from Nov 12-23. It’s going to be part business/part pleasure, but every time I’ve gone in recent years theres been no shortage of fun. Though I wont be attending RubyConf, I’ll be in San Francisco during and around it Nov 19-23.

First, If any dev shops/teams/meetup groups want to hear me talk/present about Sammy.js or any other projects I’m involved in I’d be happy to come by and drop some knowledge.

Second, I would greatly appreciate anybody willing to let me office-crash and hang out with them in their workplaces.

Finally, I would love to meet up with fellow Rubyists, Javascripters and foodies to do any one (or many) of the following things:

• eat delicious food
• write fun code
• talk about the future of the web
• drink and sing karaoke

If you’re interested, just hit me up on twitter or email me at aaron at this domain.

Quick note, I decided to use github pages instead of this here blog to post the tutorials. In the end, its just easier to post lots of inline code AND it will be easier to maintain with updates as the Sammy API changes.

I hope you enjoy it! I’m always appreciative of feedback and constructive criticism, so fire away.

I’m very happy to announce the next major release of Sammy.js. I’ve been working on this for over a month and the result has been a lot more changes then I expected but over all a smaller, cleaner core code base. Here’s a quick run through of the biggest changes. See HISTORY or the Commits for a full list and more detail.

Plugins

The biggest change, that resulted in a lot of little changes is Sammy.Application#use() which allows you to package and resuse application level code into ‘Plugins’. See the documentation on plugins for more detail. This also marks the start of an official selection of plugins, with two as part of this release and more on the way.

The default template system that used $.srender internally has been extracted out into a plugin. To enable almost the exact same functionality:

// somewhere in your HTML (after sammy.js): 
// <script src="plugins/sammy.template.js" type="text/javascript"></script>
$.sammy(function() {
  // include the Sammy.Template plugin
  this.use(Sammy.Template);
  
});

Events

Sammy.Application’s bind() and trigger() methods now use jQuery’s namespacing to bind to Events. This means that Sammy.Application can now easily catch events that bubble to it like ‘click’ or ‘focus’. The big awesomeness is that the callbacks for these bind() methods are always evaluated within a Sammy.EventContext so that even events triggered from outside the app can be handled in the same way as internal events.

var app = $.sammy(function() {

    this.bind('custom-event', function() {
      // this == Sammy.EventContext
      alert('Custom Event' + this.params['wha']);
    });

  });

  // the app is by default bound to 'body'
  $('body').trigger('custom-event', {wha: 'ZUH?!'});
  //=> system alert ZUH?!
  

Cleanup

With the advent of plugins, Sammy Core is now even smaller (8.9k minified). This is also possible because I’ve removed the former ‘classical’ inheritence code in favor of prototypal inheritence, which is a big win in terms of cleanlieness and global scope leakage.

See Also

I mentioned this on twitter, but I’m working on some new tutorials and screencasts about Sammy. If you have ideas/suggestions, dont hesitate to let me know. The first one should be up next week. I’m going to try to do them bi-weekly, we’ll see how that goes

Again, I’ve tried to be as thorough with inline API docs as I could so any changes should be in the clear. Thanks again to everyone who helped with this release and has supported Sammy recently!

I’ll be honest. When I created Sammy.js, It was more of an academic exercise then a means to an end. I had ideas for how it could be useful, and had some immediate uses for it, but the initial thought was ‘recreating Sinatra’s API in JavaScript’. Little did I know – with a little introduction and the work of some clever individuals, its real value would be revealed.

We’re at the dawn of a new age on the web, or maybe or horizon, or a precipice; the metaphor doesn’t matter, the point is, things are changing. Specifically, as browsers become more and more powerful, as developers we’re given new opportunities to rethink how we architect web applications. Whether or not some of the predictions of ‘the death of the traditional desktop’ are correct – whether or not the near future desktop is just the browser – we now have the power, without proprietary technologies (flash, etc) to create truly desktop like experiences on the web. Thats nothing mind-blowing, we’ve seen it coming for a little while now.

Ok, then: let me blow your mind.

Because of the great power that modern browsers provide us as Javascript developers a new paradigm of web development is arising. Lets take a look at the current/traditional model:

Here we have a traditional stack. The ‘power’ of the application lies on the server: our development platform of choice (Rails, PHP, etc) sits on top of our database of choice (probably relational, probably SQL). This server platform renders finished HTML and maybe decorates those pages with the use of our JS library and our application specific code (Your $(hit)). In this model we’re using probably at least 3 different programming languages and almost fully on the speed and reliability of our servers for getting data to the user. There’s probably also at least 3 steps in either direction between data and the user:

• User clicks a link on a page or follows a URL
• The request is sent to the server
• App receives request passes it on to Model/ORM layer
• ORM requests the data from the Database
• Database returns the data to the ORM
• ORM returns the data in a parse-able form to the App
• App converts it into user-readable format and displays it to user

Obviously, Rails and most other languages frameworks abstract a lot of this away, so we don’t really have to think in all these steps. They’re there, though.

Welcome to the new world. HTTP Databases and JSON Storage. The simple act of making the database and the browser more powerful on either end has destroyed the need for the middle tier. In the new architecture, Our database (JSON/HTTP based: CouchDB, Cloudkit) serves data as JSON directly to the browser. On the browser side we create a much smaller/tighter ‘controller’ layer with JavaScript. This handles the directing of the user to the right place, the displaying of the data to the user, and the conversion of user interaction into state + data. This middle piece is jQuery + Sammy.js.

In my presentation at jQuery Conf this past weekend (slides available here) I demonstrated this concept in a rather meta-tastic way. The presentation tool I used was called Swinger and it was written using CouchDB, CouchApp, and Sammy.js. The application logic was contained in a single JS file that used a Sammy application to do all the routing, getting data in and out of CouchDB and displaying it in a particularly pretty way. The coolest part about this whole thing is that even beyond taking out the middle layer, this implementation removes the traditional static file serving model, too. With the power of CouchApp and _attachments, the javascript and HTML files needed to serve the application are served directly out of the database. Its like CouchDB and Sammy.js were made for each other. Think about the new steps for this architecture:

• User clicks a link on the page or follows a URL
• Data is requested via AJAX from the server
• The server proxies to the database or processes the request directly
• The data is returned to Sammy.js as JSON
• Sammy.js uses the data it needs and displays it to the user

There are a number really amazing and exciting things to note here. First, notice how the application is written in JavaScript AND the data is JavaScript. The JSON store might actually be written in another language (CouchDB is Erlang, Cloudkit is Ruby) but we don’t really ever have to touch those. Personally, I really like JavaScript. Sure, I miss some of Ruby’s syntax and niceties, but I’ll give that up pretty quickly for something that still shares some of the similar good features (closures, loose typing) and has a ubiquitous deployment environment (the browser). Second, the end result is probably similar if not better to the end user, as we eliminate the need to reload the page at every request, resulting in a better perceived speed.

One of the provisions I gave for my talk is that “I’m less concerned with speed than awesomeness”. That rings pretty true here. I don’t have an architecture like this running in production and getting hit like twitter. I can’t really speak yet to how well it ‘scales’ or how it preforms under load. I CAN tell you about how awesome it is and how easy and fun it was to develop swinger with Sammy. That’s really all I need to know right now.

I think my talk was pretty successful and besides not getting through all my slides, it seems like I got a lot of people excited about CouchDB and Sammy.js. I’m going to write a pretty in-depth recap of the talk and post it soon.

Also, It sounds like there will be a lot more jQuery and JavaScript conferences in the near future. I can’t wait.

Vegas::Runner is dirt simple. Basically, take your existing (or brand new) Sinatra, create a bin/ file and pass your app class to Vegas::Runner. Now when you run the bin, Vegas takes care of PID’s, options, finding a suitable Rack::Handler, etc. (More information here). Gembox is the canonical example, but there are others out there.

Before today, even though I claimed otherwise, Vegas was pretty dependent on Sinatra. I was O.K. with that. Sinatra had some niceties for starting up that I found it easier to rely on. Then I realized the potential of mounting/launching other, non-Sinatra Rack applications.

For example, Cloudkit is pretty cool. With the newest version of Vegas and Cloudkit, I can create a single file, command-line launch-able data based web service.

First, I create a bin. Lets call it ‘cloudcity’. The first thing I need to do is tell the bin that we’re going to execute this with ruby:

#!/usr/bin/env ruby

Next, lets require Cloudkit and Vegas.

#!/usr/bin/env ruby

require 'rubygems'
require 'vegas'
require 'cloudkit'

OK, now that our env, is setup, we just have to build a little JSON schemaless data storage. Rack::Builder lets us just group all of the Rack middlewares and extensions we want into an ‘app’:

app = Rack::Builder.new do
  expose :people, :places
end

Next we just need to pass this app to Vegas::Runner and give it a name:

Vegas::Runner.new(app, 'cloudcity')

Thats it. Heres the whole app:

#!/usr/bin/env ruby

require 'rubygems'
require 'vegas'
require 'cloudkit'

app = Rack::Builder.new do
  expose :people, :places
end

Vegas::Runner.new(app, 'cloudcity')

Now if we run: cloudcity in the terminal, Vegas will find an open port and launch us directly into the app. For now, we get this informative but semi-useless message:

Buuuuut, if we hit ’/people’ we get a friendly JSON delivery:

{"total":0,"offset":0,"uris":[]}

So that was a pretty trivial example. Vegas didnt add that much to Cloudkit’s existing awesomeness. However, take this as a prod to think about the possibilites. You could build a javascript app, that uses cloudkit as storage, package it as a gem, with a Vegas powered bin, and have an easily distributable browser-based application with JSON storage. The beauty of Cloudkit, is that besides Rack and Ruby, there arent really any other dependencies to worry about. I haven’t tried it yet, but potentially, you could use Vegas to distribute a modern (Rack-based) Rails app (the database part might be a little tough, though).

After a mere 48 hours, Rails rumble and the app we (@mrb_bk and I) set out to build, Please Tag Your Photos is launched.

This was both of our first ‘rumble and I was really excited to participate after 2 years of sitting on the side-lines. Somehow, with not enough planning and really only about 24 hours of coding we were able to get something functional up.

What is Please Tag Your Photos? Well, a while ago I realized that I had over 1000 photos on Flickr and half of them didn’t even have real titles. Sure, I remember the moments the photos have captured now, but what about 5 years from now? I tried to do the tagging and updating in Flickr, but unfortunately, the interface made it really difficult to breeze through a lot of photos. The idea was to make an interface that would guide you and encourage you to give your photos a proper dose of data. We got pretty far in our idea, but given the time and opportunity to work on it some more in the future, I think it could actually be really useful.

What works now:

• Flickr authentication
• Some fancy background fetching and scoring of all your photos
• Updating the title, description, and tags of a photo (updates to flickr too)
• Simple ‘recent tags’ interface
• Live score updates

What we wanted to work:

• Geo-tagging interface
• Some nice flashy JS page loading to make it a single page app (Sammy, duh)

What we knew we knew we werent going to get to this weekend but would like to play with at some point:

• Image scanning (using OpenCV) to do facial recognition/tagging.
• Collaborative Photo tagging – earn ‘points’ for suggesting tags for other peoples photos

All in all, decently successful. We used MongoDB for this project and it boosted productivity in some places (not worrying about changing schemas) and was a big road block in others (getting it to work with DelayedJob). Either way it was cool to get to know it, I’ll definitely be using it for future projects. Somehow, in this exhaustive weekend of coding, I did manage to pack in: Curry Making, Two brunches, a BBQ, and some decent sleep. Not too shabby.

The Hierarchy of the Ruby Community

As a Rubyist, I use the Ruby language almost every day. I know most of the stdlib and its methods without thinking. There are certain things I love about it and certain things I hate. Have I ever thought about submitting a patch to the Ruby language? No. There are a couple reasons for this: I don’t really know C; Ruby’s openness lets me change the stdlib without changing the language itself. Something I hadn’t really thought about before, though, is that I’m not a language implementer. In fact, this applies to basically every Rubyist outside of Japan. Rubyists in the US and the rest of the world fit into different parts of the Ruby Hierarchy. Japan, and Ruby Kaigi, however, is the home of language implementers. There’s something completely and utterly different about language vs framework vs plugin vs app. The discussions on a language level are on a much higher level. As Matz revealed in his keynote, there are a bunch of language feature branches that he’s been just toying with, some that have been sitting there for months. Most of them might never be part of Ruby. Thinking about the implications of a new feature, or a change in Ruby’s API, made me realize just how different the thought processes are within the different levels of the community.

When I thought about this more I realized that there a some pretty clear delineations between different groups within the community. It started to look something like this:

The size of the section represents the relative pct of people involved. Each section feeds off each other, but the general flow of information and code is downwards.

I’m sure people have theorized about this before. Yehuda Katz has talked similarly about different groups of Rails users, App Developers, Plugin Developers, and something in between. Personally, I’d consider myself as a plugin and app developer, which is nothing to be ashamed of, its just interesting to actually think about the fact that even above rails core, there’s the interpreter implementers and above them an even smaller group of the ruby core. I’m not really complaining about this at all, its just an interesting way to look at the community that I hadn’t before.

Being a fly on the wall to Yehuda talk to Matz about issues the Rails team is having refactoring, I was witness to an unfortunately rare moment. Knowledge traveling up the chain. This certainly happens to an extent already, but at the language level, for whatever reasons (language barrier, physical distance) the Japanese side of the Ruby community is doing some awesome things that we in the US don’t hear about and vice-versa. I’m hoping more people can make the trip out to the Kaigi and maybe more Japanese Rubyists could come to some of the conferences in the states or abroad.

Ruby for Fun Profit fun

Another theme that I heard again and again is that before Rails, Ruby was a language for hobbyists. Rails changed it, and the community into something else, driven by different needs and goals. I came in with the Rails crew so I cant speak to what Ruby was really like before, but I sensed a sort of dismay about this with some of the Japanese Rubyists. To a lot of them, Ruby may never be their full time jobs. While hacking away at COBOL during the day, Ruby is a wonderful escape. It seems trying to shove Ruby in to the enterprise any way you can, has resulted in a loss of the initial ingenious spark, to do this because its fun. I love that Ruby and Rails are primarily my day job, however, I think in order to stay motivated and continue to like what I do, its important to do some things just for the fun of it. Personally, I forget this a lot: the best way to get re-inspired is often to build something completely useless. Speed, security, unit-tests, and other features we consider important in production code are often the things that bog us down from creating inspired works of code. I think the community as a whole could benefit from a little more fucking around.

Matz told a story in his keynote about how is father gave him a very large sharp knife to bring to school to sharpen his pencils. Sure it was dangerous, but he quickly learned how to use it and it gave him a great advantage over other students. He likened this to not wanting to have to dumb down Ruby so people couldn’t hurt themselves. In the end its better to have a sharp knife and learn how to use it. I would go further and say its important to push the limits of your own comfort with the tool in order to better learn how to use it. As Rubyists of all levels of experience, its important to challenge ourselves and the community for the sake of the challenge and fun, without always worrying about ‘is this secure?’ or ‘hows the test coverage?’.

In general the trip was a great success, I met a lot of people, got to hang out with some good friends and travel around a beautiful country I had never seen before (pictures here). I strongly urge people to make the trip out for Ruby Kaigi ‘10!

• Sinatra-Sammy: Inspired half by potential usefulness and half by a dare from binary42 at the first meeting of NYC.js, sinatra-sammy is a sinatra module/plugin that includes sammy.js makes multi-page apps appear to be single page (with deep-linking etc) while maintaining the SEO and other benefits of a multi-paged, normal app. Make sense? No? Yeah, OK. I’m working on putting up a good example, for now you can clone the repo and checkout the included test app.
• Speaking of NYC.js, I was honored to be the first speaker and did a little presentation about Sammy. Slides are viewable here
• Vegas + Gembox are now windows friendly. It took a bunch of hacking, specifically around the daemon-ization (Kernel.fork is not natively implemented on win32) but windows users can now use Gembox just like their Unix based brethren. Windows users can now also, and should, make use of Vegas for creating Rack based executables.
• I’m giving an updated version of the talk I gave at GoGaRuCo “Sinatra: The Framework Within” at Ruby Kaigi. I’ve been hacking on a secret and useful project and hopefully I can wrap it up on the plane and present it at the conference.
• I got a new camera. I’ll be posting a lot of drool worthy food photography on flickr.

For anybody attending RubyKaigi, please come find me and lets hack/talk/eat ramen.

My favorite feature from this update might be the simplest.

Rendering partials now uses a special swap() method on Sammy.Application. By default it just uses jQuery's html() method to swap out the old content of $element with the new content. The power though, is you easily override this to provide a cool transition when a new partial is rendered.

var app = $.sammy(function() {
  
  this.swap = function(content) {
    var width = $(window).width();
    this.$element()
      .wrapInner('<div class="inner"></div>')
      .children('.inner')
        .animate({queue: false, left: "-" + width}, 400)
        .remove()
        .end()
      .html(content)
      .css({left: width})
      .animate({left: '0px', width: width}, 400);
  };
  
  this.get('#/user/:name', function() {
    this.partial('name.erb', {name: this.params['name']});
  });
  
  //...
});

Now, when you go to '#/user/aq' or similar, it will use the swap method to do a nifty transition, instead of ye old html().

Theres more examples and Sammy on the way. Come join the mailing list or hang out in irc to learn or contribute.

• Two weeks ago I released Sammy and since then its been getting a lot of great feedback. It was mentioned in a github rebase and Nick Plante wrote a great post on DDJ. I’m really impressed with what people have done with it so far. Alex Lang, especially, has fulfilled a vision I had by embedding Sammy as the client controller for a couch app. Also make sure to check out his Boom Amazing presentation tool using Sammy as the proxy for controlling a slideshow contained in a massive SVG. I’m crossing my fingers that they’ll be a video of his RailsWayCon presentation. Sammy also has a mailing list now and (hopefully) soon a dedicated IRC room.

• Gembox was featured as a great tool for viewing RDocs on RubyInside. This inspired a little flurry of activity and commits with more to come. Thanks to Samuel Elliot Gembox works in passenger pane.

• EngineYard finally posted the videos from Scotland on Rails and you can view my talk in full quicktime glory. Really you should just take the whole weekend and watch all the videos. LOTS of fantastic talks.

• Goruco is tomorrow! If you’re attending and reading this, please come find me. I’ll probably be milling around with a bearded dude (@mrb_bk).

After consulting the Rails Bridge mailing list and with the great recommendations from the community I’ve decided to split the money in half. 50% will go to the Anita Borg Foundation who have a number of great projects to support women in the development/programming communities. The rest will be donated to Rails Bridge itself. Even though its not a huge amount of money, hopefully it will make a little impact and help with some of some of these awesome initiatives.

The fund is still open until the end of the week. Please donate!

Get Started

• Watch a Screencast (iPhone)
• Read the Introduction
• Read the Docs
• Follow @sammy_js
• Join the mailing list

The Story

About three months ago, when I was knee deep in hacking and playing with Sinatra I had this weird moment as I woke up one morning: “What if I could build Sinatra in JavaScript?” At that point it was just a challenge – I had just started doing almost full-time JS for a client and it seemed like a fun project.

As I started to actually implement it (slowly in short spurts on the weekends), I realized that using the power of JavaScript’s closures and jQuery’s powerful event system, this could be something more then just a ‘clone’. It could actually be . . . useful!

With that in mind, I set out to actually make is usable. I cleaned up the code, I wrote some example implementations, and most importantly – I documented the shit out of it.

I’m pretty excited about it (can’t you tell?) especially about its possible uses for structuring applications on the front-end for RESTful Databases and services. Embed it in a CouchApp to build an entire application in JavaScript while having access to a full range of documents/querying abilities.

The Future

I’m going to continue refining and adding examples. Please feel free to email me or contact me through github with questions/feedback.

Happy Friday!

Officially, as of today, the work is being grouped and promoted through RailsBridge.
Thanks to everyone involved. I wont be there in person, so good luck to everyone at RailsConf!

Stop what you’re doing and make your project a github page. For the love of god, your project has no documentation. RDoc is cool, READMEs are decent, but descriptive websites with examples? Oh, they RULE.

At first, I was skeptical. Pages looked cool, but it seemed like a lot of effort to create a page especially one for each project. Then two things happened:

1. Tom yelled at me/us
2. I discovered the power of jekyll

The main problem that jekyll solves for github pages is the ability to have a general ‘layout’ that eliminates the HTML copy and paste you would have to do if you were managing pages for more then one project. Having a unified layout also allows you’re project pages to have a unified brand and feel – something I believe is important.

There other things that are truly great about using jekyll.

Easy code highlighting.

Highlighting a block of code is as easy as:

{% highlight ruby %}
def awesome
  "for real. I know."
end
{% endhighlight %}

Then all you have to do is grab a syntax stylesheet. You can grab mine here

Ability to write pages in textile or markdown.

I’ve been doing all my blogging in textile for a long time now, and being able to write an easy to read page that I can easily find and edit text in makes it more likely that I’ll continue to update the pages with new releases.

Ability to pass variables from individual pages into your layout to make your layout even more reusable.

This is underused, but because jekyll interprets the layout file after its read the variables from the top of your document it means you can stick variables in your YAML head that the layout can use.

For example: In my github project pages, the YAML head looks something like:

---
layout: quirkey_code
title: sinatra-gen
github_name: sinatra-gen
current_version: 0.3.0
nav:
  - name: What
    link: "#what"
  - name: Why
    link: "#why"
  - name: Usage
    link: "#usage"
  - name: Options
    link: "#options"
  - name: Dependencies
    link: "#dependencies"
---

Beyond passing the page title, I’m also passing a ton of other variables. The github_name is used to link to the downloads of the project on github – a reusable piece of code that exists at the foot of every page. In the layout it looks like:

<h3 id="installing">Installing</h3>
        <div class="highlight"><pre>sudo gem install {{ page.github_name }}
        </pre></div>
        <p>Or directly from github:</p>
        <div class="highlight"><pre>sudo gem install quirkey-{{ page.github_name }} -s http://gems.github.com
        </pre></div>
        <p>Github in thier infinite awesomeness also lets you download the source in multiple formats.</p>
        <div class="download">
          <a href="http://github.com/quirkey/{{ page.github_name }}/zipball/master">
            <img border="0" width="90" src="http://github.com/images/modules/download/zip.png" />
          </a>
          <a href="http://github.com/quirkey/{{ page.github_name }}/tarball/master">
            <img border="0" width="90" src="http://github.com/images/modules/download/tar.png" />
          </a>
        </div>

current_version and nav work the same way. nav uses a little more liquid magic to get the job done:

{% if page.nav %}
<ul id="pagenav">
  {% for nav in page.nav %}
  <li><a href="{{ nav['link'] }}">{{ nav['name'] }}</a></li>
  {% endfor %}
  <li><a href="#installing">Installing</a></li>
  <li><a href="#requests">Bugs/Feature<br />Requests</a></li>
  <li><a href="#contact">Contact</a></li>
</ul>
{% endif %}

This way I can have a super flexible nav menu, changing what I need and what I don’t in the page instead of in the layout. You can see the full code for the sinatra-gen page or the full quirkey_code layout.

Submodules for the ultimate stoke factor.

After building a couple of these project pages, I thought “Hey! I can just put my layout in its own repo and when I start a new project page, I can just submodule it!”. Great idea, unfortunately at the time, github didn’t support it. However,after nagging PJ a bit now they do!

My workflow, is I’ve set up a jekyll_layouts repository and when I first create my gh-pages branch (described in detail here), I just run:

git submodule add git://github.com/quirkey/jekyll_layouts.git _layouts

Then, the next time I push, github graciously pulls my submodule before building my page with jekyll. Sweet. Some things to note:

• You have to have a public repository for the layouts and you have to submodule with a globally accessible URL (as in the ‘public’ clone url instead of ‘your’ clone URL).
• When you switch back to your master branch, the _layouts directory wont disappear automatically. You can add it to your .gitignore OR just delete it and it will reappear when you switch back to gh-pages.

Using the power of git, there is also a way to continue editing your submodule’d layouts while in a pages branch. The trick is that while you use the public clone URL for the ‘origin’ server of the submodule, you can add your private URL as another remote for the cloned repository.

For example: If I’m in my sinatra-gen repository at the gh-pages branch, I can cd into the _layouts submodule:

[10:47 AM:sinatra-gen(gh-pages)] $ cd _layouts
[11:23 AM:_layouts(master)] $ 

If I inspect the branches I see:

[11:23 AM:_layouts(master)] $ git branch -a
* master
  origin/HEAD
  origin/master

From here I can add another remote, which is actually the same repository – just the private clone URL.

[11:24 AM:_layouts(master)] $ git remote add upstream git@github.com:quirkey/jekyll_layouts.git
[11:26 AM:_layouts(master)] $ git fetch upstream
From git@github.com:quirkey/jekyll_layouts
 * [new branch]      master     -> upstream/master
[11:26 AM:_layouts(master)] $ git branch -a
* master
  origin/HEAD
  origin/master
  upstream/master

Now If I make a change in the _layouts directory, its as easy as:

[11:28 AM:_layouts(master)] $ git commit -am "Moved around title" 
Created commit 5726d5e: Moved around title
 1 files changed, 1 insertions(+), 1 deletions(-)
[11:28 AM:_layouts(master)] $ git push upstream master
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 314 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To git@github.com:quirkey/jekyll_layouts.git
   5013157..5726d5e  master -> master

All of my pages code is under the MIT license so feel free to use and manipulate. If your nice and or grateful, you can link back to this site in your footer.