PullMonkey Blog

Dynamic Select Boxes – Ruby on Rails 3

Over 4 years ago, I wrote a tutorial for doing dynamic (cascading) select boxes.
Still getting comments and emails to this day. Mostly asking how to get this working with rails 3, which has moved from prototype to jquery.
So here's a tutorial for getting 3 select boxes to trigger updates for each other.

First set things up:

I just used the html5 haml twitter bootstrap, etc template. Really useful.

If you need data, here's what I used - put this in your db/seeds.rb file:

Next, setup your model associations:

Genres have many artists.
Artists have many songs.
Genres have many songs through artists.

I'm just using a home controller to setup variables for the index page as well as setup variables for use in the dynamic updating:

Now the view just has the 3 select boxes and the unobtrusive javascript (triggered onchange) to make the ajax calls for updating:

We need our rjs files for updating the select boxes, one for the songs (when artist changes) and one for the artists and songs (when genre changes):

Our routes are simple:

That's it.

UPDATE: Here's an erb alternative for index.html.

And the js.haml can be converted to js.erb by taking #{...} and converting to <%= ... %> :

Using Ruby to read from a MagTek USB Card Reader

Been playing around with a lot of USB devices lately, to get them to play nicely with some of our touch screen Rails apps.
One of the devices is a card reader - specifically a MagTek reader, and the same code works for the ELO reader.

I've tried a billion different ways to ensure we're reading in all the data. At first, I was just asking the usb stream to present me with a certain number of characters, b/c that's how all the examples do it.
But we're using a lot of different cards with the readers, so that didn't work too well. So now I just read one character at a time until we find the new line.
Here's the code to find the device, open it, close it and read from it, all whilst finding and converting the data as required.

So using this code, we take the swiped data and send it to our server for storage.

Signature Pad in Linux

I'm using the topaz model T L462 HSB. It's nice now that it works. But what a PITA to get it going. The biggest problem with the device is the documentation. There is no low level documentation explaining the representation of the bytes coming in over usb. So you are stuck using their libraries which expose some poorly explained API.

Anyway, like I said, great when it works. So I'm working in linux which basically leaves me having to use java libs and a shared object file.

Here's my code:

It sits and waits until the sig pad gets some points on it. Once we have points it waits for a lapse in time where there is no change in the number of points.
Once we've decided that we have captured a signature, we store it to a file.
Then we shell out to a ruby script - see the httpi and curb article - which is how I get the file to our rails server for display and verification from the user.

Now, you'll need a few files. Most of which can be found in the java zip download from the vendor site.
From that zip, you should grab the following:
SigPlus2_60.jar
RXTXcomm.jar
libSigUsb.so - if you need the 64 bit version, go here - http://www.topazsystems.com/Software/libSigUsb7242012.zip

Then I just used eclipse to set everything up and build. Works well so far.
The only thing you may need to change is the model (I have mine set to SignatureGem1X5) and com port (I have mine set to HID1).

Using HTTPI with Curb to do multipart file uploads with spnego

It took a while to find a library that handled spnego requests, as opposed to shelling out to a curl --negotiate. Found httpi to work well with the curb adapter.
The problem was that the documentation didn't really explain how to do file uploads withing the httpi request block.
Wasn't too much of a big deal, but I thought it may save someone else some time.

Headers and Footers in ruby’s Spreadsheet gem

Have you ever needed to add a header or footer to your spreadsheets in ruby?
Yah, well, we have 🙁
Yes, you can do this with the Write Excel gem.
But we've already written years worth of spreadsheet code with the spreadsheet gem and don't want to rewrite it all.

Anyway, we thought we'd share our little trick to get page headers using the spreadsheet gem.

So what you see here (above) goes into a config/initializer, something like RAILS_ROOT/config/initializer/enable_headers_in_spreadsheet_gem.rb. Here's what's going on:

