Raymond Law

Intridea’s Present.ly has been nominated as a finalist in the WebWare 100 Communication Category

Present.ly has been nominated as a finalist in the WebWare 100 Communication Category. We’re honored to be chosen from a pool of more than 5,000 applicants to be one of the 300 finalists to compete for the title.

The WebWare 100 is a yearly contest held by CNET that allows the public to pick what the 100 best web applications of the year are. Past winners included such products as GMail and Amazon MP3, so we’re very excited to be included as a finalist for this year’s selection.

Voting is open right now, so please vote for us! We think that business micro-communication is an important next step in the future of communication, and your votes will help validate that and move it even further into the mainstream. Thanks for your support.

Easy or Hard?

I had the following conversation with a colleague about a client project recently.

At that moment, it strikes me that sometimes I want the easy ones but at other times I want the hard ones. But why? After some thoughts, I concluded with:

I want the easy ones because they are easy and quick, but annoying and boring. And I want the hard ones because they are challenging and interesting.

I think the following matrix describes it best:

Do you get the point?

As software engineers or programmers (sometimes interchangeable terms IMO), we like to solve challenging and interesting problems, regardless of difficulties. Ideally, we like everything to be in the easy and interesting quadrant, but we certainly like (sometimes prefer because it is also challenging) things in the hard and interesting quadrant as well. We would accomplish things in these two quadrants with our fullest attention and best effort.

Stuff that belong to the easy and annoying, and hard and annoying quadrants bore us. We naturally pay less attention and try to do them with spare time. However, they still need to be done. They become a drag.

Now we understand the matrix, but what can we do about the drag?

This is what I think.

I may feel ActiveMerchant is a joy and interesting to work with, but someone else may think it is a distraction to the project and just want to settle with using Authorize.net when it is already supported by ActiveMerchant to do recurring payment.

I may feel having to crop all images again and save them in a different format is a waste of my development time, but a photographer may actually enjoy such work and may even add a drop shadow to make the images look better.

The difference is in the interpretation.

Interpretation

Different people interpret the same thing differently based on their own level of interest/time/concern, …/etc. That is a fact, not an argument.

In software development, instead of the project manager assigning tasks to each engineer, programmer, QA, you name it, based on time, skill levels, familiarities with certain code pieces, scopes, existing client relationships, maybe, just maybe, it is better to ask each person which of the tasks they have the most interest in and then assign tasks based on level of interest. That way, each person on the team will put forth his/her best attention/effort to accomplish them.

Potential pitfalls

• What if none of the tasks interest me? Maybe put that person in a different project that has tasks that interest him?
• What if many people are interested in the same task? Who gets to work on it? Maybe pair programming in which several people can participate and can have inputs?
• If I keep picking tasks that seem easy (on the surface), would it make me look lazy?
• If I pick several hard tasks, I may make myself too busy.

Again, we should not be blind folded by interpretaion. I may think it is easy but someone else may think it is interesting and solve the task better. I may think it is hard but since I am so interested, I may solve it with higher efficiency, hence less time.

The above is just a thought. I have not actually tried it to see how well the process works. However, since project management is so boring and annoying to so many people. We may as well put a different interpretation to it. It certainly is a paradigm shift in project management.

Moving from Typo to Wordpress

I recently moved my blog from Typo to Wordpress. Typo served well and it was written in Rails. However, it was more difficult to upgrade and I just don’t have enough time to maintain it and keep it up to date. So it has been running at version 4.1.1 which requires Rails 1.2.6. So a change is imminent and I found a couple resources by Stuart Johnston and Max Newell.

Those are GREAT starts!. However, I had to modify the migration script for my Typo version (4.1.1) and the latest Wordpress version (2.7.1 at the time of this writing). Fortunately, the script is just pure SQL. That means I had to inspect the Typo and Wordpress database structures to correctly map the tables and columns between the two databases. It is not the funnest thing in the world though, but this has to be done. If you have other versions of Wordpress, I recommend you upgrade to the latest version first. That way, you don’t have to worry about Wordpress’s table structures because I already did this for you. If you are using a different version of Typo, feel free to modify this migration script and post feedback.

Here are the steps that you need to take after grabbing the script:

> mysqldump typo_db articles_tags tags categorizations categories contents feedback > typo.sql
> mysql typo_db < typo.sql
> mysql typo_db < typo_4_1_1_to_wordpress_2_7_1.sql

PayPal Recurring Billing with ActiveMerchant in Ruby on Rails

ActiveMerchant is great and PayPal is easy to use. A lot of us already have a PayPal account for EBay. It works great in auctions where you pay once. However, ActiveMerchant currently does not support PayPal recurring billing. One requirement of a recent project is to be able to charge for a monthly or yearly subscription plan with PayPal. Therefore, I did some googling and found that Jon Baker has already extended ActiveMerchant to add this functionality using PayPal’s Name-Value Pair (NVP) API. However, as Cody Fauser pointed out, the NVP API was taken out from ActiveMerchant, so I had to implement that with PayPal’s SOAP API.

