Saturday, March 31, 2007

Updating domain names is a trip...

It's easy to forget just how vast and complex the Internet is... easy, that is, until you put your new domain name in place and request that the Domain Name System (DNS) and all it's routers and servers recognize that new name.

We're all used to the Internet being 'instantaneous'... right? Quick response and all that depending, of course, on the speed of your pipe. Well, to update all the millions of routers and servers that are the Domain Name System takes "24 to 48 hours" (that's called 'propagation delay' in DNS-speak) according to the folks who administer the system. What they really mean is that within 24 to 48 hours, things will settle down and your domain can be reliably accessed. Until then, your experience may vary... and I do mean vary.

Briefly, here's what I experienced:

8:33am -- Started obtaining the domain name I wanted. This was done thru 1and1.com, my main ISP (they do good work, IMO).

12:10pm -- Started setting up DNS pointers (domain name is registered thru 1and1, but will be served by railsplayground.com This requires changing the 1and1 setup so that the domain is serviced by railsplayground's name servers).

1:04pm -- Got the name server information from railsplayground

2:02pm -- changed the server names on 1and1

At this point, my new domain is officially being served by railsplayground... but when I type in the address in my browser, all I get is the default for my domains... essentially an 'under construction' display.

4:00pm -- Typed in my domain and actually got my webapp!

4:53pm -- Unable to ftp to my new site using the domain name

5:00pm -- New domain works just fine

6:00pm -- Unable to access the new domain

And son on into the evening...

I'm speculating that the 'found' or 'not found' scenario occurred because at different times, the route to my new domain changed, and I might get to a router/server that still hadn't been updated... fascinating.

So be prepared to learn a lot of new stuff, make some mistakes, and wait...

...and when your new domain is actually up and running, it's quite a rush!

Friday, March 30, 2007

Houston: We have liftoff...

Well... I managed to get everything transferred from my development environment to the online site for 'real world' testing. Several glitches along the way:
  • Of course, all the email configuration changed, and that involved reviewing some FAQs and emailing tech support. The process was fairly confusing when setting up the ActionMailer::Base.server_settings in the config/production.rb, but I finally got that straightened out (with a fair amount of help from the folks at RailsPlayground.com). Along the way I forgot that relaying is a no-no, so had several emails bounced.
  • There's also the question of what to put in the "from" field (models/notifier.rb) when actually setting up the email, and that's where the "no relaying" came in: I had to use an email address from railsplayground to make that happen although that's only temporary: eventually, it has to be a valid email address from my domain.
  • For now, I'm just manually transferring the information (using FileZilla) from my development machine to RailsPlayground and -- of course -- that leads to problems. I forgot to run db:migrate the first time, then I failed to update my production configuration, then I had to deal with the email configuration, then somehow one of my controllers wound up in the config/ directory(?)... but all-in-all, successful. This makes it clear that I have to start using svn and (possibly) Capistrano...
Finally worked through all that, and I'm now able to test the site on the web, instead of in my development machine, and have a few of my friends bang away on it.

Production ActionMailer configuration:

ActionMailer::Base.server_settings = {
:address => 'localhost',
:port => 25,
:domain => 'railsplayground.net',
:user_name => 'myname',
:password => 'mypassword',
:authentication => :login
}

Development ActionMailer configuration (using the free SMTP server mentioned previously):

ActionMailer::Base.server_settings = {
:address => "mail.mydomain.com",
:port => 25,
:domain => "localhost",
}


BTW, the folks at RailsPlayground.com do a really nice job of Ruby on Rails hosting. For $5/month, you get a site (single server; no multiple mongrel's), plus access to subversion and Trac (which I'm just starting to set up... lots to learn there!). And... their email tech support is VERY responsive. I give them a question and usually have an answer within 10-15 minutes. Bravo!

Wednesday, March 28, 2007

ActionMailer rocks!

Once I got past the 'out of date' situation, it turned out to be pretty easy: the main change in ActionMailer that I can see is that instance variables have been replaced with methods (seems to be lots of that happening in the Rails world, such as @session, @flash, etc... being upgraded to methods) and the handling of variables into the body method is more like other methods.

The biggest challenge was getting smtp operating on my windows machine. Thanks to a post on Ruby on rails: Talk (which I can no longer locate), I downloaded the free SMTP server from www.softstack.com. It was a quick download/install and the only tricky thing was configuring ActionMailer. What I used to get it running is the following, in config/development.rb:


ActionMailer::Base.delivery_method = :smtp
ActionMailer::Base.server_settings = {
:address => "mail.mydomain.com",
:port => 25,
:domain => "localhost",
}


And... drum roll please: there is now built-in spam filtering on the Rails wiki... hooray! Many thanks to whoever made that happen :-)

