If you are looking for a post about software documentation or customer support then move along. This one is all about Ruby code.

We recently switched our billing system for ScreenSteps Live over to Chargify. There were a variety of reasons (the main one being how they take over the process of keeping the customers’ billing information up to date, a major pain in a SaaS product). One of the great features is their support of automatic proration of accounts when they upgrade.

What we wanted to accomplish was the following. Say for example we have a user that has a Solo account at $19/month. Half-way through their billing cycle they want to add two more users and upgrade to a Basic plan ($57/month). When they perform that upgrade we want two things to happen:

1. They should be billed a pro-rated amount for the difference in the plans:
   (new_ammount - old_ammount) * percentage_of_plan_time_until_next_billing
   In this case that would be ($57-$19) * 50% (since they were halfway through their billing cycle)
2. On the next normal billing date we want them to be charged the full amount for the new plan they have selected (in this case $57).

The Chargify API makes this very easy and they have a great Ruby wrapper for their API so doing this in Rails should be easy right? Well, it wasn’t immediately apparent to me how to accomplish this so I thought I would share how we did it.

Here are some examples of using the Ruby wrapper for the Chargify code taken from their gem:

# Create a subscription from a customer reference
subscription = Chargify::Subscription.create(
  :customer_reference => 'moklett',
  :product_handle => account_type,
  :credit_card_attributes => {
    :first_name => "Michael",
    :last_name => "Klett",
    :expiration_month => 1,
    :expiration_year => 2020,
    :full_number => "1"
  }
)

# Lookup up existing Subscription using the Customer's reference
Chargify::Subscription.find_by_customer_reference('moklett')

To upgrade a subscription you simply call:

subscription = Chargify::Subscription.find_by_customer_reference('moklett')
subscription.product_handle = 'new_account_type'
subscription.save

But that won’t add a pro-rated charge to the users’ account. After a search through the API docs I figured out how do this via the Ruby wrapper.

subscription = Chargify::Subscription.find_by_customer_reference('moklett')
subscription.post(:migrations, :product_handle => new_account_type)

The post command creates a post to a nested migrations resource under the subscription resource. This isn’t part of the Chargify gem, it is just built into ActiveResource. Probably obvious to a lot of people but wasn’t to me so I thought I would post about it.

Two weeks ago we hosted a webinar discussing the new Data Grid control available in Revolution 3.5. Revolution is the cross-platform development environment that we write all of our desktop software in and ScreenSteps uses the Data Grid control extensively. In the webinar we show how we integrated the Data Grid into ScreenSteps 2.5 and share some tips and tricks that will prove useful to anyone working with Data Grids.

The webinar is about 70 minutes long with a little over half of the time spent presenting and the reset spent answering questions from attendees. To watch the recording just visit the archive page.

A few weeks ago Kevin Miller, Bill Marriott (both of Runtime Revolution) and I put on a webinar that introduced the new Data Grid in Revolution 3.5. The data grid was originally developed for ScreenSteps so that we could provide our customers with a much more responsive UI when working with large libraries and lessons. We were thrilled when Revolution decided to integrate it into their core product.

Given the extremely positive response by attendees, Greg and I thought people might be interested in seeing how ScreenSteps 2.5 uses data grids throughout the application. So we’ve added a new webinar to our webinars page entitled Using Data Grids in Revolution 3.5. In the webinar we will show you:

• The various UI elements created using the data grid.
• The techniques used to create some of the visuals.
• The techniques used to hook the data grids up to data from SQLite, stacks, folder contents and the web.

We also plan on providing ample time to answer questions people might have. So join us on Thursday April 30th if you want to improve your data grid chops.

Sign up for webinar

One of the big pains with Rails form helpers is that they don’t have a cancel button. No, problem – that is easy enough to add in. Just use a second submit tag like so:

            <%= f.submit "Create" %>
            <%= submit_tag "Cancel" %>

Now, if the user clicks the “Cancel” button a “commit” param with a value of “Cancel” will be submitted.

This is nothing earth-shattering. I have found this technique on various blogs. But then they all suggest checking for this parameter in the update or create method of your controller. I don’t like this because it makes you add in extra “if-then” statements. I really hate “if-then” statements. They make the code so much harder to read.

So what to do?

Use a before filter.

before_filter :check_for_cancel, :only => [:create, :update]

Then add in your method to check for the cancel parameter in the commit message.

  private

  def check_for_cancel
    if params[:commit] == "Cancel"
      redirect_to admin_spaces_path
    end
  end

That’s it. So now, if anyone clicks on the “Cancel” button on an edit or new form they will be redirected to the index.

If you really wanted to you could make the Cancel button submit the cancel parameter as part of the model hash. You would do it like this:

            <%= submit_tag "Cancel", :name => "model[cancel]" %>

You would just need to update your check_for_cancel method to check for that param. I prefer the previous method though since it is more generic.

