Wednesday, November 18, 2009

Station Deletion

We pushed out a new version of GasBag a couple of weeks ago now, which adds a much needed feature: the ability to delete stations. The main reason for this is that despite sinking huge amounts of time into finding ways to keep our database clean, at the end of the day our systems just aren't as good as trusting you guys to tell us when a station is bad. This new feature was added by one of our interns, Takeshi Ohishi, and was an awesome piece of work from him, despite a difficult spec and demanding coding standards (read: I'm a nazi). Thanks Takeshi!

Here's how it works: when you find a station that shouldn't be there (it's closed, or it's a duplicate, etc), tap on it to go through to the station details screen and then tap the "Delete this station" button, confirm the action and it will be instantly obliterated.

We've now disabled our other mechanisms for identifying duplicate stations, and over the next few weeks we'll be undoing all the work that system did, because frankly it wasn't very good at what it did. So when you see new stations popping up that shouldn't be there, we'd love it if you took the time to delete the bad record (in general we prefer to keep stations with more precise addresses: eg a street number instead of an intersection, but don't stress too much about this).

One last comment: we have chosen not to make a new release of GasBag Pro with this change in it. This is because we had to make a lot of changes to our code to get it to build with the latest versions of XCode. Not wanting to break things for our paying users is pretty important to us, so we're delaying adding this feature to Pro until it's seen some more testing. If the current trends hold up, it will probably be rendered obsolete by the time we get around to rolling it into Pro.

Thanks to all our users for your support thus far, and thanks for helping us maintain the service for everyone.

James.
Co-founder and CTO.

Friday, May 8, 2009

Job posting - BD / Sales Manager

This is an incredible opportunity to join a team of talented entrepreneurs and engineers in the iPhone space. Our applications have been featured in the NY Times, TechCrunch, Wired magazine, and many other newspapers and blogs. We are fully engaged in writing innovative, user-friendly applications that drive community involvement and participation.

We are a small team across California and Australia, looking to expand our Business Development resources so we can focus on what we do best. Head office is in Mountain View and we'd prefer someone close if possible. Our technology has great traction in the consumer space and we are looking to expand that by targeting relevant institutions that could utilize branded versions of our products.

Responsibilities:

- Identify the target customer list out of a large potential pool
- Contact, negotiate with, and close deals with the largest, lowest-hanging fruit first
- Work closely with the product and engineering team


Requirements:

- 3 to 5 years work experience in software sales / BD
- Knowledge of the iPhone applications industry and the App Store process
- Ability to effectively and succinctly communicate technology benefits to Luddites
- Excellent communication and people skills
- Self-motivated and driven to succeed

Compensation:
- The company is wholly boot-strapped and post-revenues but at this stage the compensation will be purely commission-based
- The size of the opportunity is more than enough to provide excellent compensation to the right individual
- Days, hours, and working location are flexible; your performance is determined by your success!

Please contact careers at jam-code dot com for more information and send:
* Your resume
* Your contact details
* Reference from a relevant position in the last 12 months

Tuesday, March 31, 2009

DoucheBag


We are very excited to announce that our latest application DoucheBag has been released on the Apple AppStore. Official press release:

JAMCODE LAUNCHES DOUCHEBAG - PARTY WITH THE COOL CROWD

Never party with the wrong crowd again - find out immediately where to hit the town


Mountain View, Calif. – April 1st, 2009 – jamcode LLC, the leader in rich-mapping applications for the iPhone and iPod Touch, today announced the launch of DoucheBag, the best way to avoid uncool bars and clubs.

* DoucheBag uses the same rich-mapping technology as GasBag, GasBag Pro, and myATM, to quickly and easily show the users where the nearest clubs and bars are.
* DoucheBag users can rapidly identify the "Douche"-level of a bar and inform the DoucheBag community instantly
* Sophisticated trust network algorithms ensure the best DoucheBag-identifiers are rewarded and their recommendations propagated more quickly.

