ParkWhiz got an itty-bitty mention in the Feb 2, 2012 issue of Rolling Stone.

A look at how ParkWhiz parked 30% of this year’s Super Bowl attendees.

At the office today.

Come work with me!

parkwhiz:

Know any geeks in Chicago with an eye for design? ParkWhiz is looking for a talented front-end developer to help us bring parking to the people. Full job description below:

Front-end Developer

ParkWhiz is looking for a developer that is truly passionate about the front end. We want someone who is a…

parkwhiz:

We have exciting news – from a pool of more than 11,000 businesses, ParkWhiz.com has been nominated as one of 10 finalists for the Big Break for Small Business Award! We’re extremely humbled and honored by this nomination.

For those of you not familiar with ‘Big Break’, American Express and…

Help me win a trip to Facebook HQ!

Got a billboard. NBD.

A post I wrote for the ParkWhiz blog:

If you traveled to the recent Super Bowl in Texas, or you just have a strange obsession with all things Super Bowl, you may have heard about the $900 parking spot. But was Super Bowl parking really that expensive?

As a primary parking providers for Super Bowl XLV, ParkWhiz had a bunch of data lying around, so I decided to do some digging. The answer is, no, of course you don’t have to pay $900 to park at the Super Bowl. But you can, and some people did.

How many?

Not many. The median price for a parking spot at the Super Bowl was $104. While the area directly surrounding the stadium had relatively few places to park, there are several office parks within a mile. There was cheap parking to be had, as long as you didn’t mind a little walking.

In fact, the price dropped exponentially as parking spots got further from the stadium. Land available for parking increases exponentially as you get further from the stadium, and this chart shows that the increased competition had a strong effect on price. Supply and demand still applies, even at the Super Bowl.

Over half of the attendees waited until the week before the game to line up a parking spot.

The chart spikes on 1/25, when the teams playing in the Super Bowl were decided. There’s a dip over the weekend, and then things pick back up, with the most spots being reserved on the day of the game.

Most people reserved a spot from their computer, but the weekend of the game we saw a spike in reservations from mobile devices.

This most likely reflects fans who traveled to game and left their laptops at home.

Could these people have saved money by securing their spot earlier? This chart would suggest not:

But this chart is misleading. It shows the average price of the spots being reserved. Remember that sales volume was relatively low up until 1/26. The high average price early on was caused by people who knew they were going to the game regardless of which teams were playing. That indicates that these attendees are a little less price-sensitive than most.

In fact, the fans that waited until the last week to buy parking spots paid the highest prices. There were some last minute discounts on the mid-range parking spots, but the average fan would have saved by acting sooner rather than later.

So back to our original question. The average price paid for a parking spot for Super Bowl XLV was $124, quite a bit more than the average $36 you’d pay for a spot at a Cowboys home game. However, Super Bowl tickets were selling for an average of $3676 according to StubHub, a whopping 2298% markup over the $183 (according to SeatGeek) you’d pay for a ticket to a regular season game.

It almost makes the parking sound like a bargain.

PS, check back on February 21 to see if Daytona 500 parking experiences similar fluctuations.

God and Parking in Arlington, TX.

Finally. Been trying to nail this one down for a while. Will I get to sell some World Series parking this fall?

So Google launched an Android App that is supposed to make parking a breeze. One problem: it won’t.

The app works by having people report when they’re leaving their street-side parking spot. That data gets fed into the app, and then drivers can see where people recently left an open parking spot.

The problem is that data has a very short lifespan. In the time it takes you to pull out your phone and figure out how to get to that open spot you found using Open Spot, that spot will get taken. By someone who wasn’t futzing around with their smartphone.

The real solution is to price street parking for what it’s worth. That means parking meters, and that means much more expensive parking meters. Higher prices for parking create greater turnover in the spots, which makes it easier to find a parking spot. San Fransisco is taking a stab at this with the SFPark project. (Fun fact: the original premise of ParkWhiz was to do exaclty what SFPark is doing.)

Not being able to find an open parking spot is one of the hidden costs of “free” or cheap street parking. There are some other hidden costs too. Because these costs are hidden, raising the price of municipal street parking has long been a politically untenable issue.

So even though Google Open Spot won’t directly “make parking a breeze,” it, along with SFPark, and yes, ParkWhiz, helps comprise a rising tide organizations that are using technology to make parking more efficient. The best way for Open Spot to succeed is to make it unnecessary to use Open Spot in the first place.

My first foray into mobile app development. Check it out at http://touch.parkwhiz.com.

(And if you’re wondering where all of the reservable parking is, search for a destination like MSG, JFK, or Wrigley Field. ParkWhiz is primarily about event parking.)

I made an API! Check it out.

This past Tuesday, ParkWhiz was crawled by a bot that was doing 10-20 requests per second, despite a 1s crawl-delay setting in the robots.txt file for the domain (you do have a robots.txt file, right?). I ended up blocking the bot’s IP address using iptables, but that’s hardly a long-term solution. So how should you defend a site against overly-aggressive bots?

Turns out nginx makes this really simple – just use the limit_req_zone module. Set a rate limit, like 2 request per second or 30 requests per minute, and nginx will make sure no individual website visitor exceeds that limit. A “burst” setting can be used to provide some flexibility, allowing a visitor to make a number of requests in rapid succession before imposing the rate limit.

By default, nginx will attempt to slow down the visitor by delaying responses once the limit is reached. The “nodelay” option can be used to just return a HTTP 503 error instead. I think this is preferable, since it lets the offending visitor know something is wrong, rather than just making the site seem slow.

These are the settings I used for ParkWhiz:

Here’s the important part: put the “limit_req” directive in the location block that passes requests to your app server (mongrel, php-fpm, etc). If you put it in the server block, it will count all requests as part of the rate limiting, including images and other static files. A visitor will hit the rate limit simply by downloading the assets of a single page. We only want to limit requests to the app server.

Try it out; go to http://www.parkwhiz.com and ctrl-click a link a bunch of times in rapid succession.

SEO win!