Recent Posts - Page 28

Last month, Jeremy gave a presentation up at Canada on Rails on Internationalization and Ruby on Rails, which showed the audience that you could use the Globalize plugin to provide i18n support to your Rails application. But wait, Rails doesn’t include native support for i18n. Why not? This is actually asked quite frequently on the Ruby on Rails mailing list and has been an anti-Rails argument point for quite some time.

So, why doesn’t the Rails framework have built-in i18n support? There is actually an easy answer to this.

One Size Does Not Fit All

I look at i18n much in the same way that I view authentication. Each application has it’s own set of special cases and requirements. The acts_as_authenticated plugin might work great but what do you mean it doesn’t authenticate against a LDAP server? Why doesn’t it have a complicated ACL schema? This is where you are left to keep searching for another available plugin or roll your own. Often times, it’s quicker to do things the way you need them to work than to search, review, implement, and test a plugin that someone else wrote. However, there is good reason to use plugins… especially when you become comfortable with them and begin extracted plugins from your application that you can reuse in other applications that you develop.

With internationalization you will find yourself reviewing numerous options that have been developed by the Rails community. People ask on the mailing list, “Will Rails core include i18n support?” No. Why not? Well, there isn’t one solution that solves all problems. They each have their pros and cons. At PLANET ARGON we are using the Globalize plugin for every project that requires i18n support, but we have talked to others who find it to be too much for what they need. It’s a matter of the context in which it is needed. For example, the applications that we have been developing that require i18n support went beyond just needing to have various labels, headers, and application text be available in multiple languages. The applications required that all content have different translations. For example, a biography of the Brasil soccer team has 18 translations that Globalize allows the applications administrators to manage. Other i18n solutions use the gettext/text file approach, which doesn’t solve the problem that we were faced with. Globalize works great with ActiveRecord and we’ve been using it with PostgreSQL with great success.

As the Rails core team isn’t aiming to solve this problem… much like I don’t expect them to solve the problem of interacting with Legacy systems… it pushes the responsibility on developers to make educated decisions on what will solve their problem. However, when there are a good number of i18n options available, how do you know which one to use?

Help is on the way, as Martin Bernd Schmeil has started a mailing list for those who wish to talk more about i18n and Ruby on Rails. If you’ve had experience working with i18n and would like to help those who are seeking the right solution for their specific needs, you might consider offering your assistance on the mailing list.

For more information on the various i18n options for Ruby on Rails, visit:
http://wiki.rubyonrails.com/rails/pages/InternationalizationComparison

Of course, you can always contact PLANET ARGON to have us help your team solve the problem. :-)

(copy/pasted from email)

• New Business Level Rails Hosting Plans
• New Rails Application Audit Service
• Jeremy Signs Book Deal with O’Reilly
• Robby and Jeremy speak at Canada on Rails
• Ruby on Rails Podcast features PLANET ARGON
• Project Borat
• New Face at PLANET ARGON
• New PLANET ARGON Documentation Project
• Upcoming Events

New Business Level Rails Hosting Plans Launched

As a PLANET ARGON newsletter subscriber you are one of the first to hear about our new suite of business class hosting plans. Are you are seeking a cost effective solution for hosting your business critical Rails application, but aren’t ready for a dedicated server? Our Rails Business Hosting plans are just what you are looking for! More bandwidth, more disk space, more ram and fewer neighbors. Forget about the perils of sharing a server with a couple hundred users. The Rails Business Hosting plans limit the number of users on a server to no more than 15.

“All of the service and support of a shared server,” says David Gibbons, PLANET ARGON’s Lead Systems Administrator. “You’ll never have to worry about the headaches of server administration, but you still reap the benefits from being one of a select few having to share resources.”

For more information on the Rails Business Hosting plans, please visit: http://www.planetargon.com/rails_business_hosting.html

New Rails Audit Service

PLANET ARGON has a new service for businesses building web applications with Ruby on Rails: A $2500, 48 hour turn-around code audit and analysis.

“We built this service specifically for businesses wanting expert advice on how to improve and optimize their Rails applications,” says Peat Bakke, the Project Director at PLANET ARGON. “A little guidance makes a big difference, especially with development teams who are new to Rails.”

The audit provides recommendations tailored to your Rails application that might include optimizing database interactions, improving test coverage, simplifying AJAX interactions, automation with Rake, RESTful behaviors, and plugins.

For more information on our new audit service, contact us today: http://www.planetargon.com/contact.html

Jeremy Signs Book Deal with O’Reilly