"It's harder than ever to go out and have a good time without some douchebag interfering," said Mick Johnson, CEO & Co-Founder of jamcode LLC. "Now with DoucheBag on the iPhone I can avoid them like never before."

"Sometimes I just sit at home." he added.

"We've taken the best algorithms around the globe, mixed them up in a glass, and added a pinch of salt," said James Gregory, CEO & Co-Founder for jamcode LLC. "Our Advanced Douche Detection (ADD) engine is second to none."

DoucheBag is free on the AppStore - get it today.

Facebook Connect

At last we've submitted version 2.0.4 to the AppStore. As James was alluding to before, we had some extra special features we wanted to roll out, and just as we were about to, Facebook announced Facebook Connect for iPhone at SXSW. So we went back and added that in, which to my mind makes GasBag even more cool! In short, if you log into Facebook through GasBag (hit the Info screen), then whenever you update prices or fill up you can check a box to inform your Facebook friends as well as the GasBag network.

We're rolling this out for GasBag first, to be followed by GasBag Pro later.

Hope you all like it!

Sunday, March 15, 2009

iTunes Connect Scraper

Just a quick note about a, well, smaller release than most of the others. As have many other iPhone developers, we've been pretty frustrated that we're not able to automate the process of getting sales reports from the iTunes Connect portal. It's frustrating because it means someone has to have the responsibility of logging in and downloading them every day, and we've just got better things to be doing (like making great software!).

So we're trying to be part of the solution. Last night, I put together a simple script using the fabulous Beautiful Soup framework to automatically log in and download the latest daily report for you. Paragon of software engineering excellence it is not, but it does rather neatly solve this problem for us. So if you're an iPhone developer, check it out here. It's BSD licensed, meaning you can do pretty much whatever you want with it, but we'd love to hear about any novel uses you find for it, and we'll gladly accept patches for bugfixes or new features or what have you.

I hope you find it useful!

James -- Co-founder and CTO.

Friday, March 13, 2009

Taking the bear by the horns

Liz Tay at ITNews did another great piece on us and how we've been approaching business given the recession. It's been a bit of a roller-coaster I have to say, but I'm very glad we've done so and I have a huge amount of faith both in the jamcode team and also the community that is growing and growing every day.

http://www.itnews.com.au/News/98687,recession-kicks-thrifty-startups-into-top-gear.aspx

"Some businesses forged during recessions have achieved great success. These included Cisco, funded during the recession of the early '90s, and Australian start-up Atlassian that was established during the dot-com bust."

A sentiment I strongly believe in. Now's the time!

Thursday, March 12, 2009

Releases

We're about to roll out a set of updates to GasBag and GasBag Pro, so I wanted to briefly fill you in on what to expect, and provide some rationale for the process we're going to use to get these releases into your hands.

First up, what's changing: this is primarily a bugfix release, intended to target two issues that have been frustrating users since the 2.0 release: we call them "the Sydney bug", and "the price update bug". The "Sydney bug" is where the app will unpredictably jump over to Sydney, Australia, without any really good reason to do so. This is very frustrating except for a very small percentage of our users who also happen to be at that location* :). The "price update bug" is an issue we inadvertently introduced in the switch over to the new map technology. In short, when you enter a new price, that update isn't reflected on the map when you go back to it. The prices are getting to our server just fine, but no-one has any way to know that.

We're still debating whether to add a couple of small pieces of functionality, but if we do include them, we'll be sure to let you know. We're hoping that the new release will be out late next week, but as always we're subject to Apple's approval process, so we can't give any guarantees.

But the more important part of this release is that we're experimenting with a new, staged release cycle. The idea is that we're going to roll these new features into the free version of GasBag, and assuming that all goes well, we'll fold them into Pro a little while later. If it doesn't go so well, we'll repeat the process until we get it right. Why? Well, we've had a lot of feedback about our apps, on everything from our icon to our database, but nothing angers people more than unstable software (and rightfully so). Now don't get us wrong, this release has been through the same testing process that all our software goes through, and we think it's solid, but it's also true that every time we've done that, you guys have managed to find something we didn't think to test for. While we hugely value all our users, we feel that it is fair that people who have actually put down hard-earned cash get the benefit of this "crowd-testing". Ultimately, this is a bugfix release, so we're hoping that no-one's going to be missing out on anything too critical, and we're only talking about a week or two.

