So the basic workflow is to work in Git branches. To make sure the Git master and the Subversion trunk are in sync, I follow two basic rules. First, the only ways the Git master changes are:

• an update from SVN trunk
• a merge from another Git branch

Second, the only time I ever use SVN to commit or update is when I am on a clean Git master.

Here are the detailed steps I use.

Starting off

> git checkout master
> svn update
Updated to revision 435
> git commit -a
> git tag svn-435

Now master is up to date with the SVN trunk.

Working on code

> git checkout -B niftyFeature

Create a branch to work on a feature. This overwrites any existing niftyFeature branch.

(hack)
> git commit .
(hack)
> git commit .
(hack)
> git commit .

Getting ready to commit to SVN

> git checkout master
> svn update
Updated to revision 439

There will be no conflicts since Git’s master branch just tracks the SVN trunk.

> git add --all
> git commit -m"Update to SVN revision 439"
> git tag svn-439

The tag can be useful for diffing later on.

Now comes the scary part.

> git rebase master niftyFeature

That rebase essentially merges your work into the latest from the SVN trunk. Git rebase seems to work better than svn merge, but even so, you might have to resolve conflicts in the normal Git way.

The rebase also switches to the niftyFeature branch.

(test)

If there are problems:

(hack)
> git commit .

Committing to SVN

> git checkout master
> git merge niftyFeature

This is a no-fail fast-forward merge thanks to the previous rebase.

> svn commit
Committed revision 440

The SVN commit may update SVN keywords if you’re using them. To avoid confusing Git, commit these changes too:

> git commit -a -m"Update SVN keywords"
> git tag svn-440

I suppose this workflow is nothing but an ad hoc, informally-specified, bug-ridden, slow implementation of half of git-svn. I already know Subversion and am learning Git, and my goal was to practise my Git rather than learn a third set of commands (git-svn). I plan to use SVN a lot less in the future, so this way I will only have to forget one set of commands, not two.

Bonus tip: Backups

You can clone your repository to another location on your file system. A good choice might be your Dropbox folder or similar. This makes it trivial to keep your entire repository backed up.

> git clone --bare . /dropbox/projectName.git
> git remote add backup /dropbox/projectName.git
> git push backup

Making it a bare repository avoids problems with pushing. Then whenever you feel like backing up (i.e. all the time), just do this again:

> git push backup

At a high level, the most interesting part of the design is the navigation: no hierarchy, just tags. Opinions were divided, but I like the purity and elegance of the idea, and the implementation gives a lot of structure to the tags.

At a low level, they described the initial URL scheme they came up with. The site is implemented as a single-page site, with all content updates done with Ajax. For modern browsers, they use the history API to seamlessly change the URLs. For example, if a user clicks a “Travel” link, the browser address bar will switch from http://nz.com/ to http://nz.com/travel without refreshing the whole page. (Opera offer a good history API introduction.)

Browsers that don’t support the history API instead use Google’s Hash fragments specification: browsers would see the URL http://nz.com/#!travel, while web crawlers would see http://nz.com/?_escaped_fragment_=travel . (See the spec for the reasoning behind this.)

Eventually they realised they didn’t need to use hashbangs at all. HTML5 browsers, with their fancy history API, end up being able to use plain URLs like http://nz.com/travel without ever refreshing the whole page. But crawlers can use the same URLs to fetch whole pages — the backend can easily tell whether a request is coming from a crawler or a browser. And less capable browsers can just use a plain hashy URL like http://nz.com/#travel.

This is quite a nice solution, except that if a web crawler does get hold of an URL like http://nz.com/#travel, it will only ever see the site homepage. That’s an SEO fail. But they point out that this probably won’t have much of an impact because the proportion of such links floating around won’t be high.

They talked about various libraries they used to do this: jQuery plugins Pjax and History.js and the JavaScript MVC framework Backbone. (Poking around the Pjax page I discovered a very useful online Closure compiler service that actually hosts compiled code!)

I really enjoyed seeing this lively presentation from a team who are pushing a large public website into the HTML5 world. I’m feeling inspired for my next project!

But there were some particular highlights for me. Git, of course; everybody loves Git. In fact, 5 years ago I started a project in my day job. I strongly advocated using Subversion, and though there was some resistance (“What’s wrong with CVS?”) we did go with SVN. Now all our projects use Subversion. And now, working on an updated project for the same client, I’m keen to move to Git and it looks as if we’ll be doing that. Maybe 5 years from now we’ll be moving on to the next big version control paradigm. Nah, that’ll never happen, because Git is already version control Nirvana. Mmm, this Kool-Aid is delicious.

Mal recommended MacVim. I have installed it now. I spend a lot of time using Vim on various OSes, and I only know about 5 commands. Maybe if I switch to MacVim I will actually become a proper Vim user instead of a perpetual newbie.

He also spoke very highly of Sass, an “extension of CSS3, adding nested rules, variables, mixins, selector inheritance, and more”.I’ve always been intrigued by Sass and Less and their ilk, but I worry that it’ll be too easy to write logical and clear Sass code that expands to CSS code with complicated selectors, leading to cascade problems, debugging nightmares and general unhappiness. (Coincidentally, a few days later Stephen Tudor pointed out a few of these issues in Responsible Sass Authoring.) But Mal pointed out that you don’t have to go all-in: just a few key features (like mixins and variables) will make a big difference.

