The AT & T Hackfest was in Palo Alto. Sleepy, beautiful, affluent, diverse and yet economically not-diverse, Palo Alto, at the AT & T Foundry, a neat space with lots of power, sunlight, and (oddly, but great) random doors onto the street. I kind of love that place. We slowly formed a team- my teammate from other hackathons, Stacie Hibino, and Estelle Weyl, whom I’d admired her from a Javascript class a few months ago, and Stacie had worked with her at another hackfest. Two friends joined and left, graphic designers lured elsewhere. A friend Kris was with us the first day then – as server problems mounted- left for the beckoning weekend sunshine. I totally understand, and no hard feelings. For us- and I can speak for Stacie on this I believe – it was a very rough hackfest. Which, I will get into.

So, first night, we meet at 6pm – my friend Kyle and I getting a ridiculously expensive glass of wine quickly beforehand- and suffer through a ton of talks on the various APIs sponsored for this hackathon. Sure, my talk was one of them, but seriously there was too much information overload that first night. And, we were rarin’ to go. The lights go on at 9pm, and during that time, Stacie has been trying to understand the various API’s already. We only have a night, and a full day the next day, in which to hack. It’s a really short timeframe and it’s already 9pm. Oh, and the dinner has run out twice. No one on our team got any – which is kind of funny.

We put up some ideas on the board, figure out with a big grid what the prize categories are, and how each tech API fits into them. Two of our ideas make the final cut, and Estelle has to take off. Stacie, Kris and I go to dinner, and I’m still pretty overwhelmingly confused and wondering if some of our basic ideas- uploading a photo from a phone- will work in HTML5, and on what cameras, and how do we get it back, etc. I know Estelle will know these, but in the meantime feel worried that our idea is sound and that it will work.

My friend Kyle has joined a team of folks working on a fitness app. They’re using an API that uses the Facebook REST authentication, and while I help them a bit, I can tell it’s a total time suck and I need to get home, back to SF. We talk in the car about the prize categories, and some of the ideas that were tossed out. My team, at that point, was trying to do a scavenger hunt, with geolocating and photos. Kyle’s was doing a social, shareable fitness app. Kyle and I worked together at a lightweight Facebook company, so we were talking about modular styles and simplicity, and came up with a good new idea for an app.

Estelle’s working geo-locator in HTML5/JS

The next morning, waking up after a few hours sleep, corralling my carpool buddy and getting down to Palo Alto in the my borrowed car, trying to park amidst a big Palo Alto Cinco di Mayo fair, we finally settle in with all of our teammates.

I pitch the idea Kyle and I had from the car, but no one bites. We’re still on the scavenger hunt app- there’s plenty of food (fruit!). Last night Stacie’s done more reading, and we talk about our framework. We’ve chosen the AT & T Sencha/PHP API. Stacie and I sit down to pair program on the server API, while Estelle does geolocation and the HTML app, the entire app, basically, besides the photo upload stuff. She likes to sit on a couch, so she camps a few feet away in eye distance, and we setup an IRC channel. Stacie and I hunker down to what will be approximately a 10-hour experience in total frustration, ha.

I really like working with my team- something new to me as it’s usually just been Stacie and I. I respect Estelle’s initiative and ability to project-manage herself, she’s very direct, which I appreciate. She also has a ton of knowledge about CSS, JS, mobile, etc. It’s really amazing.

So, we evaluate roughly 6 servers in our search for an environment that will work. During the day we toggle between 3. This is because the samples we’re building off of not only need a LAMP stack, but one configured a certain way. Also, the sample files are confusing, we need to mimic a structure that isn’t explained anywhere. The server and client files are named the same, causing over-copying issues. It’s a poorly constructed sample.

Luckily we discover a few hours down the road that Stacie’s server- which is blocking her password but she has one locally cached password FTP connection, interprets the PHP the way the samples were written. During that time I’ve I setup Amazon EC instance, which would qualify us for another prize category. The interesting thing is that while we’re doing this, we’re constantly evaluating whether “it’s worth it” on any given problem. We can switch quickly to another server, another flavor, etc. But as you get deeper, you’re getting more committed to your architecture. Around 4pm we finally get a stable server built. Yep. 6 hours setting up our server. We thought we’d be there at 11 AM.

