free RoR book download: build your own RoR app replied by friarminor @ Fri, 25 Apr 2008 07:16:03 -0000

friarminor — Fri, 25 Apr 2008 07:16:03 -0000

Andrew,

You may also visit Satish’s rubylearning.com for free online course on ruby. He also points you to other learning materials that will surely help any newbie rubyist.

Best.
alain

Keeping up with the best Ruby blogs replied by friarminor @ Fri, 25 Apr 2008 07:10:26 -0000

friarminor — Fri, 25 Apr 2008 07:10:26 -0000

Hello!

I have been spending quite some time now searching the ruby universe and I’d like to share these new ones I just found out;
http://rubyflow.com and http://whatsupinruby.com

Best.
alain

Ruby class methods replied by woods @ Fri, 15 Feb 2008 14:08:54 -0000

woods — Fri, 15 Feb 2008 14:08:54 -0000

I was experimenting with Ruby class methods this morning, and wound up with a fairly lengthy demonstration script. What do you think? Did I miss anything or get anything wrong? Anything you don’t understand?

http://blog.westarete.com/2008/02/15/exploring-...

Rails' Architecture replied by Andrew @ Thu, 14 Feb 2008 03:30:28 -0000

Andrew — Thu, 14 Feb 2008 03:30:28 -0000

At this meetup, Scott and I started talking about really understanding Rails’ architecture, from a conceptual point of view. After a bit of searching, I came up with this blog post on Rails’ architecture: http://cfis.savagexi.com/articles/2007/09/05/ra…. Unfortunately, this post talks a lot about design patterns, etc. that don’t make a lot of sense to me. Does anyone have a more… primitive explanation of what all this means?

Heroku.com replied by Busterdog @ Sat, 09 Feb 2008 22:45:38 -0000

Busterdog — Sat, 09 Feb 2008 22:45:38 -0000

I would like an invite. I registered, but it is taking a while.

Idea for a RoR plugin replied by Andrew @ Wed, 30 Jan 2008 03:36:54 -0000

Andrew — Wed, 30 Jan 2008 03:36:54 -0000

The RoR plugin that would let you write your css files in ruby (erb, ie style.css.erb) which would compile to css. That way, you could write perfectly standard css code, and it would output several css files that are quirks compliant.You could make several stylesheets like layout.css.erb and tabs.css.erb and so on… and once you’ve out your app in production, it would flatten all of them into one file, and minify it.

Another blog, and a great tutorial on REST concepts replied by Andrew @ Tue, 29 Jan 2008 08:12:19 -0000

Andrew — Tue, 29 Jan 2008 08:12:19 -0000

An idea just struck me: I think with all the RESTfulness, rails might be evolving from an MVC to an RV (resource-view) framework. What do you think?

Keeping up with the best Ruby blogs replied by Andrew @ Sun, 27 Jan 2008 03:53:51 -0000

Andrew — Sun, 27 Jan 2008 03:53:51 -0000

Recently, a subreddit was created specifically for ruby: http://ruby.reddit.com . It should be a good source of information.

Another blog, and a great tutorial on REST concepts replied by Andrew @ Tue, 01 Jan 2008 20:26:16 -0000

Andrew — Tue, 01 Jan 2008 20:26:16 -0000

In trying to wrap my head around rest concepts, I came up with the following table that sort everything nicely (for me, anyway):

http://docs.google.com/View?docid=dgn2nsft_27c2…

Does this make sense? Is there a better way to describe and categorize these things? Disclaimer: I plan on buying the O’Reilly RESTful Web Services book; maybe there’s a much better way to think about REST in the book.

Heroku.com replied by gr8bluesgtr @ Wed, 12 Dec 2007 15:26:06 -0000

gr8bluesgtr — Wed, 12 Dec 2007 15:26:06 -0000

That. Is. Awesome.

This is scary. Just the other day I was thinking to myself “Wouldn’t it be great if someone would think up a way to a CMS like ruby on rails application, where you create, develop and edit your application online instead of on your own desktop. And here it is. Wow.