We are very excited to announce that Jeremy Voorhis, PLANET ARGON’s very own Lead Architect, has signed a deal with leading technical book publisher, O’Reilly Media. Jeremy will be writing Rails in a Nutshell, part of the popular Nutshell series. This means that PLANET ARGON has not one, but two authors writing books about Ruby on Rails! Congratulations Jeremy!

For more information and to sign up for email updates, visit: http://www.railsinanutshell.com/

Robby and Jeremy speak at Canada on Rails

Where were Robby and Jeremy on April 14? They were both speaking at the Canada on Rails conference in Vancouver, BC. Robby presented Sneaking Rails through the (Legacy) System, and Jeremy talked about Globalizing Rails.

Robby shared his insight about bending ActiveRecord’s conventions to work with a legacy database and gave a live demonstration of how this could be done with Dell’s freely available video store database. Check out the presentation slides for Sneaking Rails through the (Legacy) System at http://rubyurl.com/DRv

Jeremy shared his experiences from developing and using the Globalize plugin to internationalize Rails applications. This covers the Globalize basics as well as tips and tricks for designing your application. View the presentation for Internationalizing Rails at http://rubyurl.com/1WQ

PLANET ARGON currently has a site in production that supports 18 languages and is fully translatable through the web. PLANET ARGON is also the hosting sponsor of the Globalize project, which can be found at http://www.globalize-rails.org/.

For those of you who were unable to join us in Vancouver, Robby has collected informative links from Canada on Rails including many of the speakers’ slides. Check it out at: http://rubyurl.com/gZG

Even better, you can hear more from both Robby and Jeremy at RailsConf in Chicago this June.

Ruby on Rails Podcast features PLANET ARGON

Be sure to check out one of the latest Ruby on Rails Podcasts recorded in Vancouver, BC at the Canada on Rails conference earlier in April. Jeremy Voorhis and Robby Russell, both speakers at the event, had a chance to sit down with Geoffrey Grosenbach to discuss PLANET ARGON development practices, projects, deployment, books, and our involvement in the the Rails community.

Listen now! http://podcast.rubyonrails.org/

Project Borat

Project Borat is a top secret development project here at PLANET ARGON. It’s a big project with high expectations, a fairly tight delivery schedule, an open ended feature set, and flexible priorities. The Client has extensive startup experience, expertise in the target market and some rather good ideas.

What is it? We can’t tell you. Who’s The Client? We can’t say. What does it do? Sorry. When will we see it? Nope.

How are you building it? Ahh .. yes. That’s something we will enthusiastically blog about in the months to come.

Check out Robby’s first installment at: http://rubyurl.com/BqJ

PLANET ARGON Documentation Project

David Gibbons, PLANET ARGON’s resident Systems Administrator, recently launched a new website for the PLANET ARGON hosting community, which hopes to bring together the PLANET ARGON staff and customers to develop some first class documentation for managing your hosting account at PLANET ARGON. Tutorials ranging from installing PostgreSQL to using Capistrano with PLANET ARGON have been created and maintained by many of our customers. We encourage all our existing customers to stop by and see how you can help out and hopefully you’ll learn a few tricks!

A big thank you goes out to the PLANET ARGON customers who have helped seed the project and to those of you who will continue to build upon it.

Visit the PLANET ARGON Documentation Project: http://docs.planetargon.com/

New Face at PLANET ARGON

The demand for Ruby on Rails development is growing, and PLANET ARGON is growing to meet the demand! Meet Brian Ford, the newest addition to our development team. He’s not on our about page yet, but in the meantime you can check out his blog at (http://blog.brightredglow.com/).

Upcoming Events

• Argon Express, June 19-21—Portland, OR to Chicago, IL http://www.theargonexpress.com
• RailsConf 2006, June 22-25—Chicago, IL http://www.railsconf.com

Until next time—

The PLANET ARGON Core Team

Robby, Allison, Jeremy, David, Jason, Peat, and Brian

“It is not the strongest of the species that will survive, or most intelligent. It is the one most adaptable to change.”

- Charles Darwin

Last week I posted, Agile development begins within…, which referenced some bullets from the book, Practices of an Agile Developer. Since then, I have taken a little more time to read a bit further in the book. With books like this, I tend to jump forward and backward, so ten leaps further might put me on page two. In any event, I found a few more things that I wanted to point out… and by all means, you should go buy the book.

In Chapter 3, the authors, Venkat Subramaniam and Andy Hunt, discuss some ways to feed your Agile developer brain.

side note: while typing this… a huge bee just snuck in through my office window… where was I…

• Learn iteratively and incrementally. Set aside some time every day for catching up. It doesn’t have to be long, but it should be regular. Keep track of concepts you want to learn more about–just jot down a note when you hear some unfamiliar term or phrase. Then use your regularly scheduled time to investigate it further.

This is a very important aspect of being a developer in any environment. Otherwise, you’ll end up like that disgruntled guy who has been programming in the same language for 25 years and refuse to use tabs in a web browser. Trust me on this one. There are people like that… and it could be you!

The point that I liked within this is that you shouldn’t just wander off and figure out what it is that you’re not sure about. I believe many people have a tendency to immediately look up at their google search box in their browser and…well… google it.

Don’t! Schedule time to do it… otherwise you’ll end up learning about the Canadian farming industry. GTD it! ;-)

