If you want to slice to the end of a Ruby array, and/or get the end of a Ruby array, what you want is

arr[1, -1] # -1 means all the rest of the array

Install Adobe Air

wget http://airdownload.adobe.com/air/lin/download/latest/AdobeAIRInstaller.bin
chmod +x AdobeAIRInstaller.bin
sudo ln -s /usr/lib/x86_64-linux-gnu/libgnome-keyring.so.0 /usr/lib/libgnome-keyring.so.0
sudo ln -s /usr/lib/x86_64-linux-gnu/libgnome-keyring.so.0.2.0 /usr/lib/libgnome-keyring.so.0.2.0
sudo ./AdobeAIRInstaller.bin

The middle bit makes some symlinks so that Adobe Air can access gnome keyring (required for install). If you’re running 32-bit Pangolin, those two steps are slightly different:

sudo ln -s /usr/lib/i386-linux-gnu/libgnome-keyring.so.0 /usr/lib/libgnome-keyring.so.0
sudo ln -s /usr/lib/i386-linux-gnu/libgnome-keyring.so.0.2.0 /usr/lib/libgnome-keyring.so.0.2.0

Install Balsamiq

wget http://builds.balsamiq.com/b/mockups-desktop/MockupsForDesktop64bit.deb
sudo dpkg -i MockupsForDesktop64bit.deb

Or if you’re running 32-bit:

wget http://builds.balsamiq.com/b/mockups-desktop/MockupsForDesktop32bit.deb
sudo dpkg -i MockupsForDesktop32bit.deb

Yay For Easy

Thanks to Linux.org for the guidance on installing Adobe Air. The steps on Adobe’s own site are an awful mess.

The Javascript from my previous example is essentially unchanged.  It uses jQuery and the jQuery-form plugin. The main challenge in getting a AJAX uploading working is that form_for :remote 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. Following is the Rails code that goes in your html.erb. Remember that in my case I am creating an image that will be associated with a model “BlogPost” that resides in the BlogPostsController. Adapt for your models/controllers accordingly:

<%= form_for(:image_form, :url => {:controller => :blog_posts, :action => :create_asset}, :remote => true, :html => {:method => :post, :id => 'upload_form', :multipart => true}) do |f| %>
 Upload a file: <%= f.file_field :uploaded_data %>
<% end %>

Here’s the associated Javascript:

$('#upload_form input').change(function(){
 $(this).closest('form').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.
  },
 });
});

Now, chances are you’re uploading this asset from a #new action, which means that the resource (here, the BlogPost) that will be associated with the image has yet to be created. That means we’re going to need a model that we can stick the AJAX-created image in until such time that the main resource has been created. We can do this if we create a migration for a new BlogImage model like so:

def self.up
  create_table :blog_images do |t|
    t.string :image
  end
  add_column :blog_posts, :blog_image_id, :integer # once created, we'll want to reference the BlogImage we created beforehand via AJAX
end

The corresponding BlogImage model would then be:

class BlogImage < ActiveRecord::Base
  mount_uploader :image, BlogImageUploader
end

Of course, if your resource already exists at the time the AJAX upload will happen, then you’re on easy street. In that case, you don’t have to create a separate model like BlogImage, you can just add a column to your main resource (BlogPost) and mount the uploader directly to BlogPost. In either case, the BlogImageUploader class would be setup with whatever options you want, per the Carrierwave documentation.

Continuing under the assumption that you will separate your model from the main resource (in this case, the BlogImage, which is separate from the BlogPost), we can create this image before the BlogPost exists, and stash the BlogPost id however you see fit. Thus, your controller’s #create_asset method will look like:

def create_asset
  blog_image = BlogImage.new
  blog_image.image = params[:image_data][:uploaded_data]
  blog_image.save!
 
  # TODO: store blog_image.id in session OR pass ID back to form for storage in a hidden field
  # OR if your main resource already exists, mount the uploader to it directly and go sip on a 
  # pina colada instead of worrying about this
 
  render :text => blog_image.image.url
end

And that’s it. No new gems, plus low-fat Javascript and controller additions.

Bonus section: How to embed this AJAX upload form in the form for its parent resource

One of the more common questions from my last post was how to display this AJAX image upload amongst the form for another resource. There are many ways to accomplish this (see comments from last post if you’ve got time to kill), but in keeping with the spirit of simplicity in this post, one fast hack I’ve used:

