andyman’s posterous

• Jim introduced a term called connascense, which for software design purposes means the way two pieces of code are coupled, or two things that have to change together when one of them changes, in order to preserve correctness. There are different degrees of connascence:
  • Connascence of Name (CoN): where two components use the same name to couple, such as passing named parameters within a hash, or using  the name of a method or variable to refer to the same thing.
  • Connascence of Position (CoP): where the order matters, such as the order of parameters in a method call, or where positions in arrays are hardcoded. The coupling can be made more robust by converting this down to CoN.
  • Connascence of Meaning (CoM): using values to mean something for the two components. (Like "404" error code means page not found). These can be assigned to constants to somewhat reduce to CoN, but even in the assignment of values to constants, there needs to be contranascence (where two components have to be different, in order to preserve correctness) between the values to that the same value isn't assigned to different constants that are supposed to be different.
  • Connascence of Algorithm (CoA): the two components depend on the same algorithm to work right. For example if there is a method that creates a checksum (add_check_digit) and a check method to verify that a checksum matches. Can DRY (don't repeat yourself) it out by having a separate method that does the algorithm, and having both these methods call that method. (CoA->CoN)

Loading mentions Retweet

I started learning Ruby on Rails programming language and framework about 6 months ago and have been using it quite extensively to develop my first Rails web application, Headmagnet. (I am a former Java and PHP developer)

Here are my miscellaneous thoughts and lessons learned on Ruby on Rails:

1. There is a learning curve to learn the Ruby programming language, and also one to learn the Rails framework. Everyday, I find features of Ruby, and features of Rails that I didn't know that I didn't know - which makes it harder to proactively learn.
2. Even with the learning curve, I could code stuff up a lot faster with Ruby on Rails than with Java (and I'm supposedly fast at Java), and much cleaner than with PHP. I wouldn't want to go back to Java or PHP, except when work really requires it.
3. There's quite a difference between doing Ruby on Rails the way you write Java or PHP, and doing Ruby on Rails the "right" way. The "right" way usually tends to be a lot less lines.
4. Too many old Rails tutorials are old and obsolete. There were big changes in Rails 2. Look for Rails 2.x.x tutorials. Although many of those tutorials were written for an audience for already knew Rails.
5. Having good and quick Ruby documentation and Rails API documentation in your bookmarks is indispensible. I'd recommend Railsbrain for downloading the Rails API docs for fast local access.
6. The production environment in Rails for Mongrel is MUCH MUCH faster than the development environment. (more than 10x faster). I didn't know this until too late in the game, after much optimization work had been done.
7. Named scopes are great, allowing you to combine multiple conditions and parameters for queries. I wish I knew about this one earlier.
8. There are tons of plugins and gems. The three I'm most thankful for are: will_paginate, restful_authentication, and jrails
9. As a proponent of separation of content, behavior, and presentation, I hate the javascript that Rails generates and embeds into the html. I love the convenience it offers though, that view methods like link_to_remote, or remote_form_for offer though.
10. Writing and testing custom Javascript to do stuff more "properly" can take a lot longer than just using Rails view helpers to generate the view. 
11. It's much easier to test models than controllers. You can also play with models easily thorough the rails console, and explore what you can do with them. I guess this is why they say to keep the controllers small, besides for reusability. I find the same with helpers.
12. Autotest sure helps with continuous testing. The Rails console is useful for digging deeper and playing around with models. It can be a bit distracting though, breaking the focus/flow when coding.
13. Slicehost is a great VPS for hosting Rails. Even if you don't use them, but want to set up an Ubuntu Linux server from scratch with a mail server, mysql, nginx server (a fast lightweight server), Ruby on Rails, and Mongrel Cluster (a bunch of Mongrel servers), they got awesome documents. If you do sign up with Slicehost, please use this referral.
14. There's an overhead for calling view partials, especially if you call it in a loop. Just don't go crazy breaking things down into a million little view partials if you don't need to. Its hard to work in editors with when there are too many files to flip/browse between to find the right place. Originally when developing Headmagnet, I broke views down into many view partials to make the site more AJAX friendly and convenient to use with RJS. But soon, I had dozens of little partials and it got hard to manage and read. Later on, I simplified and consolidated drastically, as well as just wrote custom javascript to take care of things more efficiently and more responsively.
15. The Rails migration features are quite useful, especially the incremental migrations where you are just adding a column to an existing table. Don't worry if you have a lot of those during initial development. You can consolidate them later if you want to. Just refer to the db/schema.rb as your reference for what columns are where.  Don't do like I did at first in using the migration files as my reference, and change old migration files to add new columns and indices and then drop, recreate, and remigrate. Just remember also that when you add new columns via migrations, it doesn't automatically update any tests. 

Loading mentions Retweet