Main

Ruby For Rails

Coming from a PHP and Perl world, I've been working on learning Ruby on Rails since I joined VeriSign. Started writing an app awhile ago, but ran into not really finding a good succinct guide of how to go about it. Do you write your own SQL or use migrations and why is there no good guide to a one-to-one-to-one relationship of models, views, and controllers versus what I see being done in Rails apps? I never really got into the books Agile Web Development with Rails: A Pragmatic Guide or Programming Ruby: The Pragmatic Programmers' Guide. Both seemed to expect I already had a solid basic understanding of Ruby and Rails. I found a variety of tutorials around the web, but each contradicted the last. I saw the review of Ruby For Rails on Slashdot a few days ago and it looked interesting. Bought it overnight off of Amazon, had it shipped up to Portland where I was for a few days, and dug into it that night; it seems to be the exact book I was looking for.

It starts with a nice introduction to Rails, why it exists, what it does, and how it builds upon Ruby. It tells me enough to get started, but not too much to confuse me. It gives clear recommendations of how to get started and explains why it is making the recommendations that it does. It starts with a demo application, building the database schema, the models, the controllers, and the views. Then two chapters later revisits the app and adds to it.

So I know I'll get back to the Agile Development and Programming Ruby books, but I really recommend you take a look at Ruby For Rails if you’ve been like me and frustrated about figuring out how to get started.

07/21/06 | permalink | comments [0] | trackbacks [0]

My Identity on Rails

Mike Graves and I will be speaking at RailsConf on Friday. I am looking forward to three fun filled days in the windy city.
I don't want to sound like I am a programmer or a seasoned developer. I am not! But I have always been a hacker -- dangerous enough to build functional prototypes but not quite at the level of building full fledged applications. Big fan of working prototypes where end users can experience the solution first hand rather than see it in powerpoint slides. As a product manager in my previous life, I preferred building working wire frame prototype than writing long and detailed PRDs or MRDs. I feel it is important to involve the end users early and often. And in many cases the end users are not expert programmers, product managers or QA testers. They cannot take the leap from a powerpoint slide to the real system that will be delivered on their desktops. I like to keep things simple, focus on the end goal and not get too wrapped up into the weeds before an idea is vetted out. I feel it is important to experiment with different approaches before settling on a long term road map. All this is easier said than done, especially when building a small working application is an effort measures in "weeks". That's where you do a reality check and start compromising. I was looking for a "week-end" solution to prototyping. And then I discovered Ruby on Rails a few months back...

Continue reading >>

06/22/06 | permalink | comments [0] | trackbacks [0]

Forward Looking Design Decisions

I wrote about the Identity necklace and did get some comments about the post. From a user standpoint, it is clear that carrying different IDs around is an annoyance, but there seems to be wide variation in how willing people are in putting up the inconvenience. From an application standpoint, there is a significant difference between retrofitting an existing system to inter operate with other systems and designing systems from the ground up to co-exist with other applications and services. The former can be a much involved problem based on the complexity of the existing system. As for new applications in the early stages of their development, it is not too late to make interoperability as a "must have" design goal.

Continue reading >>

06/20/06 | permalink | comments [1] | trackbacks [0]