It was supposed to be easy: just read the Capistrano manual make a little magic with your deploy.rb file, and you're in business. Sounds wonderful, doesn't it? Would that it were so easy.
The documentation (manual and elsewhere) makes it clear that Cap'ping to a Windows server is pretty challenging... Cap is made for *nix machines. However, I didn't find anything about a Windows client, other than the statement that "you must have an svn client installed on your machine." I did -- RapidSVN, TortoiseSVN, and the svn client embedded in the Aptana IDE.
However, once I got to actually attempting to deploy my application, it failed every time with a "no such file or directory" error message and a reference to the repository trunk itself. No amount of hair-pulling (it was a VERY long weekend), searching the web, emailing a few contacts helped... not matter what I did, it continued to fail in exactly the same manner. I even built a new development environment on another machine just to make sure it wasn't some brain-dead Windows issue: no dice.
Tuesday night, I went to the local Ruby on Rails Meetup and got the answer from another Windows-based developer Hob Spillane -- thanks!
So... drum roll please... here's how to get Cap working on your system:
You MUST have the svn binaries installed on your Windows client machine and in your execution path before Cap can deploy successfully -- the GUI clients do not provide what Capistrano needs. The binary you need depends on the version of Apache that your provider is running: 2.0 and 2.2 require different binaries.
For my Apache 2.2, I went to the subversion download page, and clicked on the svn-win32-1.4.4.zip link, installed it in /usr/bin/svn/bin, added that directory to my PATH statement and -- voila! -- Capistrano deploys like a charm! (When I went to the download site, there was only the choice of a zip file, no setup.exe. That may change by the time you get there.)
If your version is Apache 2.0, go to this download page and chose the appropriate setup.exe or .zip file.
Nice...
Thursday, July 19, 2007
Saturday, April 28, 2007
Of presentations and security...
So... I had the chance to give a presentation to the East Bay Ruby on Rails Meetup Group (that's the Oakland part of the San Francisco Bay) about what it's like to be a nuby. Bottom line: the first step is an easy one, but after that it's a doozy (see the presentation here).
During the great discussion that followed, one of the group pointed out that production logging is at the :info level and that's not good -- information entered into the site is stored in clear text and therefore not as secure as it should be (people still have to hack the site, but obviously that's not good enough).
So I set about closing this loophole and also getting the sessions out of file storage and into the database where they are protected via password.
This should have been simple and easy, but it turned out to be really tricky: an example of things not being exactly what they seem to be. Here's the deal.
I had previously updated my environment.rb file to customize the logger, having found this code snippet at snippets.com.
For some reason I couldn't get it to work as I reported in an earlier post. I had finally gotten it to work (I think it may have had to do with restarting my server, but it's unclear) and life was good: I had smaller logs and didn't have to wait so long for it to load when I was doing some testing.
However, what I found was that -- once this new logger was running -- I couldn't change the logging level (normally done with config.log_level in environment.rb or environments/production.rb). I wanted a logging level of :error (instead of :info) so that the operation of the site wasn't so readily stored. I tried a number of things, including the following code in environment.rb:
but that didn't work... things kept getting logged at the :info level in production -- definitely not good.
I also tried setting it with config.logger.log_level = :error but that didn't seem to work either.
I finally -- after much futzing around -- decided simply to remove the new Logger snippet and see if that would do the trick: and it did. Now I can set the logging level in production (in the environments/production.rb file) with a simple config.log_level = :error.
Someday I'll go back and try to understand what happened. For now, the system is operating the way I want it to and I've moved the config.logger snippet to my environments/development.rb file so that I have that capability in development where I really need it.
Fortunately, the sessions question was as easy as 1-2-3:
1. Run the command:
rake db:sessions:create
2. Run the migration:
rake db:migrate
3. Change the production.rb file:
config.action_controller.session_store = :active_record_store
and we're in business!
This is really an analogy for my experience with Rails: some of it is subtly obscure and challenging (like the Logger situation), while some of it is wonderfully intuitive and easy (like the Sessions situation).
Let's hear it for more of the latter!
During the great discussion that followed, one of the group pointed out that production logging is at the :info level and that's not good -- information entered into the site is stored in clear text and therefore not as secure as it should be (people still have to hack the site, but obviously that's not good enough).
So I set about closing this loophole and also getting the sessions out of file storage and into the database where they are protected via password.
This should have been simple and easy, but it turned out to be really tricky: an example of things not being exactly what they seem to be. Here's the deal.
I had previously updated my environment.rb file to customize the logger, having found this code snippet at snippets.com.
config.logger = Logger.new("#{RAILS_ROOT}/log/#{ENV['RAILS_ENV']}.log",2, 131072)
For some reason I couldn't get it to work as I reported in an earlier post. I had finally gotten it to work (I think it may have had to do with restarting my server, but it's unclear) and life was good: I had smaller logs and didn't have to wait so long for it to load when I was doing some testing.
However, what I found was that -- once this new logger was running -- I couldn't change the logging level (normally done with config.log_level in environment.rb or environments/production.rb). I wanted a logging level of :error (instead of :info) so that the operation of the site wasn't so readily stored. I tried a number of things, including the following code in environment.rb:
if ENV['RAILS_ENV'] == 'production'
config.log_level = :error
else
config.log_level = :debug
end
but that didn't work... things kept getting logged at the :info level in production -- definitely not good.
I also tried setting it with config.logger.log_level = :error but that didn't seem to work either.
I finally -- after much futzing around -- decided simply to remove the new Logger snippet and see if that would do the trick: and it did. Now I can set the logging level in production (in the environments/production.rb file) with a simple config.log_level = :error.
Someday I'll go back and try to understand what happened. For now, the system is operating the way I want it to and I've moved the config.logger snippet to my environments/development.rb file so that I have that capability in development where I really need it.
Fortunately, the sessions question was as easy as 1-2-3:
1. Run the command:
rake db:sessions:create
2. Run the migration:
rake db:migrate
3. Change the production.rb file:
config.action_controller.session_store = :active_record_store
and we're in business!
This is really an analogy for my experience with Rails: some of it is subtly obscure and challenging (like the Logger situation), while some of it is wonderfully intuitive and easy (like the Sessions situation).
Let's hear it for more of the latter!
Thursday, April 12, 2007
Applicaton is live!
Well... I finally got the application out there, up, and running. It obviously still has much work to be done, but the basic secure functionality is there.
4MyPasswords -- a secure well-lighted place to store you passwords and other confidential information (e.g., Frequent Flyer numbers; credit card numbers; ...)
Feedback welcome!
4MyPasswords -- a secure well-lighted place to store you passwords and other confidential information (e.g., Frequent Flyer numbers; credit card numbers; ...)
Feedback welcome!
Sunday, April 8, 2007
A nice plugin for secure sites...
I realize that I didn't comment about the ssl_requirement plugin by DHH (David Heinemeier Hansson, the Rails guru) . It's really a very nice approach to requiring that certain actions be accessed only through SSL/https and letting the other actions through. Once I found it, it was quick and easy to install and worked flawlessly.
However, I couldn't use it: the fundamental controller for my application uses AjaxScaffold (AS), which provides all the CRUD/UI stuff that I needed and allowed the customizations that I wanted (albeit with some learning curve; see a previous post). AS uses a veritable galaxy of actions to perform its magic and there was no way (I tried) to identify the right actions individually. What I really needed was a way to identify a controller instead of an action that required SSL. I briefly considered and then as quickly rejected the idea of attempting to enhance the plugin. It's a small plugin and seems to be pretty straight-forward in operation, but I'm just not at that level and I wanted to focus on my basic application. Maybe another time...
I did have one other question regarding the plugin. Reviewing the code, I saw that it works by trapping and then redirecting the actions that you want secured. I wonder if that might not be too much overhead for a site with lots of traffic? I just don't know at this point.
However, I couldn't use it: the fundamental controller for my application uses AjaxScaffold (AS), which provides all the CRUD/UI stuff that I needed and allowed the customizations that I wanted (albeit with some learning curve; see a previous post). AS uses a veritable galaxy of actions to perform its magic and there was no way (I tried) to identify the right actions individually. What I really needed was a way to identify a controller instead of an action that required SSL. I briefly considered and then as quickly rejected the idea of attempting to enhance the plugin. It's a small plugin and seems to be pretty straight-forward in operation, but I'm just not at that level and I wanted to focus on my basic application. Maybe another time...
I did have one other question regarding the plugin. Reviewing the code, I saw that it works by trapping and then redirecting the actions that you want secured. I wonder if that might not be too much overhead for a site with lots of traffic? I just don't know at this point.
Saturday, April 7, 2007
Customizing Rails and rabbit holes
Some things are easy in Rails... others are definitely not!
I mentioned in an earlier post that I'm using AjaxScaffold for the UI... I like the looks, there is lots of functionality, a fairly active forum, and the author (Richard White) has been very helpful. It's a great plugin.
With all that said, it's still been a challenge to get everything working that I wanted. The problem as I see it is "documentation": too much of it and not enough of it. This makes improving your expertise in Rails quite a challenge and will, IMO, keep nubies nubies for longer than I would like. Here's what I mean.
On the surface, AjaxScaffold (AS) has a great deal of very good documentation. There is, for starters, the ajaxscaffold.com website mentioned above. Then there's Richard White's home site, where there are a number of excellent articles describing AS. There's also Scott Rutherford's blog at blog.caronsoftware.com: Scott clearly knows AS well and also does an excellent job of writing about AS. Finally, there's the Google Groups AS forum, with many fine developers working on, describing, and customizing AS.
On the surface, you would think that customizing AS would be a piece of cake: just search the places mentioned above, get the relevant posts, and you're off to the races. Well, it doesn't work that way... at least for nubies. And that's a shame because it just makes getting productive in Rails that much more difficult.
Here's why the current approach doesn't work well.
1. There is no single place where someone can go to learn about AS -- either for an overview or for all the details. Things are scattered all over the place. That's not to say that there aren't some great tutorials; but usually those tutorials deal with only the most basic of information. This is like many of the gee-whiz Rails videos that I've seen: you learn how to do the simplest of tasks (which are admittedly much easier than without Rails), but you don't learn how to get to the next level. The first step is easy but watch out for the next step... it's a doozy.
2. Good information coexists with not-so-good information. As a nuby, you can't always tell the difference, and you can go down rabbit holes a bit too easily. Like Alice, it takes a long time to find your way back.
3. Good information is incomplete. This is the "Curse of Knowledge" in action (see the book "Made to Stick" by Heath & Heath... awesome!). I found good suggestions in a couple of different places, with code samples no less, but the surrounding "..." (meaning fill in the blanks here) turned out to be the key information that I was missing.
4. Information is out of date. Rails is changing and changing fast. So are the supporting tools, such as AS. On the one hand, that's really great. It's always nice to see new features being added. On the other hand, it's hard to keep up with all those changes. At some point, you may have to decide to give up on new features for some stability in your own development environment. For example, AS first appeared as a generator and then it migrated to a plugin. That's great, but how do you separate comments about the generator from comments about the plugin: it's not always clear which is which. Another rabbit hole to get lost in.
5. New stuff gets added that you aren't using. Now there's a new upgrade called ActiveScaffold. It has a lot of great new features and I'm sure that it's even better than the old AjaxScaffold. It has a few features that I would like to have, but -- as a nuby -- I'm a little too slow at learning this stuff to just jump on the new bandwagon. So now there are comments about ActiveScaffold that can send me down more rabbit holes. Fortunately, Richard gave this a new name and a new website, but it could (and was originally) referred to as version 4 of AS. Were that the case, I'd be in even more trouble.
So what's the problem here? It's that there's no one place to go to where you can learn "all" about AS... and I'm getting the impression that this is not just an AS problem. I'd really like to see one place where there is solid, up-to-date documentation about the package and all the options, along with examples.
I keep wishing for something like Perl's CPAN, the central repository where all (or at least most) contributed Perl modules reside, and where complete documentation is supposed to (and usually does) live.
So how am I doing with the customizations I want? I am making progress... I spent several hours digging through the code (amazing stuff, that AjaxScaffold) and I finally have the create/edit form displaying the drop-down box as desired.
I still don't have it saving the information properly, but I'm sure that's "just a little more" code-digging, rabbit-holing time to resolve and then I'll have this piece of the application up and running.
BTW, if you're interested in the solution to my AS quest, I'm documenting it as I go in the forum, under the title: Getting a drop-down to work in the create/edit form.
I mentioned in an earlier post that I'm using AjaxScaffold for the UI... I like the looks, there is lots of functionality, a fairly active forum, and the author (Richard White) has been very helpful. It's a great plugin.
With all that said, it's still been a challenge to get everything working that I wanted. The problem as I see it is "documentation": too much of it and not enough of it. This makes improving your expertise in Rails quite a challenge and will, IMO, keep nubies nubies for longer than I would like. Here's what I mean.
On the surface, AjaxScaffold (AS) has a great deal of very good documentation. There is, for starters, the ajaxscaffold.com website mentioned above. Then there's Richard White's home site, where there are a number of excellent articles describing AS. There's also Scott Rutherford's blog at blog.caronsoftware.com: Scott clearly knows AS well and also does an excellent job of writing about AS. Finally, there's the Google Groups AS forum, with many fine developers working on, describing, and customizing AS.
On the surface, you would think that customizing AS would be a piece of cake: just search the places mentioned above, get the relevant posts, and you're off to the races. Well, it doesn't work that way... at least for nubies. And that's a shame because it just makes getting productive in Rails that much more difficult.
Here's why the current approach doesn't work well.
1. There is no single place where someone can go to learn about AS -- either for an overview or for all the details. Things are scattered all over the place. That's not to say that there aren't some great tutorials; but usually those tutorials deal with only the most basic of information. This is like many of the gee-whiz Rails videos that I've seen: you learn how to do the simplest of tasks (which are admittedly much easier than without Rails), but you don't learn how to get to the next level. The first step is easy but watch out for the next step... it's a doozy.
2. Good information coexists with not-so-good information. As a nuby, you can't always tell the difference, and you can go down rabbit holes a bit too easily. Like Alice, it takes a long time to find your way back.
3. Good information is incomplete. This is the "Curse of Knowledge" in action (see the book "Made to Stick" by Heath & Heath... awesome!). I found good suggestions in a couple of different places, with code samples no less, but the surrounding "..." (meaning fill in the blanks here) turned out to be the key information that I was missing.
4. Information is out of date. Rails is changing and changing fast. So are the supporting tools, such as AS. On the one hand, that's really great. It's always nice to see new features being added. On the other hand, it's hard to keep up with all those changes. At some point, you may have to decide to give up on new features for some stability in your own development environment. For example, AS first appeared as a generator and then it migrated to a plugin. That's great, but how do you separate comments about the generator from comments about the plugin: it's not always clear which is which. Another rabbit hole to get lost in.
5. New stuff gets added that you aren't using. Now there's a new upgrade called ActiveScaffold. It has a lot of great new features and I'm sure that it's even better than the old AjaxScaffold. It has a few features that I would like to have, but -- as a nuby -- I'm a little too slow at learning this stuff to just jump on the new bandwagon. So now there are comments about ActiveScaffold that can send me down more rabbit holes. Fortunately, Richard gave this a new name and a new website, but it could (and was originally) referred to as version 4 of AS. Were that the case, I'd be in even more trouble.
So what's the problem here? It's that there's no one place to go to where you can learn "all" about AS... and I'm getting the impression that this is not just an AS problem. I'd really like to see one place where there is solid, up-to-date documentation about the package and all the options, along with examples.
I keep wishing for something like Perl's CPAN, the central repository where all (or at least most) contributed Perl modules reside, and where complete documentation is supposed to (and usually does) live.
So how am I doing with the customizations I want? I am making progress... I spent several hours digging through the code (amazing stuff, that AjaxScaffold) and I finally have the create/edit form displaying the drop-down box as desired.
I still don't have it saving the information properly, but I'm sure that's "just a little more" code-digging, rabbit-holing time to resolve and then I'll have this piece of the application up and running.
BTW, if you're interested in the solution to my AS quest, I'm documenting it as I go in the forum, under the title: Getting a drop-down to work in the create/edit form.
Tuesday, April 3, 2007
Webapp security using Secure Socket Layer (SSL)...
One of the things I want to do with my webapp is secure certain portions of it using https -- the secure mode of http communication. That requires an SSL Certificate... essentially a digital key and associated (encrypted) certificate that allows the web server and browser to encrypt and decrypt transmissions between the two [Don't ask me much more about the detailed security aspects... I am not a security expert].
However, since my Rails ISP doesn't provide built-in support for SSL, I had to go get my own SSL Certificate. I also had to get my own domain name (see previous posts) because this kind of Certificate is "attached to" (associated with) a specific domain -- I can only use this certificate with stuff on this particular domain.
I immediately ran into acronym hell -- things like "CSR", "RSA Key" -- and a process that was less than intuitive.
First, you have to get a "Certificate Signing Request" (CSR; also called a "Certification Request"), which you then send to a "Certificate Authority" (CA; think Verisign. Thawte, and others). These folks are the keepers of the keys... the public key infrastructure keys, that is, which is nothing more than the folks who are trusted to issue cryptography keys which make secure communications possible (read "eCommerce, eBay, etc...). In essence, they electronically vouch for who you say you are.
Once you have your CSR (which by the way requires that you know some of the webserver details (Apache vs IIS, which flavor of SSL is implemented in the server), then you pick your CA and submit an application. This application includes your CSR, reams of contact information, the domain name you wish to secure, and your email address (several flavors; more later on that).
I searched out the various options and finally settled on Thawte's SSL 123 certificate: it's tailored to securing a single domain name and was quite inexpensive: $39.95 for one year. GoDaddy's Turbo SSL was cheaper ($19.95), but I thought Thawte [pun intended] had a better name. Also, Thawte gives you an online "Trusted site seal" which makes it clear that you have secured your site... something that I thought worthwhile.
Once I got to this point, I figured it was all downhill from here... and it did go downhill, just not in the manner that I expected. I did finally get my certificate and had it installed on my server, but not before I ran into a few snags. Although Thawte gives you the option of having them generate your CSR, I chose to have my ISP generate it for me. At this point, I can't remember exactly why, but I'd most likely have Thawte do it for me now. Here's the chronology:
1. Request RailsPlayground (RP) generate the CSR for me. They did so, I submitted my application to Thawte and it was bounced:
"Invalid state"
RP had put the City name into the State field and we had both missed it.
2. Request RP generate the CSR for me. They did so, I submitted my application to Thawte and it was bounced:
"State code cannot be abbreviated"
RP had put in CA and it had to be spelled out in full.
3. Request RP generate the CSR for me. They did so, I submitted my application to Thawte and it was bounced:
"Invalid email address"
It took me a few more tries until I figured out that it had to be the email address which was referenced in the domain registration system(!). Once that was corrected, my request went thru, I was issued the certificate, and it is now installed on my site.
Were I to do this all over again, I would take the simpler route and do as much as I could directly thru the Certificate Authority's website... that would have saved me some of my headaches. But you still have to dig into it and learn something about the terminology before you can make this happen. Better yet, find an ISP that already has this baked in and save yourself some grief.
I'm happy to say that now I can use https on my website.
The question is how to implement it on my website... regardless of whether a visitor types in "https://" or not, I want to secure certain actions and certain controllers, and automatically route them to use https... but that's a question for more research and another post.
However, since my Rails ISP doesn't provide built-in support for SSL, I had to go get my own SSL Certificate. I also had to get my own domain name (see previous posts) because this kind of Certificate is "attached to" (associated with) a specific domain -- I can only use this certificate with stuff on this particular domain.
I immediately ran into acronym hell -- things like "CSR", "RSA Key" -- and a process that was less than intuitive.
First, you have to get a "Certificate Signing Request" (CSR; also called a "Certification Request"), which you then send to a "Certificate Authority" (CA; think Verisign. Thawte, and others). These folks are the keepers of the keys... the public key infrastructure keys, that is, which is nothing more than the folks who are trusted to issue cryptography keys which make secure communications possible (read "eCommerce, eBay, etc...). In essence, they electronically vouch for who you say you are.
Once you have your CSR (which by the way requires that you know some of the webserver details (Apache vs IIS, which flavor of SSL is implemented in the server), then you pick your CA and submit an application. This application includes your CSR, reams of contact information, the domain name you wish to secure, and your email address (several flavors; more later on that).
I searched out the various options and finally settled on Thawte's SSL 123 certificate: it's tailored to securing a single domain name and was quite inexpensive: $39.95 for one year. GoDaddy's Turbo SSL was cheaper ($19.95), but I thought Thawte [pun intended] had a better name. Also, Thawte gives you an online "Trusted site seal" which makes it clear that you have secured your site... something that I thought worthwhile.
Once I got to this point, I figured it was all downhill from here... and it did go downhill, just not in the manner that I expected. I did finally get my certificate and had it installed on my server, but not before I ran into a few snags. Although Thawte gives you the option of having them generate your CSR, I chose to have my ISP generate it for me. At this point, I can't remember exactly why, but I'd most likely have Thawte do it for me now. Here's the chronology:
1. Request RailsPlayground (RP) generate the CSR for me. They did so, I submitted my application to Thawte and it was bounced:
"Invalid state"
RP had put the City name into the State field and we had both missed it.
2. Request RP generate the CSR for me. They did so, I submitted my application to Thawte and it was bounced:
"State code cannot be abbreviated"
RP had put in CA and it had to be spelled out in full.
3. Request RP generate the CSR for me. They did so, I submitted my application to Thawte and it was bounced:
"Invalid email address"
It took me a few more tries until I figured out that it had to be the email address which was referenced in the domain registration system(!). Once that was corrected, my request went thru, I was issued the certificate, and it is now installed on my site.
Were I to do this all over again, I would take the simpler route and do as much as I could directly thru the Certificate Authority's website... that would have saved me some of my headaches. But you still have to dig into it and learn something about the terminology before you can make this happen. Better yet, find an ISP that already has this baked in and save yourself some grief.
I'm happy to say that now I can use https on my website.
The question is how to implement it on my website... regardless of whether a visitor types in "https://" or not, I want to secure certain actions and certain controllers, and automatically route them to use https... but that's a question for more research and another post.
Monday, April 2, 2007
More on Ruby documentation.... or should I say 'less'
Trouble finding all the documentation I need. Sure, there's the Rails Framework site, which is really good for the basics, but there seem to be lots of other stuff in lots of other places, and -- so far -- I haven't found an index to the basic things.
What I need is documentation on logger: the method given on snippets.dzone.com for rotating your logs doesn't work on my version of Rails (1.2.3).
Finally found the logger documentation at the Rails stdlib site. And there's introductory material on the Rails wiki.
What I need is documentation on logger: the method given on snippets.dzone.com for rotating your logs doesn't work on my version of Rails (1.2.3).
Finally found the logger documentation at the Rails stdlib site. And there's introductory material on the Rails wiki.
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!
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:
Production ActionMailer configuration:
Development ActionMailer configuration (using the free SMTP server mentioned previously):
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!
- 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...
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:
And... drum roll please: there is now built-in spam filtering on the Rails wiki... hooray! Many thanks to whoever made that happen :-)
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.
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...
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...
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.
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.
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.
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:
But... the session dump shows that it's there:
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 IntegerWhich 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...?#{RAILS_ROOT}/vendor/plugins/ajax_scaffold_plugin-3.2.4/lib/ajax_scaffold_plugin.rb:283:in `[]'
But... the session dump shows that it's there:
---Must be something automagical...
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 {}
Tuesday, March 20, 2007
Another gotcha!
Just what I didn't want to see:
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?
Breakpoints are not currently working with Ruby 1.8.5So 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.
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.
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:
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:
- 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].
- Never trust version 0 code
- Be very careful about instructions to modify code that they didn't develop.
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...
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:
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:
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 :-)
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 %>
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 Assetworks just fine; the caps are converted to lower case. And typing in something like:
ruby script\generate controller CamelCasealso 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.
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.
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.
Subscribe to:
Posts (Atom)