Shanti’s Dispatches

Just came across this post which talks about automating Facebook interaction to perform a request in a Facebook app.

Their ruby code is here (much of it based originally off mine — which is so cool).

For the longest time I didn’t get open source… why anyone would give away their hard-earned time (in the form of code) to everyone else.

It’s not some hippie thing though. The benefits are:

* expands your “street cred” in the community
* allows other people to enhance what you’ve done, and possibly, contribute back to the project
* fosters even more giving back by growing pie — it’s not a zero-sum game, as many would believe

In my case, I’ve almost always already written the software that becomes open source. Without releasing it, the code would simply rot on the vine. Usually within 2-3 hours (though I’m getting better), I can have the code cleaned up, tests added (if applicable) and released as an open source project.

The original Facebook automation article is here: HOW TO: Automate Facebook Interaction using Ruby and WWW::Mechanize.

More recent open source work: Sexy Temp Passwords (rails plugin), Dynamic File Store (rails plugin), and The Hydra Project.

Found this via del.icio.us/popular:

Not to take it too seriously, but my personal take on being a Ruby programmer, well, more of a Ruby + Rails programmer, is not so much about it being a superior language or considering myself superior to developers of any other languages, but rather that I’ve just found a “secret” (not so much lately) way of getting things done faster.

If suddenly a new framework for Erlang, VBScript, or heck, Blub, appeared that would make development incredibly efficient on that platform, many Rubyists would definitely take a look (that’s how 99% of us came to Ruby in the first place).

Mythical (but possible) blog post:

Hey — have you checked out the new VBScript on Rollerblades framework? I know it’s hard to believe, but I get about 10x as much done!

When All Else is Commoditized, Optimize for Time

I remember when a professor back in school first introduced the appeal of commoditization of complimentary services to your own. IBM and Linux is the quintessential example. Why would IBM want to commoditize the OS market (by investing heavily in Linux), when they already make a few of their own?

Now it seems normal, with Sun GPLing Java, but a few years ago many analysts were scratching their heads as to why IBM would want to invest $1 billion in Linux and open source.

Because now IBM can sell consulting services @ $250 per hour, while the cost of their OS and server software (used to deploy production systems), remains virtually nil. A $1 bln investment is pretty cheap for a rock-solid OS, especially when you’ve got $20 billion a quarter in revenues.

If you have any doubts about this, talk to a small business owner who’s buying SQL Server and Windows 2003 Server licenses because they decided to build out their platform on MS. (I had the pleasure of doing this recently - business owners are not happy about paying more for a licensing fee than the actual hardware!)

With servers and bandwidth being incredibly inexpensive these days, while OSes, database software and web framworks remain free (that is, if you use the right one *wink*), the only thing left to optimize for is developer time.*

* I do have a vested interest here. But I challenge you to try out an inexpensive Indian outsourcing firm (commoditized developer time) and report back your results. I haven’t heard too many success stories yet.

Aaron has a great post about what it’s like to work at Wired now that reddit has been acquired by Conde Nast.

It seems like there are usually three reasons why companies (well, it’s always people, somewhere, at the companies, who make the decision) want you working in an office:

1. Camradarie, team bonding
2. Rapid convergence on a feature set or UI functionality
3. Making sure you’re “working” and not, you know, goofing off
4. A very real explicit reason why you have to be onsite - like, you’re a Bank Teller, and they don’t make offsite vaults just yet

Startups usually have the first two reasons - which are very valid. (though, you don’t need to be in a shared workspace 100% of the time to accomplish this)

The third one falls amazingly short, and seems to be a major reason why many big companies have you working in an office. It’s sad that managers or CEOs think that if they just have a bunch of “warm bodies” in the office, that things are actually getting done.

A lonely, dark, quiet night from 9pm - 5am can be about 3x as productive for me as some days of a regular 9-5pm. Heck, make that 10x, or infinity-times (due to a division by zero error) as productive compared to those days that you just can’t seem to get much of anything done.

