Second, I’m headed back to Edinburgh to speak at the Scottish Ruby Conference. I love this city, and the conference last year was very much above par. I’m excited to say I’ll be talking about JavaScript at a Ruby Conference. I’ve been working this talk out in my head for a long time, through lessons learned and taught to my colleagues and clients. There are also a lot of other great looking talks, including Tim Bray, Alexander Lang, Scott Chacon. Actually, the whole conference looks pretty incredible. I guarantee fun. As of writing this, there are still tickets available, so register now.

Third, and possibly most exciting, I’m very proud to be chosen to speak at JSConf 2010. I heard nothing but “AWESOME” about last years event, and I kept hitting myself for missing it. This year the esteemed Chris Williams is putting together what promises to be the best techincal conference ever. I can’t even say how excited I am to be a part of it. The status is that the conference is already sold out, but I would follow @jsconf with a watchful eye to see if there are any announcements. Chris is also a lover of beer, so I cant promise anything, but some very very rare bottles might sway his favor.

There are some other proposals out there as well, but these two confs were all I did this year, I’d be pretty happy.

Last week I had the pleasure of launching a big new feature set into production for one of my favorite clients, Wejetset. The excitement was greatly enhanced by the fact that City Notes Interactive makes full use of my own special framework, Sammy.js.

City Notes and the other features deployed were an almost ideal project. The design and direction was an awesome back-and-forth collaboration between myself, Tom Ran of The Scout fame, and the face and brains behind Wejetset, Taj Reid. I could probably talk forever about how much fun it is to work with those guys, but in this post I’d rather dive deeper into the challenges and takeaways in the actual code.

I knew right from the beginning that Sammy would be a good fit for this. The question was how. Sammy let me think about the construction of the app in terms of routes and instantly gave me a way to create perma-links to specific notes and even specific filters.

Templating

One of the first decisions I made was to go with server-side templating. As much as I am and have been a proponent of pushing everything client-side, for this specific app it made much less sense. Specifically, there are other places throughout the site where I’m using the same templates and the benefits of re-using them were just too strong. Also, this gives the extra bonus of making the site a little more google friendly. In fact, without JavaScript the most recent notes still display and can link to the right destinations.

Forms

One thing that I wanted to streamline as much as possible is handling forms – posting them to the server and handling the responses without leaving the page. I came up with a useful method – postFormDirectly() – that handles the post route and submits it directly to the server, handling the response and sending it back to a callback.

Heres an example call, for positing the form to create city notes.

this.postFormDirectly('/city_notes', function(response) { 

  if (response.status == 'success') {

    this.redirect('#/');

  }

});

Instantly, you can tell that a lot is abstracted and changed from a traditional route. Here we’re routing on an actual URI as opposed to just an anchor. This has the added benefit of allowing the form to work without JS. (As an aside, I’ve personally found a key to making degradable and unit testable sites is to first make the process work (albeit without any flair) without JS and then add the code to push the interactions and the single page-ness.)

To give a little more insight, heres the implementation:

this.postFormDirectly = function(path, callback) {

  var app = this;

  app.post(path, function(context) {

    var context = this,

        post_path = this.path, 

        wrapped_callback = function(response) {

          WJS.handleResponse(response, context.params, function(r) {

            if ($.isFunction(callback)) {

              callback.apply(context, [r]);

            }

          });

        };

    if (!post_path.match(/js$/)) { post_path = post_path + '?format=js'; }

    this.params['$form'].find(':input').trigger('clear-errors');

    this.params['$form'].ajaxSubmit({

      url: post_path,

      dataType: 'json',

      success: wrapped_callback,

      error: wrapped_callback

    }).trigger('show-loading');

  });

};

Lets take a little walk through. First and formost, we’re just adding a post route to our Sammy app. The contents of this route allow us to use jquery.form’s nifty ajaxSubmit to send the form to the server without reloading the page. We’re creating a response callback for the ajax request called wrapped_callback which takes the response from the server, passes it to handleResponse which then in turn calls our passed callback if it exists. handleResponse does a lot, too, but I’m not going to post the contents here (though I might make it into a plugin …). All you need to know is that the response from the server is JSON and looks something like:

{"status": "success", "message": "You're note was posted successfuly."}

handleResponse displays the little flash message and also highlights the form if there are errors. I use this pattern on a number of projects and it seems to work pretty well.