I’m convinced it’s worth a try.

Fire Eagle, from Yahoo!, is a framework for building location-awareness into an application in a way that offers users fine-grained control over the privacy of their location information.

Ideo’s free Human-Centered Design Toolkit is intended to help international staff and volunteers “understand a community’s needs in new ways, find innovative solutions to meet those needs, and deliver solutions with financial sustainability in mind.” It’s designed specifically for social enterprises operating in impoverished communities in Africa, Asia, and Latin America, but I’m sure there’s a lot in it for social enterprises in general. And it’s free, which is nice.

Vikram and Robert also handed round a copy of Business Model Generation (“A handbook for visionaries, game changers and challengers.”), a rather nice coffee-table book about building and maintaining modern business models. It looked well worth reading as far as I could tell. There’s an iPad app too.

Later, Peter Mangin (@peteinakl) facilitated a nicely nuanced discussion on the evolution of social networks. He pointed out that they’re not evil — not even Facebook! — they’re just businesses trying to make money. He singled out two Google initiatives as being forces for good in the space. Obviously, the Circles feature in Google+ aims to clarify the privacy ambiguities that Facebook has struggled with (and it may well eat Facebook and Twitter’s lunches in the process.) Meanwhile, their Data Liberation Front aims to give Google’s users as much control as possible over their data. As people become more concerned about privacy, this will become a Google feature that Facebook will simply have to copy.

This year, for the first time Barcamp hosted a panel discussion. There were three members of parliament, representing the three main parties, and four others representing various organisations and views. The discussion was worthwhile, though with the Barcamp crowd the views expressed were pretty much what you’d expect: More Power to the Internet! Of the politicians, Clare Curran the Labour MP and Gareth Hughes the Green MP both seemed to have a good grip on the issues. National MP Sam Lotu-Liga mostly just parroted the party line. At least he was obviously not pandering to the partisan audience.

It was great to see a lot of discussion on wider social issues relating to technology at the Barcamp, rather than just coding and designing the latest web app. There was a bit of that though: I’ll write up my notes for that sometime soon.

I was already aware of the basic technique: work in uninterrupted 25-minute bursts, followed by a 5-minute break. This 30-minute cycle is called a Pomodoro. If a Pomodoro is interrupted, you have to start the timer again. After four Pomodoros, have a longer break of 15-30 minutes.

Carol and Noemi fleshed out these rules with descriptions of how you should plan your day’s work beforehand, and evaluate it at the end. This is important for efficiency, but also for motivation — it’s easier to stick with the technique if you can see the progress you’re making. The final rule is to remember that “The Next Pomodoro Will Go Better”.

I have downloaded the Pomodoro Technique Book and will try the technique for myself in the coming weeks.

There was good variety in the various sessions I attended. One was on 1Password, a cross-platform password and information management tool. It looked useful, but quite heavyweight — there’s no easy way to use it on a computer unless you can run or install the 1Password program on it. Still, maybe a good solution to the problems of juggling dozens of website usernames and passwords.

I also attended a live recording of The Discourse Weekly Show. Ben & Morgan were pretty amusing, but the rough and ready setup and the general lack of microphone technique in the audience might not translate that well to the recorded result. Listen to the show if you don’t believe me.

Other sessions I attended roughly covered the areas of productivity, society and development. I’ll write up my notes on them in the next few days.

The bug is WordPress bug 13961. This prevents “pretty” search URLs from working properly. For example, http://example.com/search/hello%20world should search the example.com blog for the words “hello” and “world”, but because of the bug it actually searches for “hello%20world” and fails to find anything.

Search Fixer should make everything work as you’d expect. Sometime during 2011 2012 the bug fix should make it into the WordPress core. At that time I will update this page and we will all be able to deactivate Search Fixer and breathe a sigh of relief.

Install

The Search Fixer plugin is in the WordPress plugin repository, so you can install it using the Plugins section in your WordPress console.

Feel free to fork the project on GitHub if you want to tinker with it. And send me a Bitcoin if you find the plugin useful.

Both these issues have now been fixed. I also added a couple of new tweaks:

• The typed-in option now has a value attribute so its value can be submitted by a form. (Suggested by Trent Richardson)
• The automatically added classname is now “simpleComboActive”, which should reduce accidental name collisions. (Suggested by Jonathan Greene)

I have also updated the demo page to use jQuery 1.6.1, just to prove that Simple Combo is moving with the times.

The source code is now on GitHub so, as they say, fork away.

My Twitter widget is written purely in HTML and JavaScript. This means that I can simply put the code into a WordPress Text widget. I don’t have to edit my theme or write a plugin.

Initially I got the code for the widget straight from the Twitter website. There was a section where you could copy a little bit of HTML to paste into your site (or in a Text widget). This was great because the code was structured to be easily modifiable. They’ve changed to a more opaque implementation now, but they still serve the old scripts from their site. I’ve used these, plus an undocumented feature of the Twitter API, to make my own little Twitter widget.

