Git-SVN mirror product: SubGit

Just a quick mention for you people who can't be bothered with my somewhat intricate Git-SVN mirror setup, there now is a now is a solution packed into a product: SubGit.

I tried it out on a little local SVN repo recently, and it worked just fine. It delivered pretty much perfect two-way syncing/bi-directional mirror (which I've earlier deemed to be very impractical with git-svn).

The bad parts are:

• It's new (use at your own risk, in other words: DO NOT install it in your main-line subversion repo used by a 100 devs).
• It's closed source, so you're at the mercy of the SubGit devs for fixing any feature that you need in your special repository. 
• It requires instrumentation on the Subversion repository installation. If the repository is beyond your control (hosted externally, or by some separate department), you're stuck with my old setup.

The good parts:

• Super-sweet functionality! I mean, bi-directional Git/SVN is highly sought after.
• Seems to have a pretty high *just-works* factor, easy setup.
• It's still free (as long as they're in the EAP phase)

Google Guava's Predicates

So the other day I was working away on some rather tricky rules for validating an incoming identifier code. Like

999392304II+TJAJEIAJTI901119

or

EPFOOMNNVLLALOWEIITOE

Now, the system where this code is going is rather picky about what these codes should look like. (For the sake of this blog-post, I'll invent some business rules here on the fly, in reality they are a bit different, but the nature of them are the same):

• A code cannot be null, or an empty string (of course)
• If there are only letters (A-Z) in the code, it must be longer than 10 characters, but fewer than 20
• On the other hand, if there are letters mixed with numbers, it must be exactly 10 or 15 characters
• Numbers only are not allowed
• No other symbols are allowed, but + signs are allowed, if the code starts with 999. In this case, the max length is 10.

Instead of just going straight for the if-else'ing my way through these rules, I implemented it using Predicates from Google Guava. I was pretty happy with the result, and wanted to put it up against what the classic solution would look like.

I've created a little project on Github that demonstrates the above rules. There are two branches:

ifelse -  The old imperative way, using if's and else's

predicate - The new functional way, using predicates

Both branches pass the same test suite. I won't swear on the correctness of the implementation, as it's currently 01:59 in the night, and the tests aren't really extensive.

Performance is not a big thing in this validation function. We're dealing with codes that come in every few seconds, so we've got plenty of milliseconds to spend on making the code look as nice as possible. Also, my regexp sucks, I know.

Here's a quick look of what I ended up with using if's and else's:

(Source on Github)

And here's using predicates:
(Source on Github)

In order to really appreciate the differences, it's best to have a look at the whole classes on Github. It's a Maven project, so you can import it into IDEA or Eclipse, and use Git to jump between the two branches for comparison.

I'm not saying that the predicates way is easier to read or write, but there is something functional and declarative about it that feels kind of.. powerful. A nice thing about those predicates is that they can easily be combined with eachother, and re-used in other places, like in filtering collections using other Guava utils.

Note that the full predicate style solution is much larger, but much to blame are those base-predicates I'm defining for saying matching, shorterThan, longerThan and exactLength.

If we were dealing with a language that properly supported functions (a predicate is a function that evalutes to true/false), it would probably look a lot nicer. Perhaps with Java 8, I can slim down the code quite a bit..

I just read that the Guava developers are going to include new fluent interfaces for combining predicates in a more elegant way, than the prefix style I've used above. Maybe something like

 new FluentPredicate().not(NULL_OR_EMPTY).and(ONLY_LETTERS).build(). 

Read more here about FluentPredicates, etc. They can't be too far away, release-wise.

For other Guava resources, check out my collection here.

Some thoughts on Git vs complexity

I originally wrote this in the Git For Human Beings mailing list. The thoughts are stolen from Rich Hickey's Simple Made Easy talk. (Matthew McCullough commented the same parallel the same day, but I think his timestamp was a few hours afterwards). I wanted to tweet about it, but it ended up being a whole post, as I'm trying to gather my thoughts on it for my next Git talk.

There's simple stuff, and there's easy stuff.

Simple means the opposite of complex. Easy, on the other hand, means it's very close to the stuff you already know. Git is "simple" but hard. Subversion is "easy", but eventually complex.

Git is *a lot* of features in one tool (think of the 100+ git plumbing commands). Each feature is simple, but learning to use them together is good bit of work. As soon as you've understood the model and you get that Eureka-moment, the tool never fails you, and you find it more and more fun to use the more you learn. (This is why there are so many git enthusiasts, I reckon.)

Subversion has a very limited set of features.It also turns awfully complex when you want to do stuff like merging. Actually the more I learned about Subversion, and the more I used it, the more frustrating I found it.

Why is Subversion complex?

- Because the stuff on the server is something different from what you have locally. Your local checkout is just a thin skin. All the interaction goes over the network with a really thin and crappy API. It’s like reading a book using binoculars. The same information is there, but it’s horrible to get at it.

- Everybody is tangled together using the same repository. People start making mistakes like committing without updating first. Everyone mis-use trunk as their own sandbox. This is complexity too (everything in one bucket).

- It mixes together committing, and pushing the changes to central. A commit should do one thing, and one thing well, and the reasoning should be in the commit message. Some are refactorings, others are feature-changes.

- Because branches are completely disconnected - there’s nothing that ties them together, except being a lot like each other. That’s how merging in Subversion works: “I assume that these two directories will be very similar”, and if they aren’t, BOOM.

Git, on the other hand, is simple: It all boils down to being three kinds of objects in a graph (commits, blobs, trees), and the rest of it are algorithms that work this data-structure.

Presenting Git on Windows at the next Bonn-to-Code.net meeting

Update 18.11.2011: Due to Gad J. Meir visiting Bonn-to-Code.net all the way from Israel, we've postponed our talks that were planned for the 28th of November. Most likely I'll be doing the talk near the end of January next year instead.

It's been a while since I ran Visual Studio on my laptop. In my early university-college days, around ten years ago, .NET was just coming out of the oven. We learned algorithms and data-structures doing Java, but when it came down to actual application development, desktop- and web, connecting GUI's with databases, .NET was the thing.

I liked it. It was bit of an eye-opener for me, that I could actually use programming for building useful stuff, and not just fantasize about being a game developer.

Later on, I fell back into the Java/J2EE world, and rode there for a while. While working for Objectware's Java department, it was always interesting to see what the .NET department was up to, and while they were part of them evil scheme of Microsoft's technology lock-in, they were mighty productive in certain domains.

So, the reason I'm installing Visual Studio again is this: The Bonn-to-Code.Net meeting on the 29th of November. I'll be showing off how to get Git working in the hands of a .NET developer.

My employer, Viaboxx Systems was kind enough to sponsor me with three German Git books I can give away at the event. Hint: Asking questions might result in a free book!

Those who follow this blog know I'm actually a Mac/Linux user, so it's actually been quite a lot of research for me into finding the right Git tools to use on Windows and how to use them. Here are the things I hope to show off (with actual live demos!):

• msysgit (of course) and some Git basics
• PowerShell integration with posh-git 
• Visual Studio integration with GitExtensions
• TortoiseGit (quick mention)
• GitHub interaction
• Gitblit (Windows-friendly git repository serving)
• git-svn (for those who want to convert)

If you're planning on attending the talk, I'd love to hear any background or expectations you have. If you're undecided on attending, be aware that I just finished Scott Berkun's Confessions of a Public Speaker, so I know all the tricks of the trade now! Additionally, I've spoken a bunch of times before, some of which are recorded if you're curious what my talks are like. I promise an action-packed and dynamic talk with zero slides.

Be a Good Audience

So I'm sitting here reading Scott Berkun's Confessions of a Public Speaker, pretty good book by the way (from the Viaboxx library). I'm just through the chapter about "Working a hard room".

And then it hits me: I actually spend an effort being a good audience at talks. I go to the odd conference and user-group meeting, and whoever is speaking, and even if the talk is not hitting home with me, I always try to...

• Sit down in the middle, close to the speakers where they can see my face
• Focus my full attention on them - no smartphone/laptop
• React to what they're saying with my face, friendly smile when they say something smart, raise my eyebrowsand smile  when they say something surprising
• Laugh at their jokes (I mean, not fake laugh, but be open to laugh)
• Ask questions when I wonder about something
• Hold my criticism till after the talk, if any, and give it in person
• Think about and note any questions I'd like to ask in the Q&A

A good speaker/talk summons this behavior in the audience naturally, but I also give an effort in the not-so-good talks.

I do this because when I'm up there speaking myself, I would like to get the same behavior. A more involved audience makes my talk better, and gives more value back to them in the end.

PS: My next talk is presenting "Git for Windows users" at the Bonn .Net user group, Bonn-to-code.net, 29th of November.