Shanti’s Dispatches

Pretty sure that one’s it. You be the judge.

… but less fun defending yourself against charges of language bigotry.

Oh sweet, someone reads my blog!

Peaceful Dialog

Starbucks-window Breaking Anarchist (even in the name of good fun)

The analogy isn’t perfect, but taken to extremes this is what we’d have in the real world.

Do you care about winning converts?

No? Okay, that’s cool.

Do you want to have to defend yourself for being a Ruby (or Rails) Guy?

Let’s say you’re the Gandhi of fair trade protest. You organize massive swaths of people that come together and hope to make a difference on the issue, based on the merits of your argument and the justness of your cause. You believe that if you gathered enough people, lobbying power, etc. that you could honestly make a difference in this arena.

Then along comes a rival faction, wearing ski-masks, who at every junction when you’re about to have the spotlight, throw bricks through Starbucks windows and cause a huge ruckus doing their anarchist thing.

They totally steal all the attention away from your peaceful cause. Nay, they have hijacked your cause and now you can’t get a fair break from the media or general population.

You’re with fair trade? (Oh, one of those nut jobs …)

The Fear / Annoyance

I’m at a conference or industry event. I introduce myself and say that I’m a Rails developer.

Fellow Dev:  Ohhhh... You're with those asshats.
Me: 'Scuse meh?
Fellow Dev:  Yes, the language bigots.
Me: Oh, that's not me.
Fellow Dev:  Well okay, but that crew you roll with sure can be
   a bunch of arrogant assholes.  That's why I use Python.
Me: Well then...

I forsee this happening in the future, sadly.

Okay, first off, Obie Fernandez should really take down this post which understandably rubs many of our java friends the wrong way.

He meant it to be humor but it’s not very obvious at all that he’s joking…

That among a few other articles recently have started a major Ruby backlash, like this post.

It’s one thing to have intelligent debate & discourse, another to call people “Ruby on Rails bigots” which admittedly Obie was being in that (non-humorous) post.

Cedric in turn links to Bob’s post where in the comments they proceed to rip into Obie personally & professionaly. (that’s what you get when you offend the largest group of programmers in the world, y’know)

But on the actual merits of their argument against Ruby/dynamically-typed languages and maintainability, etc, they have been flat wrong on many of the points.

i.e. one complaint was that it’s hard in Ruby to know a magic field name from a table column.

Okay, it may not be your favorite IDE as of now but Netbeans + Ruby = Autocomplete Goodness. Screencap below:

Also if Netbeans is not your style, BAM - annotated models plugin which drops this into your ruby model classes:

  # Schema as of Sun Feb 26 21:58:32 CST 2006 (schema version 7)
  #
  #  id                  :integer(11)   not null
  #  quantity            :integer(11)
  #  product_id          :integer(11)
  #  unit_price          :float
  #  order_id            :integer(11)
  #

  class LineItem < ActiveRecord::Base
    belongs_to :product
...

Yes — this is not as nice as an IDE where you can type ‘foo.qua’ and ‘quantity’ magically appears, I will definitely give you that.

But it also doesn’t bother me much and I’m rarely thinking, wow, if only I had auto-complete this whole Ruby thing wouldn’t suck so bad.

It is indeed harder when you’re on a bigger team and didn’t name all the functions/columns yourself. i.e. you’d have called it ‘name_long’ and ‘name_short’ but someone else called them ‘long_name’ and ’short_name’, etc. Still, not the end of the world.

Academic Arguments vs. Real-life Examples

Anyawy most of the Java Bob thread was all about academic arguments and people’s pie in the sky opinions on things. It sounded very FUDy to me, personally.

Then commenter sandofsky chimes in and pretty much owns the entire thread:

Yellowpages.com had a 10 year old codebase. It was 100,000 lines of Java. It was a total mess.

This year it was rewritten in Rails. It took took five developers four months from first subversion commit to public beta. Now it’s under 10,000 lines.

Those 10,000 lines are clearer than anything from the legacy site. We assign developers to unfamiliar code and they’re up to speed in no time.

As for complexity, those four months included writing a service tier that uses our proprietary Ruby library for FAST.

As far as the pluralization conventions:
Class names are singular.
Table names are plural.

Done.

If you don’t like it, use set_table_name in your class.

I don’t know what capitalization rules you’re referring to. If you mean that classes are capitalized, all classes in Ruby are capitalized.

You can learn the “ancient tomes” of Rails by buying the book “Agile Web Development with Rails.” It’s available as a PDF.

‘nuf said.

oh and by the way, the ‘0wned’ thing is a joke… lulz

