Astroblog

Branches Visualization for Gitorious

Oh yeah, I really like Git. Having a whole repository locally and everywhere is great pleasure. And branching and merging is great fun. The only complicate thing is it's complex revision identifiers. But I don't think there's an easier way to do it right.

For overview, I use Giggle, a nice tiny tool. QGit does its job, too. When you're not in a fixed team of developers a hosting project comes handy. I use GitHub for that and the feature I use most is the Branches Visualization. But there is a problem: GitHub isn't free software and that practically centralizes development with Git.

Enter Gitorious, an open source platform. It is a bit different to GitHub, organized into project/repository instead of user/repository, but written in Ruby on Rails, too. I doubt if it will scale to many users. But that doesn't matter as much as it does with GitHub, because if not everyone sticks to gitorious.org development will become decentralized again. Like with Trac for Subversion.

The feature I miss most is the mentioned branches visualization. I want that, desperately. So I worked on it last weekend.

You can get the code from the 1-image-tells-more-than-megabytes-of-logfiles repository. I hope merging into mainline will be considered soon.

I don't know much about graph visualization and was very happy when I got it to work that quickly. My intention was to make it ordered by date instead of the natural branch/merge order. This introduces some problems under the circumstances of clock skews. I hope that my commit sorting attempt has gone right and will look nice with lots of repositories.

It should also be noted that generation of these graphs doesn't take more time than the other graphs that are already there, like the commits by week or commits by author graph, although it produces a huge SVG tree instead of tiny PNGs.

Currently, the graph is being shown vertically in the sidebar. But I like the idea of having a horizontal timeline, perhaps spanning all repositories of a project. Also, the SVG isn't 100% valid as I introduced title attributes for the circles — a way to show commit information in hint popups. At least Firefox does it. This could be done much better with JavaScript. Feel free to fork.

0 Kommentare

Sightseeing at Night

I wanted to go for a photo tour last week. But as always, one shot and »Battery is too low to take pictures«

So I charged it and took a few pictures already. Then I got on my bicycle yesterday and during six hours I crossed Jardin du Luxembourg, Place du Panthéon, Ile de la Cité with Notre Dame, Paris Plages and Musée du Louvre, where my vehicle had been almost stolen while I was taking photographs five meters away. Cité très dangereuse.

It is very entertaining to see that a lot of other tourists are unable to turn off their Flash when taking photographs of buildings at night.

I then continued along Musée d'Orsay, Pont de la Concorde, Les Invalides and got lost on my way to Tour Eiffel. But finally I found it and watched the mounted flashing lights again.

That should explain where most of these pictures were taken.

By the way, I've found a very nice flatshare until mid of September. Know of anything nice I can move into afterwards? Let me know!

2 Kommentare

Sightseeing...

As requested by others, some pictues:

My search for a flatshare hasn't been successful so far. To be precise, very unsuccessful so far. The first site I knew of (colocation.fr) charges you revealing contact details. This works by text messages. But not by a single one, this one just tells you to send another. Then you receive a code which... doesn't work!

The second site (appartager.com) has:

• Expensive rooms (very common to Paris)
• Females searching female room mates
• Males searching female room mates
• Gay males searching gay room mates

Well, my internship starts in about 2 weeks. So I'm not short in time.

My other experiences consist of travelling to Vitry-sur-Seine by bicycle. I didn't believe it is that far. Unfortunately the weather is very hot. Will not do that again.

If you ever intend to travel by Metro, forget your bike. It is allowed, but simply not doable. You've got to lift it over the ticket-eating entrances. They really do eat tickets. They re-disappear after a couple of seconds, which you may need for lifting your bicycle up and down. The train staff wasn't very helpful either. The only one who spoke English was a little boy who was engaged to talk to passengers due to a rerouting.

But at all, people seem to be much more relaxed and prices are, expectedly, much higher than in Eastern Germany.

2 Kommentare

After a trip to prague...

After a bicycle trip to Prague...

I finally got my Jabbim T-Shirt!

Thanks to spike411 for meeting me in the beautiful but tourist-crowded town centre.

3 Kommentare

Tor Exit Node port stats

While being at Camp 2007 I feel somewhat safe. Time to do good stuff, and stuff I wanted to do for a long time. Time to run a Tor exit node.

I often heard that it's a golden rule for Tor users to not abuse the network by using file-sharing on it. Tor is slow and that's what slows its spread among users.

That interested me and so I wrote a small script to grep out tor connections out of netstat and filter ports that appear only once. Sample output here:

2710  2
87    2
47251 2
20335 2
49152 3
6969  3
80    4
4662  14
6881  30
4642  35
Total: 331

Port 80 is web, I always assumed web is used most. Port 6881 is Bittorrent. Sad, but true. Ports 4662 & 4642 belong to some other file-sharing app, too. High random ports can also be a hint for P2P. Who gives a shit about well-known ports when your programs connect to each other automatically?

The number of connections may not be enough to call these statistics empirically satisfying, but now I've got a clue what main Tor traffic looks like.

0 Kommentare

Harvester: MRSS rewritten

Well, I always want to write more often here, but I'm lazy and then I think: I would be more productive if I generate some more code now.

This post is in english because there are a few similar projects out there. But I haven't looked at them at any depth because MRSS is the Harvester's core component and must always be tweakable to fit my needs.

MRSS was written when I knew just the basics of the three common feed formats RSS 0.9/2.0, RSS 1.0 (RDF) and ATOM 0.3/1.0. Almost everytime I added another feed from a different Blog Software I've had to add further hacks to MRSS. It always choked on differently styled feeds with their various forms of plain text and markup embedding, escaping and inclusion. I also avoided most ATOM feeds because it was... broken.

A few days ago I turned Stepardo's blog to Harvester food and was once reminded how crappy MRSS was. Time to refactor. Time to rewrite.

I now wish to point the reader to the source browser for a better understanding of the following discussion. You can now see a pattern I tend to use very often in my small Ruby projects. I'd like to call it Intrusive Decorators.

A way of doing things with a class, here REXML::Element, could be deriving from it and adding functions. But in this case you'll also have to convert the element's children to that class. Something we do in XMPP4R everywhere, but it's hairy, especially in combination with a monster like REXML.

When your functionality is just a short-cut like in this example one would normally create a Class Method (aka Static Function in other languages) and implement it there. But that's way too much to write when you're just using it.

In Ruby it's possible to modify classes after their end. You just define it again, but this time without a class it derives from. This technique can not only be used to create such short-cuts like MRSS' REXML::Element#s but also to add completely new features to already existing applications. See my Ruby-SOCKSify mini-library (GIT, Browse) for example.

Please pay attention to the handsome function style that can be seen in MRSS::RSS::Item#description. Make use of nil, false and NULL everywhere and in any language!

So much talk but nothing that makes a better MRSS.

The key feature is object-oriented abstraction to distinguish between feed formats. This is the only and right way to do it, and now I really wonder why I didn't use it back when I wrote the first version of MRSS. Maybe because I concentrated on just RSS while ATOM support was given birth by Neingeist.

Hell, I'm really proud of that new code. Code which violates some basic OOP rules, I guess. But that makes it even more fun.

Feel free to show me (well-formed) feeds that don't display nicely in the Harvester and I'll fix that. I'm also thinking about some test-cases. Test data (thanks to fukami for showing me this once) exist. But I like to have the same content everywhere for minimal test code.

Anyway, it's working fine for now. If I'll touch MRSS again it will be kicking REXML, the XML library I know best and which has an easy API. But it is also bloated, sometimes buggy and handles namespaces & element name prefixes the way you don't want to handle them when processing documents with multiple namespaces.

0 Kommentare