Such a GIT

Day Five: Oh, hai Twitter

2011-05-18T23:50:00.000-04:00

So, day five of #ioadventure. Like, a week after the fact. Because I'm a terrible, terrible blogger like that.

I woke up at a reasonable time today (Yay!), and arrived to breakfast a little after it started, around 7:15 or 7:30. The keynote wasn't scheduled until 9:30, so I wasn't too worried. I met up with Parker and Dylan for breakfast, and we ate pretty quickly. Dylan's competitive nature rubbed off on me, and we were determined to get good seats for the keynote. So we waited in line at the escalator up, then waited in line in front of the keynote doors. Which, incidentally, look like something you'd see in an airport hangar. We managed to get right in the front. Because we're awesome.

Two employees came around and told us we needed to stand behind a certain point, and that when the doors opened, we had to hold people back until the doors reached a certain height.

I have no idea why they did this, because they didn't actually open that door. They opened the one next to us. The jerks.

We still managed to get good seats, though. So I can't complain too much. If you're interested in the keynote, I'll embed it below.

After the keynote, we went to the sessions. Some of them were a bit over my head. Some of them were a bit obvious, to me at least. During the session, however, I got a tweet from Christian, a Twitter recruiter I know. He used to be a recruiter for Google. He wanted to know if I was in San Francisco for I/O. When I told him he was, he invited me and the #googleioparty (Dylan, Parker, and our honorary member, Kevin) to come have lunch at Twitter. I passed the message along, and we met up before lunch to travel to the Twitter offices, down the street from Moscone West.

The Twitter dining area has a really cool sign that displays a random tweet as they come in.

Christian took a picture of me and Kevin in the dining hall on my tablet.

Some engineers and documentation people came and sat with us, which was pretty awesome. We talked for a bit, and Kevin managed to get BarCamp Rochester their Twitter account back (they lost it when the person who set it up left).

After we left the Twitter offices, we walked back to Moscone for some sessions. This was followed by the Unicorn Summit, which I now get to talk about.

As it was described to me, the Unicorn Summit (or 'Advocate Summit' as it was officially dubbed. We used Unicorn Summit instead, because that name is so much more awesome) was basically a meeting between external advocates and the top executives at Google. They basically said "Hey, let's take external advocates and the top Google execs, put them in a room, and watch what happens." Which is essentially what happened. We met in the press briefing room, and the executives started taking questions. A lot of the questions were requests for support or calling the execs out on things the advocates took issue with. Which started making me feel bad; feedback should be praise for what was going right and criticism for what was going wrong. So I tried to balance out the sea of negative with a little bit of praise.

After the official Summit, project leads were available to us for questions. I met briefly with Shannon Madison, the University Program contact at Google and chatted with her about a few things. After that, we did some sessions, and met back at the GTUG lounge. We took some group pictures, and headed out for a dinner of Chinese on Google.

At the restaurant, I sat with Dylan, Joseph (the 14 year old), and a few other people. Shannon (the Google University person I spoke with) joined us, and shamed us all with her Chinese skills. We ate, talked, got swag, took pictures, and generally enjoyed each other's company for the last time.

Me and Joseph

Me, Dylan, and Steph. I look like a creeper.

Me and Van

After the dinner, I went back to my room. Dylan tagged along to say goodbye to Kevin. Kevin wasn't there, so Dylan and I chatted some. When Kevin showed up, Dylan said goodbye to us both. Which is sad. He was a bunch of fun to hang out with.

Kevin and I talked a bit as I packed, and then said goodnight.

I can't believe it's over. It's been quite the adventure.

Day 4: #googleio

2011-05-18T23:12:00.000-04:00

Yes, I'm disgustingly late with this. Oh well.

I did something different for Day 4, and created a video. Why? Because I had a shiny new tablet with a front-facing camera. Is there any better reason?

Urban Airship, with their coffee..

Google I/O Keynote, Day 1

Pamela Fox (and the Go Gopher)

Dylan and Parker in the GTUG area. First picture on the new tablet!

Just Vic Gundotra. No big deal.

Day 3: Freedom!

2011-05-10T00:58:00.000-04:00

After the epicness that was day two, I needed a bit of a break on day 3. Well, for my usual schedule it was a break, at least.

Today, I had absolutely nothing scheduled. How liberating is that? I had nothing I needed to do, nowhere I needed to be. And I made the most of it.

I woke up, showered, and got ready for the day. I had been avoiding wearing my Google gear because I didn't want to mislead anyone at any of the official events, so I decked myself out in it today. Google t-shirt, Google hat, the GTUG jacket I got during day two... I was a walking billboard for my favourite corporate giant.

I spent the day... wandering. There's no better way to put it. I left my phone in my pocket, ignoring the direct link it has to satellite maps of the area, and just walked around with no particular aim or direction. I decided I wanted to eat, and instead of pulling up a list of restaurants in the area, I just wandered until something caught my eye. I ended up buying a hotdog and a soda at a tiny little stand outside of U.N. Plaza, then eating and working with my Chrome OS laptop while sitting by the fountain in the plaza. I even made a friend: a bird of some sort (I'm no ornithologist, and will be the first to admit it) sat staring at me the entire time I ate.

After I ate, I proceeded to wander for a few minutes. My aimlessness was cut short, however, by a text message from Kevin Purdy. He just got into town, and wanted to eat. So I called him up, and arranged to meet him at his hotel. Which, coincidentally, was right across the street from mine. His timing couldn't have been better; I had just finished arguing with some American Red Cross volunteers (they had no understanding of the inherent principles involved in organizing people) and was standing mere yards away from my hotel. So I met up with him, and he and I proceeded to wander and talk until a place caught his eye and we could eat. He chose Show Dogs, a hotdog joint near the U.N. Plaza (though a different hotdog joint). I guess it was just a hotdog kind of day.

Both fed, we proceeded to wander some more, and wound up around Moscone. We stopped by the Google Networking team and saw them finalising their preparations. We also managed to pinpoint the single point of failure for the network: a door propped open with a wire running through the crack.

We continued walking, and enjoyed the sight of the giant map marker that has become tradition at I/O every year.

Kevin was tired and jet-lagged, so we started heading back towards the hotels at that point. He napped for a few hours and I entertained myself, uploading photos and checking in/updating my social media (Twitter, Facebook, etc.), which had been neglected during the excitement of my #ioadventure.

