Connecting a Wii nunchuck to Arduino

After getting started with the Arduino Uno, in order to get 3-D accelerometer data from the Wii nunchuck and onto the Arduino, you will need the following:

• a Wii nunchuck: there are some generic non-Nintendo brand nunchucks available for sale for around $6-7 (like this one) but the reviews on those seemed a bit mixed on their longevity. The official one by Nintendo goes for about $18 on Amazon currently, so I ended up buying a used Nintendo brand nunchuck off eBay to try to get the benefits of both.
• Nunchucky breakout adapter ($3, adafruit) though there are other kinds of nunchuck adapters as well. This is so that you don't have to cut up into the wires of the nunchuck and can just have something to plug it into instead.

The Solarbotics Nunchucky breakout board adapter comes from adafruit in two pieces, like so:



That piece on the right, mine actually came with 6 pins instead of just 4, but you can just snap off 2 of them. GND = ground and 3.3V = power source, while Data = the data coming in off the nunchuck and CLK = a clock for the serial connection. The nunchuck has standard I2C interface, which allows you to read input from the accelerometer inside (x/y/z force), the two buttons, and the joystick (2 axis). Basically even though you hold it in your hand as one device, the nunchuck is actually all these different devices bundled together into one, and the serial connection allows you to read and distinguish the input from different parts of the nunchuck.

Anyway, the pins need to be soldered to the board so that it ends up looking like this:



My Hackbright instructor Christian brought his soldering iron to do this with some lead-free solder that I just bought for $5 at Radioshack. The soldered part lets you plug the 4 pins into the Arduino board with some stability and conductivity for the data to pass through, from A2 to A5 of the Analog pins:



The Wii nunchuck plugs in to the adapter at the bit with the gold bars. The nunchuck's plug comes with  bits on the sides that you can squeeze to release the locking mechanism for plugging/unplugging it:



VERY IMPORTANT NOTE: plug in the nunchuck with the Nintendo logo facing up! There's a plastic bit on the bottom. The adapter will fit in the nunchuck just fine upside down, but this won't match up with the Arduino code because the pins would be all backwards then. I lost a whole afternoon to this, don't repeat my mistake!

From here, you can get the nunchuck library written by Tod E. Kurt. Of the files in the Github repository, you really only need the ones in the WiichuckDemo folder. WiichuckDemo.ino is the file with the example code that you'd want to focus on, while nunchuck_funcs.h is the library of functions you can call from your .ino file to get data off the nunchuck, like whether a particular button has been pressed down.

When you run these files from the Arduino IDE with your nunchuck all plugged in to the Arduino and the Arduino plugged into your computer, this is what you should end up seeing:



Watching that data come in as you wave the nunchuck around is seriously magical! Tod E. Kurt has some extra info in these slides (PDF file) he used for a class (the relevant slides start about halfway through) but what's in this post should be enough to get you set up. The x, y, and z acceleration data should report values from 1-255 with these directions:



Even when you just leave the nunchuck sitting on the table, it will show some values because it's reporting acceleration, not absolute position in space, so even while in a still position, there will be the downward force of gravity acting on it.

