Obie Fernandez

Workaround to Get All Your Twitter @Replies

Twitter's show me all @replies has not been working, which means you don't see people's replies to you unless you follow them. If you have a high ratio of followers to people you follow, you can really come off as a dick because of this bug. Thanks Twitter!

Luckily there's a workaround involving Tweetscan

Uploaded with plasq's Skitch!

Do a search for your Twitter username and subscribe to the resulting dynamic RSS feed. Problem solved. Hopefully Twitter gets their act together soon, though. Even though their scaling issues have nothing to do with Ruby on Rails, they still give plenty of FUD-fuel to the haters.

MagLev is Gemstone/S for Ruby, Huge News

...and I suspect it will be a hugely disruptive force in the Ruby/Rails community in the future.

Holy shit! - Antonio Cangiano (after seeing the benchmarks run)

Avi Bryant seems to be leading the project and it's only 100 days old (and how did it stay secret so long?!?) However, since it's based on the mature Fast VM used by Gemstone/S, they're already blowing away Ruby MRI 1.8 benchmarks with 8-60x speed increases. Mention was made of cooperating closely with Rubinius team to make sure that their implementation runs all the Ruby specs, and is truly Ruby and not a fork.

When MagLev is widely available, it basically means that there will be a truly enterprise-class option for writing trading systems, logistics and other large persistent object-heavy systems in Ruby. The shared memory cache (basically a large OODB) holds up to 17PB and has transactional capabilities and automatic synchronization. According to Avi, there is a strong commitment to making sure there are good ways to use Rails on MagLev -- ActiveRecord, which no longer would be truly needed, could still be used (with the exception of find_by_sql, of course).

I'm dying to play with this stuff. Ditching relational databases is a no-brainer for most of the projects that I've worked on in the last 5 years.

SAP Sued for Typical Ghetto Behavior

So... when me and my friends talk about the "bar being set so low" in this industry, we're not talking simply about programmers. Stupid, crass ("ghetto", if you will) behavior is endemic at all levels, and even at the biggest players. Case in point, SAP getting sued to the tune of $100 million by Waste Management over a failed enterprise project. (full article via cote)

The trash-disposal giant Waste Management is suing SAP, saying top SAP executives participated in a fraudulent sales scheme that resulted in a failed ERP (enterprise resource planning) implementation.

What makes this case interesting, in my opinion, is that the "fraudulent sales scheme" that SAP is accused of doing is a well-known marketing tactic used by practically every software vendor I've ever known, and is probably familiar to you as well. Read on...

In 2005, Waste Management was looking for a new revenue management system, according to a company statement. "SAP proposed its Waste and Recycling product and claimed it was a tested, working solution that had been developed with the needs of Waste Management in mind,"

Emphasis mine. They claimed it was a tested, working solution! Further, they promised to implement it throughout Waste Management in 18 months. There must be huge logistical challenges and biz-process re-engineering (BPR) factors to account for in such a deal, but 18 months is probably a reasonable time-frame to get a working, tested solution implemented. However, writing plus implementing in 18 months, for such a huge company is of course a whole 'nother story!

"From the beginning, SAP assured Waste Management that its software was an 'out-of-the-box' solution that would meet Waste Management's needs without any customization or enhancements"