In the course of updating my social media, I decided to put my I/O session calendar (a listing of what sessions I would be in) into a Google Calendar so that the 2cloud Project users who were attending I/O could find me and say hi. I did that, and noticed something funny: check-in had actually started already.

Obviously, the only appropriate reaction was to head down to Moscone again and check in. The girls behind the desk were very nice, and proceeded to have a nice conversation with me about my name tag. My full name is Sean Patrick Foran, but my mother always wanted a Paddy. So she and my father agreed to call me Paddy until I grew out of it at age four or five. Those who know me know I'm a giant six year old, so I never really grew out of the name. So while most my programming contacts know me as Paddy Foran, my Student I.D. (which I needed to present to claim my Academia badge) read Sean Foran. My solution was to have my badge read "Sean 'Paddy' Foran". The girls thought this was rather amusing, and chatted with me about it for a bit.

I then proceeded to pick up my Google I/O t-shirt. It's pretty awesome.

The morse code on the back intrigued me, so of course I sent pictures to Dylan (who was in BootCamp, which I had elected not to attend) and we decoded it. It led to a http://goo.gl short URL that led to a site telling us to Androidify ourselves with a special Google I/O t-shirt. It wasn't in the app yet, so I'm assuming it'll be there tomorrow.

My day wasn't over yet, however. At the #gtugcamp, I was told about a meetup for Chrome OS laptop owners. It was a small event hosted by Google in a wine bar a couple blocks from my hotel. Seeing as both Kevin and I had received Chrome laptops from Google back in December, he woke and met me to go to the meetup.

The meetup was small, informal, and fun. I met a host of people: a few "Consumer Operations" (like DevRel, but for consumers) employees from Google, a couple of Chrome OS engineers, a Marine, an independent developer, and Steve Pirk. Steve is the founder of Yensid and a friend from last summer. He's a nice guy, and I didn't expect to see him here, so it was nice to meet up face-to-face for once. Google footed the bill for drinks and dinner, so I once again had my dinner paid for. I was, again, the only underage one at the meetup, so I nursed my Dr. Pepper whilst the others drank wine. Which I wasn't bothered by.

They gave us some free Chrome stickers, and we parted. On the way out, the organiser pulled me aside and took my business card, so she could email me about the problems I was having accessing my school's archaic and silly LMS, ANGEL. I told her it was a problem with ANGEL and not Chrome, but she insisted.

All-in-all, one of the main things I pondered today was how nice Google employees are. I had met about a half dozen before coming to San Francisco, so I thought it might be an isolated phenomenon. But now I've met dozens from different departments, and it's shocking how friendly all of them are. None of them, whether it was the more-money-than-God Google Ventures team or the paid-to-talk-to-you Developer Relations staff, ever had a problem with taking some time to get to know you as a person and helping however they could.

And that is why I'm a GIT.

Day Two: #gtugcamp

2011-05-09T04:36:00.000-04:00

So, I haven't said a lot about it, but I'm the manager of the Buffalo GTUG. We haven't done much, just a single meeting. But that manager position qualified me for entry at the barcamp and dinner that Google held for GTUG organisers going to I/O. Of course I was in attendance. And let me tell you, it was an experience.

First of all, the event was held in Google's San Francisco offices. That means I was drinking sodas from Google's fridge for employees, sitting in their office, presenting and being presented to. That was pretty surreal. Fun fact: did you know the lights in the office are tinted in Google colours? That's so incredibly awesome.

Second, the event was heavily attended by several members of Google's DevRel team. You know, that team I want to work for? I applied to be their intern this summer (Moishe, the engineer behind the Channel API that I've been working with for the past few months, referred me) and just found out today I was rejected. That's ok, I'll try again next year. But it was really cool meeting everyone from the expected (Van Riper, Steph Liu) to the unexpected and mildly jaw-drop-inducing (Tim Bray).

We went around the room and introduced ourselves in three words. Mine were: "I got lucky". They sum up how I came to be in that room, how I came into such close proximity to Google.

The sessions were fun, informative, and informal. I sat next to a Google Brazil team member and debated how to best organise people into a software project over the internet without much face-time. I got business cards for more Android developers than I knew existed. I presented to people on how to present, according to Batman. It was a blast.

After the barcamp, there was a dinner for everyone. We left the room we were meeting in and traveled to the Google dining area. This led us straight through the offices that Google engineers work in, past computers that undoubtedly hold secrets none of us can dream of. Dylan and I were careful to avert our gazes.

When we got into the dining area, we sat at tables and talked until dinner was ready. I realised that Dylan and I were sitting with an employee of T-Mobile, and got ourselves invited to parties from several of the largest companies in the mobile space. We got invited to a meetup about the Cr-48 laptops Google sent both of us. We talked with developers from all over the world. We also got cool GTUG t-shirts and magnetic pins.

When dinner was served, I didn't know what any of it was. So I took some of everything. Now, I'm a pretty skinny guy. I'm six feet tall and 120 pounds. There's a reason for that. I don't like eating. I never really derive pleasure from my food. I do it to stay alive, and that's about it. But the food Google served... I savoured every bite. It was amazing.

After dinner, we got dessert—again, amazing—and they gave all the organisers a GTUG jacket. It's a wonderful jacket—stylish, high quality. People started trickling out, and Steph came and sat at our table. She started talking with us, and then Van came over and sat next to us. Then a few more of the DevRel team came and joined us. And we sat and chatted. It was a bit surreal.

Then they wanted to know if Dylan and I knew each other before the event. We didn't know what to say, so we told the story of how we met.

Dylan and I met in an interesting way. He was watching the #googleio hashtag on Twitter, and I asked when the tickets would go on sale. Dylan then helpfully responded. In my paranoid way, I then wanted to know how Dylan found my tweet. So I began searching around, digging up information on him. I couldn't find an obvious connection, but I noticed he and I were very similar. So I just asked him, and he explained. From there, he and I friended each other on all of the social networks we used and formed #googleioparty, a loose group of students going to I/O. We talked more and more on Google Talk, used Google Wave (RIP) a bit, and generally became friends. And then he noticed something:

The at-the-time-android2cloud logo was atrocious. I designed it, and so it looked horrible. He wanted to redo the design, and submit it for a design competition at his school. I had talked about rebranding the project before, and so agreed to let him do the new design. I talked him through my thoughts on the rebranding effort, and he came up with a beautiful new set of logos and a great tagline.