Using Microsoft Access MDB files from Ruby replied by woods @ Fri, 30 Nov 2007 13:59:28 -0000

woods — Fri, 30 Nov 2007 13:59:28 -0000

Here’s a small Ruby script that I used to open and modify a Microsoft Access database file:

http://pastie.caboo.se/123692

I wrote it to hack around a limitation with Adobe Photoshop Elements 3.0 where it can’t move your entire photo library to a different location properly. I found out that they use the Microsoft Access database file format, and decided to use Ruby to modify all the paths in the database to point to the new location (I opened the file in Access first to figure out the structure and table and field names).

The script doesn’t use any non-standard gems. However, it does need to run on Windows, since it relies on Microsoft’s Jet engine library (the engine that drives access to MDB files) via the “win32ole” gem that comes with Windows Ruby distributions.

For reference, I did get it working with ActiveRecord via a whole other set of gems, but it’s not really worth the effort for a small project like this since one of the gems is problematic to build on Windows. Instead, I’m posting this simple version here. No ActiveRecord elegance, but no time spent on setup either.

I’m posting it here in case anyone finds it useful. I think it’s also a nice demonstration of Ruby’s versatility.

Heroku.com replied by Andrew @ Mon, 26 Nov 2007 01:21:50 -0000

Andrew — Mon, 26 Nov 2007 01:21:50 -0000

I just got an invitation to heroku (an instant rails hosting/online editing app). I was thinking we could try using it during ruby meetings, since anything you create/change is instantly live. Let me know if anyone needs an invite (invitees skip the waiting list).

Good RoR plugins replied by Andrew @ Wed, 21 Nov 2007 19:54:39 -0000

Andrew — Wed, 21 Nov 2007 19:54:39 -0000

Regarding jq4r,there’s another one called jRails

Links for SQL Tree Extensions, Mercurial VCS replied by woods @ Thu, 15 Nov 2007 13:18:44 -0000

woods — Thu, 15 Nov 2007 13:18:44 -0000

Cool, thanks for the links, Russ.

For everyone who wasn’t at the meetup last night, Russ recommended Mercurial as one of the better version control systems (VCS) for people who haven’t used a VCS before. Easy to use and understand, and doesn’t require a server at first—you can just download and start using it.

We got on the tree vs. nested set vs. “connect by” topic when Tony was talking about using nested sets vs. conventional trees in your database. Conventional trees (using a parent_id column that points back into the same table) are the obvious method for representing a hierarchy in a database, but the SQL language doesn’t provide any elegant way to traverse such a structure or select cohesive subsets of the tree. Nested sets are a functionally equivalent way of representing the data, and while they’re not as obvious or easy for humans to grasp, they match SQL’s capabilities well and allow for the types of queries that you’d commonly like to do on trees. Here’s Tony’s follow up in another thread which includes a link to a comparison of the two techniques.

Russ brought up the fact the Oracle (and PostgreSQL with a recompile) have an extension to the SQL language that provides the best of both worlds; you can structure your trees the “obvious” conventional way, and the language extension provides an easy and efficient way to then work with the trees.

Links for SQL Tree Extensions, Mercurial VCS replied by russ @ Thu, 15 Nov 2007 03:33:20 -0000

russ — Thu, 15 Nov 2007 03:33:20 -0000

Here’s a nice page that explains the Oracle “CONNECT BY” SQL extension, which lets you work with trees easily and efficiently:

http://philip.greenspun.com/sql/trees.html

Postgres has a connectby() function which does something similar, but unfortunately it isn’t built by default (it’s in the contrib/ folder in the Postgres sources).

Here are some links for the Mercurial version control system:

Homepage           http://www.selenic.com/mercurial/wiki/
Book               http://hgbook.red-bean.com/
Windows GUI        http://tortoisehg.sourceforge.net/
Subversion client  http://cheeseshop.python.org/pypi/hgsvn/

The first couple of chapters of the Mercurial book are an excellent read if you have time to go through them. There are also shorter tutorials on the Mercurial home page.