• Attend local user groups.

This is a no-brainer. Find a local Ruby user group… and start going each month. Perhaps your local Ruby user group meets more than once a month. :-)

Disclaimer: I’ve missed the last few meetings at PDX.rb. Bad Robby. :-/

I wanted to post more… but have since decided that it’s probably time for you to just go and purchase the book for yourself. :-)

When I got back from Canada on Rails, I found myself looking at a review copy of Practices of an Agile Developer ¹ sitting in our library. I haven’t had a chance to really dive into the book, but did take a few minutes to skim through a few sections that I found interesting.

Some bullets that I found useful.

• Don’t fall for the quick hack. Invest the energy to keep code clean and out in the open.

There have been times where I have found myself taking the quicker–well, it seemed quicker at the time–approach to solving an immediate problem.

• Keep your project releasable at all times. Ensure that the project is always compilable, runnable, tested, and ready to deploy at a moment’s notice.

This is extremely important when there are several people working on one project. Developers have their own schedules and when we make a commitment to push new changes to a production environment, it’s important to be confident that all developers and designers involved in the project are following the same rule… test-before-you-commit. When this rule is followed, you aren’t concerned that if developer A needs to leave work early that the work that she checked in is tested. This allows us to push new changes to the production server at the end of each day if all tests are passing.

• Develop in increments. Release your product with minimal, yet usable chunks of functionality. Within the development of each iteration, use an iterative cycle of one to four weeks or so.

This is something that PLANET ARGON has been practicing more and more. Our iteration cycle is limited to 2-3 weeks, no more (unless there is a good reason to). When we are able to look at a distinct set of deliverables, which take 2-3 weeks to plan, design, develop, test, demo, and deliver, we can build our cost estimates around the number of resources that we be necessary to achieve those well-defined deliverables. It might only take 2 developers and a designer part time for those 2-3 weeks and we can adjust our cost estimates accordingly.

• Write code to be clear, not clever. Express your intentions clearly to the reader of the code. Unreadable code isn’t clever.

When Jeremy and I began working with each other last Fall… within a day of working around each others code… we decided to build a style guide for all of our code. This style guide has evolved over time… but the core principals remain. Keep your code… readable.

“Remember your code is for a human first and a computer second.”

- Martin Fowler, Refactoring

As I continue to review the book… I’ll post more thoughts. :-)

---

1. Practices of an Agile Developer, Venkat Subramaniam and Andy Hunt, The Pragmatic Programmers, 2006.↩︎

Last week, I gave a live presentation to ~250 people, which was basically me walking through the process of using Ruby on Rails to talk to a legacy database¹. For my example, I used the Dell DVD database. the PostgreSQL version. You can review some comments about my presentation by reviewing this entry on the blog of Ryan Davis. I wrapped quite a bit of the database in a few minutes and then showed what another 45 minutes of work could do with Rails. I’ll tarball that code and post it online soon.

Alex Bunardzic found it practical. I’ll take that as a compliment. ;-)

Earlier, I noticed this blog entry by Chris… where he said, “PostgreSQL also seems to be growing more briskly among the database category, while MySQL declines modestly. I guess that’s good news for Robby.” What exactly made me happy? This bullet made by Tim O’Reilly on Radar in his post, State of the Computer Book Market, Part 2.

“A surprise to many may be the s*trong growth of PostgreSQL, up 84% over a year ago*. We’ve also been hearing some signs of growth in the Postgres market from our “alpha geek” radar, with reasons given including better support for geo data, and better handling of very large data sets. New companies like Greenplum and EnterpriseDB have also brought a little focus to this market. We’re updating our PostgreSQL book, and watching this market closely.”

That’s awesome! Go PostgreSQL!

Then to my surprise, I was contacted by CRN (again) to get my thoughts on MySQL’s awesome storage-engine plugin system. which showed up a few hours later in this article. The writer of that article managed to goof my last name (Robby Hill?)… and hopefully that gets resolved soon. ;-)

