May 4, 2012

Understanding Active Merchant Integrations

Active Merchant Integrations have not been documented that well, so I decided to document my current understanding of it here. Please feel free to contribute your thoughts.

When to use integration instead of gateway

Basically always when your payment method means that the user leaves to a remote site to complete the payment.

Step by step guide to create a new integration

Generation

Checkout Active Merchant from Github

Run:

script/generate integration YourIntegration

This will create few files:

lib/active_merchant/billing/integrations/YourIntegration.rb lib/active_merchant/billing/integrations/YourIntegration/helper.rb lib/active_merchant/billing/integrations/YourIntegration/notification.rb test/unit/integrations/YourIntegration_module_test.rb test/unit/integrations/helpers/YourIntegration_helper_test.rb test/unit/integrations/notifications/YourIntegration_notification_test.rb

Integration Module (lib/active_merchant/billing/integrations/YourIntegration.rb)

Here you can configure module wide stuff such as service_url and what is sent to Notification class.

Helper (lib/active_merchant/billing/integrations/YourIntegration/helper.rb)

Here you configure how the payment form is created.

1. Initialize - initialize the form, insert hidden fields, fetch the md5secret

2. Mappings - defines form fields and field mappings between ActiveMerchant and your payment provider

3. form_fields - actions you might want to do after form is generated, such as calculate checksums

Notification (lib/active_merchant/billing/integrations/YourIntegration/notification.rb)

Notification is called when the user comes back to site (return_url). Check the app example later.

First you need to again map received parameters (your payment provider -> ActiveMerchant).

Then depending on the request type (POST/GET) you need to parse the request accordingly and then acknowledge the notification. In our case (LINK LINK) this means calculating the checksum and check that it matches with the one got from payment provider.

Testing

Testing is pretty straight forward. Check our examples here:

Module test

Helper test

Notification test

Your app

Integration to your app has three parts

Settings - you probably want to set your payment provider details (merchant_id and authcode in our case) in an initializer.

View - then you need implement the view for payment. This is done with the payment_service_for validator. In our case it looks something like this (non-dynamic product):

And then finally the controller part. For the return url you need a matching action:

That’s it :) If you do create your own integration, please create a pull request for ActiveMerchant. Instructions here: https://github.com/Shopify/active_merchant/wiki/Contributing

- Antti

11:45am | URL: http://tmblr.co/Z4rJJyKreN-e
(View comments)

March 29, 2012

The regrettable end of Splendid Bacon