HowToX...

I recently found that the Rails HowTo pages are being updated and reorganized... very nice!

"Note: This page is out of date with current API"

I want to add ActionMailer to my app, so I got the Rails wiki and look up the ActionMailer page. Unfortunately, the first sentence: "Note: This page is out of date with current API" leaves a lot to be desired from my perspective.

I see this more than I would like on the Rails wiki... nice to have a pointer to the API (which as I've said before is a great reference), but it's not necessarily helpful to nubies who want to get an quick introduction on how to get started and then dive a little deeper as they progress.

Sunday, March 25, 2007

Dealing with the 'no breakpoint' problem...

This morning was spent trying to find a way around the "breakpoint not supported' in this release of ruby... as a nuby, I'll definitely need the debugger to help me figure out what's going on.

After much searching in the forums, I found a Google Groups thread that seemed to capture what I was looking for. I followed the recommendations and am a little farther along than I was before, but two hours later, I still don't have the debugger working. Here's what I've got so far:

>>Install the debugger package (works just fine; no indication of the problem with overlaying 1.2.2 modules presented in the thread)
gem install ruby-debug-base
>>Modify the code to be debugged (Note the use of 'ruby-debug-base'; using 'ruby-debug' generates a file not found error)
require 'ruby-debug-base'
Debugger.start
...
debugger

At least this gives a clean compile, but there's no breakpoint generated that I can see.

More as I get it to work...

Friday, March 23, 2007

Well, the docs leave something to be desired...

Yes, there is 'documentation' for the standard library, and digest is one of those included. However, as it states in the intro to the library, the docs are created by volunteers, there aren't too many volunteers, and there are lots of things to be documented.

At least the lack of documentation is documented: if the name of the library entry is bolded, then it has good docs; if it's in italics, it doesn't.

digest is in italics.

I guess this is to be expected for a young environment. There was a comment on the mephisto blog recently by Rick decrying the up-and-down nature of Rails development (he called it cyclothymic).

Sigh...

Found docs for digest/sha1... and more!

I figured it had to be somewhere, and it was: the Rails standard library documentation website.

There's also documentation for the Ruby core library as well.

More on documentation... or lack of it?

Funny that I mentioned in my last post about documentation (or the lack of it for some elements of the Rails)... it just came back to haunt me.

I want to encode some data, so naturally digest/sha1 seemed to be the natural starting place. It's already required as part of login_generator, a straight forward way to add users & passwords to your application (Note that this is on the Ruby On Rails wiki, and this page, although workable, suffers from the lack of wiki gardening mentioned in a previous post.)

Anyway, I started looking for documentation about the methods and operation for digest/sha1 -- so far no dice. It's not in the Rails API (didn't expect it to be there) and so far Googling the topic hasn't lead me to any sites that make the basics available. Yes, there are lots of comments about SHA1 scattered here and there, but nothing definitive.

Sure wish I could go to a place like Perl's CPAN and find all this stuff -- it must be out there somewhere, but finding it is a challenge so far.

Answer: I don't know...

Well... now my session[:variable] works... I still don't understand why it does, or why sometimes it treats session[] as an array versus a hash.

Now, Rails has a fantastic suite of documentation. You can see the entire API, with examples, at api.rubyonrails.com. Not only can you find all the files, the classes, and the methods that are included in Rails, you can also click thru and see the associated source code. GREAT!

However, I have yet to find a comprehensive overview of the session manager: what files it uses, what the options are, how it works, ...

Hopefully someday this will become clear.

Wednesday, March 21, 2007

When is a session not a session?

OK... this is strange. Rails maintains a session hash so that you can store your state.

In one part of my code, I write:
session['user_id'] = User.find_by_login(params['user_login']).id
logger.info "Login! - /#{session['user_id']}/,/#{session['user_login']}/"

and that works just fine.

