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.
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.
Kluge Menschen anonymisieren möglichst viele
Internetverbindungen, die nicht auf Performance angewiesen sind,
und welche Requests herumschicken, anhand welcher man ein Profil
erstellen kann. Feedreader sind zum Beispiel ganz sinnvoll.
nulli fragte mich letzten August, ob es nicht möglich
sei, jegliche TCP-Verbindungen eines Ruby-Programms durch
einen Tor-Proxy umzuleiten. Ich schrieb ein Drop-in,
welches den alten Konstruktor von TCPSocket umbenennt und
einen neuen, welcher nach dem Verbindungsaufbau zu einem
beliebigen festen Server eine SOCKS5-Verbindung zum gewünschten
Ziel aufbaut.
Ich habe das Repository zwar schon einmal auf ruby-talk@
geschickt, aber es kamen keine Reaktionen. Deshalb
veröffentliche ich einfach mal eine Version 1.0. Es muss doch
paranoide anonymisierende Ruby-Hacker geben da draußen.
Da Releases zubereiten ziemlich Zeit frißt, habe ich mich nur um
eine
kleine Dokumentation
und ein Gem gekümmert. Zum
SOCKSifizieren eines beliebiges Ruby-Skripts genügen folgende
Zeilen:
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
fewsimilarprojectsoutthere.
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.
When I read Josef's Hack status for a second time, I suddenly felt in mood for reimplementation.
He did a 30 line self-contained shell script, I created a 157 line object-oriented Ruby script:
If you really want to take me serious, check it out with:
Damit das Web endlich mal Erfolg hat, muss dieses nervige Flash-Format verschwinden.
Es gibt ja nicht wenige Menschen, denen Implementationen verwehrt sind, oder die aus rein ideologischen Gründen das entsprechende Plugin nicht installieren.
Ich selbst habe mich nach dem Hype um Videoportale hingegeben und das Flash-Plugin installiert.
Eine Alternative ist da SVG, was ein offener XML-Standard ist und wofür schon mehrere Open Source-Implementationen existieren,
dank Firefox auch halbwegs verbreitet und fortgeschritten.
Folgendes Beispiel ist inline direkt im XHTML (darf kein HTML sein), sogar CSS & JavaScript stecken im SVG.
View Page Source!
Es sollte mindestens auf neueren Mozillas laufen, Browser installieren ist nicht Ziel dieses Experiments.
Mit der Performance bin ich überhaupt noch nicht zufrieden.
In dieser Größe saugt es schon recht viel Rechenzeit, in doppelter Größe ruckelt es extrem.
Dabei ändern sich die Balken nur alle 40 ms, was 25 Schritte pro Sekunde ausmachen sollte.
Wer jetzt auch Lust auf SVG bekommen hat: ich bin an Erfahrungsaustausch interessiert.