1. After all the form fields for the main resource, close the form without a submit button
2. Insert the AJAX form
3. Add a link below the AJAX form that is styled to look like a button. Have this link call Javascript to submit your main form

Not going to win any beauty contests, but easy to setup and gets the job done.

We had a write-intensive database table with small row size and a moderately big size (~700mb).  After waiting about 30 minutes for the alter table to complete, I finally got fed up and attempted to kill the alter table’s thread.  The thread did indeed change to a “killed” state rather than a query, but that killed state was still there 30..60..90 minutes later (all the while claiming that it was “renaming results table”).  Moreover, about 1800 threads that had become stuck waiting on the alter were sitting around on our Mysql process list.

I tried various remedies, from looking for deadlocks in “SHOW INNODB STATUS\G” (no deadlocks, just 1800 patiently waiting threads), to looking for the temp table that had supposedly been getting built to see if it was progressing (it wasn’t).  About three hours into the event, I decided we might as well kill the 1800 stuck processes in case it would take a DB restart to finally clear this alter table.  I followed these instructions on how to kill Mysql threads en mass, and got us down to just the alter thread along with a couple waiting threads that hadn’t been in my list of threads to kill.

Then, about two minutes later, something mysterious happened.  The alter command finished.

All of the Googling and Mysql info delving I could manage would not reveal what it was that had left the ALTER command stuck so much longer than it typically takes for a table of its size.  But whatever was keeping the alter command from finishing seems clearly to have been related to the 1800 threads that were sitting around waiting on the alter to complete.  Once we purged these, the alter finished within a couple minutes.

Hopefully this is a helpful alternate idea to try if you should find yourself with an ALTER TABLE that refuses to die no matter what steps you take.

The answer, straight from Google, makes a lot of sense:

So the one that enters the auction will be attributed with the clicks and impressions and this is dependent on the performance history associated with that auto target. The one with the stronger performance history – clicks and CTR attributed to it, will enter the auction and hence get the impressions.

Additionally if they are from different ad groups – the past ad group performance history and ad group level CTR would also matter.

Thus the answer:  whichever auto target performs best has the best chance of being shown in Google’s Adwords “auction” (the name they give to the process of choosing which Adword or GS products to show).

However, one characteristic that I have seen be consistently predictive:  starting at a young age.  Gates, Woz, and even Jordan did it.

I am not in position to say whether I make for a good, great, or gruesome coder (1).  But I know that my history with computers is epic:

• 1993: Age 13. Get our first computer, a Packard Bell 486SX/33 with 4MB of RAM.  It came with a San Diego Zoo App, an encyclopedia, and a really lame racing app of some sort (not to mention all the Win 3.1 niceties).  (2)
• 1993: Learn how to use DOS, configure games to use extended memory, figure out how windows system config files work
• 1993: Discover QBasic.  Disappointed to learn that it doesn’t compile to exes.  Decide to write a choose-your-own-adventure game with it anyway, complete with ASCII graphics.
• 1994: Start a BBS (search for “Bill Harding” in the list), get the most calls in Poulsbo/Bremerton/Silverdale area (not saying much)
• 1994: Enroll in the first of two computer programming courses at local community college (4.0).
• 1995: Wrote VBBS scripts to emulate about five most popular BBS flavors (PCBoard, OBV/2, Renegade, etc).  To my knowledge, no one else accomplished this.  It was like carving a pumpkin with a butter knife.
• 1995: Finish the community college computer programming courses with 3.9 average
• 1996: Discover I prefer girls to computers

From 1996 until late-college were the dark ages of Bill programming, wherein I spent the better part of my teens having forgotten about that whole computer thing. (3)

But the reasons coding was so magnetic to me are the reasons it still is:   a chance for me to dream up whatever I could think of, and then make it become real to feel the rush of creation.

It’s like what businesses are supposed to be:  you decide what’s important to you, and then go make that vision into reality.  But in business, there is constant compromise and pragmaticism that ultimately rules the day, unless you’re Steve Jobs.  For a competent coder, they can at any time create the best program (of a certain type) across all human history.  It could be used by thousands or millions of people.  If it’s important enough to spend years on.

Even in the more pragmatic here and now, I know of few other jobs with a comparable opportunity to build something that matters with one’s own two hands.  This is why I latched onto programming so tightly & immediately at age 13.

Most of these characteristics are present by early teens:  the desire to build things, the capacity to solve problems, the joy of seeing a project completed… I think of them as “born qualities;” thus, my hunch is that if the teenager has access to a computer, they’ll probably figure out pretty quickly if they’re a programmer or not.