1) We know that the write_from_scratch method is called when everything is said and done and the data is ready to be written to the spreadsheet file. So we make use of this and alias that method to write_from_scratch_without_header. Which opens us up to call our write_header method inside our write_from_scratch method which, of course, will call the original write_from_scratch method.

2) Our write_header method makes use of the already existing opcode for Header in the spreadsheet gem. It's not being used, so my guess is the developers intend on solving this issue at some point. We have to send the opcode, the length info and the string we want to write out. This was the trickiest part to figure out.

3) We expose an add_header method that simply takes a string and stores it in the header accessor. This means, to set the header, you simply say sheet.add_header("foo header").

To implement the footer, you'd just do the same thing, create a footer accessor, add a method to update it. Then build the writer_footer method with opcode(:footer) and append write_footer at the end of write_from_scratch.

Well, that took us some time to figure out, so enjoy and let me know if you have any questions.

Ruby’s stacked conditionals – who knew?

puts "hello readers" if you_are_a_reader if you_can_read unless you_already_read_it

I was playing around with some project euler code I'm working on (anyone else figure out the Pencils of Rays with code that executes in less than a minute??). Anyway - I was going through my code and adding "if debug" to the end of all my puts statements b/c I didn't want to see them for the next run through. So by mistake, I blindly added "if debug" at the end of 'puts "odd" if odd', giving me 'puts "odd" if odd if debug'. Neat. Then, going through trying to find the bottlenecks, I noticed it. So jumped into irb to make sure it was legit and it was.

Interesting. Not sure where I'd ever use it, though.

Azilink is working again !

If the apk is not available for download yet, you can build it yourself with the fix from here.
Step 1 - Grab the source from svn -

svn checkout http://azilink.googlecode.com/svn/trunk/ azilink-read-only

Step 2 - Update the UdpDriver.java per this azilink issue.

Step 3 - Build and install the apk

# this will give you a build.xml file
android update project --target 2 --path /path/to/your/azilinkdownload/
# after plugging in your device and from your azilink project directory
ant debug install

Step 4 - Install Open VPN

sudo apt-get install openvpn

Step 5 - Grab the azilnk.ovpn file from the downloads section.
Place somewhere you won't lose it.

Step 6 - Copy this resolv.azilink file to the same place as the azilink.ovpn

Step 7 - Copy this azilink script to somewhere you can get to it

Step 8 - Start azilink on your phone.

Step 9 - Run the script from step 7.

That's it.

Hello Android – Pindah (with Mirah) Application

Did you install the Android SDK / JDK, etc?  If not, start here - http://developer.android.com/sdk/index.html.
If you're running 64-bit like me, make sure to install the ia32-libs, since the SDK is 32-bit.

This is completely based on the Hello Android tutorial - I didn't really do a whole lot, but the hope is that this will help get some more ruby devs into android development with a simple how-to.

Step 1 - Setup RVM with jruby

Note: RVM is awesome, if you don't use it or don't know about it - read more here.

rvm install jruby
cd /path/to/your/android/pindah/mirah/project/dir/
# using your .rvmrc will trigger `rvm use jruby` when you cd into your project dir.
echo "rvm use jruby" > .rvmrc
# this will make sure your .rvmrc is working, you should then be able 
# to use rvm info and see jruby
cd .

Step 2 - Install the mirah and pindah gems

# too easy
gem install mirah pindah

Step 3 - Create your first pindah app

pindah create com.example.android.hello_world
cd hello_world

Step 4 - Create your activity - HelloAndroid.mirah

# from your project dir and inside your pindah app dir 
<editor> src/com/example/android/hello_world/HelloWorld.mirah

This is the code I used:

Step 5 - Setup your AndroidManifest.xml file

This is where you define your app, version, name, etc, but more importantly for this example - what activity will handle your main intent.
Mine looks like this:

Step 6 - Install to your device

# make sure a device is recognized  ... 
# and make sure adb is in your path (platform-tools in the SDK)
adb devices
rake install

