I asked on twitter but only got a small handful of responses. So, I’m taking it here.
Show me yours and I’ll show you mine. Your terminal prompt that you’re using. Inspire me with new ideas for my prompt.
Here is mine.
::: thumbnail
:::
Now… show me yours.
We recently switched our default builds of Rails Boxcar to leverage the benefits of using Passenger (mod_rails) for deployment of your Ruby on Rails applications and it’s been working out great for our customers. Several of our customers and colleagues mentioned that they also began using Passenger in development, which was intriguing.
But… Mongrel has been working great for us for the past few years. Why switch?
It’s true, I’ve been happily using mongrel since it came out as a replacement to webrick back in early 2006, which makes it about 28 in dog years.
{width=”500”
height=”375”}
[Nigel and I.. 2 1/2 years ago back when Mongrel was just a
puppy]{.small}
But… over the next few weeks, I’m going to evaluate Passenger in my development workflow. There’s no better way to try something then to jump head first. So… here goes.
::: thumbnail
[this guy was a passenger…and I recently started to watch the
show]{.small}
:::
Our team will be evaluating Passenger in our development work flow with a forthcoming blog post but if you want to get your feet wet right away, here are some instructions for setting up Passenger on OSX with PrefPane, which were inspired by Manfred’s posts.
To install Passenger on your OSX machine, just run the following with root credentials.
sudo gem install passenger
This will install the passenger gem on your machine. Now we need to go ahead and run a script that is provided with this gem (also with root credentials).
sudo passenger-install-apache2-module
You’ll want to follow the instructions that appear. When you see
something similar to the following output from the command, you’ll want
to copy/paste that into an apache configuration file. I just created a
file at /etc/apache2/other/passenger.conf.
Edit this file with your editor of choice
mate /etc/apache2/other/passenger.conf
Mine looks like:
```
#/etc/apache2/other/passenger.conf
# Passenger modules and configuration
LoadModule passenger_module /opt/local/lib/ruby/gems/1.8/gems/passenger-2.0.6/ext/apache2/mod_passenger.so
PassengerRoot /opt/local/lib/ruby/gems/1.8/gems/passenger-2.0.6
PassengerRuby /opt/local/bin/ruby
# Set the default environment to development
RailsEnv development
# Which directory do you want Apache to be able to look into for projects?
<Directory "/Users/robbyrussell/Projects/development">
Order allow,deny
Allow from all
</Directory>
```
Once you finish running through sudo passenger-install-apache2-module,
you’ll need to restart Apache on your workstation. This can be done by
simply turning off/on Web Sharing in your Sharing Preference Pane.
::: thumbnail
:::
Alright, we got through the hard part. Now, in order for you to begin using Passenger, we need to setup Apache to point to your individual Ruby on Rails application(s). You can hack on Apache configuration files more, but there is an easier way thanks to the Passenger Preference Pane.
This will manage your VHost files for you!
If you followed my post on installing Ruby on Rails via MacPorts, you’re going to need to install Ruby Cocoa, which can be done with the following. If you’re using the Ruby provided from Apple, you can skip this step.
sudo port install rb-cocoa
Once that is done, go ahead and move on and download Passenger Preference Pane. Once downloaded, you can install the preference pane, by double-clicking on the following file.
::: thumbnail
:::
The next part is really simple as well. Just begin to add your various Ruby on Rails projects into the Preference Pane… and when you’re done, you should be able to run your applications over port 80 without any problems.
As you can see, I’ve already setup a handful of projects and we don’t have to start/stop mongrels for each one or worry about port numbers when running multiple projects. (time savings!)
::: thumbnail
:::
Voila. Simple enough. You might need to stop/start Apache, couldn’t remember if I needed to or not.
For each host that you add into this panel, it’ll automatically be added so that you can immediately browse to http://yourhost.local and it should just work. :-)
Debugging. If you’re used to doing --debugger, it appears that you can
do something similar with the
socket-debugger
plugin. Not tried it myself, but worth looking into.
Browser testing via VMWare/Parallels/VirtualBox. Does anybody have any tips on how to best appraoch this? Our designers are curious…
As I mentioned, this is day one of trying it out and managed to motivate our entire design and development team to try it with me so that we can all learn about issues together and find solutions quicker. If you’ve been using this approach for a while, I’d be interested in hearing your story and if there are any issues that we should be aware of.
We’ll be posting some more updates on the Planet Argon blog in near future, but I wanted to invite you all to check out our new site at http://planetargon.com/. The last site was launched over three years ago. we thought it was time for a refresh. :-)
Alex, Director of Deployment Services, has been hard at work helping us get our new suite of hosting plans out for Rails Boxcar, a deployment environment that we’ve designed to help you get your Ruby on Rails applications running as painless and quickly as possible. With this new announcement, we’ve rebuilt the Boxcar image based on the feedback of our existing customers.
Additionally, we’ve been looking over some of early results from the Ruby on Rails Hosting in 2009 Survey that we’ve been running the past few weeks, which has further boosted our confidence that we’re on the right track with this big change.
What are some of the changes?
This means that with a Rails Boxcar, you can now get a pre-configured deployment environment using some of the most efficient platforms for hosting your Ruby on Rails applications. (REE has shown to increase performance by 33% in some cases)
We’re really excited about this new setup and would like to invite you all to check out our new plans and send us any questions that you might have.
Wow. Thanks to all of you who have helped get the word out about the Ruby on Rails Hosting 2009 Survey. We just passed 900 people and we have about five more days left to hit the 1500 milestone that I set for myself.
If you can spare five minutes to help us reach this goal, we’d really appreciate it.
Here is a quick sample of the questions that we’re asking the community.
Don’t hesitate… we only have a few days left!
{style=”padding-top: 20px; padding-bottom: 40px;”}
For more information, read the original post, Take the Ruby on Rails Hosting in 2009 Survey.
I fucked up this last week.
On Monday, our primary contact for a large client sent over some last minute requirements and deadlines that were needed by end-of-day Wednesday. I didn’t have a lot of time to collect requirements and execute it without having to rearrange my priorities. But, I accepted the challenge.
The big change involved was that we were going to be supplied with a ton of data to be imported in to the database and approximately 20% of the data provided was new records, while the rest were duplicates. However, the other 80% wasn’t to be discarded as there were a few attributes that needed to be updated from the data file (which was supplied from the client’s parent company). In my haste to get the task done on time (didn’t get proper export file to be imported in our system until Wednesday morning)… I ended up running a few tests locally and pushed it out to production.
I managed to get the import file to run in production before leaving on Wednesday afternoon. The following morning, I came into the office to find out that my import process didn’t match up records properly and resulted in nearly all of the 80% side of that to be duplicated in the system. This resulted in lost productivity for our client, their vendors, and our team over a 12 hour period as people were confused about why reports were running weird, online transactions didn’t account for the duplicated, etc.
It took me most of Thursday and Friday to clean up the data that got skewed due to that oversight. Hi ho.
So, the take away from this? Sure, I could have blamed it on a lack of sufficient time to properly test things, but that’s bullshit. I should have had at least one other developer from our team review the problem and evaluate my proposed solution prior to me attempting to push into production.
Luckily, the client was happy that we were able to finish the last minute tasks, despite the unexpected headaches that cropped up.
If anything, I was just disappointed in myself, but Alex reminded me how important it was to fail early, fail often. It didn’t kill me (or anybody else for that matter), cost us the project, nor was it irreparable.
In the real world, deadlines and requirements change on a moments notice and it’s experiences like this that will make ourselves more confident that we can quickly respond to and execute.
What was your latest failure?
Thanks to everyone has taken the survey and mentioned it on twitter. We just passed 400 people. We have a ways to go before we hit our goal of at least 1500 people surveyed. (if we can get even more than that… great!)
The survey is taking most people less than 5 minutes to complete, so if you haven’t filled it out yet and have experience deploying Ruby on Rails applications, here’s a link. :-)
{style=”padding-top: 20px; padding-bottom: 40px;”}
Any help that you can provide in getting the word out would be greatly appreciated.
Thanks!
Calling all Ruby on Rails developers and system administrators.
The team at Planet Argon is hoping to collect some information about how everyone is currently managing the deployment and hosting of their Ruby on Rails applications. We are inviting you all to participate in the Rails Hosting in 2009 survey, which consists of nearly forty questions about you and your Rails hosting experiences. Most people say it is taking [less than five (5) minutes]{.underline} to complete it. =)
We will collect responses for the survey until the end of January and will then publish the results (with anonymous raw data) for everyone in the community to share and use.
Our goal is to use this information ourselves to continue to evolve our hosting-related products and deployment services for you. We also want all of our fellow hosting providers and development teams to have access to this information so that they can continue to improve their services. Rails deployment and hosting is getting easier for us all, but we know that there is always room from improvement.
We make an effort to keep our ear close to the ground in the community to listen for trends and problems, but sometimes it’s better to just ask directly.
So, if you have a few minutes to spare, please take the survey!
{style=”padding-top: 20px; padding-bottom: 40px;”}
update: some people mentioned that we should have made some options multi-select. it’s too late to change it without losing submissions. so, for questions like: Monit, God, or Other (and you’re using God and Monit, put that in Other and we’ll track them accordingly)
P.S. Please spread the word about the survey!
Our development team likes to extract reusable pieces of code for our projects and have historically used plugins. However, we are finding more and more people releasing these sorts of modules/components/patterns as gems.
Which do you prefer and why?
If you use both, how do you decide to use plugins or gems?
In my last post, Subdomain accounts with Ruby on Rails
explaind,
I mentioned that you’d need to modify your /etc/hosts file to use
custom subdomains for development/testing. Apparently, there is a much
better way to handle this that I was introduced to by Nathan de
Vries. Nathan suggests using a gem that I hadn’t
heard of before that bares the name of Ghost (view project on
github).
Ghost describes itself as…
“A gem that allows you to create, list, and modify local hostnames in 10.5 with ease…” —
If you’ve ever had to modify your /etc/hosts file for anything local,
I highly encourage you to check out this shiny gem.
Like most gems, you can just install Ghost with the following command.
```
~ : sudo gem install ghost
Password:
Successfully installed ghost-0.1.2-universal-darwin-9
1 gem installed
Installing ri documentation for ghost-0.1.2-universal-darwin-9...
Installing RDoc documentation for ghost-0.1.2-universal-darwin-9...
```
Okay, now that Ghost is installed, let’s see what we can do with it.
Ghost is fairly straight forward. It’s essentially a friendly wrapper
for
dscl,
which is the Directory Service command line utility
for Mac OS X. I’ve never played with that directly, but it seems that
with Ghost… I shouldn’t need to. :-)
With Ghost, you can add, modify, and delete entries in the Directory
Service by issuing any of the following commands. Let’s start out by
running ghost to see what we have here.
```
~ : ghost
USAGE: ghost add <hostname> [<ip=127.0.1.1>]
ghost modify <hostname> <ip>
ghost delete <hostname>
ghost list
ghost empty
```
Okay, let’s see if there is anything already listed.
```
~ : ghost list
Listing 0 host(s):
```
Nope. Let’s test this out. First, we’ll try to ping a domain name that we hope doesn’t exist.
```
~ : ping bigbrown.cow
ping: cannot resolve bigbrown.cow: Unknown host
```
Alright, now we’ll add bigbrown.cow with ghost.
```
~ : ghost add bigbrown.cow
Password:
[Adding] bigbrown.cow -> 127.0.0.1
```
As you can see, it required root credentials to do this as it’s system-wide. Let’s now see if we can talk to bigbrown.cow.
```
~ : ping bigbrown.cow
PING bigbrown.cow (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.047 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.035 ms
^C
--- bigbrown.cow ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.035/0.041/0.047/0.006 ms
```
Excellent! If we run ghost list again, we should see this record.
```
~ : ghost list
Listing 1 host(s):
bigbrown.cow -> 127.0.0.1
```
We can modify the record to a non-localhost IP as well with
ghost modify.
```
~ : ghost modify bigbrown.cow 192.168.10.104
[Modifying] bigbrown.cow -> 192.168.10.104
~ : ghost list
Listing 1 host(s):
bigbrown.cow -> 192.168.10.104
```
I’ll let you play with it yourself as there isn’t much to it. This is a great little addition to my development environment. Thanks to Nathan for pointing it out and to Bodaniel Jeanes for creating this useful gem.
If you’re using Highrise or Basecamp and miss not having favicons load in your browser, you can install either of the following greasemonkey scripts that I created.
These will just add a little html to the page to load some favicons that I created from their logos. Will look like this:
::: thumbnail
:::
Hopefully 37signals will add favicons themselves in the future, but in the meantime. Here you go!