As I said at Canada on Rails in front of 250 people, “I find databases… sexy.”

(free desktop wallpaper!)

Why Rails? Why PostgreSQL?

Rails.. that’s a no-brainer.

PostgreSQL? Well.. they have compatible licenses… no dual-license smell when your trying to sell your application as a complete solution… and as Rails is database agnostic. there is no reason not to give PostgreSQL a try.

Who uses PostgreSQL on Rails?

• CDBaby
• Shopify
• PLANET ARGON (on almost every project we work on…)
• you…?

If your using PostgreSQL on Rails… email me. I’d love to hear and share your story on my O’Reilly blog, like I did with Derek Sivers and Jeremy Kemper of CDBaby a few months ago, which you can read here.

again… I find databases sexy.

If your a PLANET ARGON hosting customer… you can follow these instructions to install PostgreSQL on your PLANET ARGON hosting account.

1. According to the Rails convention (and by me)... any database created pre-Rails or doesn't follow the conventions is considered legacy. ;-)↩︎

I’ll be posting stuff in the next few days about acts_as_legacy. For those not at Canada on Rails. I announced a small project that I’m going to be working on.

Acts as Legacy!

Here are my slides… up til I tried to do a live demo. ;-)

# Inventory model
class Inventory < ActiveRecord::Base
  acts_as_legacy :table_name => 'inventory',
                 :primary_key => 'prod_id',
  
  has_one :product, :foreign_key => self.primary_key
  
  column_alias :quan_in_stock, :stock
            
end   

Let’s try something a little different…

# SalesPerson model
class SalesPerson < ActiveRecord::Base
  acts_as_legacy :table_name => 'sales_person',
                 :primary_key 'sales_p_id',
                 :column_alias => 'sales_p_'
                 
  validates_presence_of( :name, :email, :phone ) 
end

# usage....
SalesPerson.find( 7 ).sales_p_name
=> 'Nigel'
SalesPerson.find( 7 ).name
=> 'Nigel'

The Slideshow

• Sneaking Rails through the (Legacy) System (quicktime)
• Sneaking Rails through the (Legacy) System (flash)

…Jeremy posted his slides as well. :-)

Here I am at the very first Ruby on Rails-related conference. My first passport stamp!

We’re half-way through the first day and as luck would have it, I’m starting to feel ill. Am taking a short break from the conference to catch up on some rest after opting to hang out with some great people last night. About twenty of us went out last night, which ten were speakers. There are a few photos up on Flickr.

This morning started with DHH giving a 90-minute keynote about the what Rails Core will be focusing on. It went well and I’m excited to hear that they’re going to break out some pieces into plugins. Goodbye, Pagination and Web Services!

David also had some kind words for people who don’t get and/or appreciate the Rails way of doing things…

Joe O’Brien followed him with a talk about Service-Oriented Architecture with Rails.

I’m going to catch up on some rest, work on my few slides and head back to the conference shortly. :-)

Check out the lastest pics on flickr from Canada on Rails.

In a recent article titled, Just Build It: HTML Prototyping and Agile Development on Digital Magazine, Garrett Dimon writes,

“You need to temporarily suspend any notions that prototyping is always throwaway work. If you approach it as throwaway work, it will be. However, if you approach it with the intention of keeping it, you can create modular code that can be reused.”

I disagree. :-)

I’m not a HTML web designer, but when building applications, a prototype should be looked at as a process in which you agree that what is built will and should be thrown away.

Why?

When you are in prototyping mode… you should be very aware of the fact that it is a prototype. This is your chance to take shortcuts, break the rules, get creative, and express your ideas on a piece of paper, in plain HTML, or perhaps you may even run ./script/generate scaffold to spit out some code that you know will not be used in a production application later on. The goal here is to figure out what direction you want to take the project and get the client to sign off on these ideas… not to build reusable and modular code. If you’re building a prototype with the goal of reusing it than it’s likely that you’re spending too much time doing it.

Just Toss It

While you might not physically toss your application into a nearby trash can, you should aknowledge and remove any attachments that you may have that suggest that the prototype was a waste of time because no reusable artifacts came out of it. It’s the ideas that are expressed here that make this time valuable. Perhaps you don’t need a prototype phase… this would mean that you know exactly what you are about to develop. If you go the route of prototyping and find it to return nothing useful… than imagine how you’d feel if you just started developing and determined that you really missed an important requirement a few weeks later.

“The physicist’s greatest tool is his wastebasket.”