First, download this file and put it in vendor/plugins/active_merchant/lib/active_merchant/billing/gateways/. Use the GitHub from now because maintaining a separate file download is too troublesome. Alternatively, there’s a fork on GitHub at http://github.com/rayvinly/active_merchant/.

In your controller, after a user selects one of your subscription plan, the form goes to the checkout action:

  def checkout
    response = gateway.setup_agreement(:description => description, :return_url => return_url, :cancel_return_url => cancel_return_url)
    redirect_to gateway.redirect_url_for(response.token)
  end

This redirects the user to PayPal so he can login and read the description you provided. After he confirms, he is redirected back to your application’s return_url, which I set it to be the complete action below. If he cancels, he is redirected back to the cancel_return_url. You can set cancel_return_url to be the plan selection page where he can choose a different plan.

If he confirms, here’s the complete action:

  def complete
    token = params[:token]
    response = gateway.create_profile(token, :description => description, :start_date => start_date, :frequency => frequency_in_months, :amount => amount_in_dollars, :auto_bill_outstanding => true)
  end
 
    # Save this profile_id in your transactions table.  This is used to cancel/modify the plan in the future.
    profile_id = response.params["profile_id"]
 
    if response.success?
      flash[:notice] = "Your PayPal account was successfully set up for the <strong>#{description}</strong> payment plan."
      redirect_to login_path
    else
      flash.now[:notice] = "There was a problem setting up your PayPal account for the <strong>#{description}</strong> payment plan"
      render cancel_url
    end
  end

I default the frequency to be in months and turn on auto_bill_outstanding because that is what I need, but you can look at the file you downloaded and the PayPal documentation to see what other options are available. In particular, read these two PDFs:

• Express Checkout Integration Guide
• SOAP API Developer Reference

If the user wants to cancel the payment plan, a cancel action would look like:

  def cancel
    response = gateway.cancel_profile(paypal_profile_id, :note => 'Payment plan was canceled by user')
    flash[:notice] = 'You have successfully canceled your membership'
  end

paypal_profile_id is the profile_id you saved in the complete action from above. Keeping this profile_id is very handy.

That’s it. Enjoy making money!

UPDATE 2009-02-04

I updated the extension to include a credit_card hash. You will probably capture the credit card details submitted by the user in a form as in params[:credit_card], but I will just create a hash to show as an example. To make recurring payment with a credit card, just pass nil for the token (this is required, because PayPal would use the token in preference to the credit card). Pass the credit_card hash as follows:

    credit_card = Hash.new
    credit_card[:type] = 'Visa'
    credit_card[:number] = '1234567812345678'
    credit_card[:exp_month] = '07'
    credit_card[:exp_year] = '2016'
    credit_card[:cvv2] = '123'
    credit_card[:card_owner] = 'John Doe'
    response = gateway.create_profile(nil, :credit_card => credit_card, :description => description, :start_date => start_date, :frequency => frequency, :amount => amount, :auto_bill_outstanding => true)

However, I got the famous DPRP is disabled for this merchant error message when I tested it. I did a little googling but I haven’t found the cause. There may just be something that you have to turn on in your PayPal developer account. I also read that it works for newer accounts only. But since I don’t have a need for this, I didn’t look further. If you guys know, please let me know. I will try to update the extension as soon as possible to make it work with a credit card.

Sanitize your output in Ruby on Rails

We all know about the holy h() method that escapes your output when you do <%=h blah %>. But how many of us can claim we remember to use it where it’s appropriate during development 100% of the time? Can you swear you’ve never missed one? Moreover, it’s such a mental distraction to think logic and h() at the same time. And when you take over a Rails project in the middle, how can you ensure the previous developers use h()?

Here’s the rescue.

safe_erb + footnotes

I don’t think I need to explain more. Just use it and you will find all those places where you should sanitize your output with h(), sanitize(), and untaint(), …etc.

RailsRumble 2008

We just finished the Lyricist application for RailsRumble 2008 with 3 other Intridea folks. Here are some observations:

• Keep the idea small and achievable – There are only 48 hours, so you can’t build the next Google. And there’s pressure. Try to keep your idea small and make sure you can accomplish it. You have to deploy a finished product in order to have any chance of winning. So stop day dreaming about cool extra features because you won’t get that implemented.

• Prior planning is the key – We barely had any because we had decided on the idea the day before the rumble began. When the competition started, people don’t know who’s doing what and it was kinda a mess. Fortunately we had a campfire room where all conversation happen, so we can kind of iron out the issues. However, better preparation and team cohesiveness would have helped a great deal in communication.

• Deploy early – I’ve seen too many deployment problems came up before, so I took the initiative to make sure we could deploy as soon as the competition began. It helped tremendously because we never had to worry about if we could deploy before time expired. While you are fixing last minute bugs and the pressure, it would have been tough to set up a server and deploy flawlessly.

