Just a quick update: XMPP4R-Observable is now on GemCutter. That’s due to GitHub disabling gem building, and although everybody can get the source from GitHub as usual, those who want to quickly install it using Rubygems can do:
bash$ gem install xmpp4r-observable -s http://gemcutter.org
Há apenas alguns dias fiz uma apresentação no FISL10 sobre a utilização de XMPP PubSub com Ruby e sobre um fork de uma biblioteca popular à qual acrescentei os rudimentos do PubSub. Naquela mesma apresentação listei uma série de problemas que aquela abordagem tem e falei sobre um roadmap para o futuro…
Acontece que acabei me convencendo de que não posso utilizar o PubSub no lado XMPP da biblioteca e uma forma de periodical pooling no lado Ruby. Resolvi, então, substituir a biblioteca que havia forkado por uma versão Observable, preservando as coisas boas do XMPP4R-Simple. O resultado chamei de XMPP4R-Observable, e acabo de publicar no GitHub.
Uma boa parte do código está coberta por testes (e “roubei” alguns dos testes da própria XMPP4R-Simple)… pretendo cobrir o restante ao longo do tempo (contribuições são bem-vindas). Por hora, chamei esse primeiro release de versão 0.5.1 e acrescentei um .gemspec para gerar um .gem automaticamente… No entanto, o GitHub ainda não publicou o .gem… Quando publicar, para instalá-lo deve ser tão simples quanto:
bash# gem sources -a http://gems.github.com
bash# gem install spectra-xmpp4r-observable
Não deixem de reportar qualquer erro. Happy hacking.
Update 2009-09-13 10:29:00: Acabo de confirmar que o .gem foi publicado pelo GitHub.
Update 2009-10-10 20:21:00: O .gem do XMPP4R-Observable vai ser mantido no GemCutter, a partir de hoje.
I was browsing GitHub, getting to know the system and feeling pretty amazed by it (seriously… I felt I discovered Orkut for developers)… when some thought just stroke me: how do they save space?
Yes, I know git is pretty efficient when it comes to saving space. Yes, I also know that space are becoming cheaper with time, but still, they claim to have +50k developers hooked up their servers… if they’re not doing something about space, things will go inefficient quite quickly. Rails alone seems to have 464 forks! If all of them represent one bare clone of the ‘canonical’ repository on GitHub’s side, that is a lot of space wasted in duplicated things…
Git has one amazing feature: hashing the objects it keeps track of. It surely doesn’t seem too complicated to design a schema that avoids having two copies of objects with the same hash. So all those forks of Rails, on GitHub’s side, would be just hardlinks to the ‘canonical’ repository…
Surely people working in GitHub are smart enough to have though about it on their own… Who knows? Maybe that’s exactly what they’re doing already! If so, can I ask them to share their schema, since it can become very useful to the rest of us? If not, can we beat them ;-D?
Everybody seems to be using git these days… I am not very found of “hypes”, as I told you before, but there’s been some time I’ve been evaluating git. I was happy with svk for quite a long time… Lately, though, I’ve been developing and extending a lot of ruby libraries, and all of them seem to be hosted at GitHub and using git… So, why not give it a serious try?
I chose a simple task on my TODO-list: to extend xmpp4r-simple to support XMPP PubSub, so I could use it in an internal project at my company. So I “cloned” its git repo and started developing. Not a really hard task, since all I had to do was use the underlying library (xmpp4r – not surprisingly also in GitHub) and mimic what Blaine’s done for the callbacks and it was ready (and working… although I still need to put more time on the test suite).
I am still exploring… It will take some time to migrate my stuff (and maybe a lot will remain in my company’s Subversion), but that’s what git-svn is for, isn’t it? Right now I am looking for ways to work with git-buildpackage and Debian git tools… Do you have some advice on that?