1. Sessions

To get the most out of the sessions, it really pays to have read and planned which of the optional sessions you will attend. In previous Webstocks, I have had to make somewhat rushed decisions when I suddenly realise that I have to made a decision on a session that is about to begin.

Have a good read up of the programme. When we have a particular specialist capability (eg: GIS stuff), going along to an entry-level GIS talk may be of little value. I’d suggest taking a look at some of the non-technical sessions too, as they may have material that is quite interesting.

2. Networking

There are going to be plenty of old colleagues / acquaintances at Webstock. It’s a good opportunity to re-establish connections.

Take along your business cards, and hand them out.

3. What to bring

In previous years, I have taken my laptop. Probably about half the people there will have them. I’ve also taken just my iPhone, and that’s worked fine too.

If you’re not bringing a laptop, you’ll want to take some notes. I believe the webstock bag has paper and pens, etc. Plus plenty of other “advertising material”

4. Registration

Register earlier in the week – don’t leave it till Thursday. There will likely be about 1000 people trying to get their Webstock goodies that morning. Also, the popular t-shirt sizes disappear pretty quickly.

5. Seating

There are more people than seats (downstairs). I suggest trying for a table near the front. Often you’ll end up on the same table for both days.

6. Other tips

There will likely be free ice creams (Kapiti) and free coffee (People’s).

The food is normally pretty good. Sometimes you get crazy queues though – one table will have 100 people queueing while another will have just a couple. It’s often quiet upstairs.

Keep an eye on Twitter with the #webstock hashtag. Also, there is a Google Document at webstock.waveadept.com which is likely to end up with many of the referenced websites, etc mentioned during the sessions.

About Mashblock

MashBlock is a tool to visualise demographic data from the 2006 Census for 66 Territorial Authorities, 2000 Area Units, and over 48000 Meshblocks.

This site is built to provide fast location-based queries utilising the Google Maps Geocoder, HTML 5 Geolocation and the AddressFinder autocomplete library to allow the user to find the Meshblock, Area Unit and Territorial Authority their search falls in.

The backend site is built with Ruby on Rails and a PostgreSQL database with the PostGIS plugin. The frontend utilises the javascript libraries jQuery, Raphael and the Google Maps API to create the visualisations and user interaction.

All the data is sourced from Statistics New Zealand.

Please try it out, and let us know what you think.

Address Finder

In addition to the Rate Finder, you can use Able Technology’s Address Finder product to find postal codes, and validate New Zealand postal addresses. Some great API examples are available at api.addressfinder.co.nz

We use the ActiveMerchant plugin (Ruby on Rails) to connect to the DPS Payment Express payment gateway. DPS connects to our BNZ Buyline merchant account which allows us to bill customers in both NZD and AUD. When we pass through a customer’s card details to DPS they return a billing token, and when we need to bill the card in the future, we simply send through the appropriate billing token to DPS along with the amount to be billed (this amount may change if customers upgrade or downgrade their accounts). This saves us from having to store our customers’ credit card details, and worry about the security issues that this entails.

Expired Credit Cards

Until now, the only real issue that we faced was the problem of expiring credit cards. Credit cards generally expire every two years (sometimes more frequently), primarily due to the fact that this is the life expectancy of the magnetic strip on the back of the card. When a customer’s credit card expired, they needed to provide us with the updated card details, otherwise when we tried to charge their card, we would receive a ‘card expired’ error back from DPS. Clearly this somewhat limits the convenience factor for our customers, in fact many customers told us so, pointing out that their card number hadn’t changed.

The solution, as it turns out, is a little known feature called the recurring billing flag. Essentially when a payment is sent through to the bank with the recurring billing flag set, they will (generally) ignore the expiry date when processing the transaction. I came across this feature via this blog post, but could not find it documented anywhere in the technical documentation provided by either the bank or DPS. A quick call to a knowledgeable staff member at DPS, confirmed that they could in fact set this flag for us provided that we obtained written permission from the bank. Luckily we had no problem in obtaining prompt approval from the BNZ, and we were able to have the recurring billing flag enabled on our transactions within a couple of days.

I hope this knowledge is useful for other SaaS vendors who bill customers on a recurring basis. From what I understand, the banks may have different policies on allowing the recurring flag to be set.

Please let us know your experiences.

Special guest post by Scott Ryburn.