BarCamp Rochester – Not TV’s New York!

April 3, 2010 - Last Saturday, I packed up and headed out to the Rochester Institute of Technology for Rochester BarCamp 5. There was a lot of good material being presented, lots of personalities, and — in a few of the sessions I attended — I had the distinct impression that the information being presented had been learned at the expense of a mistake or two.

2010-ritoverview.jpg This was my first barcamp, so it was interesting to see this one in action. It was pretty well organized and I, probably like most first-timers, was pretty surprised at how quickly and easily order arose from the chaos.

Among the many topics that I attended were:

  • soldering 101 session where a live attempt was made to fix a robot (alas, no juice to test the fix but no shortage of ideas MacGyver would admire)
  • power inverters session where we saw what we need to change power from AC to DC
  • open-source hardware session that covered what exists and why we need it (OpenEEG - rock!)
  • binary translation or "how to bring your old games with you via emulation"
  • building the future that you want with futurology
  • antiquated coding techniques (BASIC and dialup networking) that were used to connect a PC Jr. to a computer that pulled down and fed it tweets

Here's more on four of the presentations I attended.

Interlock Rochester

2010 Interlock RochesterInterlock Rochester was the first session that I attended. It was broken up into five smaller presentations given by its members. The first part was a quick soldering demo that covered the basics of how to join two components with solder.

Following this was a quick teardown and buildup of a digital camera with new controls to wire the camera with a remote trigger. Using this, the hacker made a time-lapse video of himself digging his car out from under a foot or two of snow. The next presenter had built his own hourglass using a bit of wood and a couple wine glasses. You may have already seen this project floating around.

Following this and running short on time, we had a very quick presentation on how to build your own cat-5 cables by stripping cat-5 wire, lining up the smaller wires inside, and crimping the RJ-45 connector on the end. Finishing up the Interlock demos, we were shown a quick and easy way to fold and tie plastic bags to make them easier to organize, and less of a problem if they do find a way to liberate themselves in a strong wind.


Currently, using WebGL can still require a fair amount of heavy lifting by the developer. WebGLU aims to take some of this work out of making 3D images in script on a page and let the developer focus on the parts that are specific to the application.

Ben DeLillo, the one-man effort behind WebGLU, walked us through some code samples and showed a few examples. Based on his lines of code estimations, it sounds like WebGLU reduces the amount of code necessary by about 50%. That sounds like good progress to me!

Improving your Pages' Performance

It's totally possible to spend days talking about performance, so trying to fit the best of the best (or even the low hanging fruit) in half an hour is clearly a heroic thing to attempt. Dan DeFelippi went through a lot of good material that clearly engaged some members of his audience.

To demonstrate some performance principles, he took a look at RIT's homepage and examined the performance issues. He then went through some of the changes that might be made to improve them. One of the tools that he used was PageTest.

At YDN, we couldn't agree more that performance is important. Make sure that you check out our exceptional performance center.

New Ways to Build Games in HTML5

Ronald Jett ran through some of the things that he learned about HTML5's canvas element and web sockets while building a Scrabble clone. He started us with how he was using the <canvas> element, including animation. He then went through how web sockets can be used to communicate with the server. Following this, he showed us how he put these pieces together to make his Scrabble clone.

It was amusing to learn that some of the code he was using wasn't as optimized as it could be for the application since he didn't know what he would build when he began. For not having a specific plan from the start, the completed project wasn't too shabby at all.

Thanks Rochester and ttyl —
mich, YDN Engineering