Here’s the code, with interesting bits highlighted:

<div id="twitter_div">
<ul id="twitter_update_list"></ul>
<div><a href="http://www.twitter.com/bnnt"><img alt="Follow bnnt on Twitter" src="http://twitter-badges.s3.amazonaws.com/follow_me-b.png"></a></div>
</div>
<script type="text/javascript" src="http://twitter.com/javascripts/blogger.js"></script>
<script type="text/javascript">
function twitterCallback2_filtered(timeline) {
	// Try to select a non-reply
	var select = 0, i;
	for (i = 0; i &lt; timeline.length; ++i) {
		if (timeline[i].text.charAt(0) != '@') {
			select = i;
			break;
		}
	}
	var status = timeline[select];
	// Edit the status
	status.text = status.text.replace(/ #(?:yam|fb|in)\b/g, '');
	twitterCallback2([status]);
}
</script>
<script type="text/javascript" src="http://api.twitter.com/1/statuses/user_timeline.json?screen_name=bnnt&amp;count=5&amp;include_rts=true&amp;callback=twitterCallback2_filtered"></script>

Here’s a breakdown of the code.

The “Follow me on Twitter” button is taken straight from Twitter’s Follow Buttons page.

<a href="http://www.twitter.com/bnnt">
<img alt="Follow bnnt on Twitter"
src="http://twitter-badges.s3.amazonaws.com/follow_me-b.png">
</a>

Then the little formatting script Twitter have thoughtfully provided. It contains a function called twitterCallback2, which formats an array of tweets and writes them into a div with ID twitter_update_list.

<script type="text/javascript"
src="http://twitter.com/javascripts/blogger.js">
</script>

Twitter no longer seem to link to this script from their site, but it’s still there if you know where to look. I suppose thousands of sites will break if they ever remove this. It’s pretty simple – at some point I will write my own even simpler one and ditch theirs.

At first I simply used the above script for my Twitter widget. But then I wanted to make a couple of changes. So I wrote a little filter which would tweak the returned tweets and then pass the result to the twitterCallback2 function.

function twitterCallback2_filtered(timeline) {

First, I wanted to avoid displaying @replies, since they usually make no sense without context. For example: @DavidPlumpton “They also serve who only stand and look out of the window” (apologies to Milton). (Actually, that doesn’t make much sense even with the context.)

To do this, I set the API call to fetch the last 5 tweets instead of the last one. Then I search through until I find one that isn’t an @reply. If they’re all @replies then I just give up and take the first one.

	// Try to select a non-reply
	var select = 0, i;
	for (i = 0; i < timeline.length; ++i) {
		if (timeline[i].text.charAt(0) != '@') {
			select = i;
			break;
		}
	}
	var status = timeline[select];

I also wanted to filter out “control” hashtags that have nothing to do with the tweet. For example, the hashtag #in in a tweet will cross-post the tweet to my LinkedIn account. I don’t need this to show up in the widget. Likewise for #fb (Facebook) and #yam (Yammer).

	// Edit the status
	status.text = status.text.replace(/ #(?:yam|fb|in)\b/g, '');
	twitterCallback2([status]);
}

The last line of the function calls twitterCallback2 to render the tweet.

The last piece of the puzzle is the Twitter REST API call that actually fetches the tweets. I call user_timeline with the undocumented callback parameter to turn the response into JSONP and call my twitterCallback2_filtered function. (To use the raw JSON result I would have to contend with the same-origin policy, which would complicate things considerably.)

<script type="text/javascript"
src="http://api.twitter.com/1/statuses/user_timeline.json?
screen_name=bnnt&amp;count=5&amp;include_rts=true&
amp;callback=twitterCallback2_filtered"></script>

As I mentioned, the final step is to paste the code into a Text widget in my WordPress Admin screens. If you want to use this too, just change the two occurrences of “bnnt” to your own Twitter handle (unless you want to display my tweets on your blog).

The graph just about says it all. It shows the size of a zipped jQuery download for each release (I omitted a few of the minor releases due to laziness). I have overlaid a linear trendline, which fits pretty well and shows that jQuery’s size has grown about 4.6KB every year. jQuery 1.5 is three times the download size of jQuery 1.0. The uncompressed JavaScript is closer to five times as big, as the table shows.

The numbers in the first row may be slightly speculative, since I had to reconstruct some of those files — I didn’t just have them lying around.

In the old days, the jQuery website used to talk about the size of the library in uncompressed form or in packed form. At some point they changed this and started quoting the minified and gzipped size. This confused me at first — I thought that jQuery had actually gotten smaller — but then I realised it was just a bit of spin.

The jQuery team used to use Packer (or some variant of it) to squash the JavaScript before gzipping, but from version 1.2 they started using Minify too and from 1.3 they switched to Minify exclusively. jQuery 1.5 is minified using what looks like a custom script driven by Node.js. It’s interesting to see that minify performs quite poorly compared to Packer, but the resulting file gzips much better. The end result is still pretty lean — 29KB for the best JavaScript library around — but it’s a long way from the 6KB download I first played with five years ago.