Wow! No customization or enhancements! How do you convince skeptical purchasing managers that such a bold claim is true? (Here's where I start chuckling, knowing how common this practice is)

Waste Management said product demonstrations by SAP prior to the deal employed "'fake software environments, even though these demonstrations were represented to be the actual software."

If you're in the business of selling enterprise software, you kind of have to go read the article, because it is a priceless account of how to really fuck up a major deal like this.

Waste Management ultimately signed a sales pact with SAP on Oct. 3, 2005, according to the court filing.

The charade about fully-functional and tested software collapsed immediately.

"Almost immediately following execution of the agreements, the SAP implementation team discovered significant 'gaps' between the software's functionality and Waste Management's business requirements," it states.

I guess deep-down inside, it's this sort of stuff that drove me away from the "enterprisey" side of the industry. For all the talk of pragmatism and being lean, and Agile, this sort of thing is just still too common.

"Waste Management has discovered that these gaps were already known to the product development team in Germany even before the SLA was signed. Instead of admitting what it knew at the time -- that the software lacked basic functionality to run Waste Management's business -- SAP undertook an elaborate fraud to perpetuate the original fraud and to recover additional money from Waste Management."

How do you cover up fraud on this scale? Blame the client of course!

Members of SAP's implementation team blamed Waste Management for the functional gaps and submitted change orders requiring that Waste Management pay for fixing them, according to the complaint.

We all play our part in the grand drama of IT, behaving in ways that improve the industry or lead to fiascos like the one described above. The client is not always right, and I'm sure Waste Management played into the fraud to a large degree, with clueless managers and unreasonable expectations. The onus is on us, the technology providers, both at the executive level and below, to stand up and be honest about what can and cannot be accomplished, and risk our jobs if necessary. That's courage, although you have to admit, that given the red-hot demand for IT talent currently in place, it might not actually take that much courage to stick to your guns.

Big Name Companies Using Ruby on Rails

Woke up this morning to the following email request from the CTO of one of Hashrocket's big, important clients:

Can you give me a list of big name firms that you know are using Ruby on Rails for major projects. Need it by this afternoon for an important meeting with top management.

I scrambled together a response, including some advice from folks that responded to my query on Twitter (thx!) After some reflection, I realized that it would make a good informative blog post.

First of all, lots of people pointed me to http://www.workingwithrails.com/high-profile-organisations, which lists the following firms:

Sing ♫ one of these firms is not like the other ♫ while you're reading :)

• amazon.com
• BBC
• CapGemini
• BPN
• Cisco
• C|Net
• EA (Electronic Arts)
• IBM
• JP Morgan
• NASA
• Oakley
• Oracle
• Siemens
• ♫ ThoughtWorks ♫
• Yahoo!

In addition to the list above, there's a number of companies where I have direct, or reliably indirect knowledge of Rails adoption through my friends and associates:

• John Deere
• New York Times
• NBC
• Barclays
• LA Times
• Chicago Tribune
• Orbitz
• Google
• Turner Media
• Limewire

For good measure, I also mentioned http://rails100.pbwiki.com/, which tracks high-traffic consumer-facing websites that corporate-types won't necessarily recognize by name, but that for sure handle millions and millions of visits per day. The top ten list on that page (and corresponding Alexa rankings):

• twitter.com [642 !!?! I thought it would be higher]


• scribd.com [940]


• blingee.com [1170]


• yellowpages.com [1734]


• penny-arcade.com [2069]


• 43things.com [4190]


• kongregate.com [4488]


• pitchforkmedia.com [4740]


• projectpath.com [5041 One of the Basecamp hostnames]


• funnyordie.com [5089]

What big-name companies do you know about where Ruby on Rails is gaining traction and adoption from the grassroots level on up?

More About 3-2-1 Launch by Hashrocket

As most everyone that reads this blog knows, I recently announced formation of my new startup company named Hashrocket. (We are named after the ubiquitous key/value => operator in Ruby.) One of our two principal offerings is called 3-2-1 Launch, and this post aims to tell you a little bit more about what it means and how we came up with it.

The idea for 3-2-1 Launch was born during Rails Rumble. Our app, PretendPeople, won honorable mention and the team had a great time. Afterwards, none of us could shake the idea that working under the huge time constraints of a 48-hour deadline brought out the absolute best in us. It's like the 37signals Getting Real philosophy, charged up on adrenaline. As far as we're concerned, one of the best ways to only "build half a product", is to only give yourself enough time to do that and nothing else. Embrace constraints!

Instead of freaking out about these constraints, embrace them. Let them guide you. Constraints drive innovation and force focus. Instead of trying to remove them, use them to your advantage.

After Rails Rumble we especially wondered if institutionalizing the embrace of constraints in a consultancy would be commercially-viable -- an appealing option for other "Getting Real" believers wanting to quickly churn out 1.0 versions of their new web application ideas.

We put the concept through its paces on internal work, and came to the conclusion that a span of 3 days is just enough time to get a new project off the ground - enough to nail down some distinguishing functionality, without sacrificing quality and good looks. Of course, it's not applicable to all projects -- our team of developers is 4-6 people (mostly working in pairs) which limits the amount of complexity we can tackle in one 3-day iteration (which we've taken to calling "orbits").

