Recent Projects
Categories
Updrift is the home of J. Wade Winningham. He helps make the web work.
ThinkingSphinx Capistrano tasks
Pat Allan recently released some helpful capistrano tasks you can use to make it easier to deploy your rails apps which use Sphinx and ThinkingSphinx. These simplify the steps from my previous post about this so I’ve also included an update to my deployment setup.
ThinkingSphinx Capistrano Tasks
Each of these currently gets run in your production environment except for the thinking_sphinx:install tasks. I’m sure a patch would be welcome to make this work across any environment.
cap thinking_sphinx:configure |
Generate the Sphinx configuration file. |
cap thinking_sphinx:index |
Index data. |
cap thinking_sphinx:install:sphinx |
Install Sphinx by source. This currently grabs the current stable version of Sphinx and compiles it. |
cap thinking_sphinx:install:ts |
Install Thinking Sphinx as a gem from GitHub. If you have the plugin installed, there’s no need to do this. |
cap thinking_sphinx:rebuild |
Stop, re-index and then start the Sphinx daemon. |
cap thinking_sphinx:restart |
Stop and then start the Sphinx daemon. |
cap thinking_sphinx:shared_sphinx_folder |
Add the shared folder for sphinx for Sphinx files for the production environment. More on this below. |
cap thinking_sphinx:start |
Start the Sphinx daemon |
cap thinking_sphinx:stop |
Stop the Sphinx daemon |
Adding the new Capistrano tasks to your Rails app
If you’re using the Plugin, you don’t have to do anything as they should be loaded automatically for you. If you have any problems deploying, make sure your Capfile is up-to-date.
If you’re using the Gem add this to the top of your config/deploy.rb file:
require 'thinking_sphinx/deploy/capistrano
For either plugin or gem, add the following line at the bottom of the file:
after "deploy:setup", "thinking_sphinx:shared_sphinx_folder"
Using ‘cap thinking_sphinx:shared_sphinx_folder’
I have not personally run across any issues using symlinks, but some people have. Plus, using a symlink can make you go through extra steps during deployment. Now, there’s a new setting you can add to your config/sphinx.yml file to specify the full path to your Sphinx database files like so:
production: searchd_file_path: "/path/to/your/app/db/sphinx/production/"
This path will get automatically created if it does not exist.
Updated Method of Deploying a Rails app with ThinkingSphinx
Having a constant path to the Sphinx indexes means you really don’t have to do anything special on deployment assuming it’s already running. If your define_index block in any models are changing frequently, you can add a few lines so you don’t forget about re-indexing. Check out my revised deploy.rb file for details.
Updated deploy.rb file
My updated sample deploy.rb is pastied.
Deploying a Rails app with Thinking Sphinx
Now that I’m using Thinking Sphinx I eventually had to deploy it. Since I didn’t find much info about deploying it using Capistrano here’s what I did to get deployments running smoothly.
NOTE: Please see this updated post for more recent info on deploying your apps with Thinking Sphinx.
Putting Rails gems into the vendor directory
Over on Err The Blog is an article on placing your gems into the vendor directory rather than relying on them being in the environment.
I’ve run into the issue before where a Rails app doesn’t run on a server due to a gem not being installed. Adding them to your application seems like a perfect solution and deals with other computers possibly having various versions of gems installed.
Rails Hash Ordering
My expectation was that when I create a hash it’s going to act like a queue and be sorted in the order in which I inserted things. As I found out today, that is definitely not the case.
There is a very easy way that Rails offers to give a hash this behavior and it’s the OrderedHash function found in the ActiveSupport libraries.
my_hash = ActiveSupport::OrderedHash.new
After that initialization, your hash will be maintained in the order you insert things. Something to watch out for.
A couple of Ruby on Rails v1.2 gotchas
I recently upgraded a few projects to Rails v.1.2 and had a couple of issues arise.
Disappearing objects when dropped using drag and drop in Safari
For one project I use the drag and drop re-ordering provided by the Scriptaculous library. Not sure what did it, possibly even a Safari update, but only in Safari, once you let go of a dragged object, that object would disappear. It would come back when you refreshed the page and would have successfully triggered its intended action.
I did update my javascript files upon upgrading to v.1.2.1, but had not upon the upgrade to v1.2.2 since I wasn’t aware of any changes. I think the release of Scriptaculous on its actual site is newer (v1.7 right now) than that included in Rails so I updated my scripts and that solved the problem.
Model attributes not in the database were inaccessible
I wasn’t able to figure this one out, but was able to get around it. I have a model which has some methods to send/receive messages to a device. I had a
attr_accessor :last_response
which is an attribute that’s not in the database. It was simple a place to temporarily store the full message of the last response for use later on in the code. After the upgrade to v1.2.1 things were fine. However after updating to v.1.2.2, I started getting “Method not defined” errors. It seems like other people have hit this one, too.
My solution was simply to remove the property and change it to @last_response which worked for my limited use of it.
I’m still scratching my head though, since similar attributes work fine in other classes. The problem class, however, is unique in that instead of having ActiveRecord:Base as its parent, the actual parent is a generic class whose parent is ActiveRecord:Base.
Keep up with your Rails tests
I haven’t updated my progress on the project I’ve been working on in a while. This is somewhat due to simply getting caught up in the development of it. I’ve also been working the past few weeks on creating the CSS/HTML based on the delivered design. Here’s two things I’ve learned about my experience since last time…
Don’t forget about running your tests
While I think I did a good job creating unit tests, I definitely let my functional tests slide. I have also not been religiously running my existing tests, so it wasn’t much of a surprise that a number of them were failing when I ran them again recently. As I fix them up, I’ll be keeping track of where they would have helped me out.
One thing I do know is where I need to have functional tests. I’m not nearly as concerned with pages which do nothing but display information, mostly ones where it would change, or redirect you based on security.
IE7 is much easier to style than IE6, but still not quite as good
Okay, This isn’t really Ruby on Rails specific. This assumes you create styles like I do. Create your CSS to work in Firefox and Safari and then get it to work in IE. I did run into some IE7 weirdness, but overall, there will be far less tweaks with it than you’d have with IE6. I created separate stylesheets with IE6 and IE7 fixes and the IE7 one is roughly 80% smaller than the one for IE6.
Agile Web Development 2nd Edition
If you’ve got the first edition of this book or about to buy it to get yourself started with Ruby on Rails, don’t buy it. The 2nd edition is now available in a beta form and it’s well worth it. The most recent additions to Rails really the original print largely obsolete. Yes, that much has changed.
Getting a little off track with my project
I got to a point where I think I’m getting a little off track with my Rails project. In trying to make sure everything’s perfect along the way, I think I’ve lost sight of the rapid development part of it all. When building my models, I wrote out a lot of tests to make sure things were working. While I am glad I did that, it isn’t the way to get the application in a usable state right away.
I’m very glad I did write the unit tests, since I’ve already had to make a change where the tests were correct but my models stopped working. Running the unit tests helped me fix the problems quickly.
As I proceed to build the controllers, I’m doing what I can to get the pages to work navigationally so people can login and click around the site and see at least static content. I’ll go back in and add actual logic, including funtional tests, as I code the details.
It just dawned on me that I’ve been doing a lot of work and my co-workers haven’t been able to actually see the site. This is Ruby on Rails, so I figured that was backwards. I guess I’m still getting used to it all.
