Ben Nolan

Here are some ruby things that are really gross and you shouldn’t do:

This is a bit of a stretch, but it occurred to me while using vine, that you could look at some of the culture of reddit and use it predict what might be a successful app.

So, last Thursday at about 3pm, Erin Francis had the idea to build a mobile app that we could use to keep track of what beers we had drunk at Beervana, and to get some rankings on the beers that people drunk, so that you could see what were the most popular beers.

I think geoblogging might become a popular thing. It’s pretty nerdy, and whenever I research the larger social networks, no one really seems to care very much about location when they create content, but I think it might become a thing. I think the most popular geosocial network at the moment is foursquare, and there is a lot of microcontent being created there, hints and tips on places.

I read this interesting article by Matt De Leon, about using turbolinks and server-side generated javascript with Rails to build a nice fast app. He is a backbone developer, and found that he could build a nicer app using turbolinks than he could using Backbone.

Here’s a good idea. If you worked at a medium sized consumer start-up (say Flickr before yahoo bought them), it’d be awesome that if every time you created a git branch - your CI system automatically created a subdomain for that branch and deployed your code there.

I must point out to my readers, that I am not the Official Ben Nolan.

For those that don’t know, I’m the owner of ZoomIn.co.nz. And I thought I’d share some background:

I stumbled across this idea the other day, when I was wondering what was going on in town, so as you do, I went to the facebook page for hashigo zake, then bebemos, then little beer quarter, then goldings free dive. And I thought, there must be a better way to do this.

I’ve been working on placepinner exclusively lately, to the expense of my other web property, ZoomIn. ZoomIn is still making a little bit of adsense revenue though, so it’s ok just to tick over in the background.

I’ve been doing about two weeks of android development now, on and off. It’s been interesting. The things I like:

I’ve started working on a native android app for placepinner. I decided to go this track after trying out a quick phonegap app using ratchet and backbone.js. Even though it’s super easy to develop, and you can do some quite nice UI with CSS, I couldn’t help but notice how laggy scrolling was using Phonegap.

I released the first iteration of a mobile site for ZoomIn last night. Try it out on your iphone or android phone and you should get a mobile-designed stylesheet. It’s not complete, the recent / popular and group pages in particular aren’t done very well, and I want to add a view that shows you ‘what is nearby’ (using the html5 geolocation api), but it’s a first cut, and the place pages in particular are a lot more usable on mobile than they were before. I haven’t tested it thoroughly on iphone yet (I don’t have the simulator installed on my home laptop), but I’ll probably be doing more mobile work over the coming week, so things will slowly improve.

I’ve been working on the ZoomIn mobile view, on and off for a few months now. I initially started by creating a :mobile format in rails, so that I could render a totally different view for mobile users. Eg layout.mobile.erb and show.mobile.erb. This worked pretty well, and I got off to a flying start, styling up the mobile view and copying view code across from the desktop view.

I’ve been working on a trip planner, on and off for quite a long time now. Probably since back in 2008, when I started work on ‘weheartplaces’. The original idea was to make a site for bookmarking places you want to go, like delicious, except for places. Basically you’d use it to make a list of places you might want to go one day. Foursquare does a pretty good job of this with their ‘want to go’ feature. And trippy does a pretty good job of being pinterest for places, you can create a wall of all the pretty places you want to visit one day.

Tuesday to Friday I work at Powershop, on their large rails app that runs most of the business. They’re a great team and I really enjoy working on such a gnarly rails project.

The lifeblood of a website is it’s traffic. If no one is using your site, it’s basically dead. One of the things that interested me most when I was considering purchasing ZoomIn, was it’s traffic stats. On a typical Monday, ZoomIn has around 10,000 visitors, 85% of which are from New Zealand.

I’ve been thinking of upgrading ZoomIn to some dedicated hardware. I currently use a 4gb ram VM hosted by rimuhosting in Auckland. They’re a pretty good crowd and the performance has been ok, but IO is especially slow, so anything which hits disk is slow. I’ve fixed this by caching expensive things (for example the json used in the new search sidebar) in memcached, and adding indexes wherever explain analyze showed a sequential scan, but it’s annoying to have to do so much performance work in production, when performance is perfectly acceptable in my development version (running on a SSD and 4gb of RAM). And so I’ve been thinking about moving to some dedicated hardware - maybe something like this:

When we first wrote ZoomIn, back in the day, the built in search that came with Postgres (TSearch) was implemented as a bunch of stored procedures, and generally sucked. So we used a high performance C++ reverse index search library called Xapian. Why did we need full text search in ZoomIn? Well, the plan is that people would tag places with keywords, and then you could generate a searchable column on each place, that contained all the tags, the address and any other information we had about the place, so a search like:

I’ve been working on ZoomIn a lot in the past few weeks. I need to start writing more newsletters about what I’m doing. But anyway, there’s a technical aspect of ZoomIn that I want to highlight, since it’s really great.