On Local Tunnels

January 19, 2012 § Leave a comment

PayPal can be a pain in the butt to integrate in with your website. I sit next the guy on our team tasked with doing PayPal integration. I swear I can see the wrinkles and gray hair starting in on him. One of the biggest pains you’ll run into is testing the callbacks and web hooks. If you are doing anything more than putting a little donate button on you site, you’ll be dealing with IPN callbacks to keep your database in sync with PayPal. Typically your doing your development on a local machine that isn’t exposed to the outside world so you can’t have them post directly your dev machine. Bummer. There are a number of ways one can go about dealing with, I’ll mention two that we have tried before we found the third.

Test it on Prod

Nothing ever goes wrong when you do this right? A better solution here is to set up a separate staging machine that is hooked up to the PayPal sandbox, but setting up boxes just to do some sporadic testing really sucks. What if there was a service you could just point PayPal at to and just showed you what PayPal was posting, would that be better?

Postbin.org

postbin.org is a nice little service that provides web hook endpoints. It’ll give you a url to give PayPal as a callback url. When PayPal post to this url you’ll be able to inspect the request it sends. Unfortunately you’ll then have to manually parse it and figure out a way to post that info locally on your machine. But hey, no extra machines floating around in your cloud just wasting space and money! But there still has to be a better way to do this. I really would rather all of this just go to my local dev machine. Please tell me this can be done!

localtunnel

Enter localtunnel. localtunnel is a ruby gem that does what the name implies. It hooks your local server up to the world wide web by tunneling to a subdomain of localtunnel.com. You simply install and run the gem giving it your public key and a port and BOOM. http://as2js.localtunnel.com now points to your local dev machine. The PayPal IPN’s can now trigger all that nice sync code you have written.

I am currently working on some GitHub continuous integration web hook stuff, so this tool has been invaluable. Priceless even. The only additional thing I would like to see with this gem would be a way to deploy the server side to your own machine. While localtunnel.com is fine and dandy, I’d feel better if I controlled all the stops of the data. Anyways, get you localtunnel up and you web hooks on!

On Riding the Latest Rails

December 29, 2011 § Leave a comment

Note: I wrote this up a few weeks a go, but didn’t publish it for some reason. It is a touch out of date since Rails 3.2 RC1 was recently released, but should be close enough to give you a good idea on how to get up and running on Rails master.

I wanted to play with the latest and greatest for Rails, which at the time of writing is 3.2.0.beta (RC 1 is now out). This means building and installing the rails gem locally. It took me a good while to figure out how to get everything working, so I figured I’d throw it down here for future reference… and for anyone else running into the same problems I did.

I am using rvm to isolate my different gem set ups, so as not to get random version conflicts. These are the lists of commands with notes I ran to get everything up and running:


# create a new gemset to use with rails master
rvm gemset create rails-master
rvm gemset use rails-master

# this is where I am going to put all of the git repos
cd ~/src

# Rails 3.2.0.beta requires the most recent (as in master)
# versions of arel and journey

git clone git://github.com/rails/arel.git
cd arel
gem build arel.gemspec
gem install arel-*.gem

cd ..
git clone git://github.com/rails/journey.git
cd journey
gem build journey.gemspec
gem install journey-*.gem

# now get Rails
cd ..
git clone git://github.com/rails/rails.git
cd rails

# install all of the Rails pieces,
# i.e., ActiveRecord, ActiveSupport, etc...
cat RAILS_VERSION | xargs ruby install.rb

# check to make sure you are riding the correct rails
ruby -r 'rails' -e 'puts Rails::VERSION::STRING'

You can get just the commands in a gist too.

On My Projects Becoming Obsolete

December 27, 2011 § 1 Comment

Rails 3.2 RC1 was released last week and it announces some pretty cool new things. One of those things is something that I have played with building out myself (tagged logging) and another is something I actually did (ActiveRecord Store). When I wrote my data-attributes gem, I was inspired to do so because I had a users table that had an ever-growing number of email permission checks. I never queried against these, and they made doing a SELCET * FROM users; really painful to try and read. I decided to just throw them all in a serialized column and be done with it.

When I first read the release notes for 3.2 I had two thoughts go through my head.

1) Well, crap. data-attributes is now dead and useless. (yes, I use <code> tags in my head)

2) Awesome, the solution I came up with for a problem I was having is the same one that the Rails team came up with. Maybe I might know a thing or two about what I am doing.

