So it happened again today. A totally different aim bot started bothering me to look at it’s webcam or something or other. My second round with an aim bot took a couple more tries, but in the end, it too ceased conversing with me. Was it something I said? Oh, yes, it was, it was ‘) drop table logs; —. Perhaps I need to be a better conversationalist, I keep driving these web cam girls away.

This has me wondering. Maybe I can create an aim bot honeypot that is actually it’s own bot, chatting in sql injection. It’s a thought….

Oops, I did it again

After one started pestering me today, I gave a shot at the little bobby tables technique (sql injection). It started to reply immediately and then just kind of sat there. I’ve even tried a few more normal responses, and it just doesn’t seem like it wants to talk to me anymore. How sad.

Cat got your tongue?

This is all part of their drive to create a “Do not track me” list. Well, apparently Consumer Watchdog only wants other people to not track you, because the web site hosting their anti-google campaign is using what? They are using Google Analytics to track visitors:

Do Not Track Me uses Google Analytics

This whole argument is hyperbole. Fundamentally networks track usage, logs are created. The simple fact is, the vast majority of websites track to do one thing, and one thing only: to be able to tell which of their marketing partners are delivering value, and which ones are not. No company cares if you are having affairs on the sly or any of the other garbage that this video suggests. Consumer Watchdog, if you want to be taken seriously, grow up!

So here goes, my unvarnished opinion of the problems facing the rails community:

1. The community

The community is the single most ego centric community I have ever seen in a decade and a half hanging around the greater free/open source movement. Everyone remembers Zed Shaw ironically (but deservedly) ripping into the rails community for it’s overblown personalities. But numerous other examples abound. How can I possibly view the authors of a monitoring framework with the name God (and a tagline “like monit only awesome”) as anything other then a people with enormously expanded and wholly unjustified egos? How can I possibly take HAML seriously when the main dev‘s bio starts off with “Hampton Catlin is one of the best people in the world. Flat out.” Seriously? One has to know that this guy is going to give any production problem you have very serious attention</wry>

2. Totally decentralized, egocentric documentation

No other way to say it, the rails community is obsessed with personal branding, not with being a helpful community. Is there any centralized site that has a good set of user commentable docs covering most extensions? Php has that, and it’s part of why it’s still a defensible choice for writing web apps despite its numerous other flaws. The end result is that when you google for just about anything having to do with rails code, the first five items are all personal blogs

With rails, the community doesn’t build any sort of centralized corpus of knowledge, what they all do is write a blog entry about such and such technique, or how they fixed a problem. The problem here is that nearly all of this knowledge is outdated, and impossible to tie to any one version of the application stack. So instead we get tons of blogs with disjointed suggestions that take you in the wrong direction whenever you google about an issue (sure, this solution worked in 2.1, but not in 2.0 or 2.3). Too bad it’s in a blog without with the applicable version number instead of in a comment at the end of the documentation like mysql or php.

3. Excessive reliance on ORM

I’m sure you have all heard of the N+1 problem. Sure, lots of devs will tell you that it’s simple to avoid, but based on all the teams I’ve evern worked on, all it takes is one lazy programmer and all of a sudden your templates are taking 7000+ queries to render. It’s no wonder the rails community seems to think sql is slow. Hint: the answer isn’t memcached, the reason your rails site is slow is because the sql it’s running is craptastic. 99.999% of rails sites could be vastly improved by just hiring one or two people who actually understand relational databases. The part that I really just don’t get is that sql is much easier then coding, and RDBMS is not rocket science, but it’s treated like this big hideous bear that your developers have to hide from.

4. Pure ruby is the answer to everything

The community is utterly obsessed with pure ruby, and looks down on impure extensions that are wrappers around solid C libraries. This results in a general race to the bottom for speed, stability and maturity. The unix world is packed with easy to integrate, solid libraries. Libxml-ruby is nearly two orders of magnitude faster then rexml, and has top notch compliance with the xml spec. Yet somehow rexml is the standard and libxml-ruby is the red headed step child.