• A lot of scaffolding – I took full advantage of Rails scaffolding. There’s just no time to reinvent the wheels when all the restful model and controller methods are already available with just one command. You use plugins and gems for the same reason, right? So, don’t be stupid.

• Conflicts – The bigger your team, the more conflicts there would be when people check in and out. We were writing a new application, so people were editing the same files. Now, if you organize and assign work to people as in a regular project, conflicts don’t usually happen and even if they do occur, it is trivial to resolve. However, when you are rumbling, you will step on one another’s toes. I can guarantee you that.

• Forget about writing tests – Look, I am in support of agile and test-driven development, with one exception. That is, you are not participating in RailsRumble. There’s just no time for it. If you are a good enough programmer, you can build a small application with no tests. If you can’t, I don’t want to work with you. Writing tests for a new application starting from scratch in just 48 hours is simple not feasible. No bargain!

• No ticketing system like Unfuddle and Lighthouse – One team member had tried to use Unfuddle to create tickets to get ourselves more organized. While it was a sincere attempt, it simply didn’t work. There’s no time to accept a ticket, create a new ticket, … We pretty much abandoned it soon after we started.

• Nice to have a designer: – It is very nice if you have a designer on you team because it’s hard to wear two hats in 48 hours. Design work can draw your focus away from development.

Now that I’ve given you my insights for next year’s RailsRumble. As a token of appreciation, please vote for us!

UPDATE 2008/10/20

One more thought on RailsRumble the day after:

Numerous projects that I worked with before never deploy quickly, let alone in 48 hours. I think it’s refreshing and rewarding to have something built and deployed so quickly. It is true that we have to cut many features in order to deploy a first version, but lesser is better than never. I think many other projects can try to deploy early and often and just go through more iterations and get feedbacks from users and customers. The whole application doesn’t need to be finished. Even if you only have login and logout, you can still deploy. Add the next feature, deploy again. That way, you aren’t keeping the features to yourself. You can get feedback from users to see what improvements they are looking for and may even lead you to implement the real features that they truly want.

Google Badminton

Capistrano Deployment Recipes

Dealistic was first deployed to Slicehost when we were testing it on staging. However, I only got the 256 slice and low memory is a big problem for Ruby and Mongrel. We’ve moved to Amazon EC2 when we launched. It is running rock solid and we don’t run out of memory again, at least for now

As a result of all these, I wrote two Capistrano recipes for deployment, for both Slicehost and EC2. We also use GitHub for version control. I think these deployment recipes may be helpful to others. So here they are:

• deploy.rb for Slicehost
• deploy.rb for EC2

We wrote some custom Capistrano tasks to copy over configuration files, symlink plugins, start/stop BackgrounDRb, and a custom maintenance page. But these things are optional. It should be simple to add/remove things as you see fit.

Dealistic is launched

Andrew and I have been working on a new site Dealistic after our work at OnMyList.

We’ve also put up a screencast to show off our features (HUGE thanks to Sherry)

It lets you find deals by specifying a list of tags and it can notify you by email, RSS feed, and/or SMS when new deals appear that match your tags.

We made the site because we often need to find deals on things we want to buy but we spend way too much time looking for irrelevant deals on a lot of different sites. With Dealistic, what you get is what you want.

Never miss a deal because you don’t have time to find it! Just add a tag at Dealistic and we will let you know when a deal that you are looking for appears.

We also have a feedback tool that we hope you can give us suggestions to do better.

Home-made Strawberry Banana Rendezvous

Today I was stressed out while working because of the construction drilling noise near my house (I am working from home for Intridea). So I took a break, and tried to make a dessert aka Cold Stone Creamery ’s Strawberry Banana Rendezvous.

Ingredients I used:

• Turkey Hill strawberry ice-cream – not the greatest ice-cream brand but that’s what was on sale at Wegmans last night…
• Hersey chocolate chips
• A few Strawberries
• Half of a banana – I ate the other half separately

I put all these in a bowl and mix it to gether for one minute. The taste comes close. However, it doesn’t resemble ice-cream anymore as I am missing one huge ingredient – the “cold stone.”

I guess the “cold stone” must be needed to keep the ice-cream ice-cream during the mixing process. The result was more like a milk shake than ice-cream. I still ate it all since I am a big ice-cream lover and I couldn’t just throw it away to the trash! I mean, it is going to look like that in my stomach anyway, right?

So if anyone has a substitute for a cold stone, let me know. This is what I think can simulate the “cold stone.”

• Put the bowl in the freezer and take it out only when you are ready to begin the mixing process.
• Take the ice-cream out at the last possible second.
• Surround the bowl with a box of ice.
• It is probably a good idea to max your AC or do this only in the winter. A few degrees below freezing and being outdoor in Canada may help too.