I’m probably just a “bad programmer” in this way, but I try to explain to my lovely girlfriend Abygale, how some days it’s hard to even get the ball in gear and start coding. She doesn’t have this problem - she can show up at work and start doing loan stuff (I still haven’t figured out exactly what she does, but it involves a lot of paperwork).

That’s what Evan Williams said at the Future of Web Apps Summit last week in SF.

He was even going to go so far as to make it into a poster and hang it on the wall. Personally, I prefer this one from dispair.com:

p.s. sorry for not liveblogging the event more, like I said I would. luckily there are plenty of other sites out there w/ coverage.

Talking vs. Typing

I think that’s one of the things I like about working from home most of the time. You tend to spend a lot more time coding, than talking / debating and working out features.

Personally, I think it’s more productive to code 2-3 hours on something, trying out (in live code) as many different things as possible, than say, and hour or two of debate on the subject.

At least 50% of the time, it seems like you end up getting it wrong anyway, no matter how long you debated.

Of course, there’s always the danger of rogue coders going off the reservation and implementing stuff that is totally crazy or will never be used in live production. I think that’s OK — much like Google’s 20% time.

Gernally, programmers (or maybe it’s just my particular sensibility) would rather see things getting done, than endless debates, with no real forward progress. Hearing stories about Microsoft and their endless meetings and Powerpoint presentations, it sounds like they’ve fallen into the trap of Talking, Not Typing.

Astute readers will note the ironicalness of me blogging this instead of actually coding something right now. Ahem.

Note: this was written a while back but was sitting in my drafts section. Worth a read if you are coming from a Microsoft background at all.

About two years ago, I implemented a billing system in ASP and SQL Server. It took about a month and a half to get fully flushed out.

Even so, we still experienced intermittent problems with it that drove our salespeople batty. (we could never replicate the problem in-house, since we didn’t have a test lab)

The requirements were, however, different, since we needed to charge cards in real-time in the ASP scenario.

With Sprout, though we might at some point need to do that for certain things (i.e. re-enabling locked, past-due accounts), we generally have the luxury of billing people as needed. (on the backend, at a time of our choosing)

Billing Systems on Rails

The system we just knocked out at Sprout took only about a week. Though, Charles had been working on the requirements for quite some time.

Requirements really do help us programmers. That way I don’t have to idle on IM, asking my manager every 5 minutes about some minutiae of how the system should be implemented.

Yeah - you can always plow ahead and just do things your way… but once you’ve been burned too many times from just doing that, you tend to seek out a little more guidance in the future.

Our system at SproutIt is also a lot more robust than my previous ASP endeavor. Our Sprout system includes a really robust notification system that includes:

- three days worth of charge failed notices
- three days worth of no card present notices
- Activation reminders (signed up for a paid plan, but haven’t entered a card yet, etc)

Hopefully we won’t have to send too many of these various types of notices… but it helps to be prepared.

Rails Productivity Numbers Legit?

Much has been bantied about re: productivity and rails (10x productivity boost, oh my!). Let me just say that I think a 10x number is pure hogwash.

However, even if it were only a 50% increase … that would be incredible. Can you imagine going to a decent manager and explaining that you can get 50% more done if you just use X technology? They would be crazy to ignore that possibility.

In all reality though, I think the number hovers somewhere between 1.5 and 3. That is, you can sometimes get things done in Rails that it would take you three weeks in PHP, or ASP.Net, for example.

Now, Rails productivity vs. Java/J2EE? You’re probably 4-6X as productive in Rails compared to such a bloated monstrosity as J2EE.

I just rocked out some sweet ass JavaScript/Prototype/RJS code for Mailroom. I won’t spoil the surprise by announcing what it does, because we can probably make a nice todo out of it on the Big Act.

It took some time for me to make friends with JavaScript. It always seemed like a hackish, backwards kind of language.