One neat Sammy tidbit you might not have known about, in post & put routes, there is always a ‘$form’ param which is a jQuery object containing the HTML form that submitted to the route. Very useful for cases like above.

Modals

If you play around with the app, you’ll notice that we make pretty good use of modal windows for actions (submit/share/email to friend). The cool thing about using Sammy for this is they’re just routes, so refreshing the page or linking jumps directly to them. I also wrote a little jQuery extension that I found extremely useful for them:

$.fn.findOrAppend = function(selector, element) {

  var $this = $(this), 

      $el = $this.find(selector);

  if ($el.length > 0) return $el; 

  // el doesnt exist so lets make it

  if (typeof element == 'undefined') {

    // figure out how to build the element from the selector

    var parts = selector.split(' ');

    $el = $("<div>");

    if (parts.length == 1) {

      // single selector so just added

      $el.addSelector(selector);

    } else {

      // selector with multiple depth so we just want the last selector

      $el.addSelector(parts.pop());

      // find this down the parts

      $this = $this.findOrAppend(parts.join(' '));

    }

  } else {

    // we provided a specific element

    $el = $(element);

  }

  // append it

  $this.append($el);

  // return it

  return $el;

};

findOrAppend() takes a selector (I used it mostly with #ids) and creates a series of nested divs (if needed) that matches that selector.

For example, given HTML:

<div id="container">

  <div id="main"></div>

</div>

And we wanted to replace the contents of an element #submit_modal inside of it:

var $modal = $('body').findOrAppend('#main #submit_modal');

The first time its called, it actually creates the neccesary #submit_modal div and returns it. However, if it exists already, it will just find it using $.fn.find() and return it.

For modals, this allows me to ensure that the container exists first, then replace it with the contents of the modal that I’m fetching from the server.

this.helpers({

  // …

  showModal: function(path, selector, callback) {

    var context = this;

    this.showLoading();

    this.loadNotesInBackground();

    this.partial(path, function(form) {

      var $el = context.$element()

                .findOrAppend(selector);

      var $close = $('<img src="/images/button_remove.gif" alt="close" class="close_modal" />');                    

      $el.hide().html(form);

      $close.prependTo($el).click(function() {

        $el.slideUp(200);

        context.redirect('#', context.conditionsToURL());

      });

      if (callback) { callback.apply(context, [$el]); }

      // bind error handlers

      context.bindFormErrorHandlers();

      context.hideLoading();

      $el.slideDown();

      $('#main').slideTo();

    });

  }

  //…

});

Here I have a helper that fetches the view/template from the server using partial() and then situates its content using findOrAppend(). It also does me the favor of adding the little close icon in the upper right corner. A typical use is for the login screen:

this.get('#/login', function(context) {

 this.showModal('/account/login', '#main #login_signup.modal')

});

Analytics

It has to be said as well that I’m really excited about the burgeoning Sammy.js community. I’m lucky enough to have some other really smart individuals working on Sammy projects and sharing some of their code through plugins. Thanks to Brit Gardner and his Sammy.GoogleAnalytics plugin, adding analytics to the app was as easy as dropping in the file and adding one line to my app. That felt really really good. I hope more people will start sharing some plugins soon.

A lot more

There were a lot more discoveries over the months building this app then I can really share in a little blog post but needless to say, I’m going to try to bring the usefull and reusable stuff back into Sammy and plugins for everyone to use. If you want to hear more about it or have specific questions, dont hesitate to ping me on IRC or twitter or email the Sammy mailing list.

Highlights included:

• Going to RubyConf without actually going.
• Eating and drinking fine food and wine in Napa/Sonoma for 4 days non-stop. (Full list of vineyards and restaurants with menus on request).
• Spending time with my lovely wife.
• Seeing friends I don’t get to see enough.

Though this blog may tell a different story, I actually have been writing a lot of code as well:

• Most notably, the production, public-facing Sammy.js application I’ve been working so diligently on finally launched: Wejetset City Notes Interactive. I learned a ton writing and deploying it, and I promise to share a bunch of those lessons, soon.
• With the help of the amazing rvm I’ve started getting all my gems tested and working on Ruby 1.9. I think everyone should be doing the same, so if people are interested in my approach, maybe I’ll write a tutorial.
• I’ve even been porting other peoples gems to 1.9. Specifically I have a fork of the oauth gem that works on Ruby 1.9.1 without any dependencies. It should be merged and released to the master oauth gem shortly.
• It’s been a long time coming, but I’ve been working on a big rewrite of qadmin thats being used in production in a couple places. Its a lot easier to configure and extend and really just needs to have its documentation thoroughly updated before I can do a real release.
• I’ve also updated my portfolio to include links to my talks and some other new projects.

I’m hoping to get some more blogging done and OSS releases out in the next couple of days so stay tuned!

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.

• 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.

The episode also features Rich Kilmer – whose talk about MacRuby and HotCocoa totally blew my mind.

WTF

This weekend after reading a couple posts and a lot of tweets I started getting really frustrated about the situation surrounding Matt’s talk at GoGaRuCo. My frustration and anger did not stem from being offended by Matt’s talk, nor did it stem from thinking that everyone who was offended was wrong. It came from a gut reaction to all this horrible negativity thats spreading like wildfire.

I was at GoGaRuCo. In fact I was also speaking. I watched every talk, attended the after-parties and had one of the best conference experiences I’ve had. I learned a ton, met a ton of interesting people, and heard about things from a ton of different perspectives. I’m not going to say more then that. It was awesome.

The ‘controversy’ around Matt’s talk started as a couple smart individuals being angry and frustrated at another smart individual for making a mistake. It’s become a blame game and a reason for people to blame a single talk for the ails of an entire community that had the same issues before. I want to stay positive, so here are three simple rules of ANY community:

• You can not fault an entire community for the actions of a single individual.
• In any community there will be opposing opinions on definitions of moral correctness for n issues.
• If you actually want to change the community, you have a better chance of influencing the future community through education then the current community through preaching.

Going from the last one, lets define a problem set and move forward.

The Problem Set

Lets rip open this silver lining. If anything good comes out of this let it be that it brought a bunch of long standing issues back in to the limelight. The big complaint out of this all has been that there are not enough women in the Ruby community. It’s pretty obvious that this is an issue. I mean, out of conference of 200+ there were less then 10 women. In fact, this conference probably had more women then any other Ruby conference I’ve been to.

I’m not going to try to deduce the myriad of reasons why this is true, instead just mention something that might lead to this situation.

Ruby is not taught in Schools. If we really want to make Ruby a language and community for everyone, the only way to ensure that people actually get exposure is to get it into schools. It would be awesome if I learned Ruby in college, but beyond that – it would have been AMAZING if I had HacketyHack when I was a kid. I whole-heartedly believe that Ruby is a great first language and the veritable cornucopia of implementations and uses could convince anyone with a slight inclination to do great things with it.

FTW

Let’s actually make this happen. How can we get more women in software development? How can we bring more women into the Ruby community? I don’t have the answer and honestly, I’m not a fantastic teacher or community organizer. However, I’m a pretty decent developer and as a freelancer I’m making some decent money so that I can give some of that money to people who are much better teachers and community organizers. With that said, I’ve started a pledgie and put $500 dollars in it. After 1 month, I’m going to donate any money I’ve collected there to a charity to support either teaching Ruby/development in schools, or supporting women in development. Depending on how much we raise, I might donate to multiple organizations. If you have suggestions about specific organizations please tweet @aq or email me at aaron at this domain.

Please donate! Even if its only $2. I’ll be posting updates to twitter and here to.

Let’s try to ensure that GoGaRuCo 2025 is an awesome gathering

I haven’t even returned to NY yet – I’m writing this in Pivotal Labs SF - who were nice enough to let me steal a desk and some WIFI for an afternoon.

GoGaRuCo was amazing. Another awesome conference. Thanks to Josh Susser, Leah Silber, and the other organizers and volunteers for making a fantastic weekend of nerding out. I’m going to be posting my slides soon, and there should be a full video recording of it within the next couple of weeks. You can see a quick rundown (via live-blogging of my talk) at the Pivotal site.

(Some of) The highlights of the weekend:

• Getting a real explanation of CloudKit from Jon Crosby. Once I understood what it was – a fully compliant REST interface that abuses HTTP to create a standardized ‘appliance’ that sits on type of Rack. Think: Rack CouchDB.
• Talking to Yehuda Katz about why Javascript/jQuery is awesome and why the next version of rubygems will solve all my problems.
• Seeing Jaqui Maher talk about solving REAL problems with ruby/rails.
• Greg Borenstein blowing my mind with the knowledge that I could use Ruby to hack an Arduino.

Most importantly: I met some very cool, extremely friendly, and super-fun people in this beautiful city. I can’t wait to come back.

Update: I posted my slides from the talk at scribd