Here's a quick list of factors that empower us be ultra-productive in 3 days:

• Expertise in Ruby, Rails and BDD (using RSpec)
• Heavy automation of common tasks (pretty much anything repeatable is automated, including our initial application bootstrap which includes basic functionality such as authentication)
• Smart use of web services such as Amazon's EC2 and S3
• Reliance on Rails-based web 2.0 tools such as Basecamp, Highrise, Lighthouse, and Beanstalk

The 3 scheduled days (always Mon-Wed) refers strictly to implementation work, specifically the first iteration, ending with a public release of the software. Prior to the 3 days, our contract specifies a time period of 3 weeks during which we agree on detailed specification (RSpec Stories ftw!) and high-fidelity mockups. What we're looking to achieve is a high level of confidence that we'll be able to launch in 3 days, and that necessarily involves locking down requirements prior to implementation. We've talked about an abort mechanism if anybody on the team thinks we're not going to achieve a successful launch (unveiling) on Thursday. If an abort were to occur, we'd postpone the launch for the next available date (probably the following week) at no additional charge to the client.

Right now we're doing Rails exclusively, although we're keeping our eyes on Merb and other up-and-coming competitors.

The cost model for the 3 weeks + 3 days (including deployment and post-support) is fixed-price: 30,000 USD. An essential value of the offering involves client mentoring: our curriculum, which will probably be marketed separately within a few months teaches new web entrepreneurs the essentials about the development process, recruiting and vetting technical people, as well as evaluating hosting options and costs. We want to give our clients everything they need to establish accountability from their technical resources and not get ripped off "in the ghetto".

Our first public 3-2-1 Launch is clean-undies.com and we are planning on blogging a more extensive description of what it is along with a feature roadmap later this week.

Are you using Haml?

If not, why? Seriously, take a moment to tell me in the comments. If you haven't had a chance to play with Haml yet, here is an easy opportunity to do so online.

All of Hashrocket's new projects are done in Haml, and we've now decided to transition everything else in our portfolio over to Haml as soon as possible. The indentation-based approach works wonders for generating clean, semantic markup and the way that you can see the structure of your markup in a way that easily maps to CSS rules is simply brilliant.

My initial impression of Haml was not as favorable. If you similarly gave Haml a try when it was originally released and couldn't get it to work in a stable fashion, you might want to try again.

Do you think we are stupid?

If there's a positive side to some of the anti-Ruby negativity, it's that new voices are joining the fray. In the must-read If Rails Is A Ghetto, Please, Let Me Be Ghetto, John Munsch sums up the current anti-Ruby sentiment pretty well:

Everybody who has seen the explosive growth of Ruby and Rails over the last couple of years eclipse their favorite language/framework (e.g. Python, Groovy, PHP, etc.) seems to be blogging or commenting this idea that Ruby and Rails isn't really that great, it's just hype. It's only a committed few who have something to gain from you adopting Rails (i.e. a book to sell, consultant hours, etc.) who are promoting something that is snake oil.

Seriously, how stupid do you think we all are? I've been doing professional development since 1985 and doing it full time since '87. Do you really think that I and thousands of others can't tell when something works and it doesn't? I did HTML when the only browser was NCSA Mosaic and ASP websites to build DevGames.com and then later GameDev.net in 1999. That was painful. I can tell the freaking difference people. This works and it works well. I might not pick it for building the next version of eBay because it wouldn't stand up to the load, but I would pick it for building the early versions of the next site that will become as big as eBay because it will offer that site lots of fast growth and flexibility.

