Heat Up Your Campfire With Tinder

We use Campfire as our primary means of team communication both internally and with clients, so I was excited when I ran across, Tinder, a very cool unofficial Campfire API yesterday. Tinder has been out since the end of last year, but for those folks like me that have overlooked it, here’s a brief rundown

What does it do?

Tinder lets you programmatically log into your campfire room(s) and speak or paste messages. Tinder can also listen in on your room, allowing you to selectively respond to certain events or message, much like an IRC bot.

Why in the world would I need this?

On our team, we often communicate build statuses in our Campfire room to give each other and our clients a heads up when new features or bug fixes have been deployed. One of the first problems I wanted to tackle was a simple build notification message in the Campfire room. (I’ve got a long list of wish list items I plan to tackle, hopefully I’ll have more to blog about in the near future as Chris and I play with the project.)

A simple example: deployment notifications for Capistrano

Step one: Download and install Tinder

<code class='terminal'>
pengwynn:~ wynn$ sudo gem install tinder

Step two: Create you Campfire user (optional)

Personally, I wasn’t comfortable with having my name attached to the deployment message for Jim’s bad code, so I create a new Campfire user called Campfire Bot ;-)

Step three: Include the Tinder libraries

<code class='ruby'>
require 'rubygems'
require 'tinder'
...

Step four: Create the Capistrano task

<code class='ruby'>
desc "Speak deployment info into campfire room"
task :speak_campfire, :roles =&gt; :app do 
  message = "DEPLOY NOTICE: [#{application.upcase}] #{ENV['USER'].capitalize} deployed revision #{revision} to #{build_environment}"

  campfire = Tinder::Campfire.new 'YOUR_CAMPFIRE_ROOM'
  campfire.login 'YOUR_CAMPFIRE_USER_EMAIL', 'YOUR_CAMPFIRE_USER_PASSWORD'
  room = campfire.rooms[0]
  room.speak message

end

Four lines of code. Beautiful! Kudos to Brandon

No Cancel Button – The Gym Membership Business Model

A major holdover I have noticed from the Web 1.0 age in a number of popular online tools has been the lack of self-serve cancellation features.

You know the drill. You find this nifty little web app that makes your life easier and you decide it’s worth the five or even fifty bucks a month so you whip out the credit card and off you go. Life is good for a few months, maybe a couple of years.

Then you figure out Google’s got a new free tool that does twice as much and you need to cancel your nifty little app membership. Only to your utter frustration, you realize that there is no cancel button anywhere. There’s no live person to call. If you’re lucky they have a support ticket system that lets you submit a cancellation request as a ‘billing question.’

Recently I had to resort to having my credit card company dispute the charges for two different web tools because I couldn’t get any response from them requesting to cancel my service. This got me wondering how many tools out there are following the same model manufacturers employ for rebates, taking advantage of people’s busy lives or outright laziness not to follow up and follow through canceling a recurring charge. It’s just bad business when canceling a service is not as painless as signing up.

Why I Made the Switch

I recently left a very large company where I held a stable, secure, well paying job working on an important (so I’m told) enterprise Java application. I left to join a very small company, where I have a less stable, less paying job working on world-changing (so I think) Rails projects. Many people have asked me why (especially my parents), so I’ll list some of the reasons here:

1. Ruby & Rails

As a Java lifer, learning Ruby was nothing short of mind-blowing. Rails, too, was eye opening for someone accustomed to the Java stack. Ruby and Rails immediately struck me as being both semantically clean and syntactically expressive – power and simplicity rolled into one. That was a very uncommon combination in my experience writing Java applications. It was also the first time I heard a community talk about “happiness” as a benefit of using the framework. I was productive in Java, but did it make me happy? No, it definitely didn’t. But here was this simple, powerful framework backed by an equally simple, powerful language and their users claim it makes them happy, and therefore more productive. I had to try it. So that’s how I got hooked, and while I can’t report that I’ve reached enlightenment (yet), I am definitely much happier focusing on the art of creation rather than the art of XML sewing and jar dumping.

2. Community

I’ve been keeping an eye on Rails since 1.0 and I am amazed at the level of innovation coming out of the community. ActiveRecord, migrations, named routes, RJS, RESTful-ness, Capistrano, etc etc. When I’m part of a community like that, it inspires me to want to be a better programmer and contribute back. On a more practical level, it also gives me more confidence in using the framework and recommending it to clients. I know current problems won’t be ignored and that another innovative solution is around the corner. It doesn’t matter how technically smart, the key to any open source movement is the passion of the community. And passion is definitely one thing not lacking here.