Me & one of my unreadable diagrams… figuring out how we’re going to match long and lat to the MMS photos- which we didn’t have time to do :(

So, that was a big fail for me, as I’m doing server stuff all the time at work, and that was the part that I thought was seriously easy at a client-based hackfest. Upon a 12 hour reflection, my point of failure was relying on 3rd party APIs vs. common sense.

We get SMS texts sending. We get multimedia texts sending (photos). So that’s something. Now, we start working on interpreting the photos from a short code. We essentially give this about 3 hours. I ask the AT & T representatives a lot of questions- and thing is, they haven’t written the samples, and the developer APIs exist in about 6 flavors. So they tell us how it’s designed to work, and how to troubleshoot.

We get the MMS upload to work, but not reporting, this is looking at a manually uploaded photo file

Around 6pm, I walk up to the AT & T reps I’d been working with and told them we weren’t demo’ing because it wouldn’t work, and one of them ran over, but again, but ran away again to research something and we didn’t see him again until the demo.

I don’t know when we decided to demo despite everything– Estelle’s stuff worked, so we can show that, perhaps. Classic hackfest scenario: we’ve focused on making the server pretty for the last hour- which, since we’re only on one FTP connection, is Stacie’s job, and it looks great. Then, she asks me to add some Facebook, so I do a quick client JS file on my computer and email it to her, and watch her pop it into Sencha (a JS frame work I’ve never used). Since I don’t know it, I wrap the JS around the Sencha code, just avoiding the entire thing. When the Facebook auth’d share pops up, she looks at me and says, “That was amazing.” Ha ha.

My Bacon Unicorn Facebook contribution, haha. If only I’d done it in Open Graph!

You just never know what state your competition is going to be in. I had an idea, from hanging out with the representatives, that maybe only 1 team had gotten the AT & T payment exchange to work. We didn’t see a lot of MMS server people, so we had wiggled our way into a niche. So while Stacie was feeling pessimistic an hour before demo’ing, and I was optimistic, our roles were now reversed. Estelle didn’t know the extent of our server problems, so she was really optimistic.

We went outside to practice our demo- deciding to demo on different phones that show the features best- and ending with me explaining the server stuff. I felt defeated because of what didn’t work, but I needed to get out of that frame of mind and focus on what *did* work. Estelle, more of an experienced speaker than I, gave me a few pointers, “Don’t apologize. Don’t talk about what doesn’t work.” She basically had to say that a few times.

We grabbed our unicorns (Kris had bought two adorable ones) and I texted her a quick update. Then we presented our demo. We ended with 45 seconds to spare in a 3 minute demo- though I didn’t demo the photo upload to the short code (MMS send), as I thought most people knew how that worked, but it might have been stronger demo if I did. I think the demo went well because folks seemed interested, and Alex, the organizer, came up to ask us to demo certain parts to the judges.

Estelle’s working geo-locator in JS/HTML5

Which begins an ethical quandary, because we didn’t get the MMS reporting to work. We could upload, our app was configured correctly, we could see the photos land on our server, but the last piece of hte puzzle- the server interpreting the photos and placing them in the data structure- was not happening. I made the decision *not* to demo the MMS server to the AT & T rep, as he knew really how far we’d gotten since he worked so close with us. I did demo the Facebook share to the Facebook representative. To a degree, everything demo’d is broken in a way, but we were shooting for a functioning, truly functioning demo, and as it was, it was pretty disjointed. I agree on putting your best foot forward, but also in honesty. I told Stacie she could demo the server to Dale (AT & T guy) if she thought she should, but I wasn’t going to. I’m proud of the work we got done, and while we didn’t get it done 100%, it’s … not really our fault. I’m still not convinced the samples worked as written.

Re: the hackfest… good news- you got a lot of developers to your hackfest to use your API! Bad news, they’re frustrated with it. As someone who has written 3 API’s now, I want to say: make it easy. That is the basically the goal. If your developers can’t make fun stuff with it… it’s not easy. The “pressure-cooker” environment doesn’t help- the time limit and size of the prize. If AT & T really wanted more developer support, they would ask Stacie and I to write a sample that they’d include with their SDK. One that worked on *all* common, implemented versions of PHP. Do they know that most servers don’t support PHP5.3? That worked without Sencha, because the developer base for Sencha is not as big as, say, jQuery. Or, just normal JavaScript. When I woke up this morning, I realized I could solve our problem with 1 short PHP file interpeting JSON encoded MMS image data. One thing I learned from this hackfest is to not trust, nor rely, on the examples.

I broached this topic with the reps, and they explained that they have this complexity in the samples, to manage payments. Thing is, interpreting a MMS is not a big deal. You need to separate the dependencies, or put a lot more development effort into making it easy. Developers like easy.

Kyle Mock’s team Fitness Karma win in two categories!

On a lighter note- Kyle’s team won in two categories! It’s awesome to see them win because they worked very hard, and did all the coding in the weekend, and the app is a great idea: You can report your fitness achievements to Facebook, essentially. I’ve been talking about how fun hackfests are to Kyle, so it was neat to see him run the entire gamut from 1st time attendee to winner! I’m a witness too that Kyle put a ton of work into it himself.

I was trying to describe to Kyle in the car how I’m proud of what we’ve done, because we were tackling a big topic that has been evolving for a while- not just locating photos, which most sites do quite well now, but the live, HTML5 (lightweight) ability to post photos to a location. It’s a form of augmented reality, saying, this latitude and longitude has these photos associated with it. And a crowd-sourced way of doing it, so we’re not providing anything, our server tracks the lat and long of each photo posted. So it’s a pretty ambitious task, and one that I’m glad we tried to solve with our braintrust.

I didn’t talk to nearly enough people, and wished I’d mingled more, but with the time constraint and our server issues, I didn’t really have time. I usually do some interviewing and don’t mind getting my photo taken, but again we were super stressed. Sad, because one of my goals had been to do a lot of networking!