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.
Read the rest of this entry »
The saga of Movember is now officially halfway over (or halfway started, if you’re that type of person), and the Mo is coming along quite nicely. I feel confident that I’ll have a winning stash by the 30th. Here is a preview of the current status:
Wanna support my efforts? You can do so in only two simple steps.
1) Go to my movember page, and vote for my ’stache!
2) Donate to the cause. You can do so by visiting my donation page.
Movember is an awesome charity that I’ve been following for the past couple years. To the best of my knowledge, no other organization has harnessed the power of the moustache (aka “mo”) like these guys have. Movember is a month long moustache growing competition. As your moustache grows, you recruit sponsors, who give generously to the cause of fighting men’s health problems, specifically prostate and testicular cancer. The month ends in parties and awesome ’staches.
I have decided to join the fight. Yesterday I honed my straight razor, and without mercy dispatched all of the manly hair from my face. Here’s how I percieve the timeline:
Before:
Now:
29 Days from now:
If anyone has any ideas for the particular style of moustache, let me know in the comments! Use this for inspiration.
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.
Lately I’ve been thinking a lot about my online presence. I mean, if I ever start to market Photify.net to other companies, and if anyone there is anything like me, then they’ll instantly type my name into google. So, I put myself in their shoes and did a little ego-search:
It doesn’t look too promising. The first result is for the director of Pot Zombies. Great. The second? An ad for penis enhancement pills (which, according to google, is also hosting malware. Don’t go there). Skip down a couple and you get a facebook profile. That shouldn’t be too bad right? Click on it and you’re greeted with a picture of some dude drinking what appears to be Jack Daniels straight out of the bottle with his buddy flipping of the camera. Awesome.
None, however, are quite as disturbing as justinspowers.tripod.com. This is most disturbing since the URL clearly has my middle initial, which so far is the only thing distinguishing me from the lower classes of Justin Powers. It is a simple animated cartoon implying that I giggle, and openly announce that I am homosexual. Promptly followed by a solicitation to kill me. Please don’t.
Part of the point of this blog is to raise my google standing. I suppose it will be some time before it breaks through the ranks on google. I also created a google profile, which is nicely placed at the very bottom of the first page, forcing the would-be searcher to wade through mountains of the stoned undead, underage drinkers, and death threats. Not so long ago my linked-in profile was at the top of the ranks (see Justin Powers), but it has fallen almost completely from Google’s view.
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.
I’ve been dealing the past two weeks with getting photify.net production ready. A lot of that time has been spent on site working with the end users and business owners. Developing in that kind of environment means pushing fixes and updates out fast and furious, and bringing them into the production environment as fast as possible.
To give you a little bit of background on my setup, I am using Capistrano to deploy to two servers, both of which are running Phusion Passenger. One server is on a shared host, along with the SVN repository, and the second server is inside of a private network with a sub-optimal internet connection. Both servers share a common database. I ran into an issue running “cap deploy”, because it was trying to copy the entire application over ssh to both servers every time. This wasn’t a large issue for the shared host, but the server in the private network would keep hanging after it got past a certain point. This all took me days to figure out, because capistrano give very minimal debugging/logging information, and the error messages changed every time, usually letting me know that the I/O stream had closed.
I first set this scenario up using the Agile Development with RoR book, but since I was using an outdated PDF, turns out I wasn’t using the optimal setup. Originally, the book called for the following line in my config/deploy.rb file:
set :deploy_via, :export
The idea here is that you want to export the project from the SVN repository, but leave behind all the unnecessary subversion .svn junk. Seemed reasonable enough to me. However, in the updated PDF, they made a subtle, but gamechanging alteration:
set :deploy_via, :remote_cache
What this does, is it actually checks out a version of your project into shared/cached-copy on the target server(s), and going forward only runs an SVN update command, which only updates the files that have been changed. Capistrano then uses this copy to deploy your code the same as before.
It seems like the obvious choice, and now that I know where to look, there is plenty of information about it. But if you are stuck waiting for an hour for cap deploy to finish, or are getting random errors, it’s hard to find an answer online. In my case, I actually manually checked out my code into the shared/cached-copy directory on both servers, as I was tired of capistrano screwing it up. Once I got the initial code in there, further cap deploy’s take only 1 minute or so, compared to 30+ minutes previously. Sweet!
I’m doing it. I’m actually going to blog about things that may or may not be relevant to other people. The main point of this blog is to keep people updated on my latest project, Photify.net, while at the same time sharing problems/solutions I’ve had while developing the project, in the hopes that someone else finds it useful. This differs from the more official blog at blog.photify.net, in that I won’t bother you here with trivial announcements and such drivel. The focus here will be mostly development centered. You may also see occasional whitewater updates if you’re lucky.