Part of what I said about the Mercurial Subversion client turned out not to be true. It can only “pull” changes from a remote Subversion repository, not “push” them back. To get changes back to the Subversion repository, you currently have to check them in with the normal svn client.

- Russ

Good RoR plugins replied by Andrew @ Wed, 14 Nov 2007 19:43:09 -0000

Andrew — Wed, 14 Nov 2007 19:43:09 -0000

Just read about the make_resourceful plugin; seems like it would be really useful for RESTful development. One gotcha is that it requires haml.

Good RoR plugins replied by woods @ Wed, 07 Nov 2007 15:50:03 -0000

woods — Wed, 07 Nov 2007 15:50:03 -0000

One more!

I know that someone mentioned jQuery as a good javascript library; an alternative to Prototype and Scriptaculous. I will definitely be checking jQuery out, since its syntax seems a little easier and more sensible.

One of the big downsides though is that Prototype and Scriptaculous are already tightly integrated into Rails with all sorts of helpful helpers. It turns out there’s a jq4r plugin that is starting to produce the same helpers for jQuery. Here’s the blog:

http://jq4r.blogspot.com/

Good RoR plugins replied by woods @ Wed, 07 Nov 2007 15:19:31 -0000

woods — Wed, 07 Nov 2007 15:19:31 -0000

Here’s another interesting plugin for creating custom find queries on your ActiveRecord models. This seems very concise, and would probably make for much more readable code in the end, even if your queries aren’t complex. I’m a big fan of creating custom methods for find queries, since something like

Post.find_recent

is more clear than

Post.find(:all, :order => "created_at DESC", :limit => 10)

I further like his convention of dropping the leading “find_” from the method name, so that “Post.find_recent” just becomes “Post.recent”.

http://www.pivotalblabs.com/articles/2007/09/02…

Good RoR plugins replied by woods @ Wed, 07 Nov 2007 00:24:11 -0000

woods — Wed, 07 Nov 2007 00:24:11 -0000

Going along with the versioning stuff, we’ve used acts_as_paranoid a good bit before, and while it has a couple obscure limitations, it works fine. Basically, this is a plugin that provides “undelete” support. It simply marks your records as deleted rather than actually deleting them from the table, and then overrides the “find” method to return only undeleted items by default.

This plugin is also an excellent read. I highly recommend reading and understanding both acts_as_paranoid and acts_as_versioned, whether you’re going to use them or not. They’re great structural templates for creating your own plugins and the code, while sparse on comments and documentation, is very well written. You’ll learn a lot about changing ActiveRecord’s default behavior and about metaprogramming.

Both plugins would be much easier to understand if they weren’t so configurable—the column names that they use are flexible, which makes the code less readable.

For the record, I believe that both plugins are written by Rick Olsen, who’s now the core member that’s responsible for much of ActiveRecord itself.

Good RoR plugins replied by woods @ Wed, 07 Nov 2007 00:17:39 -0000

woods — Wed, 07 Nov 2007 00:17:39 -0000

Regarding acts_as_versioned, the plugin for revision history, I’ve pulled it apart from top to bottom before and used it a good bit.

It’s fairly simplistic, and has its limitations. As such, I’d suggest reading it all and understanding it pretty thoroughly to make sure it does what you want and to make sure you understand the limitations. Also, there’s not any documentation for it, so you pretty much have to read the code to get full value out of it!

Here’s a brief explanation of how it works: Let’s say you have a table called “customers” that you want to version. You declare it to be “acts_as_versioned” in the model, and create a nearly-identical table called “customers_versions” in the database. The “customers” table will hold the current version of the data (as usual), and the “customers_versions” table now holds all of the old copies of the “customers” records.

Now each time you save a customer, the plugin will save a copy of the old record in the “customers_versions” table and increment the version number on the current table. Since the “customers” table is virtually identical to the one that you’d have if you weren’t using acts_as_versioned (it just has an extra column to tell you the current version for each record), ActiveRecord and anything else can use that current version and ignore the fact that this is a “versioned” table.

