Coding in Shanghai: Javascript Hackathon

One Friday night, googling (or, baidu-ing?) for “things to do in Shanghai,” I found out about a hackathon being held the next day: 24 hours using MeteorJS to build a web app. Perfect! I’d built a dirt simple sign-in sheet with NodeJS and Javascript, but my code was already getting messy so I shelved it until I was ready to rewrite it from scratch. The hackathon was just the excuse I needed to try a modern framework (i.e. someone else’s code that does most of the work for you) to rewrite my sign-in sheet for the FabLab’s many machines. And hey, if it’s polished enough, maybe other FabLabs would want to use it, too.

I was finally getting used to Shanghai’s metro system and found the Agora Co-working space without any trouble. It’s a beautiful office with a garden out back and the wifi was the fastest I’d gotten anywhere in China. I liked the place right away.

This was my second hackathon (after the People’s Music School Hack Music) so I was a little more proactive about introducing myself and what I wanted to do. Pretty quickly, a small team assembled around my laser-sign-in sheet project, but it was a bit every-man-for-himself as far as learning MeteorJS goes. We were all there for the same reason, to try out the new framework, but without any kind of guided introduction / classroom situation, we were left to read the docs and getting starter guides, which isn’t really a group project.

But after a couple hours, I felt like I was learning a lot and my teammembers felt they had worked through enough of the tutorials that were ready to work on something together, but then we were all new at collaborative coding, too! Especially for a one-page app, it’s difficult to divvy up the work. We didn’t figure that out until after an hour of learning to use github (another good learning experience, though, cloning and committing and all that, that’s definitely a good thing to work through with other people in the same room instead of just reading a getting started guide.) Once we could finally push and clone each other’s code we arrived at the question of how to split up the work. We all took a stab at creating a good foundation to work up from, but were all using our own preferred approaches and stepped on each others feet when we tried to merge our ideas together, so when were getting settled in after dinner and my team members asked what we should work on, I said:

“I want to suggest that we all do whatever we want to”

And that worked out pretty well. A sign in sheet is a simple enough app that we could all write it from scratch, and this way we could experiment with the approach that interested us instead of trying to come to agreement on what tools to use together. So from then on out we worked on our own thing, snacked in the kitchen on occasion, and put on our headphones to focus whenever we wanted, and I think we all had a good time. I stayed up late and slept on that giant beanbag in the first picture.

In the morning I showed my progress to a few guys (it works, but it doesn’t have a way of saving the data or reseting each day, yet), but had to bid them farewell before the end of the Hackathon to get across town for the Shanghai Maker Carnival. It was great to find some friends in such a big city and feel like I was on a programming team (however dysfunctional) for a day.

Pictures posted on their Meetup by Julian:

Hacking Music at the People’s Music School

Our attempt at Montessori-style music composition with blocks

With a team of new friends, I got to build a musical instrument that combines LEGOs and Arduino. An ultrasonic distance sensor hangs under a gantry and plays different notes according to the LEGOs underneath it. Our hurried first build was fragile, but pulled off a successful live demo in front of the audience.

(We called it FORTissimo since you could build LEGO forts that make loud noises.)

Thanks to Nora’s suggestion to join the facebook group Hackathon Hackers, I found out about an event I couldn’t pass up: a music/technology hackathon put on by a the People’s Music School (@PeoplesMusicSch ). Only trouble was I was living 300 miles away at a cabin in the woods of Southern IL. Luckily I wasn’t too far from an Amtrak station, and I scheduled a roundtrip on the City of New Orleans inside of the 24 hours I had off work (it seemed that way at the time).

After a few hours of spotty sleep on the train, and a drowsy cab ride to Merchandise Mart, I can’t tell you how refreshing it was to walk off the elevator into a sunlit atrium filled with the sounds of a string quartet. Throughout the day a few students of the music school would set up in one room or another to give a soundtrack to the brainstorming and building. It was awesome.

This was the first hackathon I’d participated in. The way teams were divvied up was a bit awkward: after opening remarks, the audience was asked if anyone had an idea for a team yet — perhaps they were expecting more small groups to show up ready to go, but I think most of the people came as individuals. So instead a few people introduced themselves and said what comes to their mind when they think about tech / music / education. I introduced myself and said I liked to use Arduino to teach music and coding.

In the coffeecake fueled team-forming mingling that came afterward, I was approached by a couple different people who had ideas for software to help people learn music, and I ended up sitting down with a couple of women who had kids studying music — it was a lot of fun to think about what makes practicing difficult for anyone (I had dropped out of music school a few years before partly because I couldn’t quite stomach the 4 hours a day in the practice booth that my professors recommended).

We identified that the repetition of material coupled with the lack of feedback makes sitting in a practice room a pretty dull experience. So we brainstormed ways of automating feedback — perhaps a program could take a recorded example of a teacher playing a passage, and compare a student trying to copy it. I still think a computer could quickly point out wrong notes and wrong timing so that you don’t practice the same passage incorrectly over and over, but we agreed that replacing a music teacher with an app was pretty pie-in-the-sky.

People’s movement from one team to another was pretty fluid, which was great — it meant ideas got around. Having people work around each other openly, brainstorming on white boards makes it pretty easy to join a conversation, and not long after, join a team. After bouncing ideas off a few different people during the morning, I came across a table scattered with LEGOs. Alex and Ania had brought their hack-kit with them and already had some beeps going on while constructing lego towers. Of course I sat down to ask them what they had going on. Alex had seen an Instuctables for an Arduino Distance Sensor with Buzzer and LED before coming to the hackathon and brought his Arduino, distance sensor, and piezo buzzer. After catching me up, he complained that his main concern is that the buzzer wasn’t a loud enough output. I showed him that it was really easy to control the sound from a laptop via Arduino, but he insisted that he doesn’t want the product to be tethered to a computer to work. Luckily (well, I was going to a music-tech hackathon) I had speakers and transistors in my laptop bag and built two simple one-transistor amplifiers to output some simple square wave tones. We rubber-banded the mini breadboard to the top of their gantry. Happy with the improvement, they let me join their team and commence a couple hours of programming and debugging to get each note of a major scale to be triggered by a particular height of LEGOs.

Note the kid in the background who looks jealous that we got to play with LEGO.

The live demo went great, playing a melody up and down a major scale (cleverly avoiding the bug we never worked out when going from the highest tower back down to nothing). Among the rest of the presentations, ours was the only one that was more than theoretical (though there were some web mockups that were pretty impressive for 6 hours of design time). I’d still like to explore software that compares a student practicing to some standard and tells the student what they can do to improve. I’d also like to actually build FORTissimo as a kit. It really would be pretty cheap and versatile. But for now it was just a fun weekend.

Code is at