So if you're on GasBag Free, look forward to an update in the next week or so. If you're on Pro, you'll get the update as soon as we can manage, and you can be sure that it's ready to rock when it hits your phone.

Let us know what you think of the new release process in the comments -- we're always trying to do the right thing by our users. Let us know how we're doing.

James -- Co-founder and CTO.

[*] as it happens, I live quite close to the area where "the Sydney bug" dropped you, so for a long time I wouldn't believe the rest of the team that there was anything wrong!

Wednesday, March 11, 2009

myATM is launched

Very happy to announce that our latest application, myATM, has just been approved on the AppStore. Official press release below:

JAMCODE LAUNCHES MYATM

Find your nearest fee-free ATM in under 5 seconds, 
for less than the cost of a single transaction fee

Mountain View, Calif. – March 11th, 2009 – jamcode LLC, the leader in rich-mapping applications for the iPhone and iPod Touch, today announced the launch of myATM, the fastest and easiest way to save on ATM fees.

myATM is fast:

  • Same rich-mapping technology as the best-selling GasBag and GasBag Pro applications
  • 250,000+ ATM locations stored on the phone, so users can search immediately without needing to connect
  • Rapid launch brings up the map and ATM locations in under 5 seconds
  • Panning and zooming instantly refresh the map for a great viewing experience

myATM saves you money:

  • A single transaction fee can cost from $2.50 to over $6!
  • For the first week only, myATM on sale for just $0.99
  • Standard price of $1.99, still less than the cost of a single transaction fee at a foreign ATM

myATM launched with the ability to individually identify the 20 largest banks in the US, with all other ATMs identified with a generic dollar sign. It also comes with the ability to jump straight from the ATM details screen into online banking for that bank, so users can check their balance or transfer money before they reach the ATM.

“With the US economy in a tail-spin and families everywhere feeling the pinch, who wants to shell out more money in fees just to get your own cash out of the bank?” said James Gregory, CTO and Co-Founder of jamcode LLC. “Now with myATM people can get their own stimulus package, directly on the iPhone.”

myATM is available and on sale for just $0.99 on the AppStore today.

Get it at the AppStore

Wednesday, March 4, 2009

Maps

One of the most visible changes in GasBag 2.0 was our move away from Google's map over to Microsoft Virtual Earth. It's been really interesting to watch the way this change has been received, because it hasn't worked out exactly the way we anticipated.

Today I'd like to tell you all the story of why it was that we switched, and hopefully give you some insight into what we were thinking. If you don't like the change, I totally understand, but hopefully you'll find it an interesting story nonetheless.

The story starts in Summer, 2008. We had the idea to build this application, so we all went out and bought Macs, downloaded XCode and got started. The initial concept was to deliver "map-based, community-driven mobile gas-price finding". That's a very hyphen-rich mission statement, but there it is. We pretty quickly got to a point where we needed to embed a map into our app, and this is where things suddenly got hard.

We looked around, and since this was really the early days of iPhone app development, there were very few mapping toolkits around. The one we settled on, iphone-google-maps-component, seemed really nifty: it did all that hard Objective-C stuff (we all had a lot of experience in pretty hard-core C, HTML, Javascript and so on, but objective-C was still a mystery back then), and all we had to do was provide a data-source for Google Maps. We thought this was great, because it had the added benefit that since we were setting up Google Maps to serve our data anyway, we got a web version of the app for free! We put together a prototype in a week or two, ran it up in the iPhone Simulator that ships with XCode, and man, were we impressed! It was wicked-fast, had sexy Google styled maps, and it was responsive which in turn meant that it was usable. "Home run!" we thought.