Seth Goden, normally spot on, says in his post Push vs. Pull:

I can’t use internal wikis. “It’s on the wiki” is a dumb thing to say to me.

That’s because Seth Godin is CEO of his company and can afford to have secretaries / underlings running around fetching data / information / etc. for him.

Most people hate repeating themselves. If I draft a wiki page that explains something, it gets really old when a co-worker (a teammate, not a boss or CEO/CxO) asks me repeatedly how to do X or setup Y/Z, when it’s already been documented for that explicit purpose.

Whenever I create a page like this, I usually send an email out with the data in the email as well as a link to the wiki document.

In that sense, “it’s on the wiki” or “it’s in the fileshare” or “it’s in the StandardOps.doc on SharePoint” or whatever you say is simply a way of saying quit asking me every 2 seconds because you are too lazy to use the standard way of viewing the documentation / documenting these things.

You can’t say this to a CEO/CxO, so of course they will not want to use a wiki.

RSS for Wikis

Note to Seth / etc — with most decent wiki software you can subscribe to an RSS Feed of all changes on the wiki, just like a blog.

I’d imagine more sophisticated wiki software would allow you to only track certain pages (only the ones you care about) & munge them all into one RSS feed.

Image via: frederator.kz

DHH on the language of bias:

If you don’t like something new that’s getting a lot of attention, you call it out as being all hype propelled by fanboys enamoured by an immature solution.

If you like that something new, you say it has momentum that’s being accelerated by passionate advocates of a fresh approach.

I’ve wanted to write about this for a while now. Flamebaiters can sometimes be pretty good at getting us fanboys riled up at times.

The Problem is not with Being a Fanboy, but with thinking you have the One True Solution

… and thus not realizing you are being a total, utter fanboy. (says a self-proclaimed fanboy of a variety of things)

I remember several experiences over the years where I’ve been chatting with a fellow hacker, and they were simply whole-heartedly dismissive / arrogant / belittling of some idea / framework / technology that I was either expressing interest in or personal ussage of.

To be honest, I’m sure I’ve been on the other end — and I know that feeling sucks, when someone pretty much puts you down like that.

The thing to remember is that whichever side of whatever debate you’re on, it’s always shades of grey and hues of advantages/disadvantages, depending on the situation.

Top 3 Signs You’re Dealing with a Delusional Fanboy

1. If you meet someone who’s using ad hominen attacks against your ideas, instead of addressing real issues, well, run for the hills if you have the option.

2. If you ask the person tough, pointed questions about weaknesses you believe they have in their viewpoint/argument, and they fail to admit one single weakness or disadvantage, chances are they are a delusional fanboy.

Let’s face it — nothing is perfect. To be a truly passionate, responsible advocate for something, you must know it’s weaknesses as well as its strengths.

3. The person expresses their opinions as if they were fact.

Can one benchmark their opinion/fact? Okay, if there are published benchmarks then at least we have some data points.

If it’s something much more nebulous and varies from person to person (i.e. programmer productivity in various languages), one can’t simply say “VBScript with Lisp Closures is clearly the most productive language”, etc.

So I just wrote this really long email in GMail about how to setup Sphinx, and then realized it’d probably be a good idea to save it to a Google Doc file.

Copy & pasting from GMail into GDocs kept my hilighting, bolding, etc! This may sound stupid but I’m not 100% sure if this is happening at the PC/browser level or via some kind of Google special sauce.

Anyway this is very cool and is the kind of thing Joel Spolsky was talking about over here. His overall assessment of the situation is still kinda off though.

Reading through The Big Rewrite has reminded me of a few thoughts I’ve had lately on developing apps.

Here’s a huge generalization of who you might be writing an app for:

* External clients (consulting)

* External customers, spec driven internally by a small team

* Internal client (an Intranet app, spec driven internall)

* Existing specification / app (a Big Rewrite)

* Greenfield app of your own making

The Obvious

Okay, what is going to be the most enjoyable to create? Of course it will be your own. This is why hackers are always tinkering on their own projects.

If you’re working on some Foo Open Source app that you’re making, and you hit some kind of roadblock or you see a major way to simplify things (at the cost of something else), you can just do it. No argument or debate with anyone, it just happens.

Sucky Features & Annoying Code work

If you’re developing your own app, you will probably never add a feature that you yourself think is sucky. Sure, your users may want a feature that you think sucks, but it doesn’t mean it’ll actually go in the product.

Another great one is code work that is highly annoying, boring or just sucks in general to do. When it’s your own app, you can usually put this stuff off for a really long time, if not indefinitely. And if you have a few bucks you can always outsource it or find a fellow hacker who actually loves doing a certain type of gruntwork.