But as I started to compare the new ActiveRecord::Store with data-attributes, I began to realize that my little project isn’t dead quite yet. The accessors generated by the store call with AR::S aren’t full attribute accessors. By this I mean they don’t go through read_attribute and write_attribute before committing the new data to the serialized hash. This prevents you from intercepting the accessor call and doing some pre/post processing. You also don’t get default values as with other attribute accessors. Definitely not a huge deal in the least, but something to be aware of. AR::S does mark things as dirty though. data-attributes does not do this as of yet.

As for the future for of data-attributes, I think that it is actually dead in the long run. If I were to work on this problem more in the future, I’d probably do so by adding the AR::S instead of continuing working on data-attributes.

On New Gems

November 1, 2011 § Leave a comment

One doesn’t go through the process of starting a new ruby gem all that often. Even if you have published a few, it is easy to forget how get one started. So here, for my benefit as much as anyone else’s, is a quick easy way to get a gem started and hosted on GitHub.

On the command line navigate to the directory you want to use to work on your different gems.

> cd ~/Projects/gems

I like using bundler, so this is what I do:

> bundle gem <gem name>
    create <gem name>/Gemfile
    create <gem name>/Rakefile
    create <gem name>/.gitignore
    create <gem name>/.gemspec
    create <gem name>/lib/<gem name>.rb
    create <gem name>/lib/<gem name>/version.rb

It will create a directory for you with the gem name and initialize a git repo for you with everything already staged to be committed. Now you need to create a new repo on GitHub. It’s pretty straight forward, so I’ll let GitHub’s on screen instructions take it from there. My only suggestion would be to make the project name the same as your gem name to avoid confusion.

Note: If you use dashes “-” instead of underscores “_” in your gem name, bundler will treat them as module hierarchies and build folders to accomodate.

Now cd into your new gem’s directory.

> cd <gem name>

Hook the git repo up with GitHub. The link should be shown on the empty repo’s main page. Just copy that.

> git remote add origin git@github.com:<GitHub username>/<GitHub Project Name>.git

Now commit your skeleton. Everything is already staged for you.

> git commit -m "Initial commit"

Now push it out to GitHub

> git push origin master

And just like that you are ready to start working on your new ruby gem. You’ll also want to remember the following commands:

> rake build   # build <gem name>-<version> into pkg directory
> rake install # build and install <gem name>-<version> on local machine
> rake release # tags the repo with the version number and pushes new version out to RubyGems.org

Google will be able to tell you more about filling out the .gemspec file than I can. This is just to get you up and running.

On Pure Ruby Sparse Matrices

October 18, 2011 § Leave a comment

A while ago I was working on a web app built on Rails that needed some very basic tag analysis. Having once upon a time obtained a MS in Computational Mathematics I will always view tags as a big matrix. A big, sparse matrix with tag names along one dimension and the objects being tagged along the other. When you think about tags like this all kinds of avenues of analysis open up.

You can think of objects as tag vectors (or tags as object vectors) with non-zero entries representing the tags on an object. By multiplying two tag vectors together you get the dot product (or cosine similarity) of the two vectors. This a nice rough estimate of how similar two objects are with respect to their given tags.  Multiplying a tag vector (a.k.a. the query vector) with whole matrix will find you the most similar objects (or tags). Math is fun!

To this end I started poking around trying to find a sparse matrix library written for ruby to make my life easier. Alas, no glory. Now I know that Ruby doesn’t have the same math support that, say python has, but I would have thought someone would have thrown something usable together.

Side note: NumPy and SciPy are awesome.

I ended up hacking together a very basic SparseVector class to take care of my immediate needs, but felt that there was a chance to create something new for the community. I looked at things like LAPACK ruby binding and NArray, but these all dealt with dense matrices. My data was incredibly sparse, so they didn’t really cut it. With that said, I have been working on a sparse matrix gem. It’s a pure ruby implementation, so it should be nice and portable and good enough for small prototypes and datasets. I wanted it to be in Ruby so that I could subclass it off of the standard library Matrix class and have it run anywhere Ruby runs. Not having any bindings to compile is a plus for me, since it means I don’t have to worry about the different environments it might be running in. If you are working with really large datasets then this probably isn’t for you right now.

Check out my progress over on GitHub.

On the Differences of Months

July 28, 2011 § Leave a comment

Dealing with dates is hard.  Dealing date calculations is harder.  Luckily, in the Rails world we have ActiveSupport to help us with a lot of this.  It actually does so much, that I usually forget how much of a pain dealing with dates is suppose to be.  However, there are times now and then that I am reminded.  Little edge cases that haven’t yet been built into ActiveSupport.  One such edge case is determining the number of months between two dates. Why do months have to have different numbers of days?