Update:  interviewed about 50 UW CS students today. The earliest coder of the bunch started in his late teens. The vast majority started when they entered the program (??!!).  So perhaps this theory is bunk, or these kids all suck.

(1) I suppose that having built Bonz is strong circumstantial evidence that I’m not gruesome

(2) Note how I remember the software that came with my first computer in as much detail as my first kiss

(3) Not entirely true; I did still fix old people’s computers at exorbitant prices (consistent with what other computer fixers charged). But mostly the cute girls beat the computers in this round.

Eventually we moved to HopToad (now Airbrake). It was better, but lacked key functionality like being able to close exceptions en masse or leave comments on an exception.

From there we moved to Exceptional, which we ended up using for the past year.  It was alright, when it worked.  The problem was, for us, it frequently didn’t work.  Most recently, we spent the last week having received two exceptions reported by Exceptional, when New Relic clearly showed that hundreds of exceptions had happened over that time period.  Also damning was the presentation of backtraces, which were hard to read (when present), as well as an error index page that made it difficult to discern what the errors were until they were clicked through.

Enter Errbit.  Jordan found this yesterday as we evaluated what to do about the lack of exceptions we were receiving from Exceptional.  Within a couple hours, he had gotten Errbit setup for us, and suddenly we were treated to hundreds of new exceptions that Exceptional had silently swallowed from our app over the past year.

But it’s not just that Errbit does what it is supposed to — it’s the bells and whistles it does it with.

Specifically, a handful of the features that make Errbit such a great solution:

• Can set it up to email at intervals (e.g., 1st exception, 100th exception) so you hear about an exception when it first happens, and get reminded about it again later if it continues to be a repeat offender
• Allows exceptions to be merged (or batch merged) when similar
• Allows comments by developers on exceptions, and shows those comments from the main index page so you can quickly see if an exception is being worked on without needing to click through to it
• Easy to read backtrace, plus automagic tie-in to Github, where you can actually click on the backtrace and see the offending code from within Github (holy jeez!)
• Liberal use of spacing and HTML/CSS to make it much easier to read session, backtrace, etc relative to Exceptional and other solutions we’ve used
• Open source, so you can add whatever functionality you desire rather than waiting for a third party to get around to it (a fact we’ve already made use of repeatedly in our first two days)
• Open source, so the price is right (free)

Simply put, if you’re running a medium-to-large Rails app and you’re not using Errbit, you’re probably using the wrong solution.  Detailed installation instructions exist on the project’s Github home.

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

class MyUploader < CarrierWave::Uploader::Base
  version :custom_thumbnail do
    process :some_fancy_processing
  end
 
  def some_fancy_processing
    # Here our context is the CarrierWave::Uploader object, so we have its full
    # assortment of methods at our disposal.  Let's say we want to open an image with
    # openCV and smooth it out.  That would look something like:
    cv_image = OpenCV::CvMat.load *([ self.full_cache_path ]) # See past blog post on the origins of full_cache_path
    cv_image.smooth(5,5)
 
    # The key to telling CW what data this thumb should use is to save our output to
    # the current_path of the Uploader, a la
    cv_image.save_image(self.current_path)
  end
end

Just call #custom_thumbnail.url on your Uploader instance, and you should get the path to the custom result you created.

Using this framework you should be able to get CW to perform whatever sort of custom image processing you want. Thanks to these fellows for helping me decode the #current_path magic here.

Step 1: Retrieve from your store (the external place your file exists) to cache (your local machine).

my_cw_uploader.cache_stored_file!

After running that, if you call

my_cw_uploader.cached?

You should get a long string that is the filename for the file that got cached. Note that the cache status of a file is only saved on a per-object basis, so if you try something like

Image.find(1).my_cw_uploader.cache_stored_file!

… you will never again see the object that did the caching, and you will never be able to use that cache. Only call #cache_stored_file! on an object you are keeping around.

Step 2: Go access the file that you cached. Not quite as easy as it sounds. For this, I mixed in the following into my uploader class

module CarrierWave::Uploader::Cache
	def full_cache_path
		"#{::Rails.root}/public/#{cache_dir}/#{cache_name}"
	end
end

So now when you call

my_cw_uploader.full_cache_path

You’ll get the full pathname to the file you downloaded.

Hope this helps save someone else from an hour of Google hell.