5. Fragile ecosystem

Now, I’ll be the first to admit that the rails maintainers shout far and wide that rails isn’t enterprise ready, and it really truly is not. Over and over I have gotten bitten by the myriad of flaws in the rails ecosystem. Any one specific issue I’ve dealt with could have been fixed in version such and such of some gem (or it’s even worse with rails plugins.) This complaint is not about specific flaws so much as the whole ecosystem feels like it’s standing on a very fragile foundation. Some examples of the ways we have gotten bitten over the life of the multiple rails projects I have been involved with are:

• rexml violating the xml spec by totally ignoring the encoding of documents parsed by it.
• gem silently failing (not returning the proper unix return code) and thus allowing some of our instance launches to blow up without a reasonable way to catch it. (And as a note, when you have to automatically install large amounts of gems from rubyforge, it chokes a *lot*).
• Innumerable gems regularly break api compatibility even in minor releases (I’m looking at you Rack). When you add calls, you can’t just remove them between 0.9.2 and 0.9.3, it’s damn unprofessional.
• i18n has been a real problem right from the beginning.
• Passenger’s ApplicationPool choking and never coming back, forcing you to restart apache once a month
• Constant movement from one webserver to another. It’s damn frustrating to have to switch web servers every 3 months as the community hops from one the the next, as everything else gets filed in the community folder for utter crap. At that point it becomes damn hard to find support for problems. First it’s lighttpd, with mongrel, then thin, then nginx with thin and on and on. Somehow people need to support this mess. Apache works, is well supported, can be very lean, and basically every systems person on the planet knows how to work with it. Hint: as a programmer, it’s not all about you. Your applications need to be supportable; running away from standards for the sake of being different is dumb.

And just to reiterate, some of these could be actually fixed, or hell, they may have always had a *way* to work right, but the default was broken, and caused project problems that never should have existed if the rails community could ever get around to implementing a spec as it is written.

6. Generates bad, bad habits in devs
• Creates a view of the world that implicit is good. This goes all the way to the language itself and the silly fact that explicit returns use more processor power then implicit returns.
• Creates a view of the world that clever is good. Anyone who has maintained software for a few years should be able to tell you, clever is bad, very bad.
• My personal least favorite, the technological abortion known as Single Table Inheritance. Admittedly, even the community is now arguing for people to not use this. STI is a wretched way to bind a database with an object model, it encourages sparse tables as well as overloading of tables. Both of these things will bite you in the ass down the road.
7. Convention magic

Magic is the core of rails, and seems to be one of it’s biggest selling points. The problem is, there’s simply no place for magic in a world where people need to actually support your code. Explicit configuration and code is much more useful to operations folks who aren’t familiar with the codebase, framework, and language. Even if you use your developers to support your app, when they rely on a bunch of clever magic it can make for longer outages while people have to figure out what implicit thing they are failing to take into account.

8. Rails hype will kill ruby

Ruby could be a decent language. It has a lot of awesome things going for it. In a few years it really will be ready for real heavy lifting. At least that was ruby’s future. Rails has taken over the show. The Rails community is the ruby community, and it has not set ruby on a course to be a truly dependable language. Instead as rails project after rails project fails in all sorts of business environments, it is creating a permanent bias against the language in the management staff that oversees projects in american business. I’ve personally seen it in multiple companies, and expect to see it in most shops that are today fiddling with rails.

What Would Machiavelli Do?

For those of you who don’t know, this is the esteemed Niccolò Machiavelli. A 16th century diplomat, political philosopher, musician, poet, playwright, author of The Prince, and all around political badass. Far and away, his most famous quote from The Prince is “It is best to be both feared and loved; however, if one cannot be both it is better to be feared than loved.”

Personally, I plan on giving these things out like candy. If your work happens to also be a political nightmare, you can get your own in the evilsoft store at cafe press.