In part of another module (a plugin which works just fine before the change), I write:
@#{singular_name}.user_id = session['user_id']
and that fails with the error:
can't convert String into Integer
#{RAILS_ROOT}/vendor/plugins/ajax_scaffold_plugin-3.2.4/lib/ajax_scaffold_plugin.rb:283:in `[]'

Which says to me that it doesn't like 'user_id' as the key into the session hash, but it's acting as if it thinks session is suddenly an array...?

But... the session dump shows that it's there:
--- 
user: !ruby/object:User
assets:
attributes:
id: "6"
password: 8b2f204be0bad5668fd1c89f8f25b5ea4106f057
login: rich
user_login: rich
return-to:
user_id: 6
asset:
:sort:
:page: "1"
:sort_direction: asc
flash: !map:ActionController::Flash::FlashHash {}

Must be something automagical...

Tuesday, March 20, 2007

Another gotcha!

Just what I didn't want to see:
     Breakpoints are not currently working with Ruby 1.8.5
So much for that approach to identifying and solving a problem I've got with some new additions to my prototype!

Now... do I update only Ruby (I'm at 1.8.5-12 and the latest incarnation is 1.8.5-25) or do I go for the whole enchilada and upgrade InstantRails (from 1.5 to 1.6, which includes an upgrade from MySQL 4 to MySQL 5).

What the heck... I'll just upgrade Ruby and see how that works. I take a backup of my full Ruby directory, download the One-Click installer, and start it up. It says it can't install over an old version and that I'll have to uninstall it. I take a deep breath, click "OK", the uninstaller gets the go-ahead to delete the old installation... .and nothing happens. It just sits there waiting... and waiting... and waiting.

Can anyone recommend a good waggle dance parlor?

The more things change...

... the more you have to run to keep up.

So after many days of working through all the intricacies of what is admittedly a simple problem, I've got my prototype app up and running... and it does what it's supposed to do. That feels great.

However, I just learned that I'm already behind the times. AjaxScaffold, the UI plugin that I am using is "no longer supported" and the replacement -- ActiveScaffold -- is in RC1 status. And that doesn't feel quite so great.

This is obviously a problem with working on a platform that has not yet matured and is undergoing great growth & change. Sure, it's nice to have neat new things that do more, better, faster for you: that's a major element of progress. But we're surely going to have to deal with consolidation at some point in the future when all these nice, new features, extensions, plugins... prove their mettle (or not) and we settle down to the tried and true packages that really work.

Don't get me wrong: I am very happy with AjaxScaffold and with the support that the author, Richard White gave me. And I'll probably move up to ActiveScaffold at some point, depending on the added features and their importance to me. On the one hand, it's nice to have options; on the other, sometimes there are just too many options.

Reminds me of the description of how a hive of bees organizes themselves to have the greatest chance of finding the best nectar supply available (See The Wisdom of Crowds, by James Surowiecki). The hive sends out lots of bees ('foragers' they're called) to scout the area. As they find a nectar source, they come back to the hive and do a 'waggle dance', which somehow expresses the desirability of the nectar source that bee has found. The better the waggle dance, the more bees follow the forager to the source. According to Surowiecki (who quotes Thomas Seeley, author of The Wisdom of the Hive): "... a typical bee colony can search six or more kilometers from the hive, and if there is a flower patch within two kilometers of the hive, the bees have a better-than-half chance of finding it." Pretty impressive for 'dumb' insects.

Seems to me we're in the early stages of searching for great Rails enhancements; there are lots of 'foragers' out there, doing their best to develop the next indispensable package, and whoever does the best 'waggle dance' and collects the most followers, wins.

In many ways, that's the beauty of open source software. Just don't count on every bee finding the best nectar source for you... and be prepared to change when necessary.

Monday, March 19, 2007

Interesting observation about pluralization

As I was uploading my newly fixed test site out to a hosting site, I learned something else about this whole pluralization and convention thing that's a bit disturbing.

Let's say you have a controller asset_controller.rb and a model asset.rb. If you accidentally also have files assets_controller.rb and assets.rb, then you get a 500 error. Now I consider that pretty strange: if we're following convention and we have the correct files out there, then why do these non-conventional files come into play at all? Shouldn't they be simply ignored?

Seems a little fragile to me that two files that should be ignored cause the whole app to fail.

Problem solved!

I went back and rebuilt a new application from scratch (leaving out all the unnecessary details) and tried it out: AjaxScaffold worked perfectly! That's good.

I was still bothered by the fact that the old application was failing... I really like to understand problems and the solutions so that I can avoid the problem in the future. Finally, I realized that there was one thing I hadn't undone from the effort to get Streamlined up and running: they recommend a "monkeypatch" [I'm just quoting -- I don't know the genesis of the terminology] to prototype.js. They refer to a bug report - #6579 -- that caused problems in FireFox, which I'm using [see http://www.streamlinedframework.org/]. I can no longer find #6579, but there is a duplicate - #7657 - at http://dev.rubyonrails.org/ticket/7657 which says the same thing.

Well, once I removed the patch everything started working just fine!

Education for the day:
  1. Always undo EVERYTHING, even if it looks like a no-brainer [Note to self: figure out how to get svn installed on my windows box].
  2. Never trust version 0 code
  3. Be very careful about instructions to modify code that they didn't develop.
Now it's back to working on the application. Fun!

Racing along at 0 miles per hour

Another day of trying to get AjaxScaffold working and... nothing doing. It's partially working and stubbornly resistant to getting to 'done'. The display of the data comes up just fine, and I can delete records with no sweat. However, adding records or trying to edit existing records goes off into never, never land... the Ajax.Request happens, but never returns.

The developer (Richard White, www.ajaxscaffold.com) has been helpful, but now I'm down to simply rebuilding the application from scratch and seeing if that helps. Either way, I have to say that it's not a great testament to Rails' ability to 'quickly and easily' develop web applications... at least for me, so far. If the rebuild doesn't solve the problem, there's the big question of: what's going on here? If the rebuild does solve the problem, then there's a similarly big question of: why is this environment so fragile and what went wrong anyway? If I can't figure out the problem, who knows when it will hit again.

On a positive note, I really love the db:migration capability... you really can build your database in pieces as you learn about your application. And the ability to quickly and easily rollback a change is just dynamite.

Back when I finish the rebuild...

Saturday, March 17, 2007

More on [Aa]sset(s)...

I notice that I've still got "assets_helper" and I rename that to "asset_helper" and make sure that server is rebooted.... no change. So I dig a little deeper and notice that there's still layouts/assets.rhtml and views/assets. The key seems to be the layout file because now I've got my CSS goodies back...

BUT... now "Edit" and "Create New" no longer work...argh!

A little more of changing things one at a time and I find:
  • assets.rhtml yields no CSS but working create/edit
  • asset.rhtml yields CSS but non-working create/edit (this is the one that has the <%= ajax_scaffold_includes %>
TipSheetForBeginners doesn't help as there's no discussion about singular, plural, capitalization, CamelCase, underscores for Views... but it clearly makes a huge difference.

As I look around, I begin to understand why I'm confused over this particular convention: it seems that other folks don't get it right, either. This is part of the installation instructions:

Notice that they say "users", not user...

I do some testing and find that typing in something like:
ruby script\generate controller Asset
works just fine; the caps are converted to lower case. And typing in something like:
ruby script\generate controller CamelCase
also works fine: CamelCase is converted to camel_case.

But I'm beginning to reconsider my initial positive reaction to the "convention" argument... it may be a convention, but (a) it's not as easy to use/remember as I figured it would be [although I presume I'll get more used to it as time goes on] and (b) it seems as if there may be some unintended consequences in some cases of not following the conventions. Might explain some of the inexplicable (to me) challenges with this simple app.

More fun tomorrow :-)

Assets, assets.... or is it asset?

Well, I got AjaxScaffold to display at least the first page... nice. However, whenever I click on "Edit" or "Create New", the spinner comes on and nothing happens. This is the kind of thing that's been happening for the past couple of days: makes no sense to me. Anyway, I happen run across a page on the Rails wiki [wiki.rubyonrails.org/rails/pages/TipSheetForBeginners] that reminds me about the whole pluralization, capitalization, CamelCase convention "thing" and I decide to check this out one more time: I see a problem: I've got an "AssetsController", not an "AssetController"! (Never mind that I made that change a while back in the streamlined days to get something working... I'll go with convention).

I make the changes and there's definitely some progress: My Edit and Create New links now work, but all the formatting has been lost - it's now just a plain jane page. Looks like the CSS has been lost in the changes (or should that be 'change'?).

I restart mongrel, but that doesn't fix it... two steps forward, one step back.

What I (re)learned today:

1. Some conventions take time and effort to learn. No matter how "neat" or logical it seems, the conventions on tables, models, and controllers is NOT completely -- or even partially -- intuitive: my fingers and brain just do not automatically get things right. And sometimes things seem to work but really don't and they're a result of all this switching back-and-forth that Rails does automagically for me. To borrow from the author of TipSheetForBeginners said: "Things I ... have to look up every ten seconds" aren't all that productive.
2. Rebooting servers is more important than you might believe. The buzz is that Rails development environments are neat because everything is automatically re-loaded for you so it's easy to test. Well, it ain't necessarily so, as I've learned through much trial and error. Some things require that you reboot mongrel. I know now that changing plugins requires this (not documented anywhere that I can readily find) because there's some initialization required for the plugins. I've also found under other circumstances that a reboot seems to clear things up... for no apparent (to me) reason.

Note to self: Carefully crafted screencasts may look good, but there's always something that you're not seeing.

Friday, March 16, 2007

Ruby on Rails - the background

So... I'm about four weeks (part time) into trying out Ruby on Rails to see how good it is and if I can use it to develop some web-apps. Certainly the hype was powerful, so I decided to give it a whirl. I started with several books (in no particular order: "Build Your Own Ruby on Rails Web Applications" [Lenz], "Agille Web Development with Rails" [Thomas, Hansson], and "Ruby for Rails" [Black]) I give it a try.

After some fits and starts I get a very simple, one table application up and running on my development system... although it took me longer than that to figure it all out, once I've got the process down, I really can put a simple webapp up in one hour: create the controller; create simple views with scaffolding, create the database table through migrations... pretty slick.

InstantRails for Windows is downright fantastic [instantrails.rubyforge.org]... makes the job of getting all this stuff installed pretty simple: and it works, too! I start off with version 1.4 and life is good.

I also install RadRails [www.radrails.org... down as I write this] because it wasn't packaged with InstantRails until version 1.5 as I recall. It works fine, although my fingers are still tuned to vi commands. The ruby plugin for gvim [www.vim.org] is pretty slick, but without a directory tree, it's downright tedious to load/save files so I decide to make the switch .

Unfortunately, RadRails isn't so cooperative. Whenever I try to upgrade the software (I'm at version 0.7.2, but attempting to udpate only results in an error message:
'RadRails (0.7.2) requires plug-in "org.eclipse.core.runtime (2.1.0)", or later version.'
I don't want to spend the time researching this and note it for the future. However, it does make me wonder a little about what I'm getting into.

As I'm reading/trying things out, I find that:
1) the rubyonrails wiki [wiki.rubyonrails.org] is being heavily spammed by bots, and sizable chunks of what I'm looking for are nothing by junk. I try to go back thru the history and find the information I want, manage to make some changes, but in a few hours, the spambots have returned. There are pleas on the site to add some security, and there are good intensions, but the problem continued. I still go back there to find things, but I don't expect that all is good there. Too bad; nice idea and some good content.

The other problem is that much of it is outdated... as Rails develops, a fair piece of the content is being obsoleted Sometimes it's posted there; sometimes not. For a nuby, in particular, that makes life quite difficult because you don't know what's right or wrong except by trying things out... and that can take a LONG time to figure out.

The other problem is that material in the books is outdated, as well (even if they just were published... Rails is moving - fast). I spent a fair chunk of time (several days worth) trying to get acts_as_taggable running, based on the comments found in Lenz' book. I finally figured out that there was a much later version that had many more features and I got that to work. However, there were at least two blogs/forums that claimed that acats_as_taggable was deprecated and there was another, more general gem that should be used.

Another example: the login_generator gem. Been around a while, works fine. documented on the wiki.rubyonrails.org site... lots of deprecated code (or so says RadRails).

I searched for and found what was reported to be a better UI scaffold called streamlined [www.streamlinedframework.org] and worked on that for several days. Finally gave up: it sort of work on FireFox and worked better on IE6, but I never could get everything to work out right and I personally didn't like the way they handled pop-ups... so it was back to the drawing board.

I'm currently trying out AjaxScaffold [www.ajaxscaffold.com] -- so far, I like the more subdued interface and there's LOTS of documentation and a full online demo, so we'll see how this works.

My impression so far: this may be a great web development environment (I like a lot of the structure and ideas behind it), but it's not for the faint of heart.