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 Local Subdomains

January 17, 2012 § 2 Comments

I was working on a project a while ago that required the use of custom variable subdomains. If you have ever had to develop a site that used user specified subdomains, you quickly realize that editing your local /etc/hosts file over and over again sucks. A lot. You end up setting up half a dozen subdomains on a dummy domain that points to localhost. Not an ideal setup. Thanks to Railscast I tracked down a pretty cool solution to the problem.

The basic idea is to set up a live domain to point 127.0.0.1 and let DNS take care of everything for you. Tim Pope wrote about it nearly two years ago using smackaho.st. In the Railscast Ryan Bates mentions another domain setup for this, lvh.me, which was registred by Matthew Hutchinson. smackaho.st and lvh.me do the same thing, just on different domains. And because two isn’t enough, I went and registered lvho.st and configured it to do the same thing as well. The lvho.st domain comes from local virtual host, which I took from lvh.me and the fact that I liked the thought of using a .st domain like smackaho.st so I could use ho.st. Shove the two together and you get lvho.st.

Even though I don’t work with subdomains currently, I still use lvho.st for local development. Anyways, feel free to use if you have the need.

Interesting side note, this same project is the one that inspired me to write my first ruby gem, tld-cookies. It’s a nice little gem that makes it easy to set a cookie that works across all subdomains instead of just the current one.

On Sight

January 12, 2012 § Leave a comment

Here is a great little Chrome extension for developers, Sight. It’s a syntax highlighter for source files that you find on the web. It’s very nifty when you find yourself perusing the source of some open source project you are thinking of using.

Tips: ‘L’ will toggle line numbers and ‘G’ will take you to a specific line number. There are lots of font and themes to choose from as well.

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 Encrypted Cookie Sessions

June 16, 2011 § 1 Comment

Once I had finished up with the encrypted-cookie gem, it seemed like a natural extension to convert it into a Rails 3 session store.  It operates just like the basic cookie session store, just using an encrypted cookie instead of a signed cookie.  It uses the encrypted-cookie gem, so all the encryption is provided by ActiveSupport::MessageEncryptor.  To start using it add the following to your Gemfile:

gem 'encrypted-cookie-store'

And change your session store in config/initializers/session_store.rb

AppName::Application.config.session_store :encrypted_cookie_store, :key => '_app_name_session'

The dependencies will include the encrypted-cookie gem for you.  Accessing the session is the same as always:

session[:tid_bit] = "of information"
session[:tid_bit] # => "of information"

You can check out the source over on github.

Currently this only works with Rails 3.0.*. All of the session code got switched up for Rails 3.1, so it’s going to take some extra work to get it working for the new release of Rails. Update June 18: Got it working with Rails 3.1.  Yay conditional method definitions!!! Sigh…

On Serialized Accessors

June 16, 2011 § 1 Comment

One of the nice things about brand new Rails apps is that all of your database tables are nice, small and manageable.  You have relatively few columns in any given table and you are probably querying on most of the columns at some point in the app.  As your app grows in size and complexity, so do your tables.  A table that once upon a time had 5 or 10 columns now has 20 or 30.  Not unreasonable number, but you are starting accumulate a number of columns that aren’t queried against.  What should we do with these columns?

One option is to just let them build up.  It doesn’t really hurt anything does it?  I am sure that some database experts out there can weigh in on how number of columns affects performance.  Option two is where I’d to show off something a little more interesting.  Check out the data-attributes ruby gem over on github.

The premise is pretty simple.  ActiveRecord allows for easy serialization of objects to a text field in the database. data-attributes makes use of this and adds attributes that read from and written to a serialized hash that is stored in a text field in the database. From the developers perspective, once a data attribute is defined, it can be used just like any other attribute. Validations work just like they do on column based attributes. To use this gem just add the following to your Gemfile in your Rails 3 project.

gem 'data-attributes'

Let’s take a look at it in action.  We start with a user model with a serialized attribute called data.

class User < ActiveRecord::Base
  serialize :data
end

Now, let’s say we have some piece of information that we want to include in the user record, but it isn’t something that we are going to have every query on.  We define a data attribute like so:

data_attribute :favorite_food

Now how do we use this?  We can see the results of adding the above to our Userobject.

u = User.new
u.favorite_food = "watermelon"
puts u.favorite_food
=> watermelon
puts u.data.inspect
=> { "favorite_food" => "watermelon" }

Pretty easy.  The default field that the gem tries to save everything to is data, but that is just based on personal convention.  If you want to change this, it’s as easy as adding the following line to your model:

data_attribute_column :food_preferences

Or if you have multiple serialized attributes and you want to send different data attributes to different serialized attributes you can do the following:

data_attribute :favorite_food, { :serialized_column => :food_preferences }

You can also set the default value to be returned for the data attribute:

data_attribute :favorite_food, { :default => "peanut butter" }

One of the things that makes all of this possible is that fact that ActiveRecord has multiple layers of accessor that happen when you call something like user.name.  What happens is that the method name gets called which in turns calls read_attribute(:name).  Similarly name=(val) calls write_attribute(:name, val).

data-attributes contains similar under-the-hood method read_data_attribute and write_data_attribute.  This way you can have a little more control over the values that are read and written to your object.

Some things to be noted. If your ActiveRecord object has a serialized attribute then that attribute will be saved to database every time you call save.  This is because it doesn’t know if the serialized object has been edited in place or not, so it just writes it to the database every time for good measure.

Update 2011-12-26: ActiveRecord 3.2 now has some of this basic functionality built in by way of ActiveRecord::Store.

Where Am I?

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