| Back to Rails |
[Oct. 20th, 2009|02:11 pm] |
So, I'm doing RoR work again, and I'm hitting those annoying little issues that bugged me the first time around.
Today, it's the fact that I have to setup separate validations to handle nils/blanks. IMO I should be able to do this:
validates_numericality_of :elevation, :allow_nil => false
Now, this works. It validates that elevation is a number and it doesn't allow nulls. The problem is that, in the case of a null, it still sets the error message to "not a number". That's not what I want. I want "can't be blank". And I *only* want that error message. To get that effect I have to setup two separate validations, and add a conditional to the second one.
validates_presence_of :elevation
validates_numericality_of :elevation,
:unless => Proc.new{ |site| site.elevation.blank? }
What a hassle.
Update: Anonymous user posted a better solution. See the comments. |
|
|
| My biggest issue with the Rails/Merb merge |
[Dec. 29th, 2008|12:06 am] |
My copy, my beta copy, of Programming Rails 3rd edition, is already obsolete.
In other news I ran "Rails" + "Merb" through some anagram finders, since I thought a new name (or at least a code name) would be in order for Rails 3. Here were a few of my favorites:
* Rare Limbs
* Ramble Sir
* Real Brims
* Marble Sir
* Barr Slime |
|
|
| Weird session bug |
[Nov. 5th, 2008|08:09 am] |
Yesterday I spent about an hour tracking down this bizarro bug I had seen occasionally in the logs but hadn't figured out:
TypeError (singleton can't be dumped):
C:/ruby/lib/ruby/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/session/active_record_store.rb:82:in `dump'
I was finally able to reproduce this consistently. It seemed if a new user tried to log in for the first time they would smack into this bug. But, if I created their user account in advance then all was well. I eventually came to the conclusion that it was the session handling.
Further inspection revealed the culprit. I had previously implemented a feature request that new users from a specific group be given automatic visitor access (instead of simply being denied access). So, the basic code structure looked something like this:
user = User.find(uid)
if !user and login_group == 'some_special_group'
user = User.create(visitor)
else
# Deny access
end
session[:user] = user
Except, it turns out that while a user object returned by User.find is compatible with the session object, one returned by User.create was not compatible with the session store, and I'd get the mysterious "Singleton can't be dumped" error.
Why? Couldn't tell you. My workaround is to run User.find again for new users and assign that user object to the session. |
|
|
| Easily amused? |
[Oct. 24th, 2006|08:26 pm] |
I have to say that this post is the most vapid blog entry I've seen from DHH yet. So, now we can replace 'end_form_tag' with just 'end'.
Wow. Thrilling. I wonder what's on TV right now. I can't wait to start yoga next year.
Wake me up when they add support for bind parameters in the Oracle adapter. |
|
|
| Organizing my stylesheets |
[Aug. 25th, 2006|02:34 pm] |
I'm back to working on $RAILS_APP full time again. I think my HTML/CSS skills have finally reached the point where I can design a layout that doesn't suck. They're not great, mind you, but at least I don't want to gouge my eyes out any more.
One thing I've learned the hard way is to better organize my stylesheets. My original 'organization' was rather haphazard and too granular. I literally started losing track of which stylesheet applied to which view.
So, I've come to a decision: there shall be one stylesheet per controller, and that shall be applied to each corresponding .rhtml file. I will properly wrap all tables, etc, in their own <div> tags and provide class names as appropriate. Thus, users.css will be used for show.rhtml, list.rhtml, etc, for the Users' view. The <div> tag id's and class names will be used to delineate between .rhtml files, where necessary.
Keep in mind that I'm using a relatively light amount of CSS in general - less than 1 page of text per stylesheet.
How do other folks organize their stylesheets? |
|
|
| Burned by plurals in Rails AGAIN |
[Aug. 18th, 2006|08:12 am] |
| [ | Tags | | | rails | ] |
| [ | mood |
| |  aggravated | ] |
If I waste another minute because I accidentally wrote "belongs_to :users" instead of "belongs to :user" I'm going to scream. GAH!
I'm not sold on the whole pluralization thing. I know my table names, so just let me use them as-is, dammit!
Yes, yes, I know you can configure this, blah, blah. Hey, it's my blog and I'll whine if I want to! |
|
|
| Rails Parody |
[Jun. 11th, 2006|11:20 am] |
| [ | Tags | | | rails | ] |
| [ | mood |
| |  amused | ] |
| [ | music |
| | Blue Oyster Cult - Heavy Metal (Black and Silver) | ] |
I just saw this today. Heh. |
|
|
| Feature removal in Rails? |
[Apr. 3rd, 2006|09:43 pm] |
This strikes me as odd. Actually removing functionality to speed up tests is, quite frankly, bad. Who cares how fast your tests run? If they're that slow, you probably have way to much data in your fixtures. It definitely smells of a decision made by someone overly influenced by MySQL, i.e. someone who's not too keen on, you know, real foreign key enforcement.
Anyhoo, I came across this because I'm hitting FK violations in my delete tests, despite loading the fixtures in advance. But it only happens in some controllers. I don't get it. Weird stuff. Whatever. I'll just do some simple deletes through the web interface and verify that they're gone using psql.
Ugh. |
|
|
| Help Vampires! |
[Mar. 23rd, 2006|01:50 pm] |
Not to be confused with "Help! Vampires!". ;)
Anyway, this article is a good read. Funny, yet true. |
|
|
| Just print it? No |
[Feb. 16th, 2006|09:34 pm] |
| [ | Tags | | | rails | ] |
| [ | mood |
| | cynical | ] |
So, I got yelled at a little bit today for not reading all of the documentation from a section of api.rubyonrails.com that I should have. Well, I hate reading manuals online, mmkay? Especially when they're big. I did look, but I missed it. Sue me.
I mentioned that I would like to have "Rails: The Complete Reference". You know, one of those big, fat books that isn't much more than an API walk.
"Well, just print it. Duh".
Except, that doesn't work. First, the text strays off the right edge if it's too wide, instead of wrapping. I'm not sure if this is an IE/Windows issue or not. Smells like a frame issue of some sort. I don't have any other way of printing from work at the moment, so I can't check. Second, it inlines the source code. I don't know how to stop that and, even if I did, I don't want to see "view source" links sprinkled throughout the document.
If the API were to come in a nice, pretty PDF format without all the unwanted links, that would be swell. |
|
|
| RailsConf 2006 - Second time's the charm |
[Feb. 14th, 2006|02:15 pm] |
| [ | Tags | | | rails | ] |
| [ | mood |
| | cheerful | ] |
Just in case you're not paying attention, they opened up another 150 slots for RailsConf 2006. My company agreed to pay the conference fees and give us (myself and one co-worker) Thursday and Friday off, paid. So, we registered ASAP. I can handle paying the travel and lodging. I already reserved my hotel room, too. :)
So, see you there. :-D |
|
|
| No RailsConf for me |
[Feb. 12th, 2006|10:03 am] |
I was making some headway in convincing my boss to send a coworker and myself to RailsConf this year, only to find out it sold out in the first week.
Bummer.
I suppose I could always try OSCON or RubyConf 2006. |
|
|
| On Tables and Users |
[Dec. 7th, 2005|01:27 pm] |
One of the more enjoyable aspects of this Rails project I'm working on is that I have absolute control over the schema. It's so rare that I have this opportunity. I'm usually forced to deal with an already existant schema. I am basing it somewhat on the old schema, but I've changed quite a few things.
Anyway, one decision I'm pleased I made was *not* creating a separate password column in the User table. I made the decision early on that I would use LDAP authentication. I did this for a few reasons:
* Managers often don't remember to tell the app managers that so-and-so left the company, and so that user could still potentially login to the app after they've gone. In fact, user validation sweeps are one of the side jobs I have to do from time to time here at work. HR, on the other hand, is downright fanatical about removing people from LDAP once terminated.
* Users typically have to deal with many applications. What happens when they have many passwords to remember? The vast majority do one of two things - they use either their userid or LDAP password as their password because they're lazy. I'd rather they use their LDAP password, which at least has some minimal standards of difficulty.
* I don't have to deal with encrypting and decrypting password data on the fly.
* Using LDAP provides a double layer of security - they have to exist in LDAP *and* in my database.
Another issue to consider, though, is the scenario where the user hasn't left the company, but no longer needs access to the application? Do you set the password to NULL? Leave it alone? Well, I don't have a password column, so I just delete the user from the table, right? Wrong.
In my case the solution is another column called "active", which is a simple boolean column. Why have this at all? Why not just delete the user? The answer is simple - history. Users are responsible for certain events (in my case, DSLAM turnups). We can't simply eliminate the user from the table, since we need to retain who did what and when, regardless of whether they still have access to the application. It would also be a FK constraint violation.
In short, this means that a user should be (almost) never be deleted from a database. The only exception would be users who didn't have any associated events, though that would almost certainly be limited to read-only users, test users, etc. |
|
|
| The Rails Progress Report: The Good, the Bad, and the Ugly. |
[Nov. 16th, 2005|02:41 pm] |
I'm having a ball so far with Rails on the new project. Here's a rundown on how things are going so far.
The Good:
* It's easy to get Rails app up and running fast
* Rails' Model, View and Controller tie together in an intuitive fashion
* The ability to make and see changes on the fly in Rails is awesome
* Rails is feature rich, including TDD features
* PostgreSQL has worked out well so far
* Guy Decoux put out an updated pl/ruby for PostgreSQL 8.1 and it seems to work well
The Bad
* The Rails book doesn't cover config/environment issues very well
* PostgreSQL has no "create or replace table"
* Generating default scaffolding is problematic when you don't want to use the default table naming scheme
* Views in Rails seems to get confused by foreign keys referencing columns in tables with identical names.
* The traffic on the Rails mailing list and #rubyonrails is too heavy for my liking
The Ugly
* Attempting to do ldap searches via ruby-ldap causes WEBrick to core dump in 1.8.2 (but apparently fixed in 1.8.4p1).
Of the issues I listed in "The Bad", none are too serious. The traffic issue is unavoidable. In the case of the foreign keys issue, I just prepended all column names with "table_", except for the id. Only the WEBrick core dump caused by ruby-ldap is a major concern, but Ruby 1.8.4 will be out soon. Of course, there's still the "make" issue to work out for Solaris, but I'm hopeful. |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| |
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
djberg96's journal
confused
contemplative
blah