At this point, we were past the point of no return. Dylan and I were set to be friends. After he made the new icon and tagline, I told him he was my hero. He told me he didn't have a cape, and I joked I'd make him one. He said if I made him one, he'd totally wear it at Google I/O. My joke suddenly turned serious, and I pledged to make him a cape.

But it didn't stop there. I got contracted to do some Android development for Kevin Purdy and 3ones, and wanted to do a great job for them, because of how vital Kevin has been to my professional development. I thought about it, and knew I would need help doing UI/UX for the project. I asked Dylan if he wanted to help. His response was something to the effect of "For Kevin Purdy? The Kevin Purdy? Hell yes!". So I sub-contracted Dylan to do the UI/UX work.

During this time, I decided that my goal for Second Bit was to assemble a small team that made great products. And I knew Dylan would be part of that team. Since then, I've been trying to get profitable enough that I could afford to hire Dylan.

When we had finished telling our story, the DevRel team was ecstatic. They loved that two people met through the hashtag for their conference and were now close enough to be confused for brothers. Steph asked Dylan and me to email her our story, because she wanted to blog about it. It was pretty awesome.

We then proceeded to talk some more with the DevRel team, and they mentioned the after party was at a bar. I mentioned that Dylan and I weren't of age, and they all got confused. We explained that I was 18 and Dylan was 20, and they thought it was hysterical. They thought it was so cute that we were both drinking soda, instead of taking advantage of the beer and wine that we could've just picked up without a problem. They didn't think we were that young, and proceeded to make only-mildly-condescending "Awww!" noises at us. In good fun, of course. They then told us about Joseph, the youngest attendee of Google I/O. You have to be sixteen to attend I/O, but because his dad is a GTUG manager and he works with Google tech, they pulled some strings and made an exception for Joseph.

I, of course, ran over to him and dragged him back to our table to chat with us. He was a fascinating kid. I can't wait to see what he does in the future.

Finally, we talked about the Unicorn Summit. The Unicorn Summit is the code name for what is being publicly called the "Advocate Summit", but we all know Unicorn Summit is a much cooler name. I'm not sure how many details I'm supposed to share about that. I'll say it's invite-only, and it's an amazing opportunity. Even better, Steph allowed me to nominate Kevin for the event. Which was amazingly nice for her, and I think he'll be ecstatic when he checks his email in the morning.

We had to leave shortly after that, but on the way out, I noticed a slide. Yes, a slide. It seemed like the appropriate ending to a trip to the Google office. No, I did not slide down it. Unfortunately.

Night One: Startup

2011-05-09T03:25:00.001-04:00

This one's a day late. Forgive me.

I got into San Francisco at around seven PM, PST. I proceeded to wait until about 8 for my shuttle, which was annoying. By 9, I was checked into my hotel. It's TINY. My room is the size of my bedroom in my apartment, but they crammed a queen bed in instead of a twin. There's no bathroom, only a sink. The toilet and shower are around the corner, and shared. But it's dirt cheap, clean, and safe, so I can't really complain.

