Entries Tagged 'Ruby' ↓

The dreaded “No such file to load — rubygems (LoadError)” came to me today. I recently installed some Python stuff, and I ran OS X Software Update. Either one could have been the culprit, but in this case it was the Python installation. Continue reading →

If you, like me, and like so many countless people, host a Rails site on DreamHost, sometimes you need to make a tiny change to the code. (sometimes a BIG change…) But the changes don’t seem to take effect! Well, they how and why about that is pretty heady stuff I won’t go into here, but I will tell you how to restart your app the DreamHost way!
Continue reading →

Like so many people fairly new to Rails, I encountered the situation where a requested page that doesn’t exist generates the dreaded 404 not found message. (the default Rails message doesn’t actually mention ‘404′ and it should, but that’s a different matter)

The simplest, graceful solution I came up with is this:
Create a route in config/routes.rb that redirects to a ‘catcher’ method in a controller. It doesn’t really matter which controller you use. Just make sure it corresponds to the route you write.
In that controller define a method called ‘catcher’ (or whatever jives with you). The catcher method simple populates the flash[:notice] with a message telling the site visitor that the page requested does not exist and then redirects to the home page.

It’s not the most sophisticated solution, but it does work and keeps the visitor at your site rather than being turned away by a cryptic message they may not understand. This way, they’re more likely to continue browsing your site! This is a good thing, because the average, every-day human who browses a web site is completely confused and disappointed by messages like 404, even though most have seen it at some point. Besides that, such messages make your site look bad to those visitors.

Of course this method could be made more comprehensive. You could include in the controller method, ‘catcher’, additional code to log the requested address and redirection. It may seem silly, and you could probably dump most of the log generated, but if you could determine that legitimate requests were coming in often enough for a particular mis-spelling or simply a particular page or url/uri, then you might want to actually create that page, or at least a route for it.

Here’s the code:

In config/routes.rb …

# This is a catch-all for routes that don't exist, visitor is redirected to home page.
ActionController::Routing::Routes.draw do |map|
    map.connect ':controller/:action/:id'
    map.connect '*path', :controller => 'home', :action => 'catcher'
end

In the corresponding controller (in my case, app/controllers/home_controller.rb)…

  def catcher
    flash[:notice] = 'Seems that the page you were looking for does not exist, so you\'ve been redirected here.'
    redirect_to :action => 'index'
  end

Sometimes I find myself creating database tables for something that doesn’t really need to be in a database at all. Think configuration. Say you build a CMS or a blog system of some sort, and then you want some simple data to be accessible without putting in a database. You don’t need all that over head for everything!

So, what to do? This is part of the Mystery of Rails Models! Just create a model. Continue reading →

Rails Model files are sometimes mysterious. What goes in them? I don’t always know!
But one thing does go in them: validations! Any data coming from a source outside of your Rails app should have validation applied to it to make sure it’s the kind of thing you want.

So you added your validation(s)? But when you go to try out your app and you enter something in a form or upload a file, the validation works and catches a mistake, but WHERE ARE THE ERROR MESSAGES?

Most validations come with some kind of default error message. You can also define your own like so:
validates_uniqueness_of :name, :message => " is already taken. Choose another name, wiseguy."

If you want your error messages or the default ones to appear, you need to have this in your view file:
<%= error_messages_for 'chicken' %>
(replace chicken with the name of the model file that is being validated. In this case, it would be chicken.rb in /app/models

If there is one model name in Rails that seems to be appropriate in almost every project it is Category. One thing every set of categories probably needs is a default. This could easily often be “uncategorized”. But wouldn’t it be nice to have it in the database from the beginning? You can do that in your migration, just be sure the code to populate the table comes after the end of the create_table block, but inside the self.up block. (you don’t need anything about it inside the self.down block, since that block will drop the whole table anyway)

class CreateCategories < ActiveRecord::Migration
  def self.up
    create_table :categories, :force => true do |t|
      t.column :name, :string
    end
    c = Category.new
    c.name = "Uncategorized"
    c.save
  end

  def self.down
    drop_table :categories
  end
end

I recently purchased the book, Beginning Ruby on Rails E-commerce : From Novice to Professional, from Apress publishing. I’ve been working through it and I have some good and bad to say about it.

First off, it is mostly well written. They style is clear and down-to-earth. That’s great. However, it spends a little too much time on test-driven development a little too early in the book, unfortunately with tests that do not all work. This is starting to be a trend too, which is disconcerting. Apress seems to have a habit of poor technical reviewing before publishing. Not as bad as WROX, but not as good as Pragmatic Programmers (who is?).

All in all, it’s not a bad book, but I still think the SitePoint book is best for beginners. This book seems to assume beginners to web development but quickly does things that are fairly tricky in Ruby. Not good for beginners, at least not without explanation.

The biggest problem with the book is it’s inconsistencies. They begin by saying Ubuntu Linux is their baseline installation for the book, and even mention using the Trail command-line tool (though not really practical or useful) and then all web-browser screenshots are Safari (os x). The inconsistencies don’t stop there, but I don’t want to go on in much detail.

What is important about this book? There are some nice chapters on hooking up your online store to a checkout/payment system! Pretty important and left out of most Rails books.

When creating your Rails application, model names do need to correspond to to table names. That’s it. Controllers can be named anything that makes sense. Views should be named for actions defined in the corresponding controller (methods defined in that controller).
The only thing you have to care about is the name of a model when accessing it from a controller or view, and the associations of models.

Yep, file_column IS the way to go for now. RMagick works like magic with it. What’s more, file_column does things basically the way I wanted to do them, storing things in the file system in a logical, directory heirarchy. It doesn’t use RESTful routes for the directories, at least not with the setup I’ve got, though I’m sure it could. Regardless, REST is not a priority at the moment; file_column works! So now I’m on to other things with my app!

The one thing I did notice, is that file_column seems to make it’s calls to RMagick via the model rather than the controller. This is quite significant I think. This indicates to me, something I was already suspecting: RMagick calls work better from the model than from the controller.

I’ll just have to confirm that theory at a later date, when I try to recreate my own upload & resize code.

After much consternation with writing my own file upload code, I have settled with the file_column plugin for Rails.
Why? Well, my uploads were working fine, but I was having weird problems with my RMagick resizing results.
I will not say don’t do it yourself. I say do it, and I will still try to write my own upload and resize code, but I need a stop-gap measure to get my app going for now. Definitely writing your own is the best way to learn and understand what’s going on, and that is something you should do!

I have to say, that file_column should not be the first thing you attempt if you’re still new at Rails. Make sure you understand how the CRUD features generated by scaffold code work, and that you can hand code your own (even by cheating and looking at other code, nothing wrong with that, if you understand it) and then you can focus on file_column. Like all plugins and all code written by somebody else, it has a particular maddness (er.. method..) that you have to stick to. That said, file_column keeps it pretty simple and straight forward for you.

Great stuff.

Couldn’t get attachment_fu to work… (> <;)