But between Prototype, Rails’ RJS Templates and a little good-ol fashioned JavaScript, you can accomplish miracles. (But, I probably shouldn’t speak too soon… We need to put some polish on the hacks I just wrote.)

A friend who’s attending the php|tek conference said there was a bit of Ruby bashing going on. Of course, he reports as well, Java is feeling a much bigger brunt of the heat.

I’ve decided to officially stop saying negative things about my fellow Java/J2EE brethren.

Seeing articles like this, make me realize that saying bad things about Java/J2EE, is like kicking a defenseless puppy while he’s down.

It just isn’t right, and chances are, the usage of Java in many enterprise shops was carved in stone some 3-5 odd years ago after a middle-manager read about its cross-platform benefits in a Delta Airlines in-flight magazine. (oops, there I go again!! my bad…)

I’m just sorry, guys. Sorry.

You may say that I’m a dreamer
But I’m not the only one
I hope someday you’ll join us
And the world will be as one

- John Lennon, Imagine

Andrew vonderLuft (who’s learning Rails himself) pokes fun at some Java code.

The thing is, Java coders would never get the joke unless they’ve used a really elegant language like Ruby or Python.

The humorous Java code snippet:

UploadedFile uploadedFile
= (UploadedFile) fileUpload1.getUploadedFile();
String text = uploadedFile.getAsString();

To my fellow coders in J2EE / ASP.Net Land

In this now widely-circulated article, Stevey rants about languages and why he wants kick-ass ones like Ruby to really take off, so that he has a good chance of being able to use them (”legally”) at his employers.

At this point, I’m like the minority who finally makes middle/upper management. Or someone who finally moves out the inner-city and into the suburbs.

While I’m livin’ it up in Ruby on Rails heaven, I no longer really care so much about my fellow brethren toiling away on their J2EE/ASP.Net applications.

Whatever you guys do though …. don’t drink the kool-aid!!!

Finally had a chance to sit down and play with SVK over the weekend.

It helps you manage multiple Subversion repositories — i.e. keeping one in sync.

Let’s say you’ve modified Typo, but your changes won’t be making it into the core distribution.

But you also want to keep up to date on the latest trunk and changes made by the core Typo dev team.

Enter SVK.

I was a little paranoid about SVK killing my Subversion 1.2.1 with its 1.3.0 bundled version, but everything has worked like a charm. (latest OS X Tiger)

SVK Links

• SVK Tutorial
• Free online SVK Book (not quit eas good as Subversion’s yet)
• Distributed Development with SVK
• SVK - Distributed Version Control - Part I
• Explaining the SVK Workflow

Charles Jolley has a great post over on The Big Act (SproutIt.com’s weblog).

He talks about the shrink-wrap software development lifecycle. It’s not uncommon, as he describes, to only release a new update every quarter.

Can you imagine … a bug in GMail or some really popular web app … and Waiting. Three. Months.

Now, Charles on web apps, such as Mailroom:

The other night I happened to be working when someone reported a bug they found Mailroom. I immediately knew how to solve the issue, so I fixed the problem and emailed the person back within maybe 10 minutes of their report.

Three months to deliver a fix down to 10 minutes. That’s service! Think about that the next time you find some nasty bug in the software you use for your business and you have to wait for the next release to have it fixed.

This is one of the things Joel is really going to have to grok soon, if not already, following the release of Fog Creek Copilot.

Of course, Paul Graham understood this way back in the day, when he created one of the world’s first web apps. (the first, he claims. :))

What is a *REAL* Programming Language?

I got into a bit of a pissing match back at my old company, because one of my fellow developers decided that scripting languages (you know, powering many if not most of the new innovative web apps coming out these days), are not real programming languages.

Only compiled languages like C++, Java, and … wait for it …. C# are real programming languages.

Do we all remember COBOL? Mainframes?

What do we think hardcore, diehard C++ programmers will be like in 8-10 years? Hmmmm….