For my project, I basically modified the example Wiichuck code so that it would collect data while you held down the big z-button and stop once you let it go. Pressing down the z-button prints out "start", then while you keep that button pressed down, it collects the xyz acceleration vectors, until you let it go, when it prints out "stop". I also added in a timer library to more reliably initiate collecting data every millisecond (Tod Kurt uses a counter variable in the Arduino's loop), though in practice this actually gives readings about every 100ms due to the nunchuck having a sampling rate of about 100Hz.

How I came up with my Hackbright project idea, Open Sesame

The first half of Hackbright is devoted to working through exercises, from building calculators to a movie rating app, but the second half is for building our own personal projects. The Hackbright application asked for our ideas on what we might build for this personal project and I think most of us had mobile apps in mind originally, but we were warned off from that a bit since that would introduce a lot of extra complexity in just setting up.

After that, I was flailing around a bit for a project idea; I had a bunch of different ideas floating around, like a soil moisture monitoring app (for checking up on my plants in the care of my husband back on the east coast while I was at Hackbright in San Francisco), but wasn't super excited about any one idea. I told Christian that I wanted to do something with an Arduino or Raspberry Pi because I'd never worked with electronics at all before and one of things that had put me off computer science originally in high school is that I thought you had to be one of those people who could built computers from scratch.

That isn't true these days, but it seemed like it would be a very useful skill to pick up for projects with real-world physical usefulness (like this Raspberry Pi-powered cat feeder! I should build this for my parents, saddled with my cat that I can sadly never have at my own home due to my husband being allergic to cats). I am a very pragmatic person and while I very much enjoy pretty things (Pinterest, design/fashion blogs, etc.), I like cooking because I like eating, I like knitting/sewing for the creations that you end up with at the end, etc.--so for me, it's less about the process than about the end result being useful in some way.

I also told Christian that when it came to programming, the bit that I liked best was breaking down a problem to figuring out the solution, and he intuited that once I had proof-of-concept that it would work, I wasn't much interested in implementing the extra stuff, so I wasn't going to be too interested in something that was very front end heavy and require a lot of wrangling with HTML/CSS and such.

Given all that, he gave me this paper published in 2009 by from computer scientists at Rice University called uWave: Accelerometer-based personalized gesture recognition and its applications. It was a bit tough to read through at first but I got to the section on practical applications for it on the same day that a Hackbright classmate gave a talk on 2-factor authentication and a light bulb went off that what the paper was talking about, 3-D motion-based passwords, would save me from the pain of 2-factor authentication!

We have to use 2-factor authentication at work and I've gotten stuck a number of times because I left my phone or forgot the device that gives that 2nd factor. Motion-based password would be something that's pretty easy for you to remember, but pretty hard for someone else to replicate exactly even if they had watched you do it because your hand movements will vary enough that the authentication system should reject them.

So in summary, I wanted a project that had:

• hardware
• a clear real-world use
• more backend than frontend

...and I ended up making a 3-D password system! Pretty cool, huh? I decided to call it "Open Sesame" since that would make it obvious that it's related to passwords, though a couple others suggested calling it Alohomora as a Harry Potter reference--I will have to come up with a Harry Potter-themed name for my next project.

Anyway, I'll be writing a series of tutorials on how I did the project in the hopes that it will be helpful for future Hackbright students or other beginners to electronics projects.

On being scared and excited at the same time

I'm not a particularly ambitious person by nature, really. I think a big part of happiness is being content and grateful for what you have, particularly the little things, hence my "Things That Were Good Today" daily gratitude blog. I'm not particularly revved up by calls to change the world; thinking about that just makes me feel a bit tired. A great weekend is often one where I didn't have to change out of my pajamas or leave the apartment at all.

This was pretty frustrating for my mom. When I was growing up, she would frequently ask me, "why don't you want to be the best at whatever you're doing?" and I think it just flabbergasted her that I mostly really didn't care. As a result, sometimes it's hard for me to be an environment where it seems like everyone is always pushing to reach for the next thing just to get to the next level; it makes me wonder if there's something wrong with me when I'm content with what I've got.

What saves me from total complacency is 1, I get bored when I'm not learning anything new and 2, I do want to do things well and to always be improving. It took me awhile to convince my husband that when I asked him his opinion on something I'd cooked, it wasn't a trap, I really did want feedback on how I could make it better next time. These tend to be incremental improvements though, not tackling something big and new and foreign.

For those, this post written by someone who took on skateboarding from Sydney to Wollongong showed up on Hacker News a few weeks ago and though I have never been interested in skateboarding, it actually struck quite a chord with me:

If it excites you and scares the crap out of you at the same time, it probably means you should do it.

If you want to get somewhere in life, no one is going to do the pushing for you. You have to push yourself. 

For me, these two points are totally, totally true. After a childhood of mostly being pushed by my parents, it's taken me awhile to figure out how to push myself towards goals I set for myself. I still need a nudge now and then, but when I think back on the two most significant career moves I've made, I definitely was both terrified and thrilled at the same time. When I moved from the support team to a product specialist role, I was scared of the responsibility it would bring and the impact if I made mistakes, but at the same time, it seemed like it could be a ton of fun to actually have some influence over product decisions. When I decided to apply for Hackbright, it involved not just leaving my job for 2.5 months but also living away from my husband, yet I couldn't stop thinking about the opportunity.

If you had an identity as a smart kid while growing up, there's evidently this whole praise paradox where such kids are more risk-averse and less confident than kids that are praised for working hard instead of being smart. I think this is where the fear comes from, since it's a fear that you won't be good at whatever the new thing is and you'll have risked losing your reputation as a smart person for nothing. This is different than being afraid of doing something really drastic like quitting your job without any kind of backup plan, since this fear shows up even for things that have defined time limits, like Hackbright.

You can tell the difference because it's paired with that nervous excitement, when you find yourself turning it over and over it your head. You don't have to ever toss reason and planning entirely out the window or anything like that, just: pay attention to your intuition. If you feel both scared and excited, you should listen to it.

Workaround for PayPal's preference for direct bank transfers

I had a very frustrating experience the other day while using PayPal to purchase an item from Woot; I wanted to put the transaction on a credit card to count towards a minimum spending bonus I'm working on. More and more, it seems that PayPal is intentionally designing their systems to pretty much trick you into paying for transactions using a direct bank transfer by obscuring how you can change the payment method. I understand why they do this, to minimize revenue lost to credit card processing fees, but it's very much not focused on the users of their product. A brief search for ways to stop this shows other people that are very frustrated with PayPal's strategy here as well, so I thought I'd share an idea I had for minimizing the impact to you as the PayPal user.

You more or less have to have some bank account that's directly linked to your PayPal account and set as the default, and then you can choose a backup source of funding if that bank account doesn't have enough funds for your purchase. I have existing accounts with ING/Capital One 360 and they make it pretty easy to open multiple accounts so that you can do things like have targeted savings accounts that don't have fees. So, I opened a new savings account and transferred just $1 into it. I confirmed with the bank that overdrawing on a savings account wouldn't cause a fee from them:



So, my thought is that if I accidentally didn't change the payment method when paying for a purchase with PayPal, it will always go over to the backup funding source since the linked bank account only has a $1 in it.

DISCLAIMER: I HAVE NOT ACTUALLY TESTED THIS YET, YOUR MILEAGE MAY VARY! (aka I can't guarantee that this actually works, but I'll update this post if I ever end up testing it and can confirm its effectiveness one way or the other.)

she++ conference at Stanford

On Saturday, I attended the second annual she++ conference at Stanford, a conference on women in technology for Stanford/high school students and Bay Area technologists that is organized by Stanford students.

The conference was free for high school and college students and $20 for general admission, which I thought was well worth it. The day started with some opening remarks from the student directors of the she++ and an opening address from Mike Schroepfer, the CTO of Facebook. This was followed by an excellent panel of female tech entrepreneurs, including Sandy Jen of Meebo (acquired last year by Google) and Debbie Sterling of GoldieBlox. I've been reading a bit about start-ups recently and that whole world seems a bit like an impenetrable alien planet to me but impossible to avoid while out here in San Francisco; I've heard that NYC and Boston, both cities I'm more familiar with, have quite a tech start-up scene as well but it wasn't until I've been out here for awhile that I started to realize that Silicon Valley is really a thing.

After the panel, they screened the she++ documentary, which was about 15 minutes long:


It's very well-produced and a nice, quick summary of the whole gender imbalance in tech thing, so I think I will try to get my high school to do a screening of it after I give a talk at their alumni day in a couple weeks (my talk is shaping up to be a bit like trying to get the students the join the cult of getting in tech...).

After the screening, we transitioned to the workshop portion of the day. I had been given the opportunity to sign up for a workshop ahead of time as an early ticket holder, though I didn't realize that there would only be one workshop session and not a whole afternoon of rotating amongst multiple sessions. Fortunately, I got my top choice, the puzzles and brainteasers workshop co-led by Keith Schwarz, a CS professor at Stanford, and Sophia, a CS major.

The setup for the workshop was quite interesting, they talked through some general principles of puzzle-solving a little bit first (connect the game to a different game you know how to solve, force opponents' decisions, try out smaller examples, draw pictures) and then gave us packets of two-player games for us to pair up with other attendees on to talk through collaboratively on what a winning strategy would be. I had a lot of fun with this and the time flew by. When they gathered us up at the end and started to talk through the answers, I stepped aside when they got to talking about the ones my partner and I hadn't gotten to solving yet so that I could keep working on them later. Afterwards, I got to talking to Keith a bit about Hackbright and coming to CS only recently and he was super nice and supportive about it. He reminded me quite a bit of one of my favorite professors at Boston College, an intro physics instructor who was really engaging.

Lunch was intended to be a mentoring lunch but the table I had chosen (with Sandy Jen) was already full somehow by the time I got there, so I ended up at another table with a few engineers from Box, LinkedIn, and Square. What was really cool was that when I told them I was from Hackbright, they had already heard about it! We had some interesting discussion as well about the challenges of the Groupon business since the engineer from Square had done his own start-up in that same space.

The final two events of the day were a student panel of female CS majors from Stanford and a discussion/Q&A between Ruchi Sanghvi and Marc Andreessen. I had considered skipping the student panel because I thought it wouldn't be too relevant for me, given that I will never be a CS major at Stanford, unlike the high school students or other Stanford students in the audience, nor am I entrusted with changing a workplace to better attract female CS grads. But it's not like I really had anywhere better to go and I figured I might as well check it out since it was evidently a huge hit last year and I might learn something from the questions that industry people asked of the students. The student panelists were all extremely well-spoken and self-possessed, so mainly I was left feeling envious of them, though of course I wish them well regardless.

The Q&A with Marc Andreessen was pretty great, though. He repeated what many of the entrepreneurs at the career panel had discussed, which was essentially that you should not start a company unless it's something that you can't stop thinking about and can't make yourself do anything else. Kelley asked him for his opinion on alternative methods of breaking into the tech industry like Hackbright and he had a very thoughtful answer, which was that it's unclear how much college is necessary for it anyway since people can get started in CS many years before they even go to college, so the greater challenge is how to get people to that level of 10,000 hours of practice to reach expertise. Also, he said that nothing truly innovative can be built during the short timeframe of hackathons, so I felt a bit validated that perhaps the main benefit that hackathons can offer is bringing people together who might not meet otherwise.

Finally, the two conference co-chairs closed of the day with an adorable "wrapping up rap" to further contribute towards breaking stereotypes.

Key takeaways:

• Only start a company for an idea you can't stop thinking about. Startups all go through the same traumatic experiences of just being told no all the time, so it's an irrational act that people do because they can't help themselves. 
• Innovation is hard to recognize when it's happening (see this essay on "Why There Aren't More Googles" from Paul Graham that has the Howard Aiken quote "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats").
• Share ideas, don’t hoard them--if you’ve thought of it, someone else is probably already doing it.
• Practice rapid prototyping, get started with the cheapest materials available to you and then go out to get feedback on your idea (Debbie Sterling did extensive research with the young female children of her friends to see what they liked to play with).
• Sandy Jen's story getting inspired by her "stupid friends" that failed the same difficult theoretical tests that she did going out and succeeding at being entrepreneurs ("if they can do it, so can I").
• When pitching to VCs, you can draw confidence from being an expert in the product since you built it and therefore the pitch is just an opportunity to teach the VCs about it.
• Be the person that brings the tools, be the goose that lays the golden egg.
• Failure is a part of learning, you are not failure yourself because you’ve failed at something.
• Interviewing advice: always keep going, don’t ever give up even if you feel you can’t get from pseudocode to real code.

Feedback for the conference organizers:

• It seems that the conference is targeted at both industry people as well as high school and college students, which are fairly different audiences, plus additional groups like us Hackbright students. I think it would be vastly helpful to set expectations on which sessions are targeted at which audiences while still allowing for mixing of groups, just so people can decide whether they'll attend a session because they think they can benefit from it directly themselves or if they're attending as more of an observational exercise. In general, I'd like to see a clearer and more specific mission statement for the conference.
• For the student organizers that had prepared intros and such, they should practice their public speaking skills a bit more so that they don’t have to read off of a prepared text. It was obvious that they'd put a lot of time and energy into putting on this conference and it really was very well-done, which couldn't come about without enthusiasm behind it, but that gets a bit lost when you can tell that someone's reading off of a pre-written statement about how excited they are for whatever's coming up next.
• When doing intros, it would be more effective to keep the personal stories of why they decided to get involved in the conference fairly short to keep the focus more on whatever it is that they're introducing. It's interesting and touching to know where people are coming from, but be concise unless you've been specifically asked to talk about why you care about this issue, like the keynote speakers.

Getting started with Arduino

I got started on the hardware portion of my Hackbright final project (3-D gesture authentication using a Wii nunchuck and an Arduino board, aka motion-based passwords) today and want to log the tutorials that I found particularly helpful as a total electronics newbie.

One of the reasons I never really considered a career in software engineering was that I thought to be good at it, you had to be one of those people who had been building computers from spare parts in the garage since age 10. With the rise of web apps, this doesn't seem to be the case anymore, but I figured that while I was at Hackbright and had access to the excellent instructors here, I should push myself out of my comfort zone and learn something totally new. So, I come to this with some vague memories of circuits and electricity from physics classes in high school and college (I never took AP Physics and then I was a Biology major, so it was just the calculus-based Intro to Physic co-requisite course).

For the Arduino part, I decided on the $49.50 Budget Pack for Arduino (Arduino Uno R3) - Uno w/328 sold by Adafruit Industries so that I'd have a decent variety of extra parts (wires/LEDs etc.) to play around with a bit, particularly if I ended up wanting to try other projects down the line.


I have a Mac laptop that also has a VirtualBox to run Ubuntu (a particular "flavor" of the Linux operating system) using the Unity user interface, so I set both of them up to be able work on the Arduino following the steps in Lesson 0 on Learn Arduino.

The VirtualBox was a bit finicky about recognizing the plugged Arduino from the USB port, so I followed these steps to get that working (with a quick detour to this post in order to get the user group permissions bit working). And even then, I would sometimes get this "programmer is not responding" error. Following these recommendations to hit the reset button would sometimes work, but not always, so I mostly gave up on working on the Arduino from within the VirtualBox.

I then followed it through to Lesson 2 and got the LED working (if you want to modify the code in the blink tutorial, the reference for syntax you should use to program the Arduino sketches is here), but realized that I didn't actually understand how the breadboard worked.

For that, I found Adafruit's founder's site of Arduino tutorials and started over from there. The software setup was pretty much the same, but I did get an explanation for what the four black bumpy things that came in the same box as the board were: rubber bumper feet.

From this:

To this (back view):

Anyway, there was then a good explanation of the breadboard in Lesson 3 but I wanted to add a bit more explanation.

Basically, half-size breadboard that you get with the budget kit is composed of two sets of two different pieces: a "power rail" (the skinnier ones on the left and right sides that have the + and - signs and red/blue lines running vertically down) and a block of 30 sets of 5 row holes (not sure what the technical term for that is). The way these work is that the power rail, once connected, will provide power up and down all the rows, while the rows only have connectivity within their own numerical row. In the above photo, I outlined each different section in a bright blue box.

By convention, you connect the power (3.3V or 5V) in from the Arduino to the positive (red, +) side and then back out from a negative (blue, -) to the ground (GND) on the Arduino board. So, you could bring power in at the top left and out from the top right, or in from the bottom left and out from the top right, or from only in the middle, and you would still have access to that power all the way up and down the power rails.

The rows, on the other hand, are only connected to each horizontally. So 1A-1E are all connected, and if you connected 1A to power, something connected to 1C would be able to access that power as well. 2A-2E would be totally independent, as would all the rest of the rows, unless you deliberately connected something in row 1 to another row. These rows also don't go across the dip in the middle, so 1A-1E are separate from 1F-1J unless you connect them somewhere along the way.

Another thing to note while you're working your way through the LED tutorials is that when you have a directional element like the LED that has a positive end and a negative end (unlike resistors which don't have a particular direction), you connect it on the board positive-positive and negative-negative. So one configuration could be:

1. A wire from the 3.3V on the Arduino to a hole in the + column.
2. The positive end of the LED in another hole in that same + column.
3. The negative end of the LED in a hole in a - negative column (doesn't really matter which, but the LED probably can't stretch across the whole width of this particular board...if you had additional wires or a resistor in here though, there's nothing stopping you from using the whole width if you wanted to).
4. A wire from another hole in the - column to a GND on the Arduino.

One cool thing to do is supply the power pin 13 to hook it up to an LED on the breadboard while running the blink "sketch" (Arduino programs are called sketches, I guess), because then you'll get the LED on the breadboard to blink on and off as well and not just the tiny one on the Arduino board itself.

Ta da! I'll write a post as well about the exact steps to hook up the Arduino up to a Wii nunchuck because that caused quite a bit of brow furrowing for me today as well. It turned out to be not that complicated but I didn't find any super detailed descriptions or photos of what to do exactly, so I will put that up.

[edited 5/5/13] This post from the Make magazine blog is a new overview of the differences between the different microprocessors you can use for hardware projects: Arduino vs. Raspberry Pi vs. BeagleBone.

My First Hackathon: HackEd 2.0

Last Tuesday, I participated in HackEd 2.0, an education-themed hackathon put on by the Gates Foundation and hosted by Facebook at their offices in Menlo Park, CA. As I was telling my husband about it the next day, I realized that I had quite a few Opinions on the experience, enough that I decided to dust off ye old blog and use it for when I have Many Things to Say, more than can fit into 140 character tweets.

Background:
The purpose of this hackathon was to build apps in these categories: college-going, social learning, and out-of-school study. We had to form up our teams ahead of time and submit an application with this as our app idea:

Our app will allow teachers to increase student engagement with assigned books through an enriching, multimedia learning experience. Students have many different learning styles and interests, so curriculums should be flexible and adaptable. For example, teaching a unit on the book The Kite Runner could incorporate the history of Afghanistan for history-lovers, discussions on artistic expression (and repression) for art-lovers, and videos on kite fighting for sports-lovers. Our app will enable teachers to easily collect and share such materials with students and perhaps other teachers as well, fostering discussion and sharing of best practices.

We found out that we had been accepted as one of the 25 teams to participate about two weeks before the hackathon took place. Two other Hackbright teams were also accepted.

This was the first hackathon for most of us and we were all pretty much total newbies to programming just five weeks earlier at the start of Hackbright, so none of us really knew what we were getting ourselves into. We attempted to prepare for it by meeting a couple times to flesh out the details of what we wanted our app to do a bit more and go through the materials that the Gates Foundation had provided.

Day of:
The organizers made us feel really welcome and kept us well fed throughout the day, with a breakfast spread that included bagels and lox, a taco bar for lunch, and sushi for dinner, along with easy access to a microkitchen with an excellent spread of snacks and drinks. The hackathon was held in a giant room that had many different couch sections for teams to use as their home bases, and there were plenty of outlets to keep our laptops charged.

Sheryl Sandberg gave the keynote/opening speech that emphasized the dire straits that the U.S. education system is currently in, which was followed by a representative from the Gates Foundation going through some of the statistics comparing the rate at which kids from middle-high income families get into and graduate from college vs. kids from low-income backgrounds. The last talk was by someone on Facebook's developer relations team that went over the basics of how to get user data out of Facebook and some tools you could use to learn about their API. After that, they set us loose to hack away for the next 5 hours before we would have to get up in front of the whole room to do a 3 minute pitch of our idea and demo our app.

I then proceeded to spend the next three hours (60% of our allotted time!) to figure out how to do the following:

This is about 10 lines of code total. I modified the example Python-Facebook app from Heroku so that it would also request permission to access the Facebook user's Interests and then display those interests once the user had logged in.

Why did it take that long to do something that turned out to be fairly simple? Getting even just the example app to run took me awhile and then it was a repeated cycle of reading through Facebook's documentation for developers and poking at the example app to see which code changes had any effect. Turns out, it takes awhile to make any headway on learning someone's API. It was very satisfying when I got those two interests from my profile to finally show up on the app page, though, and I passed over those bits of code to my teammates and spent the remaining two hours working on our pitch.

The hackathon had two pitch coaches roaming around that you could grab and try to get advice from. It was pretty informal; going in, I had thought that there would be structured sessions that would teach you how to pitch effectively at a hackathon. I'm actually not quite sure if they were Facebook or Gates Foundation employees, but the one I talked to basically said that our idea was too broad and content-driven (rather than technology-driven) and had been attempted by many others before without much success. Once he gave me some examples of how we could've tried to tackle a smaller problem instead, I could see what he meant, but this was advice that would've been more helpful two weeks before rather than two hours before the pitch was due. He did give me some practical advice in that last year, many people had apps that they wanted to demo but could've managed their time better to talk less and demo more in their precious three minutes.

I went back to my group and discussed this with them, but at that point we felt we didn't have enough time to make a major change in what we were doing (since we couldn't fully get what we wanted to do working anyway) so we soldiered on. I pulled together a few slides for the pitch and signed us up for a slot on the early side, figuring that the judges would probably get pretty bleary-eyed near the end of all the pitches.

Once it came time to do the pitches, they set it up so that while one group was presenting, another group could get connected and they tested it was working in the back somewhere, but it went slightly awry with ours for some reason. The woman keeping track of the timer was very kind and paused it while we sorted that out. It was good (and thankfully brief) practice in public speaking.

Most of the teams created an app in the college-going category, with a few more in the social learning category, and the fewest in the out-of-school study category, which is what we entered ours in. The winner in our group, Quizlet's Lockscreen, had a working mobile app that gets you to practice vocabulary in foreign languages before you can unlock your phone. Pretty cool and nifty, though on the other hand, this is what their company does for a living ("simple tools that allow you to study anything, for free").

Advice for new developers attending their first hackathon:

• SIMPLIFY THE SCOPE OF YOUR APP, especially for a one-day hackathon like this one. It's much better to feel like you have plenty of time to tack on stuff later rather than rushing desperately to get something, anything done.
• Reduce any pressure you put on yourself as much as possible. I started getting a bit nervous about the whole thing the night before but felt a lot better once I decided to think of the day as "a visit to Facebook that happened to have some hacking work thrown in."
• Focus on one small, new thing that you want to learn. For me, it was just how to pull out the user's profile data that we wanted, but I think some the other teams got a bit overwhelmed by all the different pieces it would take to get the app up and running on Heroku and such and left Facebook feeling really demoralized and defeated. :(
• If you have the time/inclination, try to go through any basic tutorials on that API with an example app beforehand. If you can't do it beforehand, try to make your app something that you can just adapt the example app into to use to reduce the things that you have to do, like figuring out how to build the login process.
• Befriend someone with frontend/design skills so that you have something pretty for your demo.
• Even though it's only a three minute pitch, it's still worthwhile to figure out what you want to say and show and practice it beforehand so you know how to pace yourself. There were a few teams that ran out of time to show all the other cool features they'd built, which was a shame.

Feedback for Facebook:

• I had a hard time wading through the developer documentation. A lot of that was of course my own inexperience, but it seemed like there were two levels of documentation--really high-level best practices (like these on asking for permissions generally when I was trying to figure out how you ask for specific permissions) and then really detailed documentation on the specific properties. It didn't seem like there was much in the middle to connect the dots for "ok, I know I want to ask for permission to access user_interests, but how do I do that?" 
• The Graph API explorer tool is awesome (once I figured out how to use it and that its purpose is to allow you to get a sense of the structure of the data you're requesting).
• A more detailed, optional session on using the Facebook API for newbie programmers would've been well worth the time for us to attend.

Feedback for the Gates Foundation:

• If there are people unfamiliar with the edtech industry attending the event, it would be helpful to include some summaries on other strategies and apps that have been tried and what the difficulties encountered were.
• Since the ideas are submitted ahead of time and therefore go through a preliminary judging for the application, someone with experience should give some quick feedback right then to help the team with planning.
• It may be worthwhile to reconsider the format of this hackathon so that it's more productive towards the Gates Foundation's goals "to do things differently, not just better." Extending it to two days could be a start, but I've been thinking that the innovation that springs from a hackathon-type event comes from strangers with very different areas of expertise working together to develop a new idea, which you don't have as much with pre-formed teams. To get more of that, you could have either a longer competition where the entrants have a few months and can start coding as soon as they know that their idea has been accepted, or a hackathon where ideas and teams are formed at the beginning of the first day.

1752 words of description and Opinions, not too shabby. For another take on the same event, my teammate Kelley wrote a HackEd 2.0 recap post as well.