Even with it being two years since I graduated from Hackbright, it’s not hard for me to bring to mind the fairly constant low-level bewilderment I had for the first couple of weeks when it came to thinking about what kind of project I might do for the second half of the program. I’m not sure how useful this advice might be, but I’ve shared it with few people here and there so I thought it might be worth writing up how one might go about generating ideas for and deciding on The Project.
The tl;dr is: pick something new to learn, and pick something you’re a little scared of.
When I was going through Hackbright, Career Day loomed over us for many weeks. Our minds were so focused on getting there and having a demo for what felt like would be 7 minute tryouts with the partner companies there. However, afterwards, I realized as I was interviewing that going through a bootcamp is more about demonstrating your aptitude for learning a lot technical information very quickly. Companies hiring you are doing so based on your potential, and not as much on what your current level of knowledge is (or this is how I think it should be, anyway).
The way this all relates to The Project is unlike how I thought about it pre-Career Day, it’s not about having a polished demo by then. Instead, it’s about being able to talk about how much you learned. A common question I got throughout my interviews was “What was the hardest part of your project, and what did you do to get through it?”
So it should be an area where you can talk about how opaque it had been to you before, but now you’ve conquered. A good heuristic for this is a topic that you’re a bit intimidated by and therefore have to push yourself to get through it. When you succeed, though, you’ll have a pride in your accomplishment that will shine through when you’re talking about it to others.
And believe me, you will be talking about The Project over, and over, and over, and over again. For me it’s never been that useful to get advice like “work on things you’re passionate about!” because that makes me try to think of what kinds of things I sit around feeling excited about, but then I end up feeling like I’m not interested in anything at all, like I’m an incredibly boring person and I sit around feeling lukewarm about most things.
It’s the framing of “passion” that gets me stuck, though. If I think of it instead as things that I can talk about forever and my eyes still light up, or something I find myself obsessing over, or just excited to tell other people about—those are pretty good stand-ins.
When people ask me how I came up with the idea for my Hackbright project, the slightly sheepish short answer is that the lead instructor for my class, Christian, gave it to me. He handed me a C.S. paper to me to read and I thought it sounded like it would be cool to try to make what was described in the paper work. But to be fair to myself, before that, I had told him my two main criteria were that I wanted it to be hardware-related somehow, and that generally I was more interested in solving new problems than re-implementing things.
My interest in hardware came from thinking back to why I never considered studying computer science, despite having two engineer parents, despite never feeling intimidated in the slightest by science or math*, and despite attending a pre-engineering high school where we were exposed to computers and programming. And I realized it was because back then, I assumed that to be seriously into computers, you had to be someone that had been capable of building a computer from spare parts since you were 10.** So a hardware project suited me well on the “something new I want to learn that also kind of scares me” test.
The solving new problems thing is as contrasted to people that were interested in writing a compiler, or creating their new language (both of which were projects by my classmates!). For me, I would do something like that if I had as a class assignment, but otherwise my attitude is sort of like, other people have already done that and I’m sure they’ve done it really well, I’m happy to just use their work. Some people are really into diving deep into those topics, which is great! There are reams of literature on all the interesting complexities.
My project instead had just enough guidance out there for me to adapt certain tutorials for bits and pieces of it, yet nothing published about how to do it exactly that way from start to finish. I learned about halfway through that Christian had done it himself so he would reference his own implementation when I got stuck to give me guidance on where to go next. Successfully cobbling it all together and getting it working was incredibly satisfying.
The instructors are good at helping people scope out their projects for what’s doable within the timeframe before Career Day. Projects don’t have to be finished completely, and actually another question I frequently got was “what else do you want to do with your project?” so it’s useful to have some other stuff to talk about then. A few of us with some experience in product management made ourselves rough roadmaps of what our MVPs would look like and how that might map into the time remaining, so we could have a heads up of where we might need to redirect our focus with that Career Day demo in mind.
But I think pretty much no matter what, since you’re doing the work, you’ll have something to talk about, even if the work is unfinished by that particular deadline. Even failing demos aren’t that big deal, that actually would get people’s sympathies for demo-driven bug discovery, and it was a good sign if the partner companies turned to asking how I would approach trying to fix the problem.
I’ll also pass along the advice I received to ignore the urge to pick something related to the industry I was in prior to Hackbright. I had thought that maybe I should pick a project that used my domain knowledge there so that in interviews, I would be a stronger candidate in that industry. This might also manifest as picking a project because there’s a specific company you want to work at.
I think if you’re feeling that urge because you’re really drawn to that topic, it could work really well. Possibly, though, you might be doing that because it feels like a way to mitigate the risk you’re taking on in switching in careers, and if that’s the case, I think you should reconsider. You are probably leaving that field for a reason and probably aren’t all that interested in it intrinsically, so that topic might end up failing you when you have to talk about it for the 100th time. Better to have something that you can summon genuine enthusiasm for every time, because that will better catch interviewers’ attention, and better convince them you’ll be excited about your job there too.
Lastly, remember that this won’t be the last project you ever do. I remember the feeling that this was a pivotal, monumental decision, but freezing due to blowing up the decision’s importance wasn’t helpful. You’ll get to pursue at least some of the many different ideas you have, some day, and it’ll all work out ok in the end.
[edit 4/30/15] ah I forgot one more point I like to make with project ideas! Which is that when you're first developing tech project ideas, it's great to think about problems that you personally face but it can be hard to transition from thinking about what's interesting from the standpoint of content vs. the standpoint of interesting technical challenge. So a rough rule of thumb for this might be, would the interestingness of the project decrease if you had to fill it with fake data/content instead? Would it be a ton of work to generate that fake content? Note that it's totally ok to use other APIs, like maps, or scraping pages for content, but you want to look at it from the standpoint of, "this would still be interesting programming challenge even if the content served up were nonsense."
* I went to a couple “women in science!” in high school for fairly mercenary reasons, as my attitude was mostly “of course I can do science, why would that ever be in question, but ok cool if you want to give me some free stuff for it…” heh
** Also because I didn’t consider myself amongst the ones in our class that were particularly adept and/or obsessed with computers.
Showing posts with label Hackbright project. Show all posts
Showing posts with label Hackbright project. Show all posts
Connecting a Wii nunchuck to Arduino
May 6, 2013
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:
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.
- 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.
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:
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.
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
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.
Subscribe to:
Posts (Atom)