Splendid Bacon :-(

We’re sorry to announce that we’ll cease operating our Splendid Bacon service at the end next month (31st April 2012).

While we loved the service at first, we never managed to dedicate enough resources to the project to make it into a service that we ourselves would use actively. And as we don’t use Splendid Bacon ourselves, for the past year it has languished with almost no development.

While the hosted service is getting shut down at the end of April, we’re still evaluating whether it would be possible to release it as an open source project in the near future.

10:11am | URL: http://tmblr.co/Z4rJJyIkYz4w
(View comments)

Filed under: splendidbacon

August 19, 2011

"If you want to know what games are in the App Store, check Joao’s phone."

— Antti Salonen

1:29pm | URL: http://tmblr.co/Z4rJJy8VVsNM
(View comments)

(Notes: 1)

Filed under: quote iphone ios app store

June 30, 2011

"We need more elements!"

— Kisko Labs quote of the day

12:46pm | URL: http://tmblr.co/Z4rJJy6bsAuA
(View comments)

(Notes: 2)

Filed under: elements quote

June 7, 2011

Introducing Carpentry

Today we’re releasing one of the few gems that we use internally, making it available to everyone.
Carpentry is a tool that enables designers to focus on what they do best, without worrying about implementation details.

Workflow

Designers can now manage their own prototypes, without needing to worry where they are going to end up when implemented. Once ready, a developer will pick the file, move it to the appropriate place and wire it to the Rails application. Designers don’t need to care about controller design, and can try more in less time.

By default, prototypes are accessible when the application is deployed.
Now clients can see them and provide feedback before anything is implemented. If you don’t want prototypes available to everyone, don’t worry. There is an overridable before filter where anything can be added, such as authentication or a redirect if in production.

Getting started

To start using Carpentry, all you need to do is add it to the Gemfile and run rails generate carpentry:install.

The gem adds an directory (app/views/carpentry/prototypes) to a Rails project where prototype files go into, and makes them accessible at /p, following the same structure as the prototypes folder. So, if you have app/views/carpentry/prototypes/clients/new.html.haml you can access it at /p/clients/new.

Behind the scenes

Carpentry is not only useful, but it’s also available to prove a point.
Creating a Rails engine is easy, and a great way to extract functionality that is needed in several Rails applications. In fact, the whole gem has only 50 lines of code, including a Rack middleware, and a Rails generator.

Let’s take a look at the code.

First of all, there is the controller that catches all prototype requests and renders the correct file, in app/controllers/carpentry/prototypes_controller.rb:

We call the #before_carpentry before filter only if it is defined.
Since we inherit from ApplicationController, the method can be added there. The second argument in #respond_to? defines whether to look at private methods or not. In this case, we want that.

We also need to add a route to send the requests to our PrototypesController, in config/routes.rb:

Notice that we define that /p should render an index file if it exists, by setting the file_path parameter to index.

We configure our engine in lib/carpentry.rb so that Rails knows that our gem is an engine, and to use a middleware that we’re bundling with Carpentry:

Our NoRobotsMiddleware is very simple. It does nothing more than adding <meta name="robots" content="noindex, nofollow"/> before the end of the <head> tag so that prototypes don’t get crawled and indexed by search engines. The middleware is defined in lib/carpentry/no_robots_middleware.rb:

Hope this helps you understand how to build an engine. Look at the source code on GitHub and the specs we have if you’re building a small engine and don’t know where to look for examples.

If you’d like to learn more, you should probably get José Valim’s book Crafting Rails Applications.

5:36pm | URL: http://tmblr.co/Z4rJJy5scn6A
(View comments)

May 29, 2011

Google OpenID authentication using Devise and Omniauth

Since I spent one hour getting this thing to work and there is no single post clearly explaining what to do, I’ll post my findings here. Big thanks to Julián Porta for his post on the topic. That set me on the right track.

First of all if you want to do authentication with Google, you need to use OpenID. Oauth is only for allowing you an access to data.

Steps (I’m assuming you have a working Devise installation):

//Antti

2:53pm | URL: http://tmblr.co/Z4rJJy5ZNO-G
(View comments)

(Notes: 1)

May 26, 2011

Introducing sproutcore-rails

At Kisko Labs we’re good at picking great tools. We’ve been using Rails ever since we started in 2007 and haven’t looked back. We hope to keep on using it for many years to come.

However, we need more than just Rails. We need a powerful tool for frontend development that fits our projects. That is why we are extremely happy with the announcement of SproutCore 2.0. There is no way we could have used SproutCore 1.x on all our applications, but as of version 2 that is no longer true.

Within a few hours of the announcement and release of the first alpha version, we created the sproutcore-rails gem. At the moment it only contains the latest SproutCore 2.0 developer preview for use with Rails 3.1 and its awesome asset pipeline. We will keep an eye on SproutCore development and update the gem as needed. We also hope to include Rails helpers to help with Rails/SproutCore applications if needed. We’re very much open to contributions from both communities.

Today is a good day to be a web developer.

// joao

12:19pm | URL: http://tmblr.co/Z4rJJy5TM_Fc
(View comments)

May 24, 2011

Introducing Snowfinch: open source realtime web analytics

Snowfinch is an open source realtime web analytics application built with Ruby on Rails and MongoDB. The project was developed as a part of my thesis, and has then been released under the MIT license.

The application focuses on what is happening right now on your site. To a user it works just like most other analytics products: sites can be tracked by adding nothing more than a JavaScript snippet.

Sites screenshot

The dashboard view for a tracked site is very simple. It shows three counters (active visitors, pageviews today, and unique visitors today) and a chart containing both the number of pageviews for the current day as well as the previous day. Both the chart and the counters are updated every second.

There is also a text input where a URI can be pasted, and a similar dashboard is displayed for a single page of the site. This seems like a much better solution than a large list of every single page that has been tracked.

Site dashboard screenshot

In addition to the dashboard, Snowfinch provides a very neat monitoring tool. Monitoring is done via sensors. At the moment two types of sensors exist, but more can be developed.

The first sensor type is the query based sensor. This sensor is triggered when a page URI contains a given query key and value. It can be used, for example, to monitor campaigns.

Query based sensor screenshot

The other sensor is the referrer based sensor. This allows tracking of how many entries to the site there are from any given number of referrer hosts. An example use case is adding twitter.com and facebook.com as referrer hosts to see how much traffic you are getting from social media sites.

Referrer based sensor screenshot

For each sensor, a chart displaying the number of entries is shown.

Sensor dashboard screenshot

It doesn’t have all the features in the world at this stage, but if you’re interested in hosting your own web analytics application, this is a project you’ll want to keep an eye on.

I already have a small roadmap shown below. If you have any further suggestions, I’d love to hear them.

Display data for any given period of time (currently the past 2 days).
Collect and display referrer information.
Custom visitor tagging.
Geographic location of visitors.
Filter by custom page metadata (e.g. for A/B testing).
Asynchronous data collector.

If you’re looking to contribute, go ahead and start coding. I’m taking a small break from developing it, while I readjust myself to working full time, but development will continue.

The code is available on GitHub and you can reach me at joao@kiskolabs.com.

// joao

9:24am | URL: http://tmblr.co/Z4rJJy5PNSbK
(View comments)

(Notes: 18)

May 20, 2011

Why Frozen Rails will never charge our speakers a penny

If you follow Chris Wanstrath (@defunkt) on Twitter you might have noticed these two tweets yesterday:

DjangoCon Europe charges speakers $$$ to talk. Absolutely disgusting.less than a minute ago via web Favorite Retweet ReplyChris Wanstrath
defunkt

We wanted to sponsor but the DjangoCon Europe organizer blew me off when asking about the speaker $$$ thing. Stay classy.less than a minute ago via web Favorite Retweet ReplyChris Wanstrath
defunkt

…and then controversy.

To clarify, DjangoCon doesn’t charge their speakers to speak, per se, but does charge them the regular admissions fee (400–600€, by the looks of it).

I’d just like to give a few of the reasons why we would never charge our speakers a single penny at Frozen Rails.

1. They make the conference possible

If we didn’t get the great speakers we do there would be no conference. Every time we get a speaker who accepts an invitation to come speak at Frozen Rails, we’re incredibly grateful for it.

2. Some speakers implicitly sponsor us

We’re perfectly OK with paying for some of our speakers’ travel costs and accommodation, but the economics of organising a small conference don’t let us pay for every speaker and certainly make it impossible to pay a respectable speaker’s fee to any of them.

Every time a speaker (or their company) agrees to pay for their own airfares and hotel, it’s incredibly beneficial for us and helps us keep the price of the tickets down. (By the way, if you want to make a pot of money, don’t go into the conference business)

3. Many of our speakers go above and beyond the call of duty

All of the speakers we had at last year’s Frozen Rails were incredible nice people.

For example, Chris and Ryan (@rtomayko) from GitHub actually volunteered to help us with assembling the attendee packs (which involved assembling about ~300 folders) after the speakers’ dinner on the night before the conference.

And then after the conference they had a GitHub meetup with an open tab at the bar for most of the night. Oh, and all of this was after GitHub paid for both Chris and Ryan’s flights and hotels.

4. We care about putting together the best possible conference we can

Not only do we want to have great speakers at Frozen Rails, we also want to make sure we have a great audience. To help with this we do things like offer discounts and free tickets to Rails contributors. That’s right, if you have enough commits to Rails you get a free ticket to Frozen Rails. Even a single commit will get you a 10% discount.

Another reason why we offer these discounts is that we like to encourage people to get involved, which is also why we offer steeply discounted student tickets (at below cost, even).

// Matt

9:59am | URL: http://tmblr.co/Z4rJJy5HTMEy
(View comments)

(Notes: 2)

Filed under: Frozen Rails conferences

May 18, 2011

Responsive jQuery Slideshow

This example makes it possible to have fluid jQuery slideshow which scales responsively. This is the same method which is used on the new kiskolabs.com.

I am using Jonathan Snook’s Simple jQuery Slideshow in this example, but you could really use any JavaScript solution with this HTML/CSS combo. I think it’s easiest if I just show the source code and provide live example for you to try out.

HTML:

CSS:

JS:

That’s all. Did you expect it to be more complex? : )

// Viljami, @viljamis on Twitter

UPDATE:

I made an updated version of this, read the new blog post at http://viljamis.com/blog/2011/responsiveslides-js.php and check out the plugin here: http://responsive-slides.viljamis.com/.