Sazbean

Software Development Management

Main navigation

You are here: Home / Archives for Tech

Tech

/

Do big names impress you?

Continuing our Rails discussion. Should be wrapped up by next post.

Most of the web development world has dabbled on the bleeding edge of technology. Few, however, are brave or stupid enough to live out there. When pushed to pick a language for that new corporate ecommerce site, we all reach for that dog-eared copy of O’Reilly Cookbook for [php, asp, .net, java] because its safe. No one wants to be that girl in the action movies, you know the one who tests the rotted out bridge by walking across it real, real slowly.

There is comfort in knowing you are not the first down some path. So here is a cribbed list of names that are using Rails today. This comes from Obie Fernandez’s Blog and the source material is from rails100 and Working With Rails The comments on Obie’s post are worth reading as well. These represent some big industry names that are using Rails today.

  • amazon.com
  • BBC
  • CapGemini
  • BPN
  • Cisco
  • C|Net
  • EA (Electronic Arts)
  • IBM
  • JP Morgan
  • NASA
  • Oakley
  • Oracle
  • Siemens
  • Chase Bank (mentioned in the comments)
  • American Express

Newspapers like NY Times, LA Times, and Chicago Tribune are trusting Rails for their online sections, which if they are at all trying will be hosted through advertisements. The thousands and tens of thousands of smaller companies that are using rails have each looked at this list and decided that ‘Yeah, I guess I can trust my business on this platform’. I dunno, the bridge is kinda getting crowded.

/

Ruby on Rails: My advice

Lets continue our theme of Ruby on Rails reviews with the advice I give clients thinking of trying out RoR for a project.

My first piece of advice when evaluating a new language or technology is for a company to get dirty early on; get at least one small project under your belt before reaching out to a consulting group. Sure its strange advice from a consultant but it’s grounded in solid personal experience. Companies that have had first hand experience with a product or language are often more comfortable with the advantages and limitations of said product or language. That means their expectations are correctly grounded in reality. Here are some expectations that I’ve found to be true through personal experience:

  • Rails is good for delivering dynamically generated textual content over the web. Really good, actually. Really really good.
  • Rails is not as good at maintaining session state as other languages, such as Java Swing. This makes it a poor platform to replace that desktop accounting app. Better to look at a Java Hybrid product like Oracle Application Server with Forms and Reports.
  • Rails can handle Interactive Media, but not as well as Adobe Flex.
  • Rails can do AJAX well but the Scriptaculous tends to be a weighty download. It is cache-able, though so your experience may differ. I prefer JQuery Having said that, the RJS libraries in Rails makes writing JavaScript much less painful.
  • If something is working in one language, don’t redo it in Rails just to keep the source code in one silo. If PHPBB works for you, great! Stick with it.
  • The Rails Persistence layer ActiveRecord is very cool. It can greatly simplify database access for new users. However, don’t expect it to solve all data access woes.

My second piece of advice is to break the Test Once Live habit. This one is a tough sell since people love the time saved in development using Dynamic Languages and loath the trade off spent writing solid tests. Here is the reality, your application will run just well enough to get everyone excited about it. It will also fail you the moment you show it off to someone you want to impress. Here are some testing tips that I have learned the hard way.

  • Write RSpec tests before you show it to anyone. RSpec, once you learn it, can be the stories given to a consultant. We’ll love ya for it.
  • Do end user testing with JMeter and FireBug. JMeter will to load testing and FireBug will tell you more about what your browser is getting from the server.
  • Once you have a working application start running AutoTest on startup. Let it sit in the background and just forget its there. Then, when you have the last second really important change you need to make before 8AM, it can catch and alert you to a test failure before you find out live.

/

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.