Dr Nic

Migrating project websites to github pages with sake tasks, new websites with jekyll_generator

Its almost Christmas time and that means presents.

It also means that sometime between today and December 25th you need to go out and buy other people some presents because you haven’t done it yet.

But there’s someone else special in your life that deserves an Xmas gift this year. That special someone is your open source projects.

You might think, “But, Dr Nic, what do I get for the open source project that already has everything? What gift would my open source projects possible appreciate?”

Its true – this year has been a boon for open source. You probably migrated your projects from SVN to Git this year. Specifically, you probably clicked the “create a new one” link on your GitHub home page a lot this year: either to migrate your old projects to github or start new ones. Lots of new ones.

And now that your code is on github, your README file is rendered beautifully on the home page, so you were more inclined to rename it to README.markdown or README.textile and thusforthly fill it full of education information about your projects.

More people would then instantaneously figure out what the f@#$ your project actually does, thus more people used it, thus more people wrote patches or forked your code and sent Pull Requests.

All round, in 2008, I bet your open source projects had a sweet year.

Nonetheless, it is Christmas time and you should now get them a present. Something they wouldn’t get for themselves. Something you wouldn’t have done for them except for the free loving spirit of Christmas.

The Gift for all Open Source projects

A website.

Oh sure, github renders your README.markdown file. Yeah, yeah, github gives you a wiki for your project. Sure, sure, Google Groups let you communicate with your co-developers and users. Certainly, you don’t need a website for your project.

That’s why its a Christmas gift. You’re going to do it because you care.

Websites sell your project. READMEs and Wikis educate. The project website will sell it and make people want to use your stuff.

A website could have a blog with an RSS/atom feed. Then you could post updates about your project. People could subscribe and also leave comments. Oh the novelty.

And if it only took 5 minutes to get all this setup – the website code, the blog engine, the RSS feed, the comments, and published to its own hosted server – then that would just be oh so sweet.

So we’re going to do some craft for our Xmas present. A little DIY project, if you will. You’ll need a few things that you’ll find around your house, a command-line interface, and a beer or perhaps some port or sherry. Christmas cake is good too.


How to yell at people with GitHub from TextMate

Sometimes when you are perusing code you ask the question: why the hell is that there? or why does this even work?

Now you can instantly navigate from that erroneous line to the git commit where it was added, and then using github’s commenting system add a full-flavoured remark about that person’s code. I’m not sure if profanity is against the GitHub Terms of Service, but I’d rather ask forgiveness than permission.

TextMate + GitHub – how to comment/discuss on a line via GitHub from Dr Nic on Vimeo.

Download and installation instructions are available in all good bookstores.

Just for TextMate?

There is an editor for Windows – E-TextEditor – that was designed to support TextMate bundles. So far, the GitHub bundle doesn’t use any special features of TextMate’s latest-and-greatest UI libraries, so it should be usable on E-TextEditor.

Also, a VIM project has been created to port the GitHub bundle, by Christoph Blank. Cristoph can be found hanging around #hobo on irc as ‘solars’, if you want more goodies in the VIM bundle.

GitHub and TextMate Unite

I wanted to go from a source file to the equivalent file on github. I wanted a selection of lines in TextMate editor to also be selected when I was taken to github.com. I wanted to cut back on my senseless killing of innocent pasties.

Finally, I wanted to make a nice little video to show off the new GitHub.tmbundle.

TextMate and GitHub: Show the current file in GitHub from Dr Nic on Vimeo.

Which remote repository is it choosing?

If you have multiple remote references to github.com repositories, then the algorithm picks one in the following order:

  1. A remote named ‘github’
  2. A remote named ‘origin’
  3. The first remote for a github.com repository

What else could go in a GitHub textmate bundle?

GitHub Badge for your Blog with 100% guarantee of more coolness

GitHub Badge

The killer app for JavaScript in the 90s was to take a perfectly readable sequence of words – aka “a sentence” – and turn every single character a different colour. You did that, then you went back to doing normal work.

The killer app for JavaScript in the 00s is widgets/badges. Taking perfectly useful stuff from one website – aka “data” – and re-posting it on your blog sidebar.

In both circumstances, across two decades, you did this to look cool. Sure, it never works but you do it anyway.

Thusly, riding high on the world-dominating success of GitHub there seems to be a vacancy in the department of “JavaScript badge for my blog to make me look cool” projects, in the sub-category of “GitHub”.

The first entrant and thus market leader of the “Blog Badges for GitHub” micro-industry is the “GitHub Badge” It is beautifully demonstrated in static image form above, or if you click the image through to the website (or here to my blog and its aesthetically appealing enhancement with said GitHub Badge) you’ll see it live and interactive.

