The sound only works with Harman speakers, but the NFC part should work as is. I got some NFC tags as swag from conferences. If you don't have them, try hotel key cards or luggage tags. Let me know if they work.
But to be honest, when Kelly invited me to be on the panel, I wasn't sure what I got myself into.
You see, I have seen many bad panels. The panelists showed up without any preparations, so instead of an insightful discussion, it was just a bunch of people spewing unorganized thoughts on stage.
Fortunately the panel last night was not like that. Far from it. The panel was very well put together, educational and entertaining all at once.
So, what makes a good panel? Contrary to popular belief, it's the moderator, not the panelists. True, the panelists are the ones talking most of the time, but the preparation before the event makes all the difference, and the moderator is in charge of that.
Kelly was a fantastic moderator. Here is what she did:
Invite panelists with various backgrounds
Send questions to the panelists ahead of time
Highlight the unique experience of a panelist by asking a question specific to one person
Contrast the different perspectives of all the panelists by having all the panelist answer the same question
There were 5 of us on the panel. Some are hackathon participants, others are judges. Some are developers, others are subject matter experts. We all received questions a week before the event, and were invited to add more. I was asked to define the different types of hackathons since I did that in my Ignite talk on hackathons at Google I/O, but everyone got to answer questions like "Why do you attend hackathons?"
A good moderator curates the content by assembling panelists with complementary skills, let them know what will be discussed ahead of time, and directs the flow of the conversation. The hackathon panel hits all these points, and it was a real pleasure to share my experience and learn from the other panelists at the same time.
Public speaking has led to my different adventures for me. I gave an Ignite talk on hackathons at Google I/O 2012, sharing the stage with my former boss Peter Norvig. He was mentoring at Adventures of the Mind two years ago, which expanded to include a hackathon this year. He introduced me to the organizers to help run the hackathon, and that was how I got to mentor almost 200 brilliant high school students last week.
Hackathon
Kick off
I ran the hackathon with Mayank Jain, who has been organizing hackathons for high school students under Pilot. The Adventures of the Mind edition followed the same format as Pilot. Students can choose whatever language and platform they want, and go through with team formation, workshops, coding and pitching in 24 hours. I was not sure if that would work, especially since most of the students had no coding experience, and we only had 10 hours. Mayank assured me that previous events went quite well, and students were able to achieve quite a bit in a short amount of time. So we kept the Pilot format.
We started the hackathon with workshops. Cheston from mashery led an HTML5 one, and I led an Android one. We emailed instructions ahead of time asking the students to set up Xcode for iOS, Android Studio for Android, or a text editor for html/javascript on that laptop, and go through some tutorials. But naturally some people did not get a chance to do it, others struggled with installation problems. Many people had Java problems on their Windows computers, but I wasn't able to help them since I don't have Windows, and was not familiar with the failure cases.
After a while I made a radical decision: I switched to App Inventor. I was going to teach App Inventor the week after Adventures of the Mind anyway, so I already had a lesson plan. That went much more smoothly since the setup was much simpler: no install, no drivers. With that, the students were ready to write their own apps.
During the day the mentors went around to help the students, but we did not have enough mentors: only 5 mentors, and almost 200 kids. A batch of mentors dropped out last minute, and it was very difficult to find replacement on such short notice, especially since the hackathon was on a Tuesday. As a result I was only able to help a few teams, and felt very bad about the other teams that I could not help.
Despite all the struggles, the students really wowed us during the presentation. Here is a sample of their apps:
#feedtheworld: a website to direct recycling money to charities
Mind Scan: barcode scanner to exchange contact information
TravelPilot: recommend an itinerary for any destination
Overall the hackathon was rather well. A lot of students came up with wonderful ideas, learned to code, and demoed their app. But some teams could not finish their app because of technical hurdles, not knowing if their idea would be complicated to implement, and lack of guidance in general. If I were to do this again I would make sure we have a lot more mentors.
Sessions
The hackathon was just one part of this week-long program. There was a lot of interesting sessions. Here are some highlights:
Danny Oppenheimer on perception
Jini Kim on fixing healthcare.gov
Jennifer Shahade playing chess against 15 students at the same time
Nancy Segal and her twin research
Outings
We also got to visit quite a few interesting places in Los Angeles:
Autry Museum
LA Zoo
Gamble House. I love all the different wood texture.
It was really cool to hang out with all these smart kids, visit interesting places, and also get to know the other mentors. Come to think of it, this is actually my very first summer camp! I made many new friends, just like the students :)
Can you believe it's July already? I started the year with a resolution to be a public speaker, with the specific goal of giving 5 lightning talks and 3 full-length lectures. Let's see the mid-year score card!
Looks like I'm coming short on the lightning talk side, which is quite surprising. I thought it would be more difficult to get accepted to give lectures. Also interesting that all my lightning talks were in Ignite talks, which is way more challenging than the speak-at-a-meetup quick talks I had in mind when I came up with the goals.
Ignite at Google I/O
Ignite talks are challenging because it follows a very specific format: 5 minutes, 20 slides, auto advancing. The auto-advancing slides is the trickiest bit, since you don't control the rhythm any more. I rehearse way more for Ignite than my full-length lectures, because I need to internalize the timing to sync my speech to my slides. It's almost like lip-syncing!
The first time I gave an Ignite talk was at Where 2012, to a crowd of 30 people or so. I was rather scared of the auto-advancing slides, but I found that I just need to wait until the next slide to appear before transitioning to a new topic.
Ironically, because I felt I did pretty well at my first Ignite, I was more nervous when preparing for my second one. I kept thinking that it was not quite as good. I mentioned that to my friend Julia, and did a practice run with her. She loved it! I notice that I really feed off the energy from the audience, even if only one person was listening. So the practice run was all I need to get back my confidence.
Ah, confidence is such a fragile thing. I walked into the room, and wow, it's big! It probably seats a thousand people. A thousand people! Plus the event was live streamed. I never spoke to such a large crowd, and I was so ridiculously nervous while waiting for the show to start. Fortunately once I got on stage I was back to my elements.
Here is the recording of the Ignite show at Google I/O. Let me know what you think!
Once again I'm participating in a hackathon.
This time it's BeMyApp Mobile App Olympics.
I have always wanted to build something with server push technology,
so I thought it will be great to do it at a hackathon.
Friday
I signed up as a Developer without thinking, since that's who I am.
But when I arrived on Friday night, I was told that I could not work on my idea,
because I did not sign up as an Idea Generator.
I was so disappointed that I told myself I would just go home after listening to the other pitches.
Around 30 people came up and pitched their app idea.
Afterwards, the Developers and Designers vote for their favorites by giving the Idea Generator their poker chips.
The top 5 ideas would be developed during the hackathon.
One of the finalists was my friend Judy,
who proposed a music learning app for the iPad.
I actually liked the idea quite a bit, so I asked Judy if I could join her team,
even if I had no iOS programming experience.
She enthusiastically said, "Of course!"
Saturday
We came back Saturday morning, ready to build our app.
First thing first: name and logo.
The working name was PlayPitch, and we liked it.
"P" is a nice letter since we could make it look like a note.
We also came up with a mascot: the lion conductor.
He was christened "Gustav Mauler".
There were quite a few developers, and we quickly divided into sub-teams:
Elvin and I on the frontend music sheet rendering,
Peterson and Bosco on the backend pitch detection.
Peterson has written an iOS app before,
but the rest of us never wrote any iOS code.
We all learned it on the job, and were making rapid progress.
By the end of Saturday night we had basic pitch detection going,
and the UI reacted to good and bad notes as mocked with buttons.
We gave a quick demo to show everyone our progress:
Sunday morning we linked up the pitch detection with notes rendering, and it was beautiful.
We continued to refine the pitch detection, improve the UI, and work on the final presentation.
By 5pm we had a very nice demo going:
Final presentation started at 7pm. We gave a live demo with the pan flute and the keyboard, and the audience loved it.
One of the judges, Ben Parr, got so excited that he came up to try the keyboard.
The technology is super cool, but we also have an awesome business model to go with it.
BeMyApp paired each team up with a mentor,
and ours, Ivan Dwyer,
works with Alfred Music Publishing to bring sheet music to the iPad.
They already have an app that displays sheet music as PDF,
and would be the perfect partner for PlayPitch.
PlayPitch would be a freemium app.
The base app is free, with a few free songs.
Users can buy more music with in-app purchase.
Sounds familiar? Monkey Write is freemium as well.
In fact there are a lot of parallels between PlayPitch and Monkey Write:
PlayPitch
Monkey Write
Teaches music reading
Teaches Chinese writing
Grades you on each note
Grades you on each stroke
Wrong note makes lion unhappy
Wrong stroke makes monkey unhappy
Revenue by song purchase
Revenue by workbook purchase
After all four teams presented, the judges deliberated for a long while, and finally announced the winner.
And... we won!
We would be competing against winners from BeMyApp
Dallas, New York, Berlin, London and Paris. Please vote for us!
I have always been intrigued by the idea of programming for good, and tried many times to contribute to open source projects. Finally I got my acts together and attended Random Hacks of Kindness this weekend.
As my newbie, my goal was simple: observe how a charity hackathon is run, contribute whatever I can. Random Hacks of Kindess maintains a list of project proposals at the website, and we could use that as a starting point. However, the site was down during the day. Fortunately some people came with project ideas, and we heard 6 people explain their projects. We then split into groups, essentially interviewing the different projects to figure out which one was want to spend time on.
I ended up working on the project proposed by Sarah Filley, Drop2Drink. Apparently San Francisco uses potable water for fire fighting, so to ensure that there is enough drinking water during an emergency, the City of San Francisco has designated 67 Emergency Drinking Water Fire Hydrants, marked with a blue water drop. Sarah would like to use them as anchors to spread awareness for diaster preparation.
We gathered around and brainstormed. Since the group was quite large, it took a while to hear everybody. While all the talking was happening, Christiaan was typing furiously. He was grabbing the address of the hydrants from a PDF and populating a Fusion Table with it. By the time we wrote all our ideas on the white board, he had a Google Map showing all the hydrants! Awesome. Initially I was a bit worried since there was a lot more talking than doing, but seeing the map made me feel much better.
Lunch came and went, and we split into a few subteams: website, foursquare, tropo and QR code. I was in charge of the dynamic part of the website, generating one page per hydrant. Finally I got to code! I set up an appengine instance, fetched the data from Fusion Table, and populate each page with a row. This serves as the landing page when people click on a map marker, or scan the QR code we were putting on the hydrants themselves.
It didn't take me that much time to set up the base site, but the iterations were a bit slow, mostly because I had a sore throat and I couldn't talk. That turned out to be a huge problem. Since I was there to help with a problem defined by others, communication was really important. I would say the split is 80/20 - 80% talking, 20% coding. And since I couldn't talk, I couldn't contribute as much as I'd like to. By the end of Saturday I actually lost my voice, so I stayed home on Sunday to rest. I really wished I didn't have a sore throat!
All told I had a great experience, and I would probably attend more charity hackathons, knowing that the most important aspect is co-ordination. In a way it's leadership bootcamp: you meet tons of new people, try to figure each person's skill and passion, and align everything to the project goal. It's an interesting challenge.
I met a bunch of Android developers at the AT&T Mobile Hackathon SF, who told me about the App Dev Hackathon at Santa Clara today. Since I had such a great experience at the AT&T one, I decided to attend.
Sponsors and Prizes
Same as last time, there was a list of sponsors and prizes:
Tropo: Amazon Kindle for all members of a winning team that uses the Tropo API in their application.
Pioneer: $1000 cash for the best mobile app using the Zypr API.
appMobi: Amazon gift cards to the most interesting apps using appMobi's SDK. $150 for 3rd place, $350 for 2nd place, $500 for 1st place.
immersion: 5 $100 gift cards awarded to the team that makes the best use of the appMobi plugin.
Rovi: Two $500 Amex gift cards for best apps using Rovi APIs.
Sierra Trading Post: Use the Sierra Trading Post API. $1000 cash + 5x$100 Sierra Trading Post gift cards for best app, $250 cash + 5x$50 Sierra Trading Post gift cards for most creativ app.
Crittercism: Use Crittercism SDK. Top prize: Kindle Fire. Runner up: Automatic Nerf Gun.
HTC: Best app with the pen api wins the AT&T Jetstream tablet.
Guess I got lucky, since I have two existing apps that play very well with two of these APIs.
Dr Mila
A few months ago I went to SuperHappDevHouse and wrote an email gateway to Freebase. The idea was that when I travel, I often need to look up something when I don't have internet: an artist from the magazine on the plane, a signpost on the road to a tourist spot, etc. I wanted a way to queue up my queries to run when I got to a wifi spot, and it occurred to me that my email outbox is the perfect solution. All I need is a server that can read email, search the internet, and reply with the results. The email client will take care of the queuing, fetching, and offline storage. So I coded that up in an afternoon, and named it Dr Mila, with Mila being an anagram of mail.
The email gateway works this way: you send an email to ask@drmila.com with your query as the subject line, and Dr Mila replies with information from Freebase, sending images as attachments. I wanted to use Tropo to add an SMS gateway to the service.
At the presentation Tropo mentioned that if all I needed was SMS, I should use some other service instead. I didn't catch the name, so I went to their table right away. The "other service" is Smsified, also provided by Voxeo, the parent company of Tropo.
I managed to receive SMS pretty easily, but sending didn't work. Back to the table, and Adam from Tropo debugged it with me, using curl. And it didn't work because I did not provide any authentication. I was wondering about that when I was following the instructions from the message sending documentation. Turns out authentication was covered in Overview, but of course I jumped right into the section that interested me, and missed it. Not a big deal, it was very easy to fix once I knew what I needed to do.
In my first test I just sent the whole article from freebase, and got maybe 12 SMS as a result, because it exceeded the 140 character limit. As a quick workaround I took the first sentence from the description. Most articles have the first sentence as the summary, so that worked pretty well.
Movie Jot
I finished adding SMS to Dr Mila around 1:30pm, so I decided to work on my second app, Movie Jot. The idea is that I want to take advantage of html5 offline storage to quickly record something, and look it up on the internet later. The keen reader will notice that both Movie Jot and Dr Mila share the same offline theme, which is not a co-incidence. I am rather frustrated that most apps assume that my device is always connected to the internet. I decided to target specifically for movies since my friends often mention interesting movies at dinner, and I just want to quickly jot that down instead of spend 3 minutes looking it up on the internet right away.
I had a working version of Movie Jot, powered once again by Freebase. Since rovi has a nice DVD database, I thought I would change the backend to point to it instead.
As I was loading up the rovi documentation, someone tapped on my shoulder. He saw my screen, and wanted to introduce himself since he was from rovi. I took the opportunity to tell him what I wanted to do, and he gave me a quick rundown of generating md5 signatures for the API, and how to fetch images and synopsis. That saved me quite some documentation searching time. I put everything together, and was rather pleased to see that the synopsis quality from rovi was quite a bit higher than freebase.
Sierra Shake
I was done with Movie Jot at around 4pm, and took a break to talk to people around the hall. We had until 6:30pm to enter our apps for demo, and since I heard so much about quick development on appMobi, I decided to give it a shot. I tried to get the XDK, but made the mistake of clicking "Deny" when it wanted to access my hard disk. I went to the appMobi table and they helped me by running javaws -viewer and deleting the appMobi entry so I could restart.
Once I had the XDK up and running, I just stared at it, looking for a place to type my code. Finally realized that the XDK was like the browser, and you use a separate editor to write the html and javascript. Once I realized that I was able to code up my app pretty quickly. Since I didn't have a lot of time, all I did was use the Sierra Trading Post API to display a random product when you shake the phone. Actually I didn't even have time to implement the shake detection, so I just hooked a click event on an empty area to trigger the fetch.
Even though I wrote a rather silly app, I got a chance to see the whole appMobi tool chain, which was quite interesting. It was a Chrome extension that uses Java to access your local file. To test on the device, you download an Android app called applab, and use the mobile browser to authenticate and load the app you want to test. Pretty neat.
Demos
The organizers did not set up a projector for demoing on the device, so it was a little bit tricky. I used the Google Voice interface to show the SMS messages for Dr Mila, and passed my phone around for the judges to test. One of them entered "tears" as the query, and Dr Mila replied with "Tears are the secretions of the glands that clean and lubricate the eyes." Not bad. Movie Jot is an html5 app, so I just demoed it on Chrome on my laptop. For Sierra Shake, I used the XDK, which sufficed.
Prizes
Turns out Movie Jot was the only app using rovi, so I won the prize. It wasn't really a competition when there were no competitors, but hey, I am not complaining. I also won a iPod nano from Tropo, which I didn't even know was on the prize list. Again, not complaining at all.
The only complaint I have for the event was that the tables were way too high for a small person like me. Maybe I should bring a cushion next time. But that's going a bit overboard, no? I already brought a salad for dinner since last time I was starving at the SF hackathon. At this rate I would be lugging along my whole house!
I have not been doing Android development for a while, and decided to get my feet wet again by signing up for my very first hackathon. Most hackathons last until the wee hours of the night, so I was rather excited to find one that was scheduled for 10am to 8:30pm, when I am normally awake. It was the AT&T Mobile Hackathon in San Francisco on October 22, 2011.
Preparation
Since it was a mobile hackathon, I knew I was going to be coding either in Android or html5. Last time I did any Android development was more than a year ago though, so I downloaded the latest SDK and updated my Eclipse setup. I then read through the email from the organizers to see if there were any rules. I didn't see any, because the email mostly consisted of the list of hot sponsored prizes:
Tons and tons of Apple Gift Certificates for the top 3 teams, provided by AT&T and Apigee
Top hackathon team (yes, the entire team) will receive AT&T Mobile Hotspot Elevate devices (wifi pucks) with 1 month of free service courtesy of Sierra Wireless
Amazon certificates for Best App Built with the YP API
The top two apps built with the HTC OpenSense SDK's Pen API will get two exclusive new AT&T Jetstream tablets
Top two apps which leverage the Galaxy S2's GPU the best (can be GPU tweeks for exisiting games) - Two (2) Galaxy S2 - Sponsored by ARM
Top app built with ARM NEON instruction API - ODROID - Sponsored by ARM
The sponsored prizes really reminded me of Iron Chef. The secret ingredient was the API, and the dish was the app. Of course you can also just write any mobile app without using the sponsor APIs, but I thought it was much more fun to compete with a common ingredient. Though I wasn't sure how anyone was going to build an app with the ARM NEON instruction API just like that...
Tables and Talks
I took the Caltrain up, and arrived quite a bit earlier than 10am. They were still setting up the breakfast area and the sponsor tables when I got there. Since I ate already, I went to check out the different sponsors. The HTC table really caught my eyes with their gadget - the new JetStream tablet. Michael from HTC carefully unwrapped one from his towel (!) and showed me the cool apps using the pen. I was hooked, and decided then and there that I my secret ingredient would be the pen api.
As more participants showed up, we were ushered into a big conference room, where the organizers explained the schedule for the day. Each sponsor then gave a quick overview of their api, before we broke for lunch.
Environment setup
With a plate of Mediterranean food in my hand, I looked around for a nice table to set up shop, and stumbled upon a conference room with a few other developers who were already looking at the HTC pen api. Perfect.
First order of business: get an emulator running with the pen api enabled. The HTC dev site has instructions with screenshots, but unfortunately the Ice Cream Sandwich UI was rather different, so it took me a while to figure out how to give it my downloaded zip files. Even more unfortunate, I could not create an AVD even after importing the HTC add-ons! I asked David from HTC for help, and he had the exact same problem. Perry, a fellow hackathon participant, got an AVD created before he upgraded to Ice Cream Sandwich, so David and I decided to blame Ice Cream Sandwich.
Assigning blame made me feel better, but did not actually address the problem. I was going to beg David to let me develop directly on the device, but then I got this brilliant idea - I could just copy the AVD from Perry! Armed with a USB thumb drive, I obtained the precious AVD files, and voila! Emulator up and running.
Next task: try out the demo projects that came with the pen api add-on. This was when hacking with others really helped, since someone in the room already tried running the demo projects, and found out that only the compatibility demo worked. That saved me the trouble of running into dead ends.
The idea
Finally I was ready to hack out my app. With the pen api as my secret ingredient, I thought it would be natural to use it to write. Not just write anything, but write Chinese, since I still don't type Chinese very fast. But then I realized that not everyone knows Chinese, so hey, I could build an app to teach people to write Chinese! The idea was simple enough for a day's work - load a Chinese character in the background, use the pen to trace it, and when you are done, hide the character so you could see what you actually wrote.
Technical hurdles
The compatibility demo has code for converting onTouchEvent into lines on a SurfaceView, so my little app was already capturing the pen strokes and drawing them on the screen. I thought I would just wrap the SurfaceView with FrameLayout and stick in a view underneath to display the Chinese character. Alas, not so simple, since you cannot put anything beneath a SurfaceView. I brought my problem to Leigh from HTC, and she casually commented, "couldn't you just draw the background directly on the SurfaceView?" And I said, "you're right!", and rushed back to code some more.
At this point the inevitable happened: the wifi stopped working. With so many contests accessing the net at the same time, I was not surprised. My app did not actually need the internet, but to code it, I need access to Android documentation. I wished I downloaded the documentation when I was at home! Oh well. Stephan, who was sitting to my right, just calmly pulled out his tether device and moved on. Now that's what I call prepared! Fortunately we were sitting in a conference room, and I noticed ethernet cables coming out of the phones in the middle of the table. I grabbed one, plugged it in, and phew, it was connected. Back to business again.
The rest of the app was relatively straight-forward. Initially I used drawText for the background Chinese character, but the default font was really ugly. I didn't have time to figure out how to include a prettier font, so I took a shortcut and just displayed an image of a beautiful Chinese character.
Polishing
By now it was 6pm, and I had a working demo. But it didn't really use the pen api. Yes, you could use the pen to trace the character, but you could also use your finger. We need to submit our app by 7pm, so I didn't have a lot of time. I decided to use the pressure from the pen to vary the stroke width, and started pouring over the HTC documentation. Not sure if I was stressed or what, but for the life of me I just couldn't find the function to get the pressure. I asked David from HTC for help. He couldn't find the function in the documentation either, but had some unpublished sample code, so once again I whipped out my USB thumb drive and got some precious files. The function turned out to be dead simple: it was just event.getPressure() from the MotionEvent. I added that to my app, and spent the rest of the time tweaking the numbers to make the strokes look alright.
Show time
At 7:30pm we all went back to the big conference room for demos. I was the second in line to present, and gave a pretty short demo. But people seemed to like it!
There were a lot of interesting apps, and I was rather impressed by the work everyone managed to do in a day. It took an hour for everyone to demo, and then the judges got together to vote. Afterwards, it was the announcements. They first announced the overall winners. I was very pleasantly surprised when they called out "Calligraphy" for first prize! They tagged on to say that I was also one of the two winners for the pen api category. Double happiness!
Winners of the pen api contest. Bruce from HTC brought giant zucchinis as prizes!
During the day someone from Microsoft developer relations was going around asking people to fill out a survey. They would raffle out two people to win an XBox 360 with Kinect, and they announced the results at the end. As luck would have it, I was one of the winners! Beginner's luck, I suppose?
The organizers and sponsors were quite generous, and gave out a lot of prizes. More at the AT&T Developer Program Blog.
Parting thoughts
I had so much fun at my first hackathon. Working side by side other developers was really nice, and have direct help from the API publishers made the process much smoother. If are were sitting on the fence, I definitely recommend going to one.
Here are a few things I learned:
Assume that the internet will stop working at some point, and download the SDK/documentation beforehand.
Sit with people working on similar projects. The cross pollination is amazing.
Don't be shy to ask for help. People are super friendly, and you don't really have a lot of time to repeat mistakes anyway.
A big hand for the organizers and sponsors! Thank you for this very fun event. I especially enjoyed working with the HTC team.
