Join us at elektro:camp(<<2013.11>>) on 1+2 November 2013 at the StayOkay on the island Texel in the Netherlands!

Elektro:Camp is a participative workshop on Smart Metering, Smart Home, Smart Grid and Smart Ideas, in a BarCamp style. (This is the 7th meeting of the open source metering community.)

This time it is an all in arrangement, including sleeping accommodation in a hostel. For all the details, travel information and costs see ektro-camp.de.

Be there of be ▢, so sign up!!

So you’re an independent Ruby developer with all the benefits you can think of.

With a lot of freedom. You work from home, you choose your own assignments, no adjustment to a corporate culture, no managers to deal with etc.

But what about the downsides? No feedback on your work (from which you can learn), not a lot of interaction with other programmers, not easy to consult a colleague on technical or other matters and sometimes the workload is too much or too little.

So that leads me to the question: is there a form of working together without losing the valued benefits of an independent developer. Somehow it must be possible to work together on a commercial basis as individual developers more or less the same way we contribute to an Open Source project.

Living in a community (on an island) where we have a lot of benefit of existing co-operatives (for transport by ferry and the delivery of energy), I of course thought of a formal co-operative as an organization form for working as an collective.

Benefits:

• Acquisition as a collective.
• More flexible in workload. No more running or standing still. A more even distribution of the workload.
• Higher occupation on average.
• Share knowledge and practical experience.
• Learn by working together on the same project.
• More change to do what you do best (specialties).
• More change to make some money as a part time ruby developer.

The co-op will also offer the customer more continuity. A customer will value the lower dependence on a single developer or a small company.

Release early, release often:

With this proposal I like to research the possibility of working together in a formal co-operative. Of course I don’t have all the answers (yet), but I’m hoping that we can together answer a lot of them.

Let me know what you think. I made a first draft of a proposal on Github with the following subjects:

• Definitions
• Objectives
• Rights
• Responsibilities
• Obligations
• Financials
• Board
• Workflow
• Examples

I like to invite you to join this discussion and make your contribution by forking and submitting your patches!

See also:

• Rubycoop.org
• Github
• twitter
• Google group
• Lighthouse

Combine your work with nature on Texel. Balance your work and personal life! This is the change to do your regular work and to combine it with a holiday feeling.

Go out for a few days or a week with your partner/husband/wife (and/or your kids). During the day you can use a work spot with Internet access and enjoy the beauty of the Island.

In return it would be nice to do a pair programming session (if you do Ruby and/or Ruby on Rails). Contact me via frank-at-dovadi.com or 06-49416406 if you’re interested.

Description:

iDEAL payment gateway for ActiveMerchant.

What is iDEAL?

iDEAL is a set of standards developed to facilitate online payments through the online banking applications that most Dutch banks provide.

If a consumer already has online banking with ABN AMRO, Fortis, ING/Postbank, Rabobank, or SNS Bank, they can make payments using iDEAL in a way that they are already familiar with.

See http://ideal.nl and http://idealdesk.com for more information.

Merchant account

In order to use iDEAL you will need to get an iDEAL merchant account from your bank. Every bank offers âcomplete paymentâ services, which can obfuscate the right choice. The payment product that you will want to get, in order to use this gateway class, is a bare bones iDEAL account.

• ING/Postbank: iDEAL Advanced
• ABN AMRO: iDEAL Zelfbouw
• Fortis: ? (Unknown)
• Rabobank: Rabo iDEAL Professional. (Unverified)
• SNS Bank: Not yet available

If you implement tests for other banks, if they require such acceptance tests, please do submit a patch or contact me directly: frank@dovadi.com.

Install active_merchant_ideal:

As a gem:

1

sudo gem install active_merchant_ideal

Add the following to your environment.rb:

1

config.gem 'active_merchant_ideal'

As a plugin:

1

./script/plugin install git://github.com/dovadi/active_merchant_ideal.git<br />

Generate private keys and certificates

Messages to, and from, the acquirer, are all signed in order to prove their authenticity. This means that you will have to have a certificate to sign your messages going to the acquirer and you will need to have the certificate of the acquirer to verify its signed messages.

The latter can be downloaded from your acquirer after registration. The former, however, can be a certificate signed by a CA authority or a self-signed certificate.