And we kept thinking that right up until the day that we finally got accepted into the dev program and were able to install the app on our phones. You might think that a day like that would be cause for celebration, but instead we were all hugely disappointed. You see, running our application in the Simulator brought with it all the processing power of my laptop's fairly significant CPU to it plus the huge bandwidth of my home Internet link. Needless to say, the iPhone does not have as much CPU power as my MacBook Pro, nor the bandwidth. So we ran the app up on our phones and quickly discovered that the sub-second load times we'd seen from the Simulator were complete fiction: load times on the phone were about 60 seconds, and the beautifully smooth interactions we had in the simulator were nowhere to be seen either -- movement was jerky and the slow interactions affected usability badly -- pinching and swiping both worked in the app, but it was so slow to respond that for the most part nobody noticed.

Undeterred, what followed was a solid month of hacking on the code to get it into shape. We managed to get the typical load time down from 60 seconds to about 10, improved the responsiveness of the map, and we eventually got it to a point where, well, we weren't thrilled about it, but it was definitely workable, and with the screaming about gas prices at the time, we thought we helped more people by releasing than by holding it back.

So release we did, and things actually went pretty well ("well", in the sense that a startup uses it, means that the first day's deluge of users brought our server to its knees, requiring a quadrupling of compute resources to handle the load), and we saw some solid growth, helped by the gas price crisis, and for a while, we forgot about the map.

Along the way, we started discussions with WhatGas, who are an awesome bunch of guys in the UK doing some similar stuff on the web. We saw some great synergies, so we formed a partnership with them, and then began the hard work of retrofitting internationalization (or i18n as we call it) to the server and to the app. We also figured that since we'd done all that hard i18n work, why not release it in Australia at the same time. And so we got a good database of stations in Australia, and launched it and held our breath.

It was at this time that I was suddenly acutely aware of our map's shortcomings again. As a co-founder and Sydney-sider, I felt duty-bound to enter petrol prices everywhere I went, and so I religiously did exactly that. And it was at that point I realised what I imagine a lot of our users had known for a long time: the map was too slow.

But what to do? Well, fortunately the iPhone dev community has come a long way since our initial efforts, and a particularly bright developer called Joseph Gentle invented RouteMe, which is just an awesome piece of code to display a fast, responsive map in your application. So over my Christmas "break", I put together a prototype with RouteMe, and... wow! It solved pretty much all of my gripes with version 1, just like that (you'll have to imagine me snapping my fingers at this juncture).

But Google Maps as a source of map imaging just wasn't available. Not only did RouteMe not support it, we looked at the Google Maps terms of service and it was pretty clear: you can't use the map imagery outside of Google Maps. A little more research showed that they were serious about it too, having served several take-down notices to websites who had tried to push the limits. In contrast, Microsoft actually provides a detailed explanation, including source-code, on how you can build an app using their map imagery.

So we went ahead and launched with Virtual Earth as our source of map imagery. This time, we were truly proud of the application: we could say with a completely clear conscience that it was the fastest app of its type, and that it was easy to use. Like I said, all our gripes from previous versions were basically eliminated. We released, and also pushed out GasBag Pro, which added some features users had been asking for for way too long in our books.

But this is where the surprises started rolling in. We've had a huge amount of feedback from people saying "Why did you take the Google Maps away?! The new map is ugly and waaaay slower." Needless to say, we were surprised: we'd done a lot of testing prior to release, and the response was unanimous: version 2's map was a huge leap forward in terms of performance and usability.

We've now looked into a few of these, so let me give you the scoop: the issue is with caching. For those who don't know, this is a technique used in many programs in many ways, whereby the computer remembers something it did before, in case it needs to do it again. When that happens, the computer just inspects the cache and gives back the answer it worked out last time. In the case of HTTP based applications, web-browsers (and web-browser toolkits) will store data that they download from webservers, and use this cached copy the next time that document is requested.

Now as part of that effort to get version 1's load time down from 60 seconds to 10, we shipped with what we called a primed cache: we shipped with a cache that had already been loaded with map tiles for some commonly used areas, and a bunch of other stuff that we figured most of our users would need. We didn't do that with version 2. Mostly this was because the huge win in load times that RouteMe got us somewhat obviated us of the need to do so, but it was also because we wanted to shrink the download size. Version 1 clocked in at around 7MB, while version 2 is a little over 1MB -- much more palatable, especially when you're on the road and don't have a WiFi link to work with.

So what people are now seeing is that when they upgrade to 2.0 and fire it up, they're met with a few seconds of a grey screen while those first map tiles are pulled down. Similarly when they pan around, there's more grey where the first version didn't have it because those areas were in the primed cache. I hope that they're also seeing that when they do that panning, the application responds instantly, zipping and zooming wherever their finger takes it.

But the great thing about a cache is that it remembers -- after you've suffered through those first few seconds of downloading map tiles, you'll never need to wait for them again; the phone will store them and the next time you load up the app, you should get a map on the screen within about 3 seconds of tapping the GasBag icon. That's faster, much faster, than CoreLocation is able to get a fix on your location in most cases, which is pretty hard to beat.

As for the map being ugly, well, I got used to the Virtual Earth imagery pretty quickly, but it was a bit of a shock initially. As things stand, we really don't have much of a choice at the moment. The good news is that the popularity of mapping apps on iPhone is bringing with it renewed interest in mapping imagery, so we're hopeful that new options will appear in the not too distant future. We're certainly keeping an eye out.

But hey, don't get me wrong, we love the feedback. The good and the bad. So keep it coming, and thanks for your patience while we try new stuff like this out; we hope that we're making a better app for everyone.

James -- CTO and Co-founder.

Thursday, February 19, 2009

Interview on IMES Blog

International Market Entry Strategies' David Brown has just posted an interview he did with Mick, jamcode's CEO, and co-founder of the company. In the interview they chat a bit about what we think makes jamcode applications special, talk a bit about our philosophy, and there's a quick mention of our next app, which we're planning to launch soon.

It's a good interview, and there's some good advice in there for aspiring entrepreneurs who are nervous about taking the leap. You can watch it here, and keep an eye on David's Blog; he talks to a lot of interesting people.

James -- Founder and CTO.

Tuesday, February 10, 2009

GasBag Pro and 2.0

After a long wait, the new version is finally out with an awesome map and much better car tracking support. For those of you who want to track more than 1 car, please buy GasBag Pro for only 99c from the AppStore.

Below is the press release that's going out tomorrow:

JAMCODE LAUNCHES GASBAG PRO

99 cent version tracks multiple cars and ad-free, while free and paid versions have much faster maps


Mountain View, Calif. – February 11th, 2009 – jamcode LLC, the leader in rich-mapping applications for the iPhone and iPod Touch, today announced the launch of GasBag Pro and GasBag 2.0. Both enable users to locate gas stations and the cheapest gas prices while on the move, wherever, whenever.

New features in version 2.0:

• Faster panning and zooming with a new map
• Personalize your car by make, model, year, and color
• Much more stable and responsive to the touch
• Still 100% free with advertisements

GasBag Pro also provides:

• No advertisements for a bigger, easier to view map
• Track mileage and expenditure for more than 1 car
• Easily port data from GasBag into GasBag Pro
• Only 99c


GasBag was first launched in the US in late August 2008 and is available for FREE. Since then the GasBag community has grown at a staggering pace, with hundreds of thousands of dedicated users in the US, UK, and Australia.

“We rely on the constant feedback of the users and testers to ensure GasBag remains the best and fastest gas price finding application on the iPhone and iPod Touch,” said Mick Johnson, CEO and Co-Founder of jamcode LLC. “We’re looking forward to a fantastic 2009 for GasBaggers everywhere.”

GasBag also provides a logbook that calculates metrics such as miles per gallon, average price per gallon, etc. This allows GasBag users to budget and track gas expenses more efficiently. Because GasBag knows your location, how many gallons you filled, and how much you paid, that also feeds the price at that station back into the community. Users of GasBag Pro can now record these purchases and link them against one of several cars. Watch the latest video at http://jamcode.blip.tv/.

Both GasBag and GasBag Pro are available for download from the AppStore today.

Sunday, February 8, 2009

Duplicates

One of the most frequent support requests we handle here involve helping kind people around the world reporting that there are duplicate entries in our database; many including detailed reports of which entry is wrong and including comprehensive, correct data for us to use in its stead.

I wanted to write a bit about what a duplicate is, where it comes from, and some new strategies we're trying to solve the problem.

So, what's a duplicate? The case we're talking about is where a single physical station is recorded more than once in our database, with a very slightly different address. For example, one of our users might enter 12001 S Douglas Blvd, Guthrie, OK, whilst another might enter it as S Douglas Blvd & E Charter Oak Rd, OK. If you click both of those links, you'll see that they're for almost the same location -- Google's geocoder places them only 1 metre apart -- but in practice, any human would recognise both those addresses as being for the same place.

How does it happen? A lot of these duplicate entries are due to a couple of poor design decisions we made at our end. One of the issues we have is that there's an expectation that stations will appear on the map as soon as they've been entered. Unfortunately, for purely technical reasons, this is not the case: it can take up to 15 minutes for a station submission to be approved and placed on the map. When this happens, a lot of people think that something's gone wrong, so they'll try adding the station again, under some variation of the address. Other times it's where we've sourced a listing of stations from somewhere (a handful of chains have complete listings available on their websites), and find that these listings have stations listed that have already been added by our users under slightly different formulations of the address. The other source of confusion here is that GasBag 1.x will actually "hide" some stations, but I'll write more about that in a moment.

The problem with all this is that since we're a map-driven application, we need to find a way to cram all these stations onto a map. This is often hard enough when we only have one entry per station (it's common to have stations clustered around an intersection, for example), but the problem is just compounded when we have three or four listings for each of those stations. As I mentioned above, when faced with this situation, GasBag 1 will actually just stop putting stations on the map once a certain density of stations has been reached.

The big question is: what are we going to do about it?! Well, there's two main strategies we're planning to use to sort this problem out. The first is that starting with GasBag 2 (which is making its way through the approval process now), we will no longer omit any stations from the display. If its in our database, past a fairly modest zoom level, it'll be on your screen. To avoid having so many bubbles that you can't actually see the map, we've introduced an innovative new "bubble stacks" concept. The idea is that when we have an area with lots of stations, those stations will be represented by a bubble icon resembling a set of bubbles that have been stacked, one on top of the other. When you tap on that bubble, GasBag will zoom in and unstack the stack, revealing each of the stations it represents. We hope that this interface will solve a lot of problems, but we're hoping that it will at least resolve some of the confusion people are having with GasBag 1.

The second thing we're doing is to run a batch job each night to go through our database looking for duplicate stations, and we're just going to have this program pick one, scrap the other, and get on with life. Our reasoning is that if two stations are so close together that their location on the map is indistinguishable, then it probably doesn't matter that much which of them we choose to display. This script will ensure that you'll never see two stations of the same brand within a quarter-mile of each other (that's 400 metres for those of us Down Under). Initial testing of this script has shown very encouraging results. This one will be rolled out later today to our live servers, so if you've been frustrated by duplicates in the past, keep an eye out for improvements over the next few days.

We're pretty excited about this, because we know it's been a big problem since day 1, and its always satisfying to cross one of those babies off your list. So thanks for putting up with us while we work on this; we hope it will have been worth the wait.

James -- Founder and CTO.

Saturday, January 31, 2009

GasBag in Wired magazine

Very brief mention in a Wired article by Mathew Honan recently.

http://www.wired.com/gadgets/wireless/magazine/17-02/lp_guineapig?currentPage=2

I actually quite like some of his points on issues with a location-aware lifestyle; we haven't really set up societal norms for whether broadcasting your dinner plans via twitter means anyone's free to join you.