After I checked in, I sent an IM to Dylan's phone. He was already in San Francisco, at his hotel, working on a paper. After some hemming and hawing (he chose a hotel that is apparently surrounded by "bad parts" of San Francisco) his father convinced him that if he wanted to experience the city, he'd have to go out after dark at some point. So Dylan came over, and I gave him his cape (there's a story behind that-- I told him he was my hero for doing design work for the 2cloud project, so he said he wanted a cape. I, of course, made him a cape). We then went out to a little indie coffee shop and sat and talked tech until they kicked us out to close. We passed Moscone West on the way there, so of course we took pictures of the Google I/O preparations. After being kicked out, we walked back to my hotel room and carried on our conversation.

Our conversation, of course, led to an idea. An idea I had started playing with months ago. We pulled up that tech, and started discussing it. It wasn't until a hotel manager came by at eleven and told us we needed to close the door that we realised that we were doing the cliché startup thing—form an idea and iterate on it from the free wifi in our cheap lodging. He left around midnight, and I checked in on what I missed during the flights. Then I went to sleep, anticipating the GTUG Barcamp in the morning.

#ioadventure

2011-05-07T14:48:00.001-04:00

I haven't written here in a while. I have some stuff to share, but I need to catch a flight in fifteen minutes, so I'll keep this brief.

I managed to get a ticket to Google I/O this year. And somehow, managed to finagle my way into rescheduling all my final exams so that I could spend my finals week in San Francisco.

As I type this, I'm sitting across from a girl hammering on a laptop while wearing a Google shirt. I'm wearing a Google hat. I look around the packed terminal, and wonder who's here for Google. I feel like I'm home.

I'll do my best to keep this up to date with what I've dubbed my #ioadventure. I've got pictures I'll be putting up when I get a moment. I'll be writing up some stuff about exciting meetings. I'll be sharing and updating and documenting some more.

I'll be in heaven. Come with me, it's a magical place.

I'm going home.

The Human In The Machine

2010-12-26T17:17:00.000-05:00

I guess it's about time we got around to the whys of this. I mean, I've built this blog up, chronicled the rise of one of my applications from the expected obscurity of its launch to the unexpected explosion of traffic that Lifehacker brought it. I've maintained report cards and game plans, and am still stoically working towards becoming good enough at what I do that Google will hire me. There are two questions that this raises, and I want to address both of them. First, the hard one: why do I want to work for Google? Second, the more easily explained one, what is it exactly that I do? Or even want to do?

I'm going to start with that second one, and it will just naturally flow into the first one. Fair enough?

When I tell most people that my dream is to work for Google, they assume I want to write software for Google, software used by millions or billions of people on a daily basis. And I won't lie to you, that's an offer I wouldn't turn down. I'd actually work pretty hard for it. But it's not where my passion for computing stems from. I thrive, and always have thrived, on the human connections that software makes. I've always found computer geeks, of every walk of life, to be enjoyable company. And it occurs to me that it isn't computers that I love (the most, at least), but rather the community that surrounds computers. I speak, of course, of my beloved Open Source community.

What I want to do is work in Google's developer relations staff. I want to be an advocate for Google's technology, and I want to show people how technology can make their life easier. I want to travel the world and meet geeks and enthusiasts and professionals and everyone in-between, and I want to have engaging, stimulating, and mutually enlightening conversations with them. In short, I want to spend my life engaging the human aspect of this digital world, on its own turf. Conferences, hackathons, developer days, office hours, random impromptu meetings on the street. I want to lose myself in something I've been deprived of ever since my fingers hit keyboard: a computer culture.

But that still doesn't answer the question of why Google? Everyone I've spoken to has warned me that Facebook is the future. The mass exodus of Google employees seems to reinforce that vision. It would certainly be easier for me to get hired as an advocate by a smaller company, something that would still make me engage that culture I love so much. So why shoot for the stars of today, when everyone seems to agree they're going supernova rather soon?

Because a company is more than a stock price. A company is a culture. Google has a culture of trying weird, new, innovative things. Facebook does some amazing things with computers, but have none of that razzle dazzle that Google has. They have nothing exciting. Yes, Facebook Messages is basically a clone of Google Wave. But that's what it is: basic. Facebook made the best product they could within the restraints of it being simple enough to be efficient and easily grasped. Google made the best product could within the restraints of it being damn cool. That's really all Wave was: "Look at this. It's cool." It was exciting technology, and that's what killed it. It was so new, so foreign, so futuristic, it was amazing and cool. But it was also so new, so foreign, so futuristic that only the most hardcore could grasp the learning curve.

As a person, I want to work with software that's exciting and cool, even if it's less practical. Because it's exciting and cool. I have enormous respect for the people at Facebook, churning away at their platform, fine-tuning it and making computers move faster than they were ever meant to, making networks work in ways nobody has thought of. I have enormous respect for the people in Google doing that work as well. But that's not me. That's not the kind of person or developer I am. I'm here for the glitter and glitz, the presentation, the razzle dazzle.

This is what I want to do. And to do this, it's not enough to know my computers. I need to know my community, and my community needs to know me. I've made starts into that, but I need to be doing more.

So I'll see you all at Google I/O in May. And keep your eyes peeled for stuff from BuffaloGTUG. We'd love to have you at a meeting if you're in the area.

Indulge Me

2010-10-24T02:48:00.000-04:00

I'm laying in my bed, in pajamas and a sweatshirt, reading Scott Rosenberg's Say Everything during a rare break from work (school, job, or independent). And as I read about Evan Williams' creation of Blogger and his efforts to sustain the product without cash, income, or employees, I'm reminded of myself. And I mean that in the least conceited way possible.

Over the summer, I wrote a little hodge-podge of scripts that are being used by (by my estimate) roughly ten thousand people today. Let me take a second to talk about that number. I go to a college of about 4,000 people. I went to a high school of about 2,000. In all likelihood, more people than I've ever met in my life are using my software. That's unreal. This has led me to receiving emails from Google employees, an ex-Googler who now works as a Product Manager at Zynga, a Comedy Central website developer, a Lifehacker writer, and thousands of people who I have never met in my life, but who appreciate my work. No, not my work-- my play.

I have no way to monetize these scripts, I have web servers crashing every night as they're overloaded with people using the service, and I don't even have a company yet. I'm just a kid, sitting in his pajama pants in his dorm room at 2:30 am, writing code in a free software editor on his little Dell Inspiron 1525 laptop, the same one he'll cart off to his medieval literature class in ten hours to take notes on Chaucer.

People have donated. People have donated a lot. 245 people have bought the $1 download version of the app. Ten people have donated a total of more than $150 to the application. We even have a corporate sponsor, thanks to WonderProxy, who tossed us a $200 cash infusion as our servers were crashing and our coffers were empty.

I just wanted to take a moment, and note how blessed I am. How blessed I am by great users and an Internet that could allow me to hold a tenuous, limited feeling of empathy with an Internet legend. No, android2cloud is not going to revolutionise the link-sharing world. No, I don't think people will be devoting chapters to me or android2cloud in some book on the Internet in the future. And no, I don't think I'll ever be at the helm as successful as Twitter.

But I do think that, for one semester, at least, in a college where I'm not rewarded for my play, with a personal history of being told that my play is worthless and I should focus on things that will look good on a resume or that will make me money, I was given a chance to have my play mean something, and was told that thousands of people made meaning out of it.

Report Card!

2010-08-29T03:10:00.001-04:00

My classes start on Monday (which, because I'm writing this at about 3 a.m., is tomorrow morning), so my summer has officially come to a close. It's been a long time (an unacceptably long time—I'm sorry!) since I last wrote anything on here. I've been keeping busy with getting back on campus, returning to my paying jobs, and working on android2cloud. So I thought I'd do a quick post to give myself a grade on my summer school progress.

If you remember, I laid out some specific tasks for myself at the beginning of the summer: Learn C, Learn Java and C++, Learn Data Structures and Algorithms, and Gain Experience. How did I do?

Learn C: Final Grade: B-

I picked up K&R's C book, as I said, and read much of it over the summer. I've yet to actually write a program in C, but feel I have a basic familiarity with it at this point. It's not much, but it's a start.

Learn Java and C++: Final Grade: B+

I hacked for most my summer on android2cloud, which, being written in three languages across three platforms, forced me to brush up on my Java skills. C++, however, got neglected.

Learn Data Structures and Algorithms: Final Grade: D-

I, unfortunately, didn't get to delve into the more abstract studies of computer science over the summer. I understand what Big O notation is, at least, but that is really the furthest I've gotten with this. A massive failure on my part, and one that will need to be remedied in the future.

Gain Experience: Final Grade: A+

As I said, I worked for most my summer on android2cloud. Since the project's inception, I have gained over 6,000 users, learned how to write Chrome Extensions, Android apps, and am in the process of learning Firefox extensions, interacted with more Googlers than I'd ever dreamed I would, been covered by Lifehacker, and became one of the first ten people outside of Google with access to the latest API for App Engine. As far as experience goes, I figure I knocked it out of the park this summer. That's absolutely more than I expected. And the summer has introduced me to some wonderful Googlers, ex-Googlers, and non-Googlers who are offering me a variety of opportunities to expand my experience in the future. And I'm not quite done with android2cloud yet.

For an overall grade, I would give myself a solid B. Not the best grade in the world, but nothing to be ashamed of. I wish I had accomplished more, but am very pleased with what I did accomplish. And now that I'm back on campus, I'm ready to raise some hell.

Oh. And did I mention? I got Google's permission to form the Buffalo GTUG in Buffalo. Keep your eyes open—I'll have more to say on that soon, I hope.

Am I Washed Up?

2010-08-07T20:33:00.001-04:00

OK, this is the last post for a while on android2cloud. I promise. I would put it on the android2cloud blog, except it's more about me than the project, so I feel it belongs over here.

As I posted, I got a huge surge of attention when Lifehacker covered android2cloud. Over a thousand new users in a day, a bunch of new donations, and a slew of user-run servers all poured in. The requests went off the charts, and the server went down.

The next day, visits were down a little bit, but not an alarming amount. I worked to optimise the server to handle the load as cheaply as possible, and issued updates to the server, the extension, and the app that day.

That night, the negligible error rate (around or below 1%) on requests from the extension for the latest link from the server skyrocketed to over 70%. Clearly, I had screwed something up.

I investigated, and it seemed like the Chrome extension threw a hissy fit when updated. The authentication, for some reason, didn't carry over like it should have. Probably due to the change from an anonymous OAuth consumer key and secret to a registered one with Google. Whatever the case, people's extensions didn't work until they uninstalled and reinstalled, prompting a new authorisation. So I rolled out a new update, that detected when there was an auth error and forced a reauthentication, with a notification explaining things. The error rate started dropping, following that.

Since then, however, all I've heard, anywhere I go, is "doesn't work". A lot of the time, I think it's a lack of polish: people don't realise they need to select the account after adding it, instead of choosing back. People don't realise they need to add an account in the first place, trusting it to be "magic". Etc. These are definitely things the app could improve upon, and things I'll be addressing in future updates. It is disheartening to see a barrage of "Crap." "Doesn't work" messages with no issue reports, emails, or clarification, though; especially when these messages are right next to messages confirming that the app works on the exact same device.

Also since then, the number of requests per second on the server have decreased dramatically. As in, halved. I have a few thoughts on this. Yes, I think people are uninstalling the service, too frustrated to make it work. Which sucks, because it partially confirms my suspicions that I can't write software at anything more than a personal level. But I also think that people are launching their own servers, which is reducing some of the strain. I also suspect that people wanted to try out the app in the first few days, and so all of them were hitting the server that day. Whereas now, they're not all hitting the server at once, and are spaced out more.

Part of me worries it's just that everyone realised this is a simple, plain application, and left. I try not to listen to that part of me.

Whatever the reasons are, I'm going to try to get some analytical software running (or get the app's data somewhere where I can run analytical software) and try and trend total number of users and how often users are using the app, etc. Hopefully it will offer some insights as to how the application is faring, and how to better serve the users in the future.

The Double Edged Sword: Users

2010-08-05T01:26:00.000-04:00

Well, the cat's out of the bag, now. The venerable Lifehacker covered android2cloud. Others soon followed.

Before the day was over, the app gained over a thousand new users, served 2 million requests, and crashed the server. Again. We burned through 24.5 hours of CPU time.

How was this possible? I haven't advertised the application at all. The answer is simple: users.

My users, my wonderful, generous users, were spreading the app by word of mouth. Enough people found it interesting and useful that the press people organically stumbled upon it. They found it useful enough to write about it. Rinse, repeat.

This is, of course, a double edged sword, as most things are. Or even a triple. Quadruple? I'm losing track of the edges at this point.

On the one hand, more users is awesome. I'm happy so many people are finding use in my application, and am flattered that so many of them think my code is worth using. It's really a humbling experience to see hits in Google Analytics from 678 cities across every continent but Antarctica.

But with users comes server load. Server load brings crashes. Impending crashes need to be reported to users, and I have no real established way of doing so. Except that nice, big database of 1600+ emails. I battled myself over the decision—I do not want to be spamming these wonderful users who have given me so much—but decided, in the end, that keeping them informed of absolutely critical things by sending an unsolicited email was better than letting the server crash, and having a thousand plus people wonder what happened.

Some disagreed.

Totally their prerogative. I understand completely. I've received two requests not to be contacted again, and plan to honor them. My privacy policy has come under attack, too. Which is cool, as well. I'd rather have safe, smart users than a popular app any day. This is exactly why I open-sourced the project: so people could still get use out of it, while feeling 100% secure.

That doesn't take the sting out of "dev sends emails without opt in." though. Understanding your users' disappointment in you doesn't change the crappy feeling you get.

I've even received complaints about the OAuth authentication screen. A shady app name (the Extension's ID) and the "insecure" (unregistered) connection combined to make users feel uneasy. Which is wonderful, because it means people are actually reading what they're agreeing to. And it should be more polished, I agree. I'm working on that. I was just totally unprepared to have more than a thousand users under a month after I launched.

But the complaints, accusation, and distrust—all understandable, if unnecessary—are far outnumbered by the positive feedback I've been getting. I've received ideas today that go far beyond what I've ever envisioned for the application, and that I'm excited to start implementing. I've received more donations (for greater amounts!) today than I have up to now, combined. I've had more thank yous and well-wishes, more people inquiring as to how they can host servers to reduce the load, and more inexplicably wonderful random acts of kindness from strangers as they spread the word, than I have experienced thus far. This is why I'm an Open Source advocate. The very email I was so criticised for, a user felt strongly enough about that he wanted to share it on Buzz as an example of a developer that cares.

Heck, even Bob emailed me, out of the blue, to congratulate me on the success.

So, I guess that's my lesson for the day: with success comes server strain, and with happy users come unhappy users.

All I can do is try to keep the servers up, try to make the best application possible, and do my best to keep as many users happy as I can.

A Global Entrance

2010-07-26T14:47:00.001-04:00

When I hit the big green "Publish" button that made android2cloud available to the world at large, I was nervous. I was nervous because it would be my entrance into the world of mobile applications, and I knew my name would either be associated with "amateur" or nothing at all.

I spent the rest of that night ferreting out bugs that didn't exist in my tests. God bless patient testers (I'm looking at you, Patrick Kettner).