To create a self-signed certificate follow these steps:

1
2

/usr/bin/openssl genrsa -des3 -out private_key.pem -passout pass:the_passphrase 1024
/usr/bin/openssl req -x509 -new -key private_key.pem -passin pass:the_passphrase -days 3650 -out private_certificate.cer

Substitute _the_passphrase__ with your own passphrase.

With the ING bank you upload your private certificate with your iDEAL Dashboard. Be aware that there are two dashboards, one dashboard for the test environment and one dashboard for the production environment!

For more information see:

• http://en.wikipedia.org/wiki/Certificate_authority
• http://en.wikipedia.org/wiki/Self-signed_certificate

Test

Test the gem

You can run the tests from this gem with (inside the active_merchant_ideal directory):

1

rake test

Run the remote tests

• Create .active_merchant directory in your own home directory
• Copy test/fixtures.yml to the .active_merchant directory
• Fill in your own merchant id, passphrase and the correct locations to your private key and certificates.
• For running the seven prescribed remote test transactions (ING bank) which are needed to activate the iDEAL account use

1

rake test:remote

Example (Rails)

First configure the gateway

Put the following code in, for instance, an initializer:

1
2
3
4
5
6
7
8

IdealGateway.live_url = 'https://ideal.secure-ing.com:443/ideal/iDeal'
IdealGateway.merchant_id = '00123456789'
IdealGateway.passphrase = 'the_private_key_passphrase'

# CERTIFICATE_ROOT points to a directory where the key and certificates are located
IdealGateway.private_key_file = File.join(CERTIFICATE_ROOT, 'private_key.pem')
IdealGateway.private_certificate_file = File.join(CERTIFICATE_ROOT, 'private_certificate.cer')
IdealGateway.ideal_certificate_file = File.join(CERTIFICATE_ROOT, 'ideal.cer')

View

Give the consumer a list of available issuer options:

1
2
3
4

gateway = ActiveMerchant::Billing::IdealGateway.new
issuers = gateway.issuers.list
sorted_issuers = issuers.sort_by { |issuer| issuer[:name] }
select('purchase', 'issuer_id', issuers.map { |issuer| [issuer[:name], issuer[:id]] })

Could become:

1
2
3
4
5
6
7

<select name="purchase[issuer_id]">
  <option value="1006" selected="selected">ABN AMRO Bank</option>
  <option value="1017">Asr bank</option>
  <option value="1003">Postbank</option>
  <option value="1005">Rabobank</option>
  <option value="1023">Van Lanschot</option>
</select>

Controller

First you’ll need to setup a transaction and redirect the consumer there so she can make the payment:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

 class PurchasesController < ActionController::Base
   def create
     # â?¬10.00 in cents.
     purchase = @user.purchases.build(:price => 1000)
     # We want an id for the URL.
     purchase.save(false)

     purchase_options = {
       :issuer_id => params[:purchase][:issuer_id],
       :order_id => purchase.id,
       :return_url => purchase_url(purchase),
       :description => 'A Dutch windmill'
     }

     # Save the purchase instance so that the consumer
     # can return to its resource url to finish the transaction.
     purchase.update_attributes!(purchase_options)

     gateway = ActiveMerchant::Billing::IdealGateway.new
     transaction_response = gateway.setup_purchase(purchase.price, purchase_options)
     if transaction_response.success?

       # Store the transaction_id that the acquirer
       # has created to identify the transaction.
       purchase.update_attributes!(:transaction_id => transaction_response.transaction_id)

       # Redirect the consumer to the issuerâ??s payment page.
       redirect_to transaction_response.service_url
     end
   end
 end

After the consumer is done with the payment she will be redirected to the :return_url. It’s now your responsibility as merchant to check if the payment has been made:

1
2
3
4
5
6
7
8
9
10
11

 class PurchasesController < ActionController::Base
   def show
     gateway = ActiveMerchant::Billing::IdealGateway.new
     transaction_status = gateway.capture(@purchase.transaction_id)

     if transaction_status.success?
       @purchase.update_attributes!(:paid => true)
       flash[:notice] = "Congratulations, you are now the proud owner of a Dutch windmill!"
     end
   end
 end

