Improvements to rabbitvcs

RabbitVCS is handy for those making the jump from TortoiseSVN in windows. I usually make do with svn log / git log and the command line, but as part of my new work there's often horrible user names (think completely numeric) and commit messages that are just a pain to trawl through.

So, I've turned to RabbitVCS to fill in a gap. I managed to heckle the maintainers, and a release was put out not long after. Neat, I thought - but I saw their issue tracker, and saw patches languishing without love.

I started out with triage, and highlighting patches that could be implemented. Even then, it still wasn't working for me. I added a few bug fix patches; posted to the mailing lists, etc - a few got accepted, but overwhelmingly there was silence.

Unfortunately when I get interested in hacking away at something, I'll put in a few hours - uploading static .diff files and abandoning them in my local working copy was getting a bit annoying, and I suspect the folks on the devel lists were unprepared for a patch flood.

So... I've mirrored it, and then forked it onto my github account. I've put it back to the developers that I'll keep mirroring, and help them migrate if they so choose.


I give you 6 distinct bug or feature requests.

• Filter log dialogs by typing in text
  
• Copy log messages to clipboard using a context menu or ctrl + c
• Refresh commit dialogs
  
• Hit escape / ctrl + w / ctrl + q to close dialogs (well, most of them, there's a lot and it's boring to implement).

and there are less bugs overall.

I learnt a fair amount about python's GTK libraries, which turned out to be all pretty straight forward if a little tedious to work with at times - text buffer wants to force me to use an iterator, rrrr.

That aside, to get your hands on the latest:

$ git clone git://github.com/CloCkWeRX/rabbitvcs.git
$ sudo python setup.py install

And the first time you do this, you'll need to fix permissions on the config

$ sudo chown -R you:you ~/.config/rabbitvcs/

To test, it's pretty simple - go find a Git or SVN repository, and type:

$ rabbitvcs

If you spot errors, check the latest bugs and report. Hopefully either folks will swap over to the new github home without much angst (I'll transfer it to a github org of theirs if needed), or the patches will get applied against SVN.

pySerial and Roomba

So when I'm not looking for the ghost in the machine, I seem to be spending a fair amount of my time pining for a Roomba.

It isn't even because I have a low-mess problem that obviously needs robotification (I mean, who doesn't have one of those), but because the damned thing comes with an open interface.

With a little bit of expense, I could remote control my Roomba with nothing more than a laptop, really long serial cable, and a whole bunch of Python.

From there, it's only a hop, skip and a jump to a day of internet fame with a wiimote roomba, and then it's on to rule the world program away my household hygiene issues.

The biggest obstacles I seem to have is only the worst website in the world and simply not having much of a decent idea for exactly what I would use my roomba for...

So lets hear it: 3 best applications for a robot slave you can come up with.

Scary Conversations

I just read Why Learning Haskell/Python makes you a worse programmer, and have to agree with most of the article. It focuses on the idea that once you learn something better than what you have, it's hard to go back to tromping around in Java/C#.

I was surprised when I read the comments at how some people suggested embedding python into your work codebase - like this comment:

Be a human virus.

1) If what you are working on is a rather large application why not embed python in the applicaion? That's the bottom up approach. That way those peksy solutions wanting to get out can be a script in the tool.

2) It it's more of a utility program then top down is probably better. Use Python to provide an umbrella wrapper. Acting as glue, the underlying C# code can be used for those areas where it's needed most.

Caveat. You of course understand the dangers? Your prototype has to be at least 60% bullet proof and cause no harm to the underlying code base. Second you most likely need to be prepared to do a skip level introduction of your idea to management. My observation is that the line manager was most likely the one who selected the language and they picked it based on their comfort level. so you are going over their head in a sense to hopefully a more neutral third party. But there are risks.

But the reward, ah the reward, you get to use your skills. And is it worth it? Yep. A VP once told me -- "You spend 1/3 of your life working. Why waste that time in sloth and despair?"

Can you imagine submitting patches to the Subversion project, for instance, introducing a component written entirely in LISP? You'd get thrown out on your fucking ear.

Lone Cowboy Syndrome is a scary beast. On the other hand, at least we aren't still stuck with the design patterns of 1972.