Stake Ventures

The Debian world seems to be on a rant on why the RubyGem’s are bad and why we should all be using aptget instead.

For rants see: Wouter – Rails? Stay the f* away from my system, Gunnar Wolf – Ruby has a distribution problem as well as the official Debian take on RubyGems.

However, the Debian/Ruby Extras team fear that Rubygems will make it much more difficult to package and distribute Ruby software in Debian (similar concerns have been raised by other individuals and GNU/Linux distributions)

Updated: Just discovered that Gunnar actually wrote this really good post It’s just a different mindset. Not necessarily a sane one, though, which I think is a way better explanation of his concerns. I still don’t see why Gems is “the most obnoxious of them all”. Gem’s can and should improve. But at its current state I actually do like it.

I always wondered why their rubygem package was intentionally broken. But never took the time to worry too much about it, when it’s easy to uninstall it and install it from source.

RubyGems like CPAN are about being OS agnostic when writing and deploying our apps. At the application level, I really do not care nor want to care about what server os I’m running.

I develop on Mac and deploy to Ubuntu, Gentoo, Redhat and OpenBSD. Using aptget, rpm, portage and pkgadd is fine for initial server setup and on going maintenance, but for day to day deployment of applications nothing but a PITA.

Different worlds, different points of view

The fact is that we are talking about 2 completely different worlds here. The whole thing is something very much akin to the old Men are are from Mars, Women are from Venus meme from a few years back.

For me my focus is the application. Most Ruby developers write applications for a living. For sysadmins their focus is on keeping servers running. Most Debian maintainers probably come from that world. Regardless if my assumption is right or wrong on that, their focus is definitely on Debian and not on Ruby.

So you now have the situation where an American is laughing at the stupid Limies calling a cigarette a “fag” and an Brit laughing at the stupid yanks calling a bum a fanny.

Get over it. We come from different worlds and have to live together. If your job is maintaining a bunch of sysadmin type services such as mail, dns etc you know what you need to do your job. Application developers also know what we need to do our job. It might even be that these things are different.

However if your job as a sysadmin is to support several web applications server, then I’m afraid when it comes to the applications you are no longer king. You need to support the developers and not hinder them.

But as Gunnar says:

By using Ruby Gems, you dramatically increase entropy and harm your systems’ security.

This is what we politely call FUD in the tech industry.

On the server it is the sysadmin’s job to understand the benefits of postfix vs. sendmail. tinydns vs bind etc. It’s the DBA’s job to decide on when MySQL 5.1 feels stable enough to use in production.

It is our job as application developers to understand the finer points between RedCloth 3 and 4.1. RubyGems allows us to test our applications with specific dependencies and make sure that this is exactly how they are deployed.

This enables us to have the confidence to deploy without having to do full regression testing when moving from a Gentoo to a Ubuntu server. Or to deploy minor updates from our Mac’s onto a server.

After having spent years of managing servers manually, the simplicity and beauty of deploying with capistrano is amazing. Besides initial server setup (which I can soon wave goodbye to thanks to PoolParty) I want to focus on the application.

RubyGem’s give me the freedom to develop on a Mac/PC and deploy onto just about anything. I deploy onto Ubuntu, OpenBSD, Redhat and Gentoo.

aptget is fantastic at what it does, installing base software on my server. Maintaining my application dependencies is just not its job. The Debian community is right to be conservative. However the ruby world works at tremendous speed, change is part of our core DNA.

I don’t want to necessarily be installing a new MySQL or GCC version on a daily basis, but I am willing to use the often daily updates of ruby gems. As I have the tests that prove they work and fantastic transparency about what was changed via GitHub

The Debian maintainers should stop breaking software out of some misguided principal. For gods sake Debian is an Open Source OS not North Korea. You broke your RubyGem package, now fix it.

There must be some way of creating virtual packages that just install the gem. This method could be reusable for Perl’s CPAN packages and any other application level packaging system.

Update: Violent platform wars going on over this post on Hacker News

Create, negotiate and accept legally binding contracts for free with our Agree2 service.

RSpactor is one of the greatest tools out there for developing Rails apps on the Mac (Yes it’s Mac only) using RSpec. It works just like autotest, just with out any configuration and without using more resources than absolutely necessary.

