Posted by Paul Haddad
Fri, 21 Dec 2007 00:33:00 GMT
For some reason I’m not a big script/console user. Not really sure why but I normally either work with script/server or by running unit tests. However script/console and irb are useful tools, here are a few quick hints.
Wirble this gem adds in some really nice features to both irb and console. Specially nice are persistent history, color syntax highlighting and tab completion.
ri I have the web interfaces to rdoc and api.rubyrails.org bookmarked. However this can be more convenient. Just use ri classname or ri classname#methodname to get docs on an object. As a nice bonus Wirble adds in ri support to irb/console.
reload! should reload in all your model changes within console. This hopefully should reduce the number of times you have to exit out of console.
Tags console, Hints, irb | no comments
Posted by Paul Haddad
Fri, 30 Nov 2007 01:50:00 GMT
This one took me a while to figure out so hopefully it'll be useful for someone out there. I had a fairly simple need, an in_place_editor_field that updates multiple elements. The main trick here is to make sure the
:script => true option gets passed in.
In the View do the following
<%= in_place_editor_field :asset, :name,
{ :id => "in_place_editor_#{@asset.dom_id}" },
:script => true %>
And in the Controller
def set_asset_name
asset = Asset.find_by_id(params[:id])
old_value = asset.name
asset.name = params[:value]
asset.name = old_value unless asset.save
render :update do | page |
page.replace_html "edit_#{asset.dom_id}", asset.name
page.replace_html "in_place_editor_#{asset.dom_id}", asset.name
end
end
Again the key is to make sure the
:script => true option is set, otherwise you'll get the JS code generated by the render :update instead of the new value.
Posted in Code | Tags Ajax, in_place_editor_field, javascript | no comments
Posted by Paul Haddad
Tue, 23 Oct 2007 19:38:00 GMT
So assuming you’ve ordered a MediaTemple Dedicated-Virtual Server account and you want to setup a proper rails/mongrel setup you’ll want to follow the below instructions.
The first thing you want to do is ask support to make some changes to your machine.
- Ask them to enable root ssh access
- Ask them to install the Developer Tools on the machine
- (Optional) Ask them to disable Plesk. I personally don’t like stuff like Plesk, but some folks do.
Unfortunately, MT was a bit slow at doing all the above so give yourself a day or two for all the above to finish, they’ll probably need to re-image your server, so wait until they are all finished before you put anything on there.
For some reason MT doesn’t install yum as part of their base install, so the next step is to install yum.
Go to the Centos Vault and download the needed packages. Should be the following.
- yum-2.4.3-1.c4.noarch.rpm
- python-sqlite-1.1.7-1.2.i386.rpm
- python-elementtree-1.2.6-4.2.1.i386.rpm
- python-urlgrabber-2.9.8-2.noarch.rpm
- sqlite-3.3.3-1.2.i386.rpm
- sqlite-devel-3.3.3-1.2.i386.rpm
Use wget or curl to download these files to a directory and then use
rpm -i *
to install everything (note make sure you do this as the root user).
Now that you have yum install you can easily install the right versions of apache and ruby. First let’s configure yum to grab new versions of apache from the Utter Ramblings Repo.
Create a file in /etc/yum.repos.d called utterramblings.repo and add the following lines to it.
[utterramblings]
name=Jason's Utter Ramblings Repo
baseurl=http://www.jasonlitka.com/media/EL$releasever/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://www.jasonlitka.com/media/RPM-GPG-KEY-jlitka
Once this is done you should issue a
yum update
command and let the latest apache and such be updated. Follow this up with a simple install of ruby 1.8.5 using the CentOS-Testing.repo.
Create a CentOS-Testing.repo in /etc/yum.repos.d and put the following content in it.
[c4-testing]
name=CentOS-4 Testing
baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing
This time just issue an
yum update ruby
command. Edit the CentOS-Testing.repo file and set
enabled=1
to
enabled=0
since we don’t want this particular repository for anything other then this.
Almost done! Just follow the RubyGems Installation Instructions and type in
gem install rails
Voila a Rails setup. You’ll probably want to add in gems for mysql and such, but at least this should get you going as far as MT is concerned.
Posted in Hosting | Tags Hosting, MediaTemple, yum | no comments
Posted by Paul Haddad
Mon, 22 Oct 2007 21:54:00 GMT
So more time wasted on this gem. Turns out my previous fix didn't work with the console. The problem is console doesn't seem to load in the boot.rb on startup, at least the irb process doesn't. Fortunately I was able to come up with a better fix that doesn't depend on modifying boot.rb in anyway.
# this is here for bug http://dev.ctor.org/soap4r/ticket/433#comment:6
require 'rubygems'
RAILS_ROOT = "#{File.dirname(__FILE__)}/.." unless defined?(RAILS_ROOT)
Gem.path << "#{RAILS_ROOT}/vendor/gems"
Gem.source_index.refresh!
gem 'soap4r'
# done with hack for http://dev.ctor.org/soap4r/ticket/433#comment:6
The idea here is pretty much the same as before, the only real difference is the refresh! call which causes the gems to be re-looked at. The RAILS_ROOT bit is just there because since console doesn't call boot.rb it won't be defined otherwise.
One more issue I ran into is that on a newly installed machine I didn't have the httpclient gem installed. So just made sure that was added in my vendors/gems directory and all is good.
Posted in Hacks | Tags bug, Hack, soap4r, sucks, workaround | no comments
Posted by Paul Haddad
Fri, 19 Oct 2007 15:00:00 GMT
I was going to talk about setting up rails at MediaTemple, but I just wasted a good portion of yesterday dealing with soap4r. So I figured I’d write/vent about that instead.
The problem is if soap4r is installed as a gem it tends to kill anything that doesn’t have require 'soap4r' installed at the very top of environment.rb. This is detailed in the this bug. Even though its marked as invalid I think the soap4r guys really should do something about it.
Anyways until this is fixed and because I didn’t want to modify some perfectly fine apps, I had to come up with a workaround, perhaps there is a better way to do this, but this is what I came up with.
From RAILS_ROOT
gem install -i vendor/gems soap4r
This causes the gem to get installed into vendor/gems. Note I don’t think there’s a way to uninstall the plugin via gem, but for now it’ll do.
Continuing on, I added the following right after the require 'rubygems' line in boot.rb.
Gem.path << "#{RAILS_ROOT}/vendor/gems"
and then I just have the standard require 'soap4r' at the top of requirement.rb.
Not what I’d call the most elegant solution to this problem, but it should work for our env.
Posted in Hacks | Tags bug, Hack, soap4r, sucks, workaround | no comments
Posted by Paul Haddad
Thu, 18 Oct 2007 14:35:00 GMT
I think I'm on my 4th web provider in 3 years. I started over at Hurricane Electric which is actually a rather decent provider for static content. They are however a bit expensive so I was lured over to DreamHost. Now I know a lot of people dislike DreamHost but for static content its hard to beat them from a feature and price standpoint.
The problem with Dreamhost started when I went to deploy my first rails app. This is something I wouldn't recommend for anyone. Dreamhost just isn't setup to host something like rails, they have very strict monitoring software that kill any long running processes or anything that consumes too much memory. This pretty much kills Rails so it was time for another move.
After looking around for quite a bit I settled on HostingRails.com which seemed to be a good choice, for a while. They had fairly knowledgeable support folks and were able to setup some mongrel instances and a fastcgi instance for me. I'm not really crazy about their cPanel based control panel, but then I'm not really crazy about any of those control panels. However HostingRails.com has started getting really problematic lately. I have offsite monitoring tools running and several times a day my rails site would show as being down, most of the time this was a 10-30 minute problem, however recently I've had at least a couple outings that lasted several hours. Following up with support wasn't really very useful, it'd take several hours to fix anything and sometimes I didn't even get replies. The final straw was when for no reason they decided to firewall outgoing packets to my credit card processor.
After more looking around I switched over to a Virtual Host over at MediaTemple. I debated going with their Grid Service but saw a few bad reports on it and was tired of risking it. The Virtual Host setup seems to be pretty good (specially once I had them remove that Plesk stuff). Their email based support seems glacially slow, but that's about the only complaint I have with them so far. I've got 4 mongrel instances running across 3 different applications (2 typo blogs and the backend store for PTH. Again so far so good, I'm a little concerned that I might be going the memory allocation, but they haven't complained yet. :^)
I'll talk some more about how to properly install rails on one of these Centos 4 like boxes in a future blog entry.
Posted in Hosting | Tags Dreamhost, Hosting, HostingRails, MediaTemple | no comments