This particular use case can be very useful when dealing with recurring payments.  Calculating the number of payment cycles a subscriber has gone through can tell you how much revenue they have generated.  I have put together two class methods for the Time object that will calculate just this.  One is a simple loop that takes time proportional to the time between the start and end times, and the other a more efficient direct calculation of the same number.

The simple loop looks like:

def months_between2(start_date, end_date)
  return -months_between2(end_date, start_date) if end_date < start_date

  count = 1

  while true
    return count - 1 if (start_date + count.months) > end_date
    count += 1
  end
end

It just starts at the start_date and keeps adding months until it passes the end_date. Not particularly difficult, but should get the job done for most cases.  All the complexity of the more efficient version comes from checks dealing with the various cases arising from different months having a different number of days. Anyways, the source code for that one looks much nicer over on GitHub.

On the Size of a String

July 21, 2011 § Leave a comment

In computer programs, number constants can be interesting and bewildering things.  Trying to figure out why one was chosen over another can be really confusing.  For a good while I was confused as to why ActiveRecord would set a string attribute to be a VARCHAR(255) in the database.  It limits the size of the string attributes to 255 characters long.  256 is a bit more natural when choosing constants in computer science.  255 is commonly used to denoted the last index in a 0-based array of 256 elements.  So why 255?  The short answer is “because of InnoDB and UTF-8 character sets.”

InnoDB has a limitation on the size of a key for a single column index of 767 bytes.  When the table is encoded with a UTF-8 character set, each characters has the possibility of using 3-bytes to represent its intended character.  That means in order to be able to fully index a UTF-8 encoded varchar column, the string must be able to be represented in 767 bytes.  767 / 3 = 255 2/3.  This means that the largest UTF-8 encoded varchar column can be 255 characters long, hence the ActiveRecord default string attribute size.

Problems on the Way

As bigger and bigger pushes are made for complete internationalization, we’ll see more things encoded with UTF-16 and UTF-32.  Characters using these encodings might require up to 4 bytes to represent their value.  When this happens, ActiveRecord will need to reduce the size of indexable string attributes to 191 characters.

For Fun

Here is a truly awesome magic number that seems to come out of no where, 0x5f3759d5.

On When Create Is Not Like Create

July 14, 2011 § Leave a comment

I recently ran into an interesting issue in ActiveRecord while trying to set default values on an object using the after_initialize callback.  One would think the following blocks of code would be equivalent:

# new, save
Product.new(:name => "Awesome Product").save

# new w/ block, save
product = Product.new do |p|
  p.title = "Awesome Product"
end
product.save

# create
Product.create(:title => "Awesome Product")

# create w/ block
Product.create do |p|
  p.title = "Awesome Product"
end

In 99.9% of cases this is going to be true.  The last one, create with a block, however, can potentially cause you some problems if you are using after_initialize. The problem arises when you use after_initialize to set default values for attributes are are dependent on other attributes. Let us consider our Awesome Product has two more attributes, msrp and wholesale_price, that are tied to each other. If we have one of them we can always determine what the other should be. In this case, there wouldn’t really be a reason set both of them when creating a new object. Just set one and let the other one get set automatically.

For our example we’ll say, msrp = 2 * wholesale_price. You might use an after_initialize that looks something like this:

def after_initialize
  # set wholesale_price based on msrp
  if !msrp.nil? && wholesale_price.nil?
    self.wholesale_price = msrp / 2
  # set msrp based on wholesale_price
  elsif msrp.nil? && !wholesale_price.nil?
    self.msrp = wholesale_price * 2
  end
end

We can instantiate an object like this:

product = Product.new(:name => "Awesome Product", :msrp => 20)
 => <Product ...>
product.save
 => true
product.msrp
 => 20
product.wholesale
 => 10

Everything is working as it should. Now let’s use create instead of new and save.

product = Product.create(:name => "Awesome Product", :msrp => 20)
 => true
product.msrp
 => 20
product.wholesale
 => 10

Still works just fine. Now create with a block:

product = Product.create do |p|
  p.name = "Awesome Product"
  p.msrp => 20
end
 => true
product.msrp
 => 20
product.wholesale
 => nil

Uh, oh… Why didn’t wholesale_price didn’t get set? Take a look at the implementation of create in ActiveRecord::Base.

