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?
- Moving to Ruby Enterprise Edition (REE)
- Moving to Passenger (mod_rails) by default
- All-new pricing structure! (starting at $35/month)
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.
- Where is your source code hosted?
- Which database do you typically use in production?
- which performance monitoring tool do you use?
- How much of your monthly budget is allocated for deployment and hosting expenses?
- So, can Rails scale? ;)
Don’t hesitate… we only have a few days left!
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. :-)
Any help that you can provide in getting the word out would be greatly appreciated.
1 comment Latest by Alex Stoneham Tue, 02 Feb 2010 18:20:27 GMT
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?
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 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!
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!
Older posts: 1 2