found drama

Last night was the second BurlingtonJS meet-up and once again it felt like a huge success. Many thanks again to Patrick and Pete for organizing it; there was a great turn out and a lot of great discussion. The theme of the night was Node and the presenters did a fantastic job. First up, Dave Howell and Jeffrey Pierce (pictured below) presented on their “all JavaScript” rendition of Terry Riley’s In C (“in.c”), with special attention paid to the library they wrote to wrap the Web Audio API and the pain and suffering involved in synchronizing the audio context’s clock with the canvas context’s clock. Next up was Jon Sullivan, giving a high-level overview of how Node fits in to the technology stack at Mindflash. The meet-up had a great turn out, the conversations were great, and I think every attendee got something useful (or at least fun) out of the night.

Dave and Jeffrey (Pixel to Noise) demo “in.c” (source). (Photo originally posted to Instagram.)

Above and beyond the technical JavaScript nitty-gritty fat-chewing that went on, there were a couple of observations/take-aways for me:

1. Burlington has a pretty vibrant JavaScript community. I don’t know what last night’s head count was, but it looked like there were even more this second time than there was the first time. Everyone was really engaged, there were lots of great questions, and the room just felt full of smart, friendly people.
2. Burlington’s JS community is eclectic. We had people from all different company sizes, and companies doing all different kinds of software. We had some students. We had some hobbyists. We had all skill levels. And what made it even more fun: the first presentation went pretty deep into music nerdery as well as JavaScript nerdery, and there wasn’t a single yawn or glazed-over eyeball in the place.
3. Hardly anyone is saying “SOA” but everyone is talking about SOA. This was especially evident during Jon Sullivan’s talk. Jon mentioned using Node as a façade or proxy for other, older, legacy applications — pulling data out and sending it along to the newer, smaller, purpose-specific applications. And then boom here come the questions/comments from the audience about their old and crufty and monolithic monster legacy apps. (For those of you that were there: here is one of the Songkick dev blog posts about their migrating-to-SOA process. ¹) Anyway: the conversation kept veering toward SOA, but the social pressure of “hey we’re here to talk about Node!” kept pulling it back the other way and… Anyway, this might make for a good talk or round-table sometime, since there’s so much interest.
4. Getting involved in open source. This was the other “meta-theme” of the night. Again: the theme of the night was Node, and as such, npm modules came up over and over. How do you find them? How do you find good ones? What makes a module “good”? If it’s technically superior to the alternatives but it isn’t actively maintained, is it still “good”? This is not a problem that’s unique to Node, of course, but do a search for “template” in npm sometime and you’ll see what I mean. One of the points that we made ² was that while it is tempting to write your own module… sometimes the right thing to do is instead to fix that bug or add that feature or write that contrib lib and submit a damned Pull Request. And if a project looks DOA, maybe contact the original author and offer to take over stewardship. And now that GitHub has enabled redirects on repos, ³ there’s even fewer excuses.

Anyway… The meet-up was great and I’m looking forward to the next one. If you see Patrick or Pete, give them a high five or buy them a beer or something. BurlingtonJS is a thing that needs to keep happening.

1. From there, the rest are easy to find.[↩]
2. I say “we” because: as part of his talk, Jon was talking about contributing back to the modules they used; and Artur was urging people to make Pull Requests instead of just forking or writing their own thing all the time; and I was right up front nodding vigorously.[↩]
3. Wherein I praise GitHub’s repo redirect feature and explain why it’s important: link.[↩]

About Rob Friesel