What's This Crap About a Ruby Backlash?

Zed's rant triggered some patently false anti-Ruby memes that have now been bouncing around the programming blogsphere echo chamber for a few weeks. Disturbingly so. It's time to put a bullet to the head of the idea that Ruby is experiencing a widespread backlash, that it was just a fad, or that it is inferior to competing technologies such as Groovy. As far as I can tell, the originators of these ideas are people that betray agendas against the success of Ruby and/or Ruby on Rails. Specifically, I'm calling one of them out by name:

Daniel Spiewak (for being a liar)

His post, The End of the Ruby Fad? really set me off and was the final straw that made me write this post. As a community, I don't think we can just let the FUD and lies perpetuate unchecked. Daniel's post in question is full of wrong-headed opinions, but it also has lies in it that I believe are specific enough to be called out as willful deception:

Daniel: "Ruby posts to link sites like DZone or Reddit get voted down before they have a chance to see the light of day."

Simply browse the ruby links on programming.reddit.com or the list of over 2000 ruby-related links on DZone to disprove that lie. My contention, which I think is fairly obvious to people on this side of the Ruby/Anti-Ruby divide, is that the people echoing the Ruby backlash theme are all folks with entrenched anti-Ruby stances and agendas. There are no neutral observers chiming in on the matter.

It's the same old FUD, repackaged:

Daniel: "...while Ruby may not be suitable for an enterprise level, high-traffic web application,"

Peter Cooper of RubyInside calls him out on that one better than I could hope to do so:

Peter: "You say you don’t like the hype or the backlash, but then you come out with this sort of vague non-statement to keep the fire burning. Any language “may” or may not be suitable for any task, but you seem to be implying in the context here that Ruby is “not” suitable for developing enterprise level, high-traffic Web applications without actually going the whole hog and just saying it. In any case, this, of course, is not true. At least, it’s no more true for Ruby than it is for Python, Perl, PHP, or Scala, say."

What about the most general of facts, about the nature of Ruby itself as a programming language?

Daniel: "(Ruby is) hardly a general-purpose language, so it could never replace Java and company."

Ruby is by definition, a general-purpose language. (Wikipedia makes a contrast between domain-specific and general-purpose languages.)

You have to question the actual knowledge of someone making such blatantly wrong assertions. In other words, does Daniel know what the hell he's talking about? He answers that question himself in the comment trail:

Daniel: "It has been pointed out that my "Rails" example is quite foolish and naive. This is absolutely true."

Oh the irony! How folksy and cute to write blatant crap in your blog, enjoy the publicity and then admit that you knew it was crap to begin with. To that I say "UNACCEPTABLE!"

Even his rhetoric is faulty, like this plainly false categorization of developers:

Daniel: "Developers these days fall into two camps: those who have heard the hype and rejected what it stands for, and developers who are totally carried away by the emotion of the fad."

Maybe not technically a lie, more of an opinion, but certainly bad rhetoric. There is a huge third camp, that dwarfs the extremists on both sides, full of intelligent, pragmatic individuals that are choosing to use the tools available to us without prejudice. That includes Java, Ruby, Python, Scala, etc. There is no silver bullet, and all that jazz...

Oppression

Daniel's post led me to question, what is the motive for piling on to the heap of negativity started by Zed and perpetuated by Rick Hightower, Graeme Rocher and others? Why pick on the Ruby community? Is it simply a reaction to the hype cycle?

Daniel: "Perhaps now that the bubble has burst, we’ll finally get to see the popularity of Ruby in its proper place."

Aha! Above all, that sentiment is the common thread amongst the haters of the progressive Ruby community. Oppression! They want to keep Ruby (and by extension Rubyists) in our proper place! What is that proper place I wonder -- perhaps it is out of the mainstream, out of the limelight, out of the enterprise, out of the places where we threaten the status quo!