The Voltron Theory of Developing Apps

Working in a small team of really talented, devoted guys & gals is probably the best way to get software done. Not too many chiefs (who can’t code), but indians (who can) and are at times empowered to be their own chiefs & get the product done and working.

Some things simply require a Benevolent Dictator who will take charge and get it done.

In the voltron cartoon, five “lions” would come together to form Voltron. (the metaphor here being that together they are bigger and better than the sum of their parts individually)

Having a team of guys/gals who bring different skills to the table is key. You might have:

* designer / UI lion
* backend coding lion
* database / MySQL lion
* IE6 / Safari browser compatability lion
* inscrutable bug finding & fixing lion

… and together these will form your Web App Development Voltron.

One guy decides he doesn’t want to convert his site over to Rails after all, switches back to PHP, and does it all MVC and “Rails”-style.

The article hits the front page of digg, reddit, del.icio.us — all the usual suspects.

Suddenly people are claiming Ruby/Rails to now be in the “trough of disillusionment” cycle of programming languages. Were people really expecting Ruby & Rails to sprinkle magic fairy dust on every single one of their development & scalability problems?

The initial “hype” around Rails was all about quickly building greenfield apps with rapid prototyping, less code & less configuration. A promise which it has largely delivered upon.

Massive Google.com-like scalability, integration with 100s of legacy tables, etc. was never (nor will ever be) the sweetspot of Rails. I’m personally sorry if you got led down the wrong path, Mr. Sivers.

The Twitter / Rails Fiasco

Twitter hit a major performance bottleneck a few months ago (not unlike PHP-powered Digg when it went down for several days in early 2006), but Twitter has since improved performance 10,000%.

Turns out it wasn’t very much of a Rails/application-server issue at all. The database architecture needed some reworking along with the infrastructure for supporting the more than 90% of requests to the site that come in through the Twitter API.

But when just the one site was having issues, everyone wanted to lay the scaling blame at Ruby’s feet.

Derek Sivers Prefers PHP

Okay. Who is this guy again? So he made a big hullabaloo when he decided he was going to switch to Rails from PHP on his massive application that uses hundreds of tables and faces customers, employees, suppliers, etc.

You thought this would be an easy task in Rails how exactly?

I think there is more going on here than meets the eye.

Part of what you do in Rails is break things down into Model-View-Controller containers. Views, go into rhtml and rxml files.

Was Derek & Co. not breaking things into views for Rails these past two years?

Just doing that would be a good step in the right direction. Rails views could fairly easily (imho) be ported over to PHP templating views. It’s largely a matter of syntactic sugar. ($foo vs. @foo, etc) Some of the more elegant Ruby syntactic sugar might have to be dropped (@items.each into “for $item in $items” or whatever PHP looping preference you have)

Re: The Point on Sample Sizes

The next time someone tells you that the Earth is flat, are you going to change your whole worldview based on one person’s opinion?

Think for yourself people.

Joel Spolsky has posted another thought-provoking strategy letter:

In the late 80s, Lotus was trying very hard to figure out what to do next with their flagship spreadsheet and graphics product, Lotus 1-2-3. There two obvious ideas: first, they could add more features. Word processing, say. This product was called Symphony. Another idea which seemed obvious was to make a 3-D spreadsheet. That became 1-2-3 version 3.0.

Both ideas ran head-first into a serious problem: the old DOS 640K memory limitation. IBM was starting to ship a few computers with 80286 chips, which could address more memory, but Lotus didn’t think there was a big enough market for software that needed a $10,000 computer to run. So they squeezed and squeezed. They spent 18 months cramming 1-2-3 for DOS into 640K, and eventually, after a lot of wasted time, had to give up the 3D feature to get it to fit. In the case of Symphony, they just chopped features left and right.

Neither strategy was right. By the time 123 3.0 was shipping, everybody had 80386s with 2M or 4M of RAM. And Symphony had an inadequate spreadsheet, an inadequate word processor, and some other inadequate bits.

Peter Colijn, a developer at Google, nails it in his response:

He then goes on to say that history is repeating itself with AJAX, giving Google, and Gmail in particular, as his choice for the contemporary Lotus. However, the comparison isn’t entirely apt.