If you want to go get a previous version of the customer, the plugin simply looks in the “customers_versions” table for the same record that has the previous version number. It then generates a new instance of the model with that data and hands it back to you. If you save it, you’ll save a new version and essentially revert back to the old data that you requested.

That’s basically it. There are a couple other nice methods to help you traverse the history for a record and do some simple manipulations. It’s a pretty simple plugin, as versioning goes.

So what are the limitations? The plugin just saves a copy of all the record’s attributes into its history, without any regard for what those attributes mean. This works fine if you’re dealing with attributes that don’t have any special meaning to rails, like “first_name”, “title”, or “body”. However, it doesn’t work well at all for things like “contact_id”, or “position”. The reason is that those attributes refer to other records; records that might have changed since the last version was saved. If the old record is resurrected, and contact_id is no longer valid, or if the position of the neighboring records has changed (“position” is used by acts_as_list), then your referential integrity is going to be broken. You’ll call “customer.contact”, and you’ll get an exception since the old contact_id can no longer be found in the current database.

Versioning relational data is really hard. I’ve read big fat books on it (I can dig up the title if you really want it), and I have to say that it’s not worth implementing yourself unless it’s the point of the entire exercise—it shouldn’t just be a feature in your application.

So basically, if you’re using it to version unrelated data like wiki pages, you’re fine. You’ll get in trouble if you want to use it to version positional data (e.g. individual items in an ordered list) or relational data (e.g. a family tree).

Good RoR plugins replied by woods @ Tue, 06 Nov 2007 23:55:01 -0000

woods — Tue, 06 Nov 2007 23:55:01 -0000

Here are my usual suspects:

exception_notification – Mandatory for production. sends you an email every time an exception is raised.
rspec, rspec_on_rails – Easier, more readable testing than the default Test::Unit, in my opinion.
haml – Cleaner HTML/CSS, both in your views, and in “view source” in your browser.
annotate models – Adds a rake task that puts a description of the database table in a comment block at the top of each of your models.
redhillonrails_core – Provides support for foreign key enforcement in your migrations, among a couple other features. Useful for database nerds like me.
assert_request – Allows you to declare and enforce the method/params interface to all of your actions. This can make your application more secure, reduces validation code in your actions, and can prevent some obscure bugs when your views call your actions with incomplete/unexpected information.
atom_feed_helper – Makes it easy to create feeds for your indexes. Might be built into rails 2.0 now?

Those are in rough order of importance to me, with the top four being almost universal in my projects. The rest of them depend more on the app’s features and how robust it needs to be.

Sorry there are no links, but I procrastinated long enough on this reply! A quick google search should turn each of them up.

Maybe after the next meeting ActiveScaffold will be in there too…

Good RoR plugins replied by Andrew @ Mon, 22 Oct 2007 15:12:57 -0000

Andrew — Mon, 22 Oct 2007 15:12:57 -0000

I was wondering if we could list the plugins for RoR in this forum, that are useful? In particular, I was wondering about the plugin that lets you do revision history.

RoR Technical Questions replied by woods @ Wed, 10 Oct 2007 16:05:00 -0000

woods — Wed, 10 Oct 2007 16:05:00 -0000

Sounds like a great plan. I’ve really enjoyed that workflow before too, but just wound up there through a combination of luck and procrastinating on the hard parts: figure out what the user interface should look like, so you know what you’re building, for whom, and why. Then figure out the models for how you’re going to store the information and do the application logic. Finally, write the controllers to glue everything together (usually the most nebulous part), using your ideal URLs as a guide. Maybe do several iterations like that for each distinct chunk of functionality in the site. Neat. Maybe I’ll intentionally try for that workflow next time!

RoR Technical Questions replied by Andrew @ Wed, 10 Oct 2007 14:37:02 -0000

Andrew — Wed, 10 Oct 2007 14:37:02 -0000

wow… thanks for the help, guys! This confirms how I might want to proceed: finish making my interface mockups, think of good urls for them, then think about what controllers are needed.

Edit: I already have (most) of my models figured out.

RoR Technical Questions replied by woods @ Wed, 10 Oct 2007 14:12:59 -0000