Andreas is working on a next generation Cocoa based tool, which looks great. I know many of us are using the original command line version of it still, which unfortunately broke, when the RSpec team introduced some API changes. No worries though, I’ve forked the older command line version on Git which you can also install as a gem:

sudo gem install pelle-rspactor --source http://gems.github.com

Create a simple NDA with zero legalese in no time at all and for free at our service Agree2.

I suppose I should write a detailed post at some point about this. But here are a couple of notes from working intermittently on Talk.org in the last couple of weeks.

First of all Python is definitely not Ruby. It is very different in many ways. So just accept that and get on with it. Ruby still puts a much larger smile on my face than Python does, but that might be inexperience.

Secondly Django is not at all like rails, even though most python guys seem to claim it is. Pylons seemed much more rails like. However I decided to stick with Django as it’s always good to learn something new.

The best resource I found for getting started was this example project Wuzhere that was demonstrated at Google IO. It is really a great guide to get your head around structuring your project. In particularly coming from Rails, I learnt way more just reading through this code than reading various tutorials on the web. A key piece of code to simplify your life as a rails guy coming over to Django is their view.py class, which acts kind of like a rails render method.

You should use the Django Google App Engine Helper if you are doing Django which is described in this little tutorial. However the approach to laying out your application taken by the Wuzhere developers seemed more logical to me than the approach suggested by the Google App Engine helpers.

Generally speaking I like the AppEngine design. The models are great even if they require you to think a bit differently about the design of your data model. I don’t see a clever way of doing callbacks on the models like with activerecord, but I suspect that something similar would be possible with clever use of Decorators

I would like to say though that while I am still a novice at Django/Python it does seem to me that there are design decisions in both that I’m not quite happy about. Once I’ve worked more with it I’ll see if I still feel that way and can formulate it a bit better.

Share your confidential code safely with a Source Code Confidentiality Agreement on our free web service Agree2

To make Talk.org a playground for more than just me, I’ve decided to open source it. You can find it on GitHub

I have released it as GPL3 as I think it makes sense for an app like Talk.org that we all get to learn from our experiences.

I will do my best to bring as many new features people create into the live application as possible. However be aware that at some point I may want to put some unobtrusive ads or something on it to make to pay future AppEngine bills. You have been warned. But then again you could do so yourself if you so please.

Anyway, it is a fairly simple app at the moment and is not seing large amount of use, however a fair amount of people came to try it out during the Stevenote.

These are the performance graphs from the Google AppEngine Dashboard:

The requests seem to take about 500ms each, which should improve once memcache is working properly again:

So far we have 58 users who have posted in total 166 posts. Not bad really for a tiny app, originally written last Friday over breakfast.

So far the todo list is:

• Allow users to pick their own nickname when signing up (right now it relies on what Google gives me, which is wrong)
• Atom/RSS/JSON support
• OAuth
• Followers
• Tracking

Concensus seems to be that the best way to do IM/SMS support is for a 3rd party server todo it via OAuth/HTTP as AppEngine doesn’t yet support XMPP. This is obvious as a great separate project for some Erlang geek out there.

Create a Software Development Agreement with our free web service Agree2

Well it’s not exactly a twitter clone as you can’t follow or track anyone. There is no IM or SMS support either. However you are able to do some of what you would do on Twitter. So it might come in helpful during Steve Job’s keynote if Twitter goes down. Go to Talk.org to try it out.

This is my first little play project using Google Appengine

Right now it just uses Google Accounts, so for most people you don’t even need to sign up.

So what’s next for Talk.org

My original plan for this was not for it to go the Twitter clone way. There are a few features that I think might be more fun to do than trying to be an exact clone of twitter.

Following and Tracking should not be too overly complicated features to add. But I may endup being wrong about that. From my understanding Twitter’s real scalability problems are from these two features and not the messaging plat form itself.

I’m thinking that unless they’re well designed these may endup presenting problems even on AppEngine. Of course they would only be a problem if you got people with extremely large amount of followers.

I can’t see implementing IM and SMS in the current architecture of AppEngine. However it might be possible to create a separate messaging server using Amazon EC2.

There is also a really annoying bug in Memcache on AppEngine that pretty much excludes the use of the Memcache API until it’s fixed. They are working on it so lets see.

I don’t want to use too much time on this, maybe just an hour or two a week in the future, but I think I may post the code to GitHub as soon as I get it cleaned up a bit.

Create, negotiate and accept legally binding contracts for free with our Agree2 service.