- Albert Einstein

The shortcuts that you should have taken earlier have likely created too much technical debt in your code. A fresh start should be the next step. Prototyping is part of the development process but the moment you allow yourself to think that you should reuse some of the prototype in your application is when you begin to become too attached to the notion that your prototyping phase was a waste of time end energy. Go into the prototype phase knowing that reusable artifacts are not the goal of this phase. Throw it away. ;-)

“Every act of creation is first of all an act of destruction”

- Pablo Picasso

Keep The Lessons and Ideas

You don’t need to rm -rf the_prototype but you should be very honest with both yourself and your client that the prototype phase is a way to quickly express an idea or process in a both a technical (and often) visual manner.

Prototyping Generates Confidence

Clients have (many) ideas. I hate to be the one to break it to you, but it’s almost certain that they are not as confident in you as you would like to believe. Confidence evolves over time and should be nourished on a regular basis. Their ideas are important to them and they are paying you to be part of the execution of those ideas. If you even remotely sense that you are not confident in their ideas… tell them this. Prototype their ideas. It could save both you and your client a lot of time, money, and resources in the long run… especially if an idea proves to be too complicated to execute.

Ideally, this is when you both agree that this idea is a good idea and that you both understand how it will be executed. This is both a good and healthy process. :-)

Document your learnings, the changes presented by both your client and yourself, and then revisit your Use Cases.

What you are about to build is that much clearer now. This feeling of clarity is exactly why you created a prototype. Remind yourself of this.

Always Start Fresh

Now that the client and you have come to an agreement about what is to be developed… the next phase should begin.

rails the_real_app

…and remember… don’t be afraid to revisit prototyping again. If an idea is not clearly defined yet, whip up a new prototype and see what comes of it. Just keep it out of your code base…. and if it’s already happened… please Refactor. ;-)

Like I said… I am not a HTML person… reusing the colors, graphics, and html artificats that you worked on might be useful… but modular code shouldn’t fall out of a prototype.

However, prototyping is a good idea and I highly encourage it.

Prototyping can also be extremely fun!

Similar Post(s): Keeping the Code Organic, The bitter-sweet taste of agnostic database schemas

While working on certain section in my book, I find myself coming across areas of the Rails documentation that could use some love. Most of the patches that I’ve submitted recently have been for pieces of Active Record that doesn’t get enough exposure… such as Reflection and Observer. I have been running a cron script on my development workstation to keep track of the latest docs… and decided that our team could use this… and then went one more step and decided that I would just make it available online as well. Caboose also does this. but I want to style ours in the near future. :-)

See: http://edgedocs.planetargon.org for bleeding edge Rails docs!

I was playing around with an application from script/console and all of a sudden… my Observers just stopped working. It took me a while to figure out that when I would call Dispatcher.reset_application!… it wouldn’t reload config/environment.rb where I have defined the observers.

I really don’t like that this is the current implementation for invoking Observers and adding them to the controllers is not kosher with my (do-it-in-script-console) approach.

The current solution?

# app/models/foo_bar.rb
class FooBar < ActiveRecord::Base
end

FooBarObserver.instance

… there needs to be a better way!

First of all, I would like to thank all of you who took a moment to gather around the campfire with me and share your stuff. That was much appreciated.

So, I started playing with the idea of logging in unit and functional tests and I quickly realized that calling logger.info wasn’t an option. What’s the deal-e-o? Before I gather up my posse and conspire a train hijacking, I decided that I would see how quickly I could solve my problem before I called you all out to the Rio Rails Grande for an old-fashioned shoot out. Ya know, the kind that results in a Bon Jovi song and a little blood.

You’re all in luck because:

• A) my holster was eaten by my dog
  and
• B) I found a quick solution to clean up this logger situation.

Okay… are you ready?

I know… this is totally groundbreaking!!!

Open up test/test_helper.rb and add the method… logger.

# other stuff at the top of the file... just 
# look down below at def logger
class Test::Unit::TestCase
  self.use_transactional_fixtures = true
  self.use_instantiated_fixtures  = false

  # here... look here! right below this
  def logger
    RAILS_DEFAULT_LOGGER
  end
end

Save that and pick up your pistol…

The next step is to call the logger method in your unit and functional tests.

def test_the_obvious
  logger.info( 'asserting that 1 is 1' )
  assert 1, 1
end

I posted this on Rails Weenie as well.

Wow. I didn’t want to be the last one to mention on their blog that Rails 1.0 is out! (like 2 days ago… I’m so behind on stuff…)

Kudos to Rails Core team!