Touch it. Feel it. Press the “Show more” link for hours of entertainment.


Then get it for yourself. Read the GitHub Badge website or just…

Slap the following into your blog sidebar:

<div id="github-badge"></div>
<script type="text/javascript" charset="utf-8">
  GITHUB_HEAD="div"; // e.g. change to "h2" for wordpress sidebars
<script src="http://drnicjavascript.rubyforge.org/github_badge/dist/github-badge-launcher.js" type="text/javascript"></script>

Only GITHUB_USERNAME is a required pre-set variable. The others above show the defaults, and can be changed by being specified.

For my WordPress sidebar, which uses <li> and <h2> for sections and headers, I use the following:

<li id="github-badge"></li>
<script type="text/javascript" charset="utf-8">
<script src="http://drnicjavascript.rubyforge.org/github_badge/dist/github-badge-launcher.js" type="text/javascript"></script>

Thus the badge is inserted in the <li> element, and the “My projects (drnic)” header is an <h2> instead of a <div>.

Source and tests on github

You can fetch the source from github – http://github.com/drnic/github_badges/tree/master – using:

git clone git://github.com/drnic/github_badges.git

You might want to add an option to turn off the auto-CSS generator so you can theme it yourself.

The JavaScript tests are in test/ folder. Either run them with rake test, or individually open the files in your browser.

Future cool things the badge could do…

Ultimately, when Chris Wanstrath (harass him on twitter) adds more fields and APIs to the GitHub API then the badge can do more. Currently it orders the projects in reverse order – that is, newest projects first. If I can get the network/watching counters then I can order the list using those values, etc.

Any other cool ideas for what the badge could do?

I’d like to be able to show project version numbers (e.g. gem version numbers) and other project meta-information. This would require GitHub to offer a CRUD UI for generic key/values and for the fields to be returned via their API.

If you know Chris and can throw heavy objects at him with moderate certainty of hitting him and not damaging any expensive equipment, please do so til he gives me this stuff.

Git for Rubyforge accounts

rubyforge has git - account creation

First there was CVS, then came SVN to RubyForge. Actually, I’m guessing that CVS was the sole SCM initially, and SVN was added later. I just can’t imagine them starting RubyForge from scratch and explicitly saying “yeah we’ll offer CVS because …”. I don’t know how that sentence would have finished. It must have been added first. There is no valid “because …”.

But now, with each RubyForge project there is a Git repository. This is great for two very good reasons:

  1. the end is nigh for empty or unmaintained SVN repositories
  2. less centralised decentralised development

GitHub + Gitorious are the go-to-guys for somewhere to hang your proverbial hat: somewhere you push your local git repository to so other people can access it.

Yet when I’m investigate someone’s new RubyGem or other project, the first place I look for its source is RubyForge. I assume the project name is the same as the gem name, and goto http://rubyforge.org/projects/pastiepacker for example.

rubyforge scm link

Then I click on the SCM tab. Normally this gives SVN instructions. In this modern era, many projects SVN repos can now be blank or unmaintained with Git repos being preferred by many.

So, the reason to push your git repository to RubyForge’s new git system is to make life easier for me. I mean, I don’t know who else clicks on the SCM link, but I do.

While this is all well and great for new projects – you can select “git” instead of “svn” as per the first image above – but I’m not yet sure how to migrate old projects [follow support ticket].

The other reason is to actually help your distributed repository be distributed. Push it to github. Push it to gitorious. And now you can push it to rubyforge. Sweet.

Adding another remote repository

Since your default remote repository is probably called “origin”, you may wonder how such a naming schema could ever expand to multiple remote repositories? Might I suggest “rubyforge” as the name of the rubyforge repository?

git remote add rubyforge gitosis@rubyforge.org:pastiepacker.git
git push rubyforge master
git push origin master

If you do this for all your projects, perhaps a bash script is in order:

function gpall() {
  git push rubyforge master
  git push origin master

One project equals one repository, but multiple packages

Using a Rubyforge project’s git repository might be problematic where you release multiple packages/rubygems (codeforpeople, seattlerb, mongrel, drnicutilities, etc). Here I’d prefer one repository per package, rather than one repository for the whole “project”.

Perhaps you could push the master branch from your local repository for each package into different branches of the rubyforge git repository. Thoughts?

Can’t push to your rubyforge git repo?

From the FAQ:

RubyForge Git repositories are managed via gitosis; gitosis does authentication via public keys. This means that in order to push to a RubyForge Git repository you’ll need to upload a public key to your account – see notes on that here.

Generally, Git support is something we’ve just introduced, so feedback about it on the forums would be quite welcome.

What is Pastie Packer?

I can’t tell you. Its a secret.