History

In 2006 an iDEAL payment library was written in Ruby for a web shop build in Rails for selling mobile phone credits. It was basically a translation of the PHP example given by the iDEAL organization (see iDEAL Advanced Integration Manual PHP). Is was released as the ideal-on-rails plugin.

In 2007 this code was refactored as a patch for the ActiveMerchant library, this was mainly done by Fingertips for a client project. This patch was never accepted due to the fact it was too different (and maybe too obscure) from the ‘normal’ credit card gateways.

In 2009 Fingertips forked the ActiveMerchant library and added an iDEAL gateway (presumable based on the first ActiveMerchant patch) to a new ideal branch.

In 2010 this code was extracted and converted into a separate gem, so it can be more easily used in combination with the latest version of ActiveMerchant. This library is just an extraction, nothing more and nothing less. There are no fundamental changes between the code from the ideal branch and the code of this gem.

Maintainer

This gem is maintained by Agile Dovadi BV, contact Frank Oxener

My first little gem has_attributes_from for merging attributes from one ActiveRecord Class to another individual STI subclass.

So why, do we want to do that, you might ask? Well, I was working on a rails project where clients take care of the administration (planning and billing) for child daycare centres. In this project I have all kinds of people objects, like a child, a contactperson, a father, mother, caretaker etc. etc. So, the ideal casus for a Single Table Inheritance implementation. So I implemented a ‘classic’ Person Class as follows:

1
2
3
4
5
6
7
8
9

  create_table :people, :force => true do |t|
    t.string   :firstname
    t.string   :lastname
    t.string   :initials
    t.string   :type
    t.string   :social_security_number
    t.string   :gender
    t.datetime :date_of_birth
  end

However, I like to add certain extra attributes to a Child, like for example its nickname and information about its allergies. So I introduce another class which I call ChildDetail. Of course I can add these attributes to the people table as well, but in this project I had several more fields to add and some other attributes for a father., which would lead to a lot of columns for only two subclasses (of the five in total).

1
2
3
4
5
6

create_table :child_details, :force => true do |t|
    t.string   :nickname
    t.string   :vaccination
    t.string   :allergy
    t.integer  :child_id #belongs_to relationship with Child
end

Ok, now I can access the extra attributes

1
2
3
4
5
6
7
8
9
10
11
12
13

class Person < ActiveRecord::Base
end
class Child < Person
  has_one :child_detail
end
class ChildDetail < ActiveRecord::Base
  belongs_to :child
end

child = Child.first
=>#<Child id: 2, firstname: "William", lastname: "Oxener", type: "Child", social_security_number: "123456789", gender: "m", date_of_birth: "2005-12-02 00:00:00">
puts child.child_detail.nickname
=>"Bill"

This is not really the way I want it, I like to ask directly for the nickname of a child without going through a child_detail. So to solve this ‘problem’ I wrote the has_attributes_from gem. Add the following line to your environment.rb file

1

config.gem 'dovadi-has_attributes_from', :lib => 'has_attributes_from', :version => '>=0.1.1', :source => 'http://gems.github.com'

Install and unpack this gem to your vendor directory or install as a plugin

1

./script/plugin install git://github.com/dovadi/has_attributes_from.git

Now we can do the following:

1
2
3
4
5
6
7
8

class Person < ActiveRecord::Base
end
class Child < Person
  has_attributes_from :child_detail
  validates_presence_of :nickname
end
class ChildDetail < ActiveRecord::Base
end

With has_attributes_from the attributes from ChidDetail are merged with Child. A child object acts as one single object and I can even do validation on nickname directly (or the other attributes from ChildDetail).

1
2
3
4
5
6
7
8
9
10
11
12

child = Child.first
=>#<Child id: 2, firstname: "William", lastname: "Oxener", type: "Child", social_security_number: "123456789", gender: "m", date_of_birth: "2005-12-02 00:00:00">
puts child.nickname
=>"Bill"
child.update_attributes(:nickname=>nil)
=>false
child.errors.full_messages
=> ["Nickname must be present"]
child.nickname="Daam"
=>"Daam"
child.save
=>true

I think this is much nicer, besides it was fun to make and a good exercise to put some Ruby meta programming into practice.