Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

Boxcar on Twitter

Posted by Fri, 23 May 2008 02:00:00 GMT

We’re about to roll out some announcements for Boxcar, our professional VPS hosting solution for Ruby on Rails applications. As we roll out these new updates, we’re going to offer some extra special deals to those who are following us on twitter. :-)

If you want in on the action…

As usual, we’ll be posting some announcements on our blog as well… so be sure to subscribe to our feed.

Announcing Cobalt and monthly subscriptions for Boxcar

Posted by Mon, 14 Apr 2008 14:24:00 GMT

We’ve been designing and developing a new centralized billing platform over the past few months and late last week, we launched it! Along with this new billing platform, we launched another new application, Cobalt, which is a new account management and support tool for our hosting customers.

Cobalt - account management
Uploaded with plasq’s Skitch!

We’ll be migrating all of our past customers over to this new system in time, but are initially using it for new Boxcar customers.

We’ve been building the new system to use Braintree as our new credit card payment gateway. With this switch, we’re also introducing monthly subscription rates for Boxcar, which means that you can try it out month-to-month now.

Over the next few weeks/months, we’ll be announcing several features to Cobalt that will ease your Rails deployment experience.

I want to thank all those on my team that helped get these new applications up and running.

If you’re looking for professional VPS-based Rails hosting, hop on our train by ordering a Boxcar today for $99/month!

For more information, visit railsboxcar.com or Planet Argon.

Also, be sure to follow Boxcar on twitter.

Deploying Rails with an interactive Capistrano recipe to your Boxcar

Posted by Thu, 28 Feb 2008 21:27:00 GMT

I wanted to share something that I’ve been meaning to share on here.

When we began planning Rails Boxcar, we really want to reduce the amount of work that it took to setup and deploy a VPS for a Rails application. During this period, we began to look at the deployment process itself and began working on an interactive tool for developers for setting up their deployment environment on their Boxcar instances. So, we worked with few customers to develop an interactive Capistrano recipe.

The Goal? Spend less time configuring the server or editing recipe files.

During the initial setup, we can have the customer provide a few details from the safety of their Rails application directory by answering the following.

  • What database server will you be using? (PostgreSQL or MySQL)
  • What port does your database run on? (if different than the default for your db server)
  • What is your database username?
  • What is your database user’s password?
  • What port will your mongrel cluster start with?
  • How many mongrel servers should your cluster run?

Great… setup the server and let’s deploy!

Default
Uploaded with plasq’s Skitch!

Feel free to snag our interactive Capistrano2 recipe.

We’re trying to take the pain out of deploying your Ruby on Rails applications with Boxcar.

On a side note, we’re in the process of expanding our team and recently hired Alex Malinovich. Do stay tuned as we’ll be posting important announcements about changes to our Rails hosting services in the next few weeks. (grin)

Boxcar: Open for business

Posted by Tue, 04 Sep 2007 17:04:00 GMT

We’ve been quietly rolling out our new Rails hosting solution over the past month, each week… inviting more people to ask questions and place orders. Initially, we invited some of our business hosting customers, and then sent out invites to those who signed up on the Rails Boxcar announcement list. We’ve been taking orders for the past few weeks and have had sites running on Boxcar for over a month now.

You’ll also notice that we’ve begun to phase out all of our older shared hosting solutions for new customers and are focusing solely on our Business and Boxcar accounts (aside from custom managed/dedicated solutions that we’ve been offering upon request).

To learn more about Rails Boxcar, read the announcement on the PLANET ARGON blog.

In other news, Daniel Johnson, our Lead Systems Administrator broke his arm while riding his bike while participating in Zoo Bomb (and cracked his helmet in the process). He’s at home today on pain medicine and we hope that he has a swift recovery.

YSlow and Rails performance: Getting UJS and AssetPackager to play nice

Posted by Fri, 27 Jul 2007 17:40:00 GMT