Little did I realise, however, that this would be a global entrance into the Market. I understood that people all over the world could use my application... I just didn't think they would. In the weeks since, I have been shown how wrong I was.

First, a disclaimer. All these numbers are coming off the project page. This is based on the assumption that people going to the project page are people who are actually using the project. In the next release, I'll be tracking statistics for the actual application, so my numbers will be much more specific and accurate.

Since its release, android2cloud has seen visits from over 700 people, in 313 cities, across 42 countries. The country driving the most traffic is Japan. It has served over 1,000 links, and has 209 users. (Those last two came right from the database, so I know they're accurate.)

A large part of this popularity can be accounted for, I'm sure, by the coverage the application has received. Juggly.cn, a Chinese (I believe) blog, covered the app twice, here and here. Moongift.jp, a Japanese (I believe) blog, covered the app here. After these three articles were written, the visits to the projects page and the app usage both skyrocketed. As I write this, the server is serving 6 requests every second, and has served 250 thousand requests in the last 12 hours. As I upgrade the software and App Engine gets its Channels API, I expect the requests to plummet. Still, App Engine has handled this huge amount of traffic without even blinking. The free quotas absolutely covered all the traffic, and I've not seen any unscheduled downtime.

All in all, android2cloud was a huge success. I've been contacted twice about translation and localisation efforts, and the wonderful people at Yensid have contacted me about writing Android apps. I've brainstormed two new applications, and will be launching them in the future. An update is planned for android2cloud, and is mostly completed. I expect to release it in the next few days.

Thanks, everyone, for your support. Especially the people that are donating; you really are too generous. I'm doing my best to repay you for your kindness, and hope you like the features that are coming. If you have ideas I haven't implemented, please contact me on the Google group, or file an issue on the issue tracker. I love hearing from users; you always have better ideas than I do.

Update to android2cloud

2010-07-20T20:15:00.000-04:00

android2cloud has been a hit, so far. I keep meaning to do a post with statistics, coverage, and post-release data from it, but I keep forgetting to aggregate the information in a comprehensible form. I promise, I'll have one up soon.

I do not, however, intend to rest on my haunches. There have been a couple of suggestions, and there are a few features I'd like to see included, as well. A few of these are taking priority right now:

"Silent Sending": this was a feature I hadn't thought of, but one of the commenters in the App Store requested it. Essentially, it asks that users can elect to skip the screen entirely, and just push their link to the cloud from the share intent, in the background. This requires a major restructuring of the code, but I'm hoping to include it in the next update.
Settings for the Chrome Extension: this is an embarrassing oversight on my part; I thought I had included a settings page in the Chrome Extension before release that allowed people to select their server and change the account they were using to authenticate. Clearly, I was mistaken. I am working to rectify this, but there is a bug in Chromium's OAuth code that is blocking this. As soon as that bug is fixed, I'll be releasing this to the general public.
Login Failure Detection: right now, the error handling for logins from the Chrome Extension is a bit... crude. It does nothing; doesn't alert you, doesn't log you out, nothing. If, somehow, your OAuth token or secret gets corrupted, changed, or stored incorrectly, Chrome will happily just keep pinging the server, and will do nothing when the server returns an error. I have a system to handle this largely in place, but it's being blocked by the same bug that Settings is being blocked by. As soon as that bug is fixed, I'll be rolling out that update, as these two features should have been included from the get-go.
Allow moving the app to SD storage: This one should be a relatively simple fix. Someone has requested that they be able to store the app on their SD card. I thought about including that, but didn't think it was worth it, as the app is so small. It will, however, allow people to move the app between phones simply by moving their SD card, and it has been requested, so I'll enable it for the next release.

There are, of course, other issues and features I'd like to have included. If you're curious about them, or have a feature request, check out the Issues page on the project website.

Thanks to everyone who has downloaded the app, and especially all the people who have downloaded the donation app. You guys rock.

Android, OAuth, and Google App Engine

2010-07-17T04:48:00.001-04:00

The single biggest delay in android2cloud I ran into was trying to get Android and App Engine to play nice over OAuth.

Getting Started

I ran through several different iterations of the account support in android2cloud before I finally managed to make this work. Save yourself the trouble, Focus on one thing at a time. This project can be broken down into component parts, and those are much easier to tackle. Half the time, I wasn't entirely sure whether Android, Signpost (the OAuth library for Android I was using), or App Engine's OAuth implementation was at the root of my problems, and debugging was frustrating when I tried doing it all at once. Save yourself that headache. Build in Java first. The first thing I did was build a working Signpost client that ran from the command line. I abstracted every single step of the OAuth protocol into its own method, and tied them all together in main(). When I got that authenticating against App Engine, I knew any subsequent OAuth issues were solely due to my handling of the protocol in Android.

Gotchas:

Signpost on Android doesn't work with the DefaultOAuth* classes. Use CommonsHttpOAuth* instead.
You need to make sure you add a header to your request, or App Engine will complain. Here it is:
request.addHeader("Content-Type", "application/x-www-form-urlencoded");
Your consumer key and secret are both "anonymous"

Make Mine Mobile

Once you have the working Java implementation, it's time to port it over into Android. This is tricky, because you need to pass a lot of information between Activities, and sometimes you don't even control the activities, so managing your information gets to be a tricky business. Intent.putExtra will become your best friend, and a solid understanding of startActivityForResult and Intent.getIntent will save you a headache or four.

Advice:

Figure out how you're storing information ahead of time. It will save you trouble. Remember you need to store, at the very least, their token and secret.
Store your consumer and provider in fields. It's much easier than instantiating new ones every method.
I shouldn't even need to say this, but store your host, URLs, consumer key, consumer secret, and any other constants as... well... constants.
Add "btmpl=mobile" to your authorize URL to get a mobile version of the authorization page.

Another interesting note is the debate between WebViews and the browser. I chose to open a WebView for users to authorize the application with. As Abraham pointed out, that's asking a user to trust my application not to harvest their details through that WebView. He suggests I use an Intent and protocol filter to process the callback. I actually experimented with that method, and found it not to my liking, as it made the back button's functionality weird, and sent unexpected results to the application, at times. After his suggestion, though, I'm back to tinkering with it. If I can make it consistent and user friendly.

For those interested in how I handled the callback, I actually set a callback URL on the host. When the WebView loads a page, it checks the URL. If the URL matches the callback, it extracts the returned parameters. Otherwise, it just loads the page up. I found this to be the most immersive, user-friendly experience, so that's what I went with. I'll write again if I switch to the protocol method.

And, of course, all of my code for my OAuth implementation is in the project's source on Google Code. I'd be flattered if anyone actually used it, so hack it apart, take a look at how I did it, or anything else you want to do that will save you some time. And if you have suggestions or find bugs, go ahead and file an issue. I'll work on it.

android2cloud Alpha Release

2010-07-12T18:11:00.000-04:00

After a full month of development (ok, it didn't actually take that long—I got sidetracked and busy in the middle there) I'm ready to announce the android2cloud alpha release.

I hit the big green "Publish" button last night; today saw its first upgrade, to version 0.1b (a few usability tweaks and support for Android 1.5). You can find the app in the Market by searching for "android2cloud"—you'll notice there's a Donation app, as well, if you feel like tossing a buck my way. The applications are 100% identical, however.

The Chrome Extension is also live. You can download it here.

I set up a default app engine server at http://android2cloud.appspot.com. You're not going to see much there through the web interface.

Of course, all of this can be downloaded, inspected, and viewed at http://code.google.com/p/android2cloud. The entire project is open-sourced, and I'm releasing it there. By all means, open issues, leave feedback, and (if you can) contribute code to the project! I built this as decoupled as possible and open-sourced it for a reason. I want it to grow beyond me.

We also have a discussion group at http://groups.google.com/group/android2cloud. Stop by and say hi!

I learned a lot from developing this application. I used three different programming languages, four different frameworks, and three technologies that were entirely new to me. It was a challenge (more on that in a minute) but it was absolutely worth it.

If you remember correctly, the last time I posted about this, I was at a roadblock, having trouble with OAuth and Google App Engine. I'll be drafting a post in the next few days about how I debugged the issue and got around it, and will be sure to include a step-by-step tutorial on how to implement OAuth with Google App Engine from Android in the future, along with some common pitfalls and mistakes.

Go on, give it a try. Let me know what you think.

Roadblocks Are Bad

2010-06-16T14:54:00.000-04:00

There has been a lot of stuff going on with Google recently that I have kind of wanted to write about: the background on the main search page, the Blogger template designer, and the addition of a UX legend to the Android team (and their subsequent UX focus for the next launch). And yet I haven't. Why is that?

Well, I promised you an application. And I'm racing to get it done before we start seeing its counterpart appearing on Nexus Ones worldwide. Unfortunately, I've hit a roadblock.

You see, I'm determined to build this right the first time. Well, "right". I do believe you should be embarrassed of your v1, but I also believe your v1 should be built on the same framework as your iterations will be. The same ideologies, the same principles. And so I'm putting my foot down, and refusing to save your username and/or password on your phone. I'm just not comfortable doing it; I don't want that responsibility. The only place your username will ever be stored is within App Engine, and only because I can't avoid it there.

Fortunately, OAuth makes this a relatively simple process. Even better, App Engine supports being an OAuth Provider right out of the box. I managed to get the Chrome extension built and authenticating using OAuth in about six hours.

I've spent over a week trying to get Android to authenticate using OAuth, and App Engine just won't take my requests. In the interest of saving some others time, and perhaps getting some help myself, I'm going to share some of the quirks I've learned using OAuth:

SignPost, the OAuth library for Android I'm using, is very versatile. I'd recommend it.
Apache's HttpClient, which I'm using to make the POST request with the link to the App Engine server, does not support changing the URL of a request once it's initiated. Therefore, using a query string signing method requires you create two requests:

String host = settings.getString("host", DEF_HOST);
consumer = new CommonsHttpOAuthConsumer(CONSUMER_KEY, CONSUMER_SECRET);
String access_token = settings.getString("token", "error");
String access_secret = settings.getString("secret", "error");
consumer.setTokenWithSecret(access_token, access_secret);
String target = host+"/links/add";
HttpPost request = new HttpPost(target);
List data = new ArrayList(1);
data.add(new BasicNameValuePair("link", url));
UrlEncodedFormEntity entity = new UrlEncodedFormEntity(data);
request.setEntity(entity);
DefaultHttpClient httpClient = new DefaultHttpClient();
consumer.setSigningStrategy(new QueryStringSigningStrategy());
String newTarget = consumer.sign(target);
HttpPost newRequest = new HttpPost(newTarget);
newRequest.setEntity(entity);

String response = httpClient.execute(newRequest, new BasicResponseHandler());

For some reason, App Engine doesn't care if you use users.get_current_user() or oauth.get_current_user() when it's coming from Chrome_Ex_OAuth (note: I've only tried with GET requests, which may be why). However, when POSTing from SignPost, App Engine does care, and you need to make sure you're using oauth.get_current_user()
I have no idea why, but App Engine will not play nice with SignPost. For some reason, it returns "InvalidOAuthParametersError" for all of my requests, no matter what method I sign them with. I can't seem to figure out whether it's saying my token and signature don't match up, or whether it's saying I've included an unsupported parameter, or even whether it's saying I've not signed the data within correctly. All I know is it doesn't like something about my parameters. Anyone with any insight on this would be greatly appreciated. I'll update here when I figure out the issue.

So far, navigating the OAuth realm has been tricky and treacherous. I still think it's worth it, and hopefully, you guys will, too. As soon as I actually figure it out.

Android Development

2010-05-31T18:49:00.001-04:00

I approached developing the Android application for android2cloud with a few expectations in mind. Not all of them were met. Let's run through my naive list of presumptions, and then we can compare them with reality.

Developing for Android was simply writing Java. I assumed that writing an Android application would simply be writing a Java application, with a few conventions, and plenty of tools that made things easier for me.
There was an open-source application that did something similar. I expected there to be an open-source Android application that had implemented the Share Intent, an application that had made a POST request to a server, and an application that integrated OAuth.
I could curate the code of these applications. Rather than writing the entire application from scratch, I could re-use the code written in the applications mentioned in 2 to create android2cloud, which would save me a lot of time in getting a prototype out the door.

Reality, however, decided it didn't want to meet my expectations. All of them, at least.

Android != Java. Android is, as best I can explain it, a framework built on top of Java. You write using Java, but you're not writing a Java application. You're writing an Android application. There's a whole new way of thinking, several new paradigms, and a new system you need to understand. Fortunately, the documentation is wonderful, so as long as you actually learn what you're trying to do, instead of taking shortcuts, you'll be fine.
The Android community is wonderful. There were indeed several different applications that had implemented everything I wanted to implement already. They had POST requests, they had OAuth, they had the Share Intent. I could simply stitch them together, and have android2cloud.
I could not simply stitch them together and have android2cloud. As I mentioned in 1, as long as you actually learn what you're trying to do, instead of taking shortcuts, you'll be fine. Unfortunately, stitching together components of other code is a major shortcut. Which is why it's appealing. So for a new developer on the Android platform, it really helps to write everything from scratch. Follow the tutorials, ask questions, and write your own code. Later (as long as what you're doing is legal and ethical) you'll be able to curate your code without any problems.

Those are my findings on Android development so far: taking longer than I'd hoped. But, thinking about it, I'd rather spend the time doing it properly. It makes sense that, for my first foray, I should "own my code".

android2cloud Update

2010-05-22T04:59:00.001-04:00

I announced yesterday that I would be embarking on a project that would reverse the Cloud to Android push that Froyo enables. The purpose of this software would be to enable a user to send a longer article (one found in Google Reader, online, or from Twitter, for example) to their computer with the push of a button on their phone. I challenged myself to build the cloud part of this in the four hour round trip to my brother's commencement in Rochester.

It actually took six hours. What can I say? Developing for a platform you've never looked at before with only your phone for internet is tough.

Granted, my implementation isn't spit-shine perfect yet—I still need to make the icon, still need to set up the main page of the App Engine site, still need to fix the OAuth middleman (it keeps saying you're coming from the extension ID, which is a long, unintelligible string of characters; I'd much rather it say I'm coming from android2cloud), and I need to let you destroy OAuth tokens. But all in all, it works, albeit with a (up to) 15 second delay.

Here are the features as they stand:

OAuth integration: you don't need to trust me with your password
Chrome/App Engine integration: links are stored in App Engine, and if Chrome recognises them as a "new" link (a link it hasn't previously opened) it auto-opens a new tab for them.
A browser icon that forces a check for your latest link. It will open that link without bothering to check if it has been opened before. Handy for revisiting your latest link.
Tied to your Google Account: Only you can open links you've shared, and only links you've shared can be opened automatically for you. No worries about someone spamming your browser with their links.

All in all, it's a very simple system. I'm going to have to wait for my Nexus One (I think I'm ordering it in a couple of days, as in Monday/Tuesday/Wednesday) to check and make sure my android side of the plan makes sense. I intend to hijack the "Share" intent, and throw a post request to the server. Once I confirm that makes sense, is doable, and exactly what the UX will be like, I'll start the android app.

Another entirely new platform I'm developing on.

Android to Cloud Push

2010-05-21T00:01:00.001-04:00

I was watching the Google I/O keynote today (sadly, on YouTube—I'm a terrible GIT, and don't have the money to fly across the country for the conference. No matter how badly I want to) and I saw Vic Gundotra demo the Cloud to Android push feature. And I thought "Hey, what a neat idea! You push a button, and share the page you're on with your phone." Reminded me of Avatar, whose viewscreens transfer content with a simple swipe action.

One thing I thought, though, was that a lot of the time, I'm reading feeds or Twitter on my phone, and I'd really like to read articles or links on my computer. But that would involve manually typing in the URL, searching, or finding the referrer again. So I figured that Android to Cloud push would be at least as useful as Cloud to Android.

So I'm going to write it.

I have a 2 hour car trip to Rochester tomorrow, to see my brother graduate from RIT. I want to fully write the Chrome extension (and possibly the App Engine application) that will handle the "Cloud" side of this during that trip—a 2 hour trip there, whatever time I find while in Rochester, and a 2 hour trip home.

Of course, in the spirit of "open" (a word tossed around quite a bit at I/O), I'll be releasing this project under the public domain when it's finished. When I get my Nexus One (a matter of days!) I'll be figuring out the best way to integrate the "Android" part of this, and will be licensing that under the public domain, as well.

I do have an interesting pricing scheme for the Android half of this, but we'll cross that road when we get there.

Think I can write the Chrome extension and App Engine app in a few hours, in a car, with my parents?

I think I can, if I can keep my laptop charged.

Story In Progress

2010-05-10T17:45:00.001-04:00

Hey everyone, my name is Paddy. As you may or may not know, I'm trying to get hired by Google as a software engineering intern (or more!). As I went over my to-do list for getting hired (I'll get to that in a minute), I realised that it would be quite a journey, a little project of its own right. And everyone knows, a journey didn't happen unless somebody documented it. So I'll be blogging here, almost as a journal, about my progress on my laundry list of things to do before I can be hired by Google.

Unfortunately, I have no set-in-stone laundry list of things to do that will assure me employment at my favourite company, the only company I would consider programming for for a living. What I do have, however, is a neat little list of things that I should do before applying, supplied to me by wonderful Google employees. At the moment, I'm not sure whether they wish to be named or not, and both assured me that this advice was coming from them, personally, and did not constitute any official Google advice or policy. But I do have a bit of a better idea about where to head, thanks to a current Google software engineer (we'll call him Bob, after the man that taught me Python) and a current Google recruiter (we'll call him Ted, after the conference).

The following are things I need to do before I apply to Google:

Learn C

"Python is a great language, but you need experience with more than just Python. You need to learn C. You need to know how memory is allocated, what a pointer is, how all that works. K&R's book is a great place to start."

Learn Java and C++

"I would also try to get a rudimentary familiarity with C++ and Java, OO languages that aren't as dynamic as Python. Pros and cons vs Python and C would be good. Most programming at Google is C++, Java, and Javascript. Python is a distant fourth."

Learn Data Structures and Algorithms

"Data structures and algorithms. (This is somewhat tough to learn on your own.) Big-O notation. This stuff is super important to getting a job. You can use a hashtable, but do you know the performance characteristics of all the operations? Can you implement a hashtable in C? How about a binary search tree? When would you use a linked list vs. a vector? Can you implement them? etc etc"

Gain Experience

"One way to learn a lot of this stuff is to find an open source project that you like and start hacking. You could fix Chrome bugs! For example. Or you could do a successful Summer of Code project."

Clearly, I have quite a project ahead of me. Fortunately, you're all joining my story after it has begun. This semester, I took a Java course in college (I had taken one in high school, but it was independent study, and I needed the refresher). I've also started as a contributor to the Spaz Project. After I've learned what I can there, I plan to reduce my hours (somewhat; I have no intention of abandoning the wonderful people at Spaz) and picking up hacking on a more... complicated and related project. Perhaps, as Bob suggested, I'll work on the Chromium project. I'll make that decision when I get there. I've also picked up K&R's "The C Programming Language", and intend to study it over the summer as a "summer school" of sorts.

So there you have it. My 4 step plan to getting my dream job. Now that you're up-to-speed with me (sort of; I'll have to give you some more background on my skillset, I'm sure, as time goes on), I'm going back to what I was doing: finishing finals week, getting in programming when I can, and trying to learn the skills I need. I'll keep you updated with my Google travails as they happen, and perhaps my fanboyism will let me work with my heroes.

I'm feeling lucky.

-- Paddy Foran