Posted by Scott
Tue, 26 Jun 2007 22:41:00 GMT
It’s head-scratching discussions like this and this that make me thankful everyday that I’m a Rails developer.
Why are people wasting time on these questions that do nothing to deliver product to people? Everyone: try Rails! Now.
no comments
Posted by Scott
Fri, 15 Jun 2007 16:58:00 GMT
SoftwareDeveloper.com recently published Rails in Action: The 56 Best RoR Driven Sites. It’s worth checking out.
no comments
Posted by Scott
Sat, 09 Jun 2007 09:33:00 GMT
Recommended reading:
Rails Testing: Not Just for the Paranoid
no comments
Posted by Scott
Fri, 18 May 2007 03:01:00 GMT

I spent today flying over Colorado, Utah, and Oregon on my way to RailsConf 2007. Full reports on the next three days of geek speak to follow!
no comments
Posted by Scott
Wed, 09 May 2007 22:43:00 GMT
Some Rails programmers skip all unit tests that they consider simply “testing Rails”. I agree that you should not waste time writing unit tests to test that “validates_uniqueness” is working. It is.
Yet, I do like to start off creation of a new model with a simple test to ensure that I wired up everything correctly. Is the database table created as I expect? Did I wire up the right field names in the fixture? Did I have any typo in the model name? Did I accidently create the model in plural format (e.g. referral_visits instead of referral_visit)?
So, I create a simple test that some would consider is just testing Rails. I do it to test me!
Here’s one I wrote just now, for example.
def test_save
referral_visit = ReferralVisit.new(:account_id => /
referral_visits(:visit1_from_synap_link).account_id)
assert referral_visit.save!
end
A simple test like this gives you comfort that all is set up like you expected and it also helps get the test case juices flowing to encourage you to continue with the practice of test-driven development.
no comments
Posted by Scott
Sun, 29 Apr 2007 04:17:00 GMT
With the powerful object model that Ruby and Rails provide, it gets easy to forget there is (usually) a database behind it all. And that it is important to tune that database just like with any other application.
A large part of database tuning is index creation and except for making the ‘id’ columns a primary key, Rails won’t do this for you automatically. So it is important that you remember to create indexes for performance gain.
Indexes
How
Indexes are both the most common and most easily implemented database performance enhancer. Rails makes it easy to add indexes by way of migrations.
def self.up
add_index :accounts, :account_name
end
def self.down
remove_index :accounts, :account_name
end
Where
While indexes are syntatically simple to create in Rails, it still takes knowledge of effective database design to understand when and where to add indexes.
Here are the common sense candidates for indexing.
- Create indexes when a column is often in the WHERE clause and the column’s values are fairly distributed. For Rails: when an attribute is often on either side of an equal sign (’=’), that attribute’s database column should probably be indexed.
- Create indexes when a column is read as part of the WHERE clause much more often than it is written or updated. This is because everytime a value in an indexed column is written or updated, the database must take time to update the index as well.
- The distribution of column values is an important consideration. If a column holds only two or three values (such as a boolean value), then it is often not worth creating the index. Think of it this way, if the index only narrows the dataset down to “this half”, then it may not be worth the overhead of maintaining the index.
- Are there any columns that are read as part of before or after filters? A common example is authorization. Common authorization schemes have before filters on almost every controller. The before filter might authorize the user to access a record by comparing a session variable or portion of the url to a user and an account object. This means there could be (depending on caching activities) database queries against the users and accounts table at every turn. Even if your tables do not have millions of records, adding an index could cut the database time by tenths of seconds. That might not seem like much, but when you consider that an action might call authorization against several different models/tables, it can all add up.
If you do not have indexes in your Ruby on Rails app, go ahead and take some time now to add them.
no comments
Posted by Scott
Thu, 12 Apr 2007 23:32:00 GMT
From the O’Reilly Conference folks:
RailsConf 2007
May 17-20, 2007
Oregon Convention Center Portland, Oregon
http://conferences.oreilly.com/rails
A fourth technical track has just been added to the RailsConf schedule.
That means a limited amount of space has opened up for those folks who
didn’t get a chance to register before RailsConf first sold out in
February.
If you haven’t yet registered and would like to attend RailsConf 2007,
please register now at:
http://conferences.oreillynet.com/cs/railswaitlist/create/reg/
(If you do not already have an O’Reilly user account you will be required
to create on in order to register for RailsConf. When prompted for your
password, click on “No, I am new to O’Reilly.” When you have finished
creating an account for yourself you will be taken back to the RailsConf
registration page.)
Note: We are no longer accepting checks for this event. All registration
fees will need to be paid in full by credit card at the time the
registration form is completed.
RailsConf Keynotes Just Announced
Chad Fowler and Ruby Central have put together a stellar program, which
now includes four simultaneous tracks. They’ve also just announced some of
the keynote speakers presenting on the main stage this year:
Ze Frank, Comedic Digital Savant
David Heinemeier Hansson, Creator of Ruby on Rails
Dave Thomas, The Pragmatic Programmers
Avi Bryant, Creator of Seaside
Tim Bray, Co-creator of XML and Atom
More speakers are being confirmed every day.
Check out the entire list of
speakers and sessions on the RailsConf web site:
http://conferences.oreillynet.com/pub/w/51/speakers.html
Remember, seating is limited and likely to sell out very quickly. If you
haven’t already done so, register right away as this email does not
guarantee your seat.
We look forward to seeing you in May!
The RailsConf 2007 Team
no comments
Posted by Scott
Tue, 27 Mar 2007 05:56:00 GMT
Reviews for our small business lead management product, LeadsOnRails.com, are starting to come in. A new one today is not about the product, but rather about the product’s website. Bob Walsh, the man who wrote the book
on micro-ISVs and blogging
, and the author of this review, of the LeadsOnRails product site, made an important point that I want to make sure us Rails programmers get.
Bob says:
LeadsOnRails could have derailed (sorry) at this point by doing a laundry list of features, leading with the ultra sexy (to programmers), ultra cool (to programmers), fact it’s in Ruby on Rails; that it’s not a Web 1.0 app, but a Web 2.0 app (only programmers understand this), that it’s driven with clean URLs (I barely understand this), etc., etc., etc.
They did no such thing. They understand that while these features appeal to programmers, benefits – especially benefits couched in terms of what small business owners care about – was the way to go.
If we want to see Rails’ adoption rate grow, we need to be explaining why it and development methods associated with it (agile, rapid, test-driven, etc.) are good for business. Not just why it’s kewl.
no comments
Posted by Scott
Tue, 20 Mar 2007 18:14:00 GMT
LeadsOnRails is currently deployed on Rails 1.1.6. Yesterday I added Textilize/Redcloth to part of the program and found that paragraphs did not show up as expected. I could not get blank lines between paragraphs because paragraphs were broken only by
breaks, not
.
After a little googling I found this to be a common complaint and saw that there is a setting to specify hard breaks or not.
The simplest solution that seemed to work for me was to simply override the Rails implementation by putting this in helpers/application_helper.rb:
def textilize(str)
RedCloth.new(str).to_html
end
Is this dangerous in any way? Any reason not to do this this way?
no comments
Posted by Scott
Sun, 11 Mar 2007 18:53:00 GMT
GoDaddy DNS technical issues bit us and users of LeadsOnRails.com today.
DNS entries and your applications should be with the same people. That may be obvious to everyone else, but I learned the lesson the hard way.
I use Slicehost.com to host my Rails applications. SliceHost is great and highly recommended! And, even though they recently started offering DNS services, I just have not yet moved my DNS entries over from GoDaddy DNS.
GoDaddy is having technical issues today, preventing anyone from being able to reach one of my product sites (LeadsOnRails.com lead management software for small business). Frustrating for me and frustrating for users. Luckily it is a Sunday, but that is little comfort to anyone trying to use the system today.
So, I am now moving my DNS entries over to SliceHost. DNS entries is one area where distributed information makes no sense. It doesn’t help if Slicehost goes down, but my DNS entry is still there. It doesn’t help if GoDaddy goes down but my slice is stil there and no one can find it. So now, I’ll have all my eggs in one basket and that’s a good thing.
no comments