Playing with Mirah

Mirah (formally duby) is pretty freaking cool.   Plans are to scrap java and use mirah for future android development, we'll see.  Here's a rough example of some pretty basic mirah.

To get started, you'll need jruby and the mirah gem:

rvm install jruby
rvm use jruby (or put in your .rvmrc)
gem install mirah

Then create an example:

puts "hello world!!"
500.times do |x|
  puts x
end

Time in ruby:

time ruby test.mirah

...
=> .457s

Compile to Java and time:

mirahc test.mirah
time java Test

....
=> .081s

Less than 1/5 the time and it compiles to Java ... neat 🙂

mirahc -j test.mirah

// Generated from test.mirah
public class Test extends java.lang.Object {
  public static void main(java.lang.String[] argv) {
    int __xform_tmp_1 = 0;
    int __xform_tmp_2 = 0;
    int x = 0;
    java.io.PrintStream temp$1 = java.lang.System.out;
    temp$1.println("hello world");
    __xform_tmp_1 = 0;
    __xform_tmp_2 = 500;
    label2:
    while ((__xform_tmp_1 < __xform_tmp_2)) {
      x = __xform_tmp_1;
      label3:
       {
        java.io.PrintStream temp$4 = java.lang.System.out;
        temp$4.println(x);
      }
      __xform_tmp_1 = (__xform_tmp_1 + 1);
    }
  }
}

VIN API – fair pricing model

It can't be a shock to any of you that after many months (wait - more like a full year) of running VIN API completely free and out-of-pocket, it is time to monetize. As I am sure most of you know, the back-end data is quite pricey. For example, a monthly subscription for a "lite" data set (your typical year, make, model, engine type, etc) at one of the better known distributors would run you about $260.00 a month for ~800 VIN decodings. This is some very expensive data at 32.5 cents a VIN. Some of you that use our API are running 50,000+ VINs through in a weekend, that is $16,000! Wow!

Ok, so what did we decide to do? Well first, and most importantly, we decided to keep the service up and running; for a while there it was looking pretty bleak and if you take a second to look at the numbers (financially) you can understand why. Anyway, to be as fair as possible, we did not feel this could be monetized as a subscription-based product, some months you need 500,000 VINs and some only a 1,000. Looking at the data for year, we had many questions - what plan would you pick? should the plan rollover it's unused decodings?

We discovered a lot of complexity in the subscription model, so we decided to setup the pay as you go plan, where you buy your decodings at various bulk levels. For instance, you could buy in groups of 1,000 or 10,000 or 100,000 such that you would realize savings on a price-per-VIN basis the larger the group you purchase. There is no use policy either, so you can sit on the VINs for as long as you want, or you can even buy decodings the day (even the minute) before you need them. No monthly credit card bill, no rollovers, just simple "buy what you need," and if you buy in bulk, you save.

Another consideration in doing this was having to maintain soft limits. For example, if the user purchases the 5,000 VINs per month plan, and the their site does well this month and they need 6000 VINs, should they have chosen the 10,000 VIN plan? We didn't think so, we figured no hard limit, just soft limits, and after the soft limit is hit, we would charge the additional VINs at the current rate per VIN to the user's next month's bill. We tried to explain this to a few current users that are helping us come up with reasonable rates and they were not all that thrilled about it. So we had a problem, we did not want users to pay for what they did not need, but at the same time we did not want to cut users off in the middle of a month when they hit their limit. That entire idea had to be scrapped and along with it went the idea behind the subscription plan itself. We like it though, it's simple now - buy your decodings and use your decodings, we will email you if you are getting low and may want to add decodings to your account.

Subscription models are great for static resources and static services, but not a single one of our customers decodes the same number of VINs each month, so it just won't work. So onward and upward, pay as you go and regardless of how the other API providers offer their service, we are excited to be a little different and lot cheaper as you will soon find out.

Enjoy!