Yesterday, I started to dig deeper into YSlow and decided to pick an application that we recently launched for a client. The performance grade that I saw at first was an F, which wasn’t surprising to me because we knew that there was going to be some fine tuning in the near future.

There is a lot of JavaScript in this application and we have several files to break up stuff to make it more maintainable. However, in production, we really don’t need to send the client (browser) 19 different JS files. We’ve been using mod_deflate to compress these files, but it doesn’t solve the problem of having several connections opening to download all the necessary JavaScript. The same is true for our CSS files.

At RailsConf, DHH announced that an upcoming version of Rails would bundle all the stylesheet and javascript files into one file and compress it. We’re running on 1.2.x for this application and decided to look at the AssetPackager plugin as a good solution to this problem.

I installed the plugin via piston and ran the following task, which is provided by AssetPackager.

rake asset:packager:create_yml

This went ahead and created config/assets_packager.yml. I then went ahead and updated our capistrano configuration to call the rake task after updating the code on the server when deploying.


desc "all of our other tasks/commands to run after updating the code" 
task :after_update_code do
  #
  # all of our other tasks/commands
  #
  run "cd #{release_path} && rake RAILS_ENV=production asset:packager:build_all" 
end

The first thing that I noticed was that the yml file that gets generated will not make any assumption as to what order the javascript libraries should be loaded. So, immediately, line 1 of our compressed javascript file was causing an error as the code was trying to reference a library that hadn’t been defined yet (showed up later in the file). So, when you do this, you’ll need to organize the yml file to load things in order that they are needed. This was also a good opportunity for us to say, “oh, we’re not using that one anymore. Let’s remove it.”


--- 
javascripts: 
- base: 
  - prototype  
  - effects
  - scriptaculous
  - controls
  - dragdrop
  - application
  - slider
  - pngfix
  - nav
  - lowpro
  - lightbox
  - folder
  - builder

Great, so we re-dployed and everything at first glance seemed fine… or so we thought!

We used the unobtrusive javascript plugin for this project and it seems that we couldn’t just compress every single file. Each page has a behaviors javascript file and since everything was being compressed into one file (and cached), RJS calls quickly broke throughout the site. OH NO!

So, I opted to merge all of the other javascript files and use the standard way of including unobtrusive javascript in the application layout.


<%= javascript_include_merged :base %>
<%= javascript_include_tag :unobtrusive %>

We also removed lowpro from the list of javascript files to compress since the ujs plugin is currently including this when we call <%= javascript_include_tag :unobtrusive %>. I plan to look into modifying this so we it’ll only include the page-specific behaviors and not load the lowpro javascript file (so we can compress that as well).

Once this was re-deployed, we saw that the RJS issues were resolved and everything felt to be loading quicker. But, let’s look at YSlow again for step 1 in improving the performance of the application.

side note: the following grading was also after making some other adjustments that were suggested by YSlow, which I’ll discuss in another blog post soon.

So, where we once had a grade F, we now have an D… which is due to the client having us add several (four) external javascript files for mint, google analytics, etc. We’re only loading 3 javascript files for the application, when we were originally loading many more.

Obviously, there is some more tuning to be done, but we went from a grading of 43 to 74 in about three hours of time spent reading the YSlow documentation, adding asset_packager, and making various tweaks to our web servers (as suggested by YSlow).

Until next time…

Related Posts:

Introducing Boxcar... coming soon to a train station near you!

Posted by Tue, 08 May 2007 19:35:00 GMT

As I just announced on the PLANET ARGON blog... our new hosting solution is almost here!

Last month, we put a freeze on new orders on several of our Rails hosting packages so that we could do some remodeling. Well, we’re almost done and excited about what we’re going to be reopening with. :-)

We’ll be posting updates on the PLANET ARGON blog over the coming days/weeks… so yo might consider subscribing to our feed.

Be sure to sign up on our mailing list to be amongst the first to be notified when Boxcar gets launched!

Older posts: 1 2 3 4 5 6 ... 8