In my last post about developing ScreenSteps Live with Ruby on Rails (which was far too long ago) I talked a lot about what led to me getting started with Rails development. In this post I want to talk about what were some of the things about Ruby and Rails that I found really useful and what things were really confusing.

Once again – a little of my background. When I started this I had a music degree from the Berklee College of Music, knew some basic HTML and was at least competent at using CSS thanks to the book “CSS: The Missing Manual“, which I can’t recommend enough.

So I was by no means a programming expert. Concepts such Classes, Modules, ActiveRecord, View Helpers, Partials, Arrays, and Hashes were all totally foreign to me. I had done some database work several years ago where I got to dig into SQL commands a bit. This background at least gave me a good understanding of how relational databases worked.

The Stuff That Confused Me

Here are some of the things that initially confused me about Ruby and Rails:

Block notation

It looks something like this:

@posts.each {|p| p.some_method}

For some reason that totally confused me. Once you figure it out it is wonderful and very powerful. But as I read books and searched the internet I could find all these things that mentioned blocks but didn’t define what they were or how they worked. I think that I will do a post soon about the important things I wish I had known about blocks but I don’t have space for that here. Now that I understand them I can find plenty of information on them. Isn’t that always the case?

Ternary operators

url.blank? ? "Preview not available" : url

That type of stuff totally threw me for a loop. All it is doing is evaluating an expression and returning a value depending on the value returned by the expression. It is short hand for an if-then statement. But those ? and : are very intimidating when your code vocabulary is limited.

Array Operators

posts.collect {|p| p.title } posts.select {|p| p.title == "My Post"}

I didn’t like that stuff at all, mainly because I wasn’t comfortable with arrays yet. That compounded with the block notation had me dong a lot of head scratching.

The Stuff I Liked

(more…)

At Blue Mango Learning Systems we primarily develop two applications:

• ScreenSteps Desktop Software: This is developed for Mac and PC. Trevor handles all of this and uses Runtime Revolution as his development environment.
• ScreenSteps Live: This is our hosted compliment to ScreenSteps Desktop. It is all coded in Ruby on Rails and I handle all of the work on that side.

Distributing a product for Mac, PC and running a hosted web service is a lot of work, especially when there are only two people in your company. Therefore we have had to choose our development tools very carefully. For us, the most important aspect of any development tool is our ability to quickly iterate over a product until we feel that we have it “right”. Really, for us, all other considerations fall way behind. If we can’t iterate efficiently then we are going to move on to another tool.

Ruby on Rails has proven to be a great tool for this type of development. There are a lot of people getting into Ruby on Rails so I thought some of you might be interested in my experience. I think that ScreenSteps Live is an interesting case study in the benefits and drawbacks of Rails, so over the next couple of months I will be posting some of the things that I have learned as I have dived into the Rails world.

First, a little background on myself as a programmer and ScreenSteps Live as a web app.

ScreenSteps Live Struggles to Come To Life

I have no background as a programmer. Well, almost none. We first got the idea for ScreenSteps Live back in late 2006 or early 2007. At that time I had never even attempted to program a web application. I knew some basic html, enough to throw up a web page, and enough php to do some basic includes. But nothing beyond that. I also had programmed some smaller desktop apps with Revolution but only after extensive help from Trevor.

But we needed a web app. Trevor wasn’t going to have time to do it so we decided to outsource. I won’t go into all of the details on this but our first attempt didn’t work out so well. Suffice it to say that after 2 months we had nothing and were out a few thousand dollars. All I can say is be very meticulous in checking out the people you are hiring to develop your stuff. We weren’t and it came back to bite us in the form of lost time and lost money.

(more…)

Round here we develop all of our desktop applications using Revolution. I recently attended the RunRevLive 08 conference in Las Vegas where one of the speakers was Robert Cailliau, the co-developer of the web. Robert spoke on “Programming systems and the birth of the Web”. Following a very interesting presentation on how the web came about he discussed some characteristics he thought a good programming language should have:

• You should not need the reference manual lying open next to you.
• A good assignment operator.
• The less “swear” characters the better. These are characters from the top of the keyboard and are like the top shelf at a newsstand – dirty.
• You should not need lots of comments.

His point was that you spend most of your time reading your code, not writing it. Therefore the language should be easy to read and understand. Since Revolution uses an english-like syntax it fulfills all of Robert’s criteria.

(more…)

Over the last few weeks we have been shifting the primary focus of ScreenSteps Live to manuals. In doing so we have been looking at ways to easily integrate the manuals you create into a variety of different applications.

One feature we recently added was the ability to fetch a list of manual lessons that has been filtered by tags. For example, if I have a manual for my web application I can tag all of the lessons that discuss managing users with “user management”. I could then add some javascript (supplied by ScreenSteps Live) to my user management screens that displays all lessons from my manual tagged with “user management”. As I continue to add lessons and make updates based on user feedback those lessons pertaining to “user management” would automatically show up in my web application.

(more…)