Setting up Shakacode’s React on Rails: HMR, SSR, xhr, and a handful of hacks
Rails/React gem options comparison: react-rails vs react-on-rails vs webpacker-react
Fix: IRB pasting is super slow, typing in ruby debugger has lag
After numerous hours spent trying unsuccessfully to fix this problem by following the instructions outlined on a few StackOverflow posts, Jordan presented a recipe for fixing this problem (that actually fixed the problem) today.
The essence of the issue is that the readline package that gets installed with REE is by default some bastard version that lags, at least on our Ubuntu and Mint installations. Installing the rvm readline package did not fix it for either of us, nor did an assortment of experiments on compiling REE with different options. Here’s what did:
$> sudo apt-get remove libreadline6-dev
$> sudo apt-get install libreadline-gplv2-dev
$> rvm remove ree
$> rvm install ree
One problem you may encounter is that if you’re avoiding newer versions of Ubuntu until admit defeat about Unity, the “libreadline-gplv2-dev” package is by default only present in Oneiric and above. Here’s where I found the package versions that worked with Maverick: https://launchpad.net/~dns/+archive/test0/+sourcepub/2252776/+listing-archive-extra. After downloading the packages from this link, the install sequence became
$> sudo apt-get remove libreadline6-dev libreadline5
$> sudo dpkg -i libreadline5_5.2-9~maverick0_amd64.deb
$> sudo dpkg -i libreadline-gplv2-dev_5.2-9~maverick0_amd64.deb
$> rvm remove ree
$> rvm install ree
EC2 vs. Heroku vs. Blue Box Group for Rails Hosting
Not to kick a company when it’s (literally) down, but today’s 12+ hours EC2 outage has finally driven me to write a blog post I’ve been holding in my head for several months now: comparing a few of the major players within today’s Rails hosting ecosystem. In this post, I’ll compare and contrast EC2, Heroku, and Blue Box Group. I’ve chosen these three not only because of their popularity, but also because I believe each has a value proposition distinct from the other two, which which makes each ideally suited for different types of customers. In the interests of full disclosure, we are a current Blue Box Group customer, but we have spent a great deal of time looking at our choices, and I think that all have their advantages in specific situations. The facts and opinions below are the result of weighing data gleaned from Googling, popular opinion, and three years running a Rails site that has grown to serve more than 2m uniques per month.
Heroku vs. EC2 vs. Blue Box Group, Round 1: Price
Let’s start by establishing a pricing context. We’ll use a dedicated (not-shared resource/virtual) 8 GB, 8 core server with 1TB bandwidth as our baseline, since it is available across all three services (with some caveats, mentioned below).
| Heroku | EC2 (High-CPU XL) | BBG | |
| Dedicated 8-Core Server with 8 GB | $800.00 | $490.00 | $799.00* |
| 1 TB Bandwidth | $0.00 | $125.00 | $0.00 |
| Total | $800.00 | $615.00-695.00** | $799.00 |
* In the case of BBG, their most current prices aren’t on their pricing page. They should fix that.
** This doesn’t include I/O costs for Amazon EBS. While these are fairly impossible to predict (varying greatly from app to app), it sounds from Amazon like you’d be talking about something more than $40 for this. Give that we’re comparing a “high end machine” here, perhaps $80 might be a more accurate estimate, that would make the price more like $700.
Various minor approximations were made to try to get this as close to apples-to-apples as possible, but the biggest caveat is that the Heroku instance (Ika) only has about 25% the CPU as the EC2 and BBG instances (though it has the same amount of memory. They don’t configure their DBs with comparable CPU muscle). The next highest Heroku instance (Zilla) is $1600 per month, and more comparable to the other two in terms of CPU, but has twice as much memory as they do. Note that EC2 and BBG make offer discounts when committing to a year of service — I couldn’t find a comparable offer from Heroku, which is not to say that it doesn’t exist (readers?). These discounts typically range from 10-25% off the no-commitment price.
Heroku vs. EC2 vs. Blue Box Group, Round 2: Setup
Heroku is ridiculously get started with, the runaway winner of the bunch when it comes to hitting the ground running with zero red tape. Per their homepage, all you do is run a couple rake commands and you’re in business. Even cooler, they offer a vast and useful collection of add-ons to make it easy to get started on whatever the specific thing is that you app is supposed to do.
Setting up Rails with EC2 is not quite the same walk in the park, but it’s not necessarily bad. Amazon handles configuring the OS for you, so in terms of getting your app server setup, you are essentially just getting Ruby and Rubygems installed, and letting Bundler take care of the rest. If you managed to set up your development environment in Linux or on a Mac, chances are you won’t have too much trouble using packages to fill in the gaps for other non-Ruby elements to your application (like Sphinx). When EC2 gets trickier is when you start figuring out how to integrate EBS (Amazon Elastic Block storage, necessary for data that you don’t want to disappear) and the other 20 Amazon web services that you may or may not want/need to use to run your app. It can ultimately amount to quite a research project to figure out which tools you want, which ones you need, and how to tie them all together. That said, you may end up using these tools (S3 in particular) even if you use BBG or Heroku, so that cost is not entirely unique to using EC2.
Ease of getting started on Blue Box is somewhere in between EC2 and Heroku. There is no high-tech set of tools that automatically build stuff like Heroku, but unlike EC2, you have a friendly and qualified team willing to help you get your server setup in the best possible way. In my experience, when they have setup new servers, they will ask in advance how we plan to use the server, and then automatically handle getting all of the baseline stuff we’ll need installed such that we can just focus on deploying our app. Which brings me to Round 3…
Heroku vs. EC2 vs. Blue Box Group, Round 3: What’s Best Suited for What?
For pet projects, small sites, or newly started sites, I think that hosting with Heroku is a no-brainer. You can be up and running immediately, you get a huge variety of conveniences with their add-ons, and there is a wealth of Google help behind you if you should happen to encounter an trouble, given the immense user base Heroku has managed to establish. All three of these these services can scale up available hardware within hours/minutes-not-days (yay for clouds!), but Heroku is probably the most straightforward to rapidly grow an application with their “Dynos” approach. However, given their highest cost amongst the choices, and their lower-than-BBG application-specific support, the significance of those advantages will erode as your application grows into the 10’s of thousands of monthly visitors.
I believe that EC2’s greatest selling point is its price, with its scalability and ubiquity (= generally good Googlability) being close seconds. As detailed above, on balance, EC2 tends to run 20-30% cheaper than other choices by leveraging their immense scale. Nifty features like auto-scale have the promise of making instant growth possible if you get flooded after your Oprah appearance. The trade-off for those advantages is that you will get 0 application-specific support, and even getting generic system-wide support can be hit-and-miss, as folks who suffered through today’s EC2 outage learned firsthand. Transparency is not Amazon’s strong suit at this point in their evolution, which can be a real problem if you have real customers who depend on your product and want to know when they can expect to see your website again during an outage. Also, as mentioned in the setup section, figuring out your way around the Amazon product ecosystem can be dauting at first.
I would consider EC2 the best choice for intermediate-sized businesses, particularly if 100% uptime is not imperative to their existence. EC2 is a great option for bootstrapped startups who want to get online as cheaply as possible, and are willing to put in the extra work setting up their servers in exchange for those cost savings. Also, since you will probably be unclear about what kind of resources your app is going to consume as it scales, EC2 is a great proving ground to get a sense for what kind of resources you might need if you decide to venture beyond Amazon for improved reliability and service. I would also take a long look at EC2 for huge businesses that can afford their own IT department, which diminishes the significance of EC2’s lack of application-specific support or monitoring.
While their prices are competitive with EC2, I would assert that the real differentiator with Blue Box is their focus on service. Included by default for business-sized BBG customers is 24/7 pro-active human monitoring of all services, including the ability to bring servers back online if they should happen to crash and you’re not around. Having gone through a fair number of web hosts in our day, we we have come to realize that, once you are signed up at a given host, it can be a huge pain to change. Most hosts use this knowledge to their advantage, and after a very romantic honeymoon period, become inattentive to their customer’s needs after it becomes clear the customer would be hard-pressed to move.
At Blue Box, their customer-focused attitude has not diminished a bit over time. We still regularly find them answering our questions…on the weekend…within minutes of the question being sent. Equally important, Jesse Proudman (BBG CEO) has built a team around him that gives the customer the benefit of the doubt. In more than a year of being hosted at BBG, I can not ever remember them “blaming” us for server changes we’ve made that have caused havoc (not the case at some of our past hosts). Instead, BBG has a solution-focused team that is consistently personable, reasonable, and most importantly, effective when it comes to solving tricky application and server problems.
While BBG offers small VPS instances, as well as cloud servers that can quickly scale, I consider their sweet spot to be businesses that have grown beyond the point of being able to easily maintain their server cluster themselves, but they don’t want to hire an on-staff IT guy. Or maybe they do have an IT guy, but they really need two. Over the past couple years, BBG has been our “IT guy,” working to implement systems for us ranging from a Mediawiki server, to load balancers, to Mysql master-master failover clusters. And compared to having a real IT guy on staff, the price is a huge bargain (not to mention the savings on health insurance, taxes, etc.)
Another nice benefit for those that have been stung by EC2/Heroku uptime hiccups: in 20 months with BBG, our total system downtime has been something between 1-2 hours (excluding downtime caused by our mistakes).
Conclusion
The best host for a particular Rails app depends on a number of factors, including phase of development (pre-launch? newly launched? rapidly growing? already huge?), need for 100% uptime, makeup of team, and cash available. Hopefully this post will be helpful to someone trying to figure out which host makes most sense for their unique situation. Please do post any questions or anecdotes from your hosting experience for future Google visitors.
Update: Response from BBG
Blue Box emailed me after this post, with a few extra details that I believe are pertinent:
- 4 x 300GB 15k SAS outperforms EBS (which both Heroku and Amazon rely on) by almost 30% based on our client benchmarks.
- Neither Heroku nor Amazon provide 24 x 7 monitoring with proactive human response. This can be is a *key* differentiator, particularly when comparing costs.
- All of our dedicated database instances are running bare metal, meaning you gain consistent and reliable performance, and aren’t subject to similar massive outages caused by the muli-tenancy of a SAN.
If anyone from Amazon or Heroku would like to provide extra details of what makes them a strong choice, I’d be only too happy to post those as well.
Set/Increase Memory Available in Rubymine
I did not find anything to love about the results I was getting searching for queries like “Increase rubymine memory” and “set rubymine memory”. Here’s the location of the file that dictates Rubymine memory usage in my Ubuntu install:
[RUBYMINE_DIRECTORY]/bin/rubymine.vmoptions
Inside you can specify lines like:
-Xms800m
-Xmx1200m
-XX:MaxPermSize=1000m
-ea
These declare maximum memory usage, maximum sustained memory usage, and, uh, some other stuff.
[Hops onto soapbox]
I love Rubymine, but I sometimes wish that instead of adding a ridiculous number of new features, they’d just make the damn thing run consistently fast, and not make me worry about memory usage. I know that with my web site I always have a preference toward adding cool new stuff, but responsible thing to do is often to perfect the pieces that are already there. Almost everything negative I’ve heard about Rubymine (which isn’t all that much) is along this same vein, but I’ve never heard the Rubymine team admit that it wishes that the product ran faster or its memory management were better.
[Hops back down]
For my money, still definitely the best choice for Linux IDEs.
New Relic Apdex: The Best Reason So Far to Use New Relic
Since we first signed up with New Relic about six months ago, they’ve impressed me with the constant stream of features that they have added to their software on a monthly basis. When we first signed up, they were a pretty vanilla monitoring solution, and impressed me little more than FiveRuns had previously. They basically let you see longest running actions sorted by average time consumed, and they let you see throughput, but beyond that, there was little reason to get excited at the time.
Since then, they’ve been heaping on great additions. First, they added a new view (requested by yours truly, amongst others) that let actions be sorted not just by the average time taken, but by the arguably more important “Time taken * times called,” which tends to give a better bang-per-buck idea of where optimization time should be spent.
They’ve also been rearranging which features are available at which levels, which has made “Silver” level a much more tempting proposition, with both the “Controller Summary” (described last paragraph) and “Transaction Traces,” which allows you to see which specific database calls are taking longest to complete.
But by far my favorite New Relic feature added is their brand new “Apdex” feature. If you’re a busy web programmer or operator, the last thing you want to do is spend time creating subjective criteria to prioritize which parts of your application should be optimized first. You also don’t want to spend time determining when, exactly, an action has become slow enough that it warrants optimization time. Apdex provides a terrific way to answer both of these prickly, subjective questions, and it does it in typical New Relic fashion — with a very coherent and readable graphical interface.
I’ve included some screenshots of the Apdex for one of our slower actions at right. These show (from top to bottom) the actions in our application; ordered from most to least “dissatisfying,” the performance breakdown of one of our more dissatisfying actions; and the degree to which this action has been dissatisfying today, broken down by hour, and put onto a color coded scale that ranges from “Excellent” (not dissatisfying) down to poor. Apdex measures “dissatisfaction” as a combination of the number of times that a controller action has been “tolerable” (takes 2-8 seconds to complete) and “frustrating” (takes more than 8 seconds to complete).
New Relic is to be commended for tackling an extremely subjective problem (when and where to optimize) and creating a very sensible, objective framework through which to filter that decision. Bravo, guys. Now, hopefully after Railsconf they can spend a couple hours running Apdex on their Apdex window, since the rendering time for the window generally falls into their “dissatisfaction” range (greater than 8 seconds) 🙂
But I’m more than willing to cut them some slack for an addition this useful (and this new).
Rails Ajax Image Uploading Made Simple with jQuery
Last week, as part of getting Bloggity rolling with the key features of WordPress, I realized that we needed to allow the user to upload images without doing a page reload. Expecting a task as ordinary as this would be well covered by Google, I dutifully set out in search of “rails ajax uploading” and found a bunch of pages that either provided code that simply didn’t work, or claims that it couldn’t be done without a Rails plugin.
Not so. If you use jQuery and the jQuery-form plugin.
The main challenge in getting a AJAX uploading working is that the standard remote_form_for doesn’t understand multipart form submission, so it’s not going to send the file data Rails seeks back with the AJAX request. That’s where the jQuery form plugin comes into play. Here’s the Rails code for it:
<% remote_form_for(:image_form, :url => { :controller => "blogs", :action => :create_asset }, :html => { :method => :post, :id => 'uploadForm', :multipart => true }) do |f| %>
Upload a file: <%= f.file_field :uploaded_data %>
<% end %>
Here’s the associated Javascript:
$('#uploadForm input').change(function(){
$(this).parent().ajaxSubmit({
beforeSubmit: function(a,f,o) {
o.dataType = 'json';
},
complete: function(XMLHttpRequest, textStatus) {
// XMLHttpRequest.responseText will contain the URL of the uploaded image.
// Put it in an image element you create, or do with it what you will.
// For example, if you have an image elemtn with id "my_image", then
// $('#my_image').attr('src', XMLHttpRequest.responseText);
// Will set that image tag to display the uploaded image.
},
});
});
And here’s the Rails controller action, pretty vanilla:
@image = Image.new(params[:image_form])
@image.save
render :text => @image.public_filename
As you can see, all quite straightforward with the help of jQuery. I’ve been using this for the past few weeks with Bloggity, and it’s worked like a champ.
Monitor Phusion Passenger Memory Usage
We are on the cusp of having Passenger running, but I am paranoid, based on our Mongrel experiences, of Passenger instances leaking memory up the wazoo and eventually exhausting our system resources. With Mongrel, we’ve used monit to ensure that memory usage remains intact with each Mongrel, but I hadn’t found a straightforward way to do the same with Phusion yet. So I’m improvising:
kill $(passenger-memory-stats | grep '[56789]..\.. MB.*Rails' | awk '{ print $1 }')
This single line (run via crontab) ought to do what our thousand line monit config file used to do: kill off Rails processes that exceed 500 MB. From my testing so far, it seems to do the trick.
I have verified that it does indeed kill one or multiple Rails processes started by Passenger if their memory usage is reported as being a three digit number that starts with 5-9. Obviously if a Rails instance were able to jump past the 500-999 MB range in less time than the frequency of our cron task, that would be a problem.
Will report back once I’ve witnessed it at work in the wild.
Update from the wild: Yes, it works.
Oh Woe are We: Desecrating Rails for a Brighter Tomorrow
Rails programmer, how long do you think these glory days will last?
I first started thinking about this while attending Railsconf and talking to programmers who were creating Rails projects within gorillas such as AOL, LinkedIn, Monster, and of course Yellowpages (my apologies to AOL, LinkedIn, and Monster if any of those projects were supposed to be secret). After watching DHH’s keynote, it sunk in further. Now I hear that EngineYard just got $15m more funding, and the picture is crystal clear: the hobgoblins from years’ past that have kept Rails away from corporate use are melting away faster than polar ice cap.
This is a bad thing for those that like the competitive advantage Rails affords. With the advantage of RoR (and two tablespoons of Firebug), right now is one of those rare times in which a motivated programmer or two can compete technologically with legacy web companies that have payrolls 100x greater.
If Bonanzle could dig up an ounce of business savvy (still TBD) to go with our technology, I like to think we could be one of the seminal examples of this. Look down the list of our technological advantages vs the gorillas (real time offer making, integration with all major IM clients, image cropper, price guessers, pretty urls, 0-page-load item creation, real time messaging built into site, item importers for eBay/Craigslist, etc. etc.), and it’s clear that we’re living in an age where the possibilities for the underdog are as rife as ever.
But how long will that be the case? With a test-driven development environment like Rails, where metaprogramming and a solid MVC architecture can cut 125,000 lines of code to 20,000 lines (like Yellowpages did in moving to Rails), suddenly gorillas are nimbler, and order is restored to the world. Eventually, the gorillas might just figure this out. The horror.
In light of these facts, I have taken to pumping up the FUD on Rails whenever possible. I like my unfair Rails advantage, and would miss it if it were gone. In the interests of helping the reader perpetuate Rails FUD amongst their own social circle, I have created the following collection of sound bites to help you desecrate Rails:
- Rails Doesn’t Scale. C’mon, you know it’s true. I even preached this one myself. Tell them that “Ruby is the slowest programming language” ever. I mean, it’s slower than an excellent language like Python by a factor of 3x. It’s slower than C by about 70x! I can only imagine how much slower it is than x80 assembly. Visualize how screaming fast your assembly-driven site could be. If your listener happens to mention cloud computing, I recommend you retort with the thousands of dollars they’d have to spend on a server cloud for a heavily trafficked site. If they point out that those costs are a fraction of the development costs they’d incur otherwise, move on to point number two.
- No Big Sites Use Rails. Yes… yes… yes! In Rails’ history, excluding a couple one shot wonders like YellowPages and Twitter (don’t forget: Twitter is rumored to be leaving Rails), no “big” web site is running on Rails. Point out that both Facebook and Flickr run on PHP. Or better still, perhaps your listener would like to literally be the next MySpace and build on .NET? Hopefully they do not retort that almost none of the biggest sites were built when Rails existed, or that most new sites are built on RoR, or that any kind of bad Rails juju they encountered could be monkey patched since it’s all open source. It should suffice to say that if no big site has been built on Rails by now, no big site ever will be. Still not dissuaded?
- Google uses Python. Yes, they also use Ruby. But they use Python more. This one ought to work well when convincing a take-over-the-world CEO.
- Other Languages have More Libraries. This works sort of like number two… point out how many libraries PHP already has. Or .Net. Or Java, or C++. You can manipulate the hell out of an image with any of these choices. Or if you decided at the last minute that you wanted to make your web site into a PS3 game, you’d be glad you chose C++ and its PS3 libraries. Only the savviest enterprise-y tech guy will be able to discern between quantity and quality: think how many underdeveloped, crap libraries they’ve become accustomed to while dealing with Java.
- Open Source Software is Unsupported Software or Ruby on Rails Doesn’t Deploy on Windows or URLs Don’t Matter. Alright, if they still weren’t convinced after four points that terrific, you’re going to need to fire some scattershot. These arguments should close the case for the last few Windows types, and for others, hopefully they tilt in favor of Anything But RoR. But for the last few hard-to-budge listeners, you’ll need to pull out your ace in the hole…
- The Creator is an Ass. Have you ever listened to DHH talk? What an elitist snob. Thinks he is God’s gift to programming. The way he repeatedly cut off this nice Python fellow was disrespectful. Any framework created by this guy must be an elitist, disrespectful framework to use.
And that should about do it… double bonus points for anyone who can convince eBay to give ASP .NET a whirl!
(Note to busy/dense readers: #1-6 employ heavy use of irony)