Rails vs Whitewater » Photify.net

Out of sight, out of mind

Justin — Wed, 02 Dec 2009 15:19:54 +0000

So today I set up observe_form for one of my search forms. I’ve been wanting to get rid of the submit button for my form, so that when users change a search field, it would just update the search results, in real time. Think kayak.com. It took surprisingly minimal work, and the result just feels good. One problem though, is that nothing happens when I change the time slider on my form.

First things first. There isn’t such thing as a slider on a form (at least until you get to HTML5, I believe), so I hacked a solution in. Using a custom javascript slider, whenever the user moves the slider, a hidden_field_tag gets updated, by tying into the onSlide callback of the slider. This hidden field is passed along with the rest of the form upon submission. However, this hidden field isn’t being observed as part of observe_form. I suspect it’s because javascript is doing the updating, and not the user. Either way, I couldn’t find a rails way of fixing it. Here’s my observe_form as it stands today:

<%= observe_form 'search-form', :before => "Element.show('spinner')", :complete => "Element.hide('spinner')", :url => {:action => 'search'} %>

My solution was to hook into the onChange callback of the slider itself (ignoring the hidden fields). I used onChange instead of onSlide because I didn’t want a dozen requests going to the server per slide. I simply added the following javascript.

Element.show('spinner'); new Ajax.Request('/search',{asynchronous:true, evalScripts:true, onComplete:function(request){Element.hide('spinner')}, parameters:Form.serialize('search-form')});

A simple note: I suck at javascript. Not that I’m particularly dense, I just haven’t taken the time to learn it. I simply gleaned this little gem by using firebug to see what Rails had generated using the aforementioned observe_form, and simply modified it slightly. Win!

Of Capistrano, Github, and Branches (or, a forking mess)

Justin — Tue, 27 Oct 2009 01:58:25 +0000

Disclaimer: I am a Github newbie, and I am still learning the various concepts. If I misrepresent something in this post, please let me know in the comments!

I recently switched my project over from SVN to Github. My reasons were varied, but a large reason was because I needed to create various branches to accomodate my ADD style of development (work on layouts for a bit, then switch to security, then switch to fine tuning my models). I also need to create a branch for productions servers, as well as a branch for my staging server, which is set up at home. The latter was a bit confusing at first, until I found a great tutorial here.

First, a couple of notes about my setup. I am the sole contributor to my (private) repository. Up until now, I have not had a need for this “forking” business that I see from time to time. In configuring up my multistage setup, I ran into an issue when I tried to use set :branch, "2.0" in my staging deploy.rb file. Even though I had created a branch for “2.0″ like so:
git branch 2.0
I was getting the following error:
`query_revision': Unable to resolve revision for 'invalid' on repository 'git@github.com:*****/******.git'. (RuntimeError)
This confused me for quite some time, until I found out that the set :branch isn’t referring to the branches that I had created locally, but to github forks. To create a fork from the branch, I simply had to do the following:
git checkout 2.0 git push origin 2.0

The origin bit is what does the magic. As soon as I refreshed, I was able to see the newly created fork in the github web UI, and my deploy recipe worked like magic. Brilliant!

Note: I still have to find out how this will affect my git workflow, but since the clone URL is still the same, it seems that I should still be able to continue with my current way of doing things.

ActiveMerchant nonsense

Justin — Tue, 28 Apr 2009 21:10:00 +0000

I’ve been a little hesitant about putting in credit card processing into Photify.net, and it turns out is was with good reason. The set up is just plain annoying! Due to client needs, I had to go with Skipjack as my portal. They seem relatively developer friendly, except that their customer service is about 50/50, literally. I’ve called there several times during normal pacific hours, only to find out that in Eastern time I’m actually calling fairly late. They only have two reps, one of which is helpless, and the other of which is knowleadgable and helpful.

After doing some digging, the best solution for processing payment in my rails app seems to be using ActiveMerchant. It seems fairly well documented, at least if you are using a mainstream credit card processor like Authorize.net. For skipjack though, it’s a little lacking. For example, it’s not clear what, if anything, you need to put in the ‘password’ field. And no matter what I do, I can’t get any non-standard (by ActiveMerchant’s terms) fields to transmit, such as “comment”. But perhaps the most frustrating thing of all, is when I had everything working and fine tuned in development, and I tried to throw the switch to production, by changing the login and using “:test => false” in the login hash. After all, that is the only indication of where to send the transaction. However, after several days of beating my head against the wall, I find this little gem (pardon the pun):

ActiveMerchant::Billing::Base.mode = :production

I almost slapped myself when I saw that. Why in the world are there TWO places to set the mode? Anyways, credit card processing now works, there is balance in the force, and everything is right in the world.