3. Meaning

This is a very personal reason, and I could fill a book on this topic alone, so I’ll try to summarize. I’ve always been a very spiritual person and I think we’re here to do more than accumulate wealth and reproduce. For me, the simplest way that I could see to make a positive impact on the world was at a startup with other like-minded people. The guys at Praexis immediately caught my eye as first class human beings with a high level of integrity and technical prowess. The corporate gig offered lots of vacation days, but those are only necessary when you’re not doing anything meaningful.

4. Flexibility

On so many levels, working for a small company offers more flexibility. Work experience: you get to wear many hats. Time: main thing is getting your stuff done, not that you’re in the office 9-5. Location: this is becoming less and less important. As long as you communicate effectively, you can work from the park, the coffee shop, or Africa. Financial: there are much better (and fairer) ways of being compensated than just salary.

5. Experience

One thing I love about the software industry (at least in America) is the tolerance of failure. If you participated in a failed startup, it is not a mark of death. Depending on how it failed, it could be actually a source of great pride. Of course, the experience of a successful startup is also quite helpful.

6. Excitement

There are certain jobs that are done best in large corporate settings. But most software development doesn’t fall into that category. A small, dedicated team can build powerful, world-shaking software. The excitement of being part of such a team, and partaking in such an endeavor is why I entered the industry in the first place. Don’t get me wrong; the thought of helping a large company make money is also exciting, especially if it results in a nice year-end bonus, and some rounds of golf with executives. But the potential ceiling for impact and financial reward is much higher in a small startup.

7. Risk

Tolerance for risk is one advantage of the unmarried. This is definitely a factor that individuals have to consider for themself. But for me, I couldn’t tolerate the risk of letting a great learning opportunity pass.

So there you have it, the reasons why I decided to make the great leap. Have you made a similar switch? I’d like to hear the reasons. If you haven’t but thought about it, what’s stopping you?

The Browser Ate My Ajax Call

To improve the video uploading for authors in our favorite video learning site, I’ve been working on a nifty media uploader app-within-an-app using Merb. In the process I had to sprinkle some magic Ajax dust on the user interface to show the progress of the current upload.

Lesson #1: Check the switch in the basement before you check every bulb on the roof!

Since Prototype and the other modern Javascript frameworks do such a good job of wrapping up things like Ajax requests and I already had an end-to-end example working in another project, it was easy to take for granted that the problem was in the last 5% of the implementation.

We programmers try to short-circuit the debugging process and jump right to where we ‘know’ the problem lies. So, there I was just like our favorite vacation movie hero in my favorite Christmas movie checking every line of the Javascript that updated the page without bothering to check to see if the Ajax call had been made in the first place.

Lesson #2: A different port = XSS (cross-site scripting)

I guess this is the first time I’ve stumbled across this scenario in needing to call the same server on a different port from Javascript. I did not realize that although the request is going to the same server name and IP, the browser considers Ajax calls made on a different port than the original page to be a security concern and prevents the call from completing.

It’s also curious that both Safari and Firefox (with FireBug) log an error to the console when a page attempts to call Javascript across frames in an unsafe manner but neither log a message when an Ajax request attempts the same thing.

Capistrano – Deploying With Subversion Tags

When deploying to multiple levels of environments (eg TST to ITG to STG to PRO), it is generally not a good idea to deploy from SVN TRUNK. By forcing a project to always deploy from TRUNK, you are in essence telling the development team not to check in any modified code until the current release goes to PRO. Otherwise, any late check-ins could potentially go straight to PRO without testing and rendering all of the testing performed in previous environments meaningless.

Luckily for us, it is very simple to TAG releases with Subversion and equally as simple to deploy TAGs through Capistrano with a simple deploy.rb modification. Thanks to the guys from Aisle Ten for their Cap SVN Tag Deployment to help me out with this.

Below is my version of the recipe that I added to deploy.rb. After running a cap deploy command, the below code prompts the user for a TAG name. If one is given, it will deploy from that tag. If a tag is not given, it will deploy from root.

<code class='ruby'>
set :repository, "svn://your/repo/root"  
namespace :deploy do
  
 desc "Asks the user for the tag to deploy"  
 task :before_update_code do  
   set :tag, Proc.new { CLI.ui.ask "Tag to deploy or just hit enter to deploy to trunk: "}  
   if "#{tag}".strip.empty?
     set :repository, "#{repository}/#{application}/trunk"
   else
     set :repository, "#{repository}/#{application}/tags/#{tag}"
   end
 end  
end