Sazbean

Software Development Management

Main navigation

You are here: Home / Archives for News & Notes / Opinion

Opinion

/

Google cannot see the future

Yesterday morning, Google made a little announcement.  You may have heard of it already.  Tuesday’s blog reader was like a million tiny voices all calling out the same word.  That cacophony continued on through today and I suspect it will remain as such throughout the month, or at least until Apple releases something shiny.  So much has been made of this small release, that I have vowed not to refer to it by name in this post.

The internets chattier apologists are already manuvering into position to hand Google the gold-painted plastic trophy of ‘Best Browser Ever‘ despite its current 0% adoption share, buggy Javascript, or total lack of support for my fruit-themed notebook.  I think this is a mistake.

Remember how quick we were to jump over to Microsoft’s camp when they announced IE would free us from paying for a browser?  Or when Firefox shook us out of that complacent stupor, slapped our faces and told us we didn’t need 10 windows open at once and that hey, we might like these super useful user created plugins?

Google isn’t putting out this reflective metallic bauble because it want’s to convert the masses.  They know they cannot see into the future, so any effort to corner the browser market is likely effort in vain.  Overlooked in the hype was a message that I heard loud and clear – and it was coming from Google.  Somewhere around the discussion of open sourcing the software, they made a very strange statement.  ‘We want others to copy our ideas, improve them, do it better, and reinvent the internet for us all’.

If that is true, why make their own browser?  Why not simply put their mental might behind Firefox, which is fully open sourced and free to fork off?  I truly don’t know, though I suspect that is what they did.  Looking under the hood (or more accurately read under the press releases), much of the plumbing is changed.  Multi-process based instead of single process with rewritten javascript JIT compiler makes the app different from firefox as steam locomotion is from gas combustion.  Still, there are pieces that are coming from Mozilla and WebKit which makes this more of a reinterpretation than a reinvention.  WebKit is the JavaScript renderer used in Safari and iPhone, so I would suspect to see this also be adopted in Google’s mobile OS, Android, as well.

I can’t say that Google will not come out ahead of the pact with this mirror-like offering.  Once they get their sea legs they will have their half-tillion dollar geek cred behind them.  Even so, I can say is that no one should be calling this race over.  The brower wars are heating up again and only the gentle sob of your company’s web designer is heard above the blogging din to mark the occasion.  Hell, that ‘Best Browser Ever’ trophy was stolen anyway, years ago, by the Opera fanatics.  Rumor says it is buried somewhere in Norway.

/

Ruby on Rails: Four misconceptions and a truth

Ruby on Rails

Business type people, cover your eyes for a sec. This one is for the web developers. Ok, so if you have not yet seen the Ruby on Rails screencast then the next fifteen minutes may change a few perceptions regarding web development. Take a look. Go on, I’ll wait. That little video has done more to poke the fire of web controversy than any debate since the IE v Netscape browser wars. It made big waves with people looking for alternatives from Microsoft and Sun. From the other side of the yard, php and perl programmers were impressed by the full service nature of the framework. Testing, DB connectivity, MVC, AJAX, even web services were all rolled into the system in the beginning, not bolted on afterward. It hit a sweet spot in the community at just the right time.

The business world (thats you guys with your eyes closed) appreciated the quick application turnaround and the low low price. Suddenly simple applications could be modeled in hours and up and running in a day. The quality of those early apps were rough, but the quick turnaround gave the stakeholders something tangible to see and experience. I have used Rails in many applications in my day job and I have reaped the benefits both as a department head and as a programmer. We have been trusting Ruby on Rails more and more for critical applications both internally and out in the wild.

Here are some misconceptions about Rails

  1. Ruby is too new to trust your applications to: Ruby is not a new language. Ruby is almost old as Perl, having started in Japan over 10 years ago. This means it is a well tested, fully proven language to develop in. The Rails hoopla has allowed for many authors to fully explore ruby and rails in book after book. The language is a very safe bet at the moment, possibly a better reputation at the moment than Java at least in the web community.
  2. Hosting rails applications is impossible: I will say that hosting rails is tricky, but no more so than PHP, Python, Perl or Java. The hardest part is overcoming the knowledge gap between what is assumed by instruction writers and what you truly understand. That just takes a bit of time, a good book, or a good consultant. Since its true that difficulty breeds opportunity, the safest solution is to host with a pro. I will be interviewing the CEO of EngineYard in an up-coming segment.
  3. Rails wont Scale: If someone tells you not to use Rails because you cannot scale up the site to large number of users, thank them for their assistance and walk away from the conversation. It’s a troll bait argument which has no defendable position either for or against. Sure, there are large apps that run rails. There are also large apps that run rails and have success issues. The real kernel of the argument is ‘Do you know enough to make a certifiably scalable application in language X instead?’ If not, then just don’t worry about it. For the non expert, rails has just as many pit falls as php, java, perl, python, asp, .net, etc. With the exception of Microsoft, Rails tries just about the hardest to avoid those pitfalls for new users. Arguments can be made that they succeed more often than Redmond, too. So if your site’s traffic is modest at best, don’t let scaling scare ya. When your site gets huge, you can still keep your site in ruby.
  4. The Rails community has a Our Way is the Only Way attitude: Yep, can’t really argue with this one. The leadership of the Ruby on Rails group is tight knit and self facing. They are solving problems that they see in ways that they believe is best. Nothing wrong with this and actually it is a perfect model for highly focused software design. One of the traps of programming languages and applications is the human tendency to compromise. Compromise leads to more than one way to achieve a goal, which always leads to complexity, confusion and non conformity in implementation. Rails skirts this issue by just saying ‘Do it our way’. This isn’t a problem for 99.9% of the web community so it really is overplayed in the media. If you want Rails to do something it doesn’t do, you are free to fork the source code and make your own version.