The main point of Joel’s story, though, was that current AJAX developers (and in particular Google) are busy doing the present-day equivalent of rewriting inner loops in assembly, i.e. tweaking and heavily optimizing JavaScript and dealing with annoying browser compatibility issues and so on, and that soon this won’t matter because there will be some great platform that abstracts all of these details away. I find this hard to believe, for a number of reasons. JavaScript execution may get much faster, both due to hardware and software improvements. There are new JS engines that are much better than Spidermonkey, which is Gecko’s default. But that’s only a small part of the problem. Once you have the JavaScript on the client, it is already executing fast enough most of the time. It’s not the bottleneck.

The bigger problem is bandwidth and latency. Bandwidth does not increase at a pace at all similar to Moore’s law. A lot of people have broadband now, but the networks themselves are overloaded (the tubes, if you will, are clogged).

Similarly for latency; a typical HTTP request has about 50-100ms of latency each way on a very good connection, and that’s not getting any better any time soon. This means that doing frequent or large (or both) network requests will be problematic for some time to come. So a sloppily-written AJAX app that does 90 HTTP requests just to load is slow today, and guess what? It will still be slow in 6 months!

Exactly. But there’s more.

Over at SproutIt, when we were building the first iteration of Mailroom 2.0, it only took one extremely talented front-end developer (Charles Jolley) to optimize some pretty incredible AJAX.

See a preview below or signup for an account yourself and take it for a spin.

It’s just as fast as GMail’s JavaScript, and if we had millions of dollars to pay for infrastructure, our AJAX responses could be just as fast as Google’s as well. But even as is, our server-side responses are pretty darn fast, especially considering the under ~$2-3k pricetag of our boxes (monthly).

Charles even rolled the front-end JS framework into a reusable library, open-sourced as SproutCore. You may have seen it in the recently-launched .Mac Web Gallery (more on SproutCore here)

Thus, Joel’s assertion that a company needs an army of developers to sit around and optimize JavaScript, well, it’s simply bull hunkey.

So, a Team of 3-5 Could Compete with GMail?

Yes, on a functionality front. But once your site gets TechCrunch’d and 50,000 users are trying to signup all at once, your site will be pwned. Toast.

No startup (yet) can compete with Google’s infrastructure for massively deploying applications to millions of users. Someone might be able to get there, if they had to — but their solution would likely only solve a single aspect of the scalability problem. i.e. you might solve the problem of getting hundreds of thousands of email messages into an app within a short time span, but will you also have solved how to stream hundreds of gigabits of video too?

Options for Scalability Problem Vectors

Amazon S3 is a step in the right direction for sites that are very file-serving intensive. (think YouTube, Flickr, etc)

Amazon ECS, GridLayer, mediatemple’s Grid-Service, etc help if your site is very appserver-centric (i.e. lots of PHP or Mongrel/Ruby processes chewing up fatty amounts of CPU on biz logic, etc). Still grids are clearly not a panacea.

For database-intensive apps (like Wikipedia), there is no simple solution for scaling MySQL. Sure, it scales, but you have to do it per application. Does your site do 10,000 reads per second and 50 writes? Or 500 writes and 50 reads per second? Those two scenarios will need entirely different MySQL setups.

Startup Weekend’s idea is to get 67 (or however many show up) people in a room and try and build a startup together in one weekend.

Anyone who’s delt with the all-too-common “too many chiefs, not enough indians” problem knows that 67 somewhat strong-minded entrepreneurial types will have trouble getting much of anything done.

So it was no surprise that after the weekend finished, the startup had not even been launched yet. The people who knew how to deploy the code had already gone home. (for some reason I just find that last part hilarious)

Enter RailsRumble

Over September 8-9th, over 100 teams came together to build fully-functional, deployed webapps in 48 hours through RailsRumble.

No bickering about silly one-off features, just 2-5 dudes in a room (or remotely) coding some stuff up together and doing their best to make it shine.

This is how startups should be done — it’s also similar to Y Combinator’s model, only on an accelerated pace.

To be sure — some of the apps are pretty silly and pointless. The point is that they got something going, and launched in just a few short days.

Could Startup Weekend Work?

Yes, I believe so. But the idea would have to change to more of a rumble/hackfest type of event. Small teams of 3-8 people, not one giant team of 67.

Throw them all in a room together, let ‘em synergize, order pizza & have massage-fests (see the video of this floating around from Startup Weekend somewhere.. ), and I think you’ll have a great event that’ll also get stuff launched.

Have lawyers on hand & genericized paperwork to form ad-hoc partnerships as people formed into teams. But I think many are not as concerned about securing equity in startups launched at these types of events; it’s more for the social aspects.

One other great thing about the original Startup Weekend is the initial buzz it generated, while Rails Rumble has remained largely uncovered beyond the ruby/rails community.

Leveraging this early press to get early adopters using your service would be invaluable.