Sazbean

Software Development Management

Main navigation

You are here: Home / 2008 / Archives for May 2008

Archives for May 2008

/

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.

/

Do your customers have satisfaction?

Knowing what people say about your company is pretty important for maintaining your brand image and quality of service. The Internet allows people to easily post opinions, problems and reviews. How do you know what people are saying about your company?

One way is to provide a forum where people can go to post reviews, problems, questions, etc. Get Satisfaction provides neutral ground for this conversation, which you can easily link to your website. Anyone can startup a conversation about a product or company, but if you own the company you can claim them (Get Satisfaction then verifies your claim). Once you’ve claimed or started a conversation, you can represent your company as an official representative or just an employee. More importantly, you can interact in an official manner with your customers and potential customers to provide your own side to any problems, questions or issues. As a customer-centric company you should take this input in order to improve your products or services and then interact with the community to get their continued feedback.

Besides linking or creating a badge to the conversation from your website, Get Satisfaction also provides the ability to add topic widgets in order to increase the visibility of your customer support conversation. These topic widgets can be customized by topic, order, number, summaries, etc. and you have have multiple widgets if you want to target different topics. Anyone can add their own customized topic widgets to their own sites – allowing your customers to increase visibility of the conversation as well. If you insist on keeping the conversation on your own website, an API is provided for integration with your site.

Conversations are organized by products, tags, questions, ideas, problems, and talk and can also be identified by recently active, latest and unanswered. Replies to the conversation can be rated by the participants so you can quickly get an idea of the overall emotion of the community to any particular idea – information that has previously been the realm of in-person focus groups.

For companies looking for a quick and easy way to interact with customers, Get Satisfaction can offer a great deal of functionality for free. However, keep in mind that the company is still in beta and hasn’t yet decided on how they will make money. Obviously without a business plan, the company may also disappear at some point – but right now, according to The NYTimes, they have comments on over 2,000 companies with 40% of the companies responding.

Technorati Tags: , , , , , , , ,

CrunchBase Information
Get Satisfaction
Information provided by CrunchBase

/

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.