def create(attributes = nil, &block)
  if attributes.is_a?(Array)
    attributes.collect { |attr| create(attr, &block) }
  else
    object = new(attributes)
    yield(object) if block_given?
    object.save
    object
  end
end

Notice in the else block that a new object is created and then the block is yielded. This means that the after_initialize callback is run on the instantiated object BEFORE the block code is run. msrp is not set yet when after_initialize is run, so wholesale_price can’t be set. create without a block work fine because it is literally the same as using new and save.

TL;DR – after_initialize runs before the block code when using create and a block. Be careful when using after_initialize to set default values for attributes that depend on other attributes.

On Cross Subdomain Cookies

July 12, 2011 § 1 Comment

The first Ruby gem I ever wrote was tld-cookies.  While it is very poorly named, probably should have been called root-domain-cookies or something like that, it adds a nice little bit of functionality to the Rails 3 cookie jars.

One of the things about Rails 3 that I thought was really cool, was the way cookies were accessed. It’s not a big and fancy piece of code, but to me it is just a slick way to do things. The chaining of the different cookie jars makes it trivial to create the cookies you want and need.

cookies.permanent.signed[:awesome_cookie] = "cookies awesomeness"
cookies.signed[:awesome_cookie]
 => "cookies awesomeness"

At the time I was working on a project at work that required the use of a lot of dynamic subdomains, and we wanted to be able to write cookies across all of the subdomains as well as for individual subdomains. In Rails 3 you could set the domain when you write to the cookie like:

cookies.signed[:awesome_cookie]     = { :value => "cookies awesomeness",           :domain => "example.com" }
cookies.signed[:awesome_cookie_sub] = { :value => "cookies awesomeness subdomain", :domain => "sub.example.com" }

Now that is a lot of extra work and looks pretty ugly. You could set the default domain for you cookies like this:

Rails.application.config.session_store :cookie_store, :key => '_app_name_session', :domain => :all

But I guess I’d rather explicitly say when a cookie is to be used across all subdomains. To this point I tld-cookies add a tld cookie jar to your Rails 3 app which sets the domain for the cookie to be the root domain, i.e. example.com.

cookies.tld.signed[:tld_cookie] = "ACROSS ALL SUBDOMAINS!!!"
cookies.signed[:tld_cookie]
 => "ACROSS ALL SUBDOMAINS!!!"

As you can see above, you use it similarly to how you would use the permanent cookie jar. The slight difference is when you want to delete the cookie you have to use the tld accessor.

So yeah, first Ruby gem. Poorly named, fun little learning project.

On Selecting A Single Column

July 9, 2011 § 1 Comment

Many times when we are selecting a rows out of the database we just want a single column and have no need for the entire object. There are a number of ways to accomplish this with ActiveRecord. One can get all the records from the database and then collect the attribute needed:

Posts.where(:status => 'published').collect(&:id)
=> [ 1, 5, 8, 10 ]

This has the benefit of being able to us any overwritten accessors, but has a lot of overhead associated with generating the objects. Another way to do it is to go directly to the database:

ActiveRecord::Base.connection.select_values("SELECT id FROM posts WHERE status = 'published'")
 => [ 1, 5, 8, 10 ]

This is much faster, but requires one to use the direct connection to the database and have the SQL literal prepared. Not particularly user friendly even if you can get the SQL literal using the to_sql:

ActiveRecord::Base.connection.select_values(Posts.where(:status => 'published').select(:id).to_sql)
 => [ 1, 5, 8, 10 ]

Wouldn’t it be nicer if you could just do the following:

Post.where(:status => 'published').select_column(:id)
 => [ 1, 5, 8, 10 ]

The select-column gem provides the above functionality above.  You can you it in your Rails 3 app or checkout the source code over on github.

Usage

select_column accepts a single optional argument. This is the column that you want to have returned in an array. The returned column can also be specified using the select query method.

If neither a select nor an argument is given, :id is assumed to be the column to be returned. If multiple select query methods are present, the first one defined will be the column returned.

Some examples:

# selects an array of ids
Post.select_column

# selects an array of titles
Post.select_column(:title)

# selects an array of ids
Post.where(:status => 'published').select_column

# selects an array of titles
Post.where(:status => 'published').select_column(:title)

# selects an array of titles
Post.select(:title).where(:status => 'published').select_column

Update (Jan 21, 2012): It’s like they keep looking at my gems and integrating them into Rails. As of Rails 3.2 this gem’s functionality has been replicated by ActiveRecord::Relation#pluck. Check it out in the release notes.

Where Am I?

You are currently browsing the Ruby category at The On Blog.