woods — Wed, 10 Oct 2007 14:12:59 -0000

Hey Andrew,

Every view does need a controller. You can put static HTML pages in /public, but if it has ruby code in it, it will need to go in /app/views/#{controller_name}/. Note the path there—the controller/view relationship is a strict hierarchy in RoR, where each view belongs to one and only one controller. This is used to represent the default one-to-one relationship between controller actions and their views. Each controller action (public method of the controller) will automatically render its corresponding view in /app/views/#{controller_name}/#{action_name}.rhtml (or .html.erb if you’re on edge rails). You can and should think of each view as being a template for its corresponding action.

However, things get more nebulous (creative?) with models and controllers. Whereas the relationship between controllers and views is fairly strictly defined, the relationship between models and controllers is wide open. Any controller can and should call upon any model. How you organize your controllers in your application is completely up to you.

There are a couple guiding principles that help out a lot though. First of all, you don’t want your controllers to have a million actions. After my controllers start getting more than 10 actions, alarm bells start going off. Granted, each situation is different, and it’s ridiculous for me to mention a firm figure for the number of actions you should have in a controller, but I wanted to give you some idea of the range I’m usually thinking of.

Second of all, it’s considered good form to keep the controller actions themselves as short and succinct as possible, and push the guiding application logic down to the models, and any rendering logic up in to view helpers (also using view partials to reduce repetition). Here’s the original article on “Skinny Controller, Fat Model”, followed by an even more succinct writeup on the same topic on the Rails Way (same guy, Jamis Buck):

http://weblog.jamisbuck.org/2006/10/18/skinny-c…
http://www.therailsway.com/2007/6/1/railsconf-r…

So how do you decide what controllers to have in the first place? What do you call them?

If you’re designing an application using REST principles, then each controller represents a “resource” that people would want to access. For example, if you’re designing a bookstore, then you might very well have a /books controller (REST controllers are usually plural). People could list the books using a GET request to /books, look at a particular book using GET /books/23, and the admin interface would remove a book by issuing a DELETE request to /books/46. The actions that are available are generally limited to the standard create, show, index, update, delete, edit, and new, which is a feature of REST. Once you know the resource name and what it represents, you pretty much know how to use it.

Note that there’s no rule that your resource (controller) matches a model! For example, Amazon might have a /products controller, which would encompass their Book model, their HomeAndGarden model, and their Clothing model. The key is that they decided that it made sense to expose “products” as a single resource, so that’s how they designed their (hypothetical) REST controller. That controller’s actions would then be dealing with all the different models.

That said, in practice I find that many simple REST applications do wind up having a one-to-one relationship between models and controllers.

If you’re not doing RESTful controllers, then you have more flexibility. You can stick with the default scaffolding actions, or you can have entirely different ones. You can lay out your controllers however you’d like. You can have actions like /admin_interface/run_nightly_reports . At this point, how you lay out your controllers is largely a matter of taste and experimentation. On the one hand, you don’t want too many controllers, because then it gets cumbersome to reference them all in your links, because you’re always having to specify the controller (you don’t have to specify the controller in link_to params if the linked-to action is in the same controller as the current view). On the other hand, controllers with 50 actions can look and feel a bit ridiculous.

The tradeoffs in non-RESTful controller/action design are similar to how you’d design your module/function layout in a procedural program. A lot of times, the final guiding principle for me is how the URLs look and behave. Generally, when I’ve hit upon the right combination, the URLs make sense and flow between one another logically. Sometimes I’ll even start the whole process by designing all the URLs and their interplay first, and then figuring out how to implement them (I always do it this way for REST controllers).

Finally, you don’t have to settle on one controller design for your application. Quite frequently, we’ll have to settle for one non-RESTful controller in an otherwise RESTful application. Sometimes you run into views/actions that just don’t want to be shoehorned into CRUD. Hopefully the non-RESTful part is not a core part of the application though—it’s nice to have a consistent style of interface for the core functions.

Hope this helps, looking forward to others’ feedback.

Scott

Recent Posts in Ruby | State College Ruby Group