bits and bikes

Just spotted the Volkswagen Bik.e Electric Scooter on Wired’s Gadget Lab blog. Aside from the whole no-pedals thing, it’s definitely an interesting concept. Charlie Sorrel says:

The Bik.e is actually a sidekick for your car, something you are supposed to remove from the trunk when you have parked up and can go no further on four wheels. The Bik.e is electric, and folds up to fit in the spare-wheel well in the back of your car. While sitting in the dark like a kidnap victim, the Bik.e recharges from the car’s electrical system as you drive, meaning it is always ready to go.

Skip past the techno-themed intro to see Bik.e in action.

This reminded me of an email that I sent to Zipcar a few years back. My suggestion was that they should store folding bikes in the trunk of each of their cars, and rent them out through a “Zipbike” bikeshare program. They could piggy-back on existing infrastructure: they have already secured bicycle parking (read: trunks) throughout many metropolitan areas, they have already built a robust software/hardware payment and access system for rentals, and their primary focus is transportation. I haven’t used Zipcar for several years, but at the time they had many VWs in their Boston fleet. It seemed like a no-brainer to me, but I never did hear back.

Seems worth suggesting again to the carshare programs out there: Why not run a bike-sharing program out of the trunk of a car-sharing program?

Update (2011/04/24): Just ran across Geely’s electric McCar concept, which is another concept car with an electric scooter in the back. Will be interesting to see if any of these concepts make it to market.

Damon Horowitz and Sepandar Kamvar recently published a paper — referentially entitled “The Anatomy of a Large-Scale Social Search Engine” (PDF) — in which they nicely lay out the social search problem and the Aardvark solution. As I was reading this paper, one thought kept surfacing: Learning networks are about social search.

It seems reasonable to claim that since Q&A is about learning, Aardvark’s network-based Q&A site can be described as a type of learning network. The less obvious but, in my opinion, more interesting claim is that the design of learning networks can (and should!) be viewed as a social search problem. Illich argued this, Meetup demonstrates it quite nicely, and Grockit is moving in that direction, too. In an email exchange published last year, I suggested that the future of AI in Education will have a lot to do with social search:

I think the AIED systems of the future will be less about teaching directly, and more about providing guidance: when and how a student would benefit from working with someone else (perhaps a teacher, tutor, or peer.) When I get stuck solving a particular type of problem, who (that’s online and available) can best help me understand it? A good system will have predicted the frustrating challenge, and will have already lined up the person best-suited to explaining it to me in a way that I will understand. After I’ve demonstrated that I mastered the necessary skills, who can I then explain it to, both to help them and to clarify it for myself? A good system will be able to seamlessly coordinate this process. Through these interactions, the system will unobtrusively be learning more about me — both as a learner and as a peer-tutor — in order to improve with time.

Downright Aardvarkian.

(Cross-posted from the Grockit blog.)

I’m happy to announce that Grockit will be offering its paid summer research internship program for the summer of 2010. This is the second year that we’re doing this (thanks again, Angela!), and I think it’s a great opportunity for doctoral students to apply their own research experience to a system that a large (and growing) community of learners uses everyday. It’s worth mentioning that Grockit has a large and interesting set of educational data, a variety of research interests, a very talented team, and a fantastic work environment. I just posted details about this program (with an application form) on the 2010 Summer Research Internship, and I encourage you to check it out.

I wanted to share a few thoughts on why we’re offering this, what we have in mind for the program, and why you (or perhaps someone you know) should consider applying.

Grockit, as you may know, is a San Francisco-based web startup building a platform for — and a community around — synchronous collaborative learning games. We strive to provide our growing global network of learners with a smart platform informed by peer assistance and adaptive support. Towards this end, we’re constantly exploring new ways to support collaborative learning online, and we’re frequently examining and applying techniques for analyzing the learning data that we’ve been collecting. One reason that we’re offering this program is to expand on the ways in which we pursue these goals.

Two of the challenges in studying computational systems for peer learning — both of which I faced in completing my own graduate work — is that these systems can take quite some time to build, and it can often take even longer to cultivate a sufficiently large community of participating learners. As a result, the time required to get from hypothesis to data analysis can be (or at least can feel) quite long. At Grockit, we’ve been making good progress with regards to both challenges, and hope that this internship will provide an enterprising graduate student with the opportunity to speed up this process for their own research questions.

In addition to the research opportunity, we’re offering a program stipend, an accommodation stipend, and a travel stipend. You’ll also get a healthy breakfast and lunch cooked in the office every weekday and the chance to spend your summer in vibrant San Francisco. So if you are a doctoral student studying in a university in the United States and interested in applying for a summer research position with us, I’d encourage you to submit an application.

The deadline is March 1, 2010, and you can apply today.

Just a quick post to let you know that several hundred great new ideas on how we might reimagine learning have just been submitted to the Digital Media and Learning competition. This week only, you can contribute to the conversation by adding your own comments. Be sure to check out QuestionLab, which is a proposal outlining how we can leverage Grockit‘s platform for live collaboration to create a new game that actively engages learners in asking questions and sharing their work with the world, in concert with our friends at Connexions.

I’d love to hear your feedback, so please leave a comment about QuestionLab on the DML site!

Update: The public viewing/commenting period is now closed. For the curious:

QuestionLab: Using inquiry to power a community of peer learning online

QuestionLab encourages inquiry and collaboration through social online games. By expanding on Grockit’s live web-based collaborative learning platform, QuestionLab complements the existing focus on students answering challenging questions with a new activity engaging small groups of students in asking/authoring their own questions, assessing peer responses, and sharing their work via automatic publication to the Connexions OER Content Commons.

While Grockit games are primarily built on instructor-written multiple-choice questions, QuestionLab supports student-written open-ended questions. Using a real-time collaborative editing environment, small groups write STEM-oriented questions of interest to them. Students are encouraged to draw on Open Educational Resources in composing these questions, and QuestionLab affords doing so directly from Connexions, a “Content Commons” of free and open-licensed educational materials. By attaching descriptive tags and estimating question difficulty, students shape which of their peers are later presented with that question.

Complementing this new collaborative inquiry activity is an expanded form of Grockit’s existing problem-solving game, in which students work alone, with peers, or with a teacher to research and answer questions. Students specify their topics of interest and a Grockit game is prepared based on those criteria. After seeing a question and submitting an answer, the group reviews and assesses past responses and can award points and achievement badges to past respondents and/or the question authors. All student work produced within QuestionLab will carry a Creative Commons license and we automatically be externally published to Connexions.

QuestionLab leverages several strengths of Grockit’s platform: its social and game dynamics that motivate engagement, its growing global network of peer study groups, and its popularity both in and out of school. By fueling these games with the products of student inquiry, peer-assessment, and open educational resources, QuestionLab creates a culture of participatory learning among a community of peers.

I’ve recently been playing around with Etherpad, which was generously open-sourced by Google after they acquired AppJet. It is a fantastic piece of work, and I’ve enjoyed exploring the source code and brainstorming new applications for the technology.

My favorite find, so far, is in the billing controller:

I read this as a sign of a Lean Startup in action.

My bicycle has a flat tire, so I’ve recently been walking to work. I seem to end up spending much of this time thinking about how to be less late when commuting without a bike. While I always follow the same route when biking to work — one that balances total distance with hilliness — I have found no clear best route for commuting by foot. My path changes the most in the Mission, where the ground is flat and the streets are on a grid. I never walk any more than necessary to get there, but I hate the idea of standing still at an intersection while waiting for a light to turn green.

The beauty of walking is that the sidewalk grid is more detailed than the road grid. A standard intersection has two crosswalks on each of the four corners. If you are trying to walk northeast, a North-facing red light isn’t a slow-down, since it will be accompanied by an East-facing green light. Since I can’t really remember which intersections have lights, I can’t really plan ahead too much. So I commute by heuristic.

So this is the sidewalker’s dilemma: When arriving at a street corner en route from Point A to Point B, how do you decide whether to turn or to walk? I’ll lay out a few variations to make things interesting. Feel free to leave your heuristics (or additional variations) in the comments:

1. Let’s start simple: There is a rectangular grid of streets with sidewalks on either side. Your work is n blocks over and m blocks down from your home.
2. Some intersections have traffic lights, but you don’t remember which ones. When you arrive at a street corner, you can see the color of the lights at that intersection.
3. You can look a block ahead of you to see if there is a light at that intersection, but you don’t know what color the light will be by the time you arrive.
4. Each light is on a different schedule, and the schedules seem to change. Lights have pedestrian crosswalk signals that count down seconds before the light turns. You can see these numbers as you approach the crosswalk. You can muster up the energy to sprint a bit to get to the intersection in time to make the light. But only some maximum number of times during the commute, because you’re not really a morning person.
5. You remember a few of the intersections that have lights and a few that do not.
6. There are several coffee shops in the neighborhood. You know where they are, you know you want a coffee, and you don’t really care where it’s from.
7. You’re running too late to walk. You head to the nearest bus stop.

Does this describe your commute? What’s your strategy?

My bike has had a flat tire for longer than I’d care to admit, so I’ve been commuting recently by foot and by bus. This leaves me with plenty of time to think, but mostly just thoughts about walking and/or taking the bus.

If you’ve spent time waiting for erratically-timed buses, you know this question well: Will I get there faster if I continue waiting or if I start walking? You can look to recent literature in recreational mathematics for some general guidance on this dilemma [1] [2]. But while waiting may pay off for the lazy mathematician, I like to get some exercise in the process. So here’s a twist on the problem: How far can I walk without missing the next bus? I’ll propose three practical solutions:

1. Walk backwards, so you can spot the bus as soon as it becomes visible. When you do, make a run for the closest stop (preferably in the direction of your destination.)
2. Move to a city that displays bus arrival predictions at bus stops. Run to the first such display, check out the next arrival prediction, and do some quick mental math as you start to walk.
3. Live somewhere that offers open access to city datasets including real-time bus location and prediction feeds. Write the following iPhone application, and then email me when it’s ready.

App description – Given your current location (determined by GPS), your walking speed (based on past commutes), and your destination and bus route (stored in preferences or assumed based on time-of-day), it calculates two commute options and displays each with an estimated time of arrival. The first option minimizes your commute duration while maximizing the portion traveled by foot, and the second option minimizes your foot-only commute time. For example:

Your best commute options today are:
* ETA 8:55am – Walk to Church St, then get on #48. (0.5mi exercise)
* ETA 9:05am – Walk directly. (2.5mi exercise, saves $2.00)

Any takers? Seems like it would be a great candidate for the DataSF App Showcase.

While there’s a growing range of interest in and options for commute-oriented bicycles (e.g. the $900 Novara Fusion, the $1100 Breezer Uptown, $1600+ Civia Hyland, etc.), if you’re considering bicycle commuting, I would recommend against purchasing one these. Instead, I’d suggest borrowing a lesson from Agile software development: iterate.

Somewhere, in your basement, in your garage, your old bike is leaning against wall. The tires may be flat, the chain may be a bit rusty, but the frame is the right size. Let’s start here. You’re willing to give bicycle commuting a shot, at least for a week or two. I don’t think this necessitates the Hyland just yet, but a tune-up at your local shop is definitely in order. Give them a call and schedule it.

Let’s skip ahead a bit. You’re enjoying the daily commute, have done a bit of reading online about the little things that help make commuting easier. But even after a two or three weeks, your seat is still uncomfortable. Or perhaps your back is sore from leaning too far forward. Or you’re having trouble seeing bumps in the road on your ride home. Whatever is bothering you most, it’s time to address it. Head back to the shop, and get that new saddle, the handlebar extensions, or the headlight. The following week, you’ll be able to appreciate the difference. Another few weeks later, when something else is bothering you, repeat the drill.

I’ve seen a few instances of the big, up-front new-bike investment based on good intentions to begin commuting, and it’s always sad when it doesn’t play out as planned. What I’m suggesting here is an alternative: that if you incrementally improve your commute, you will keep your investment in line with the experience payoff.

I’m not saying this will be pretty. I started in grad school (which, by the way, is an excellent time to begin commuting by bicycle), on an early-nineties steel-frame mountain bike, to which I bungee-corded a milk-crate to carry my laptop and books. Over the past few years, the milk-crate has been replaced with REI Garage Sale panniers, the seat has been replace by a more comfortable saddle, the pedals now sport Power Grips, the front headlight, rear blinky, and wheel monkeylectrics are all LED-based. The tires got skinnier, more puncture-resistant, and grew fenders. The handlebars sprouted comfortable extensions. The water bottle holder now holds my sound system. I’m still waiting for the opportunity to turn it into a NuFixie. Lest it should sound like I now ride a completely different bike, I will point out that these changes happened slowly, over the course of several years and thousands of miles of commuting. In that time, I continued to prove to myself that the incremental improvements were worth the time and cost. And while this early-nineties steel frame bike now likes like some sort of FrankenGiant, it’s one that I’ve been quite happy with.

At this point, now that I’ve convinced myself that I’m in it for the long haul, I feel comfortable investing in a shiny new bicycle. Every now and then, I stop in a bike shop to try out something new. Ultimately, I seem to always walk away disappointed, thinking about the ways that I wished the test-ride was more like my daily commute. I’m sure some day soon, I’ll try something that grabs me. But until then…

Click for larger image

I posted an entry on the Grockit blog today, about how aim to build a learning platform that we is both both peer-powered and data-driven. My goal is to contribute a new post each week or so, which you can find here: http://blog.grockit.com/blog/category/learning/.

Following my acquisition of these socks, I’ve actively been on the lookout for interesting opportunities in my field. I’m excited to have found something great in the works at Grockit, and will be joining Farb and his team there next month. More details in the weeks to come… This blog will most likely be quieter for the next few weeks, after which I plan to continue posting at my breakneck pace of 50 posts every year.

Following on my recent posts on the hackable Monkeylectric LED spoke lights and the Altoids tins of bicycle hacks, I’d like to share a new idea. I don’t have the parts, tools, or know-how to build this myself, but perhaps you do, so I’ll share:

The idea is to build an automatic continuous transmission for a bicycle, by wiring up a controller for a NuVinci CVP designed to maintain a constant level of effort from the rider.

In the past year or two, I’ve spotted articles and reviews discussing an interesting new technology for bicycles: the NuVinci CVP from Fallbrook Technologies. The “CV” of the NuVinci CVP reflect the fact that the gear ratio is continously variable: While most bicyclists are familiar with the clicking feeling of switching between discrete gears, the NuVinci CVP offers an alternative in which a continuous spectrum of gear ratios are available. The demo video gives a nice overview. While a few high-end bicycles now incorporate the NuVinci into configured bike, you can also purchase just a hub or purchase just a pre-built wheel. Most user reviews so far have been quite positive about the technology, ratio speed range (350%), and test rides, but have been less positive about the added weight (~8lbs), reduced efficiency, and price (~$400). (See the reviews at bikehugger, veloblog, and bikecommuters).

…build a controller that continually adjusts the NuVinci’s gear ratio to maintain peak efficiency.

So let’s assume for the moment that the NuVinci CVP lives up to its billing. I’m suggesting that rather than constantly adjusting the NuVinci’s “CruiseControl” twist-shifter to maximize your efficiency, we build a controller that continually adjusts the NuVinci’s gear ratio to maintain peak efficiency. If I’m not mistaken, the effect should feel something like riding a stationary exercise bike. Or am I mixing up effort, power, and cadence? I did a bit of looking and came across one off-the-shelf power output sensor (the Polar Power Output Sensor Kit), and there are a whole slew of relatively cheap cadence sensors available.

Automatic controls for gear-shifting has made a recent resurgence, thanks to the three-speed Shimano Coasting group. Bicycles built on the Coasting components (or a similar system) automatically switch gears based on the bike’s speed (?? correct me if I’m wrong on this.) The goal of the Coasting system has been to enable simple bicycle designs for non-riders, by removing those pesky hand controls for shifting and braking. Clearly I have a different goal in mind than Coasting: elegance, not simplicity.

A bicycle that automatically and continuously maintains the preferred gear ratio (or cadence?) for the rider. Too good to be true? A simple afternoon hack? Please share your thoughts on the NuFixie Challenge…

Let me start by saying that I believe in visibility. And not in the dim-red-blinky kind of way. A healthy dose of LEDs and reflective tape cover both me and my bicycle when I ride after dark. But while my 4-AA front Cateye is quite bright, and my PlanetBike SuperFlash on back is nearly unmissable, my side visibility falls short. So a few years ago I picked up a pair of Hokey Spokes, and attached one to each wheel. (These battery-powered units attach to a spoke and fill the wheel with light from 16 yellow LEDs when it is spinning.) Last week, I took off the Hokey Spokes to try out something new: the Monkeylectric Monkey Light (m132s model.) I’ll start with a few videos…

I first heard of Monkeylectric last summer, when I met Dan Goldwater in Cambridge to see his then-current prototype. Dan, the force behind it, is a bona fide Maker. Prior to Monkeylectric, he was a co-founder of Instructables, a community site for how-to’s and DIY projects. He has contributed a large number of projects there, both LED-themed and bicycle-themed, and the Monkey Light clearly draws on this body of work. Where the Monkey Light differs, however, is in accessibility: It is for sale, already assembled and ready to use.

I will compare the Monkey Light to the Hokey Spoke based on the three criteria that I believe to be most important to the bicycle commuter: enjoying the commute, practicality, and staying safe.

Enjoying the commute:
There’s no questions about it: the Monkey Light is fun. Bright colors, in a variety of patterns, constantly changing.

I’ll repeat a request I made when reviewing another fun bicycle accessory: I’d like to see the lights blink to the beat of the music, a la iTunes Visualizer. Dan has posted schematics online, so perhaps this may not be impossible after all. If you figure this one out, please let me know…

Practicality:
Installation does take some time, but you only need to do it once. The included instructions are a bit skimpy, but Dan has posted a detailed guide on Instructables, which I recommend printing out. The unit is attached to spokes with zip-ties, and a set of rubber spacers eliminates any rattling. The Hokey Spokes, on the other hand, rattle incessantly, regardless of how much they are tightened. On the other hand, they were designed to be easily removable (with a screwdriver), and that does advantages over zip ties. I used the Hokey Spokes in the winter, when I ride home in the dark, but take them off in the summer, when it remains light longer. Now that the Monkey Light is zip-tied on, it’s not coming off again (unless someone cuts it off.) One suggestion: Before using the zip-ties, think about which side of the bike you stand on more often, and orient the Monkey Light so that the buttons are accessible from that side of the bike.

Unfortunately, the battery cage of the Monkey Light is not water-proof. You can either remove the batteries when parked outside on rainy days, or follow Dan’s Instructable on waterproofing the batteries, themselves. On the other hand, everything electronic outside of the battery cage has been coated with a water-proof layer, so you can use it in wet weather, if you so choose. The Monkeylectric website has photos of wheels partially-submerged in puddles during a downpour, to reassure you. I have yet to leave mine in the rain, but will update this review once I do… Monkey Lights now ship with a waterproof rubber cover for the battery cage, which works just fine.

When it comes to bicycle accessories for daily commuting, my preference is generally for road-ready manufactured products over homemade DIY products. Rain, snow, salt, constant jostling, and potholes are eventually unavoidable, and so my bicycle and the things on it must be able to handle that. So while it looks like a great project, I haven’t assembled a SpokePOV kit. Aside from the Hokey Spokes, there are other approaches to side-lighting for bicyclists. Commute by Bike reviewed the Pedalite Self-Generating Luminescent Bike Pedals earlier this year, and while it doesn’t look particularly bright, it wins points for not requiring any batteries.

Hokey Spokes do offer one feature missing from the Monkey Light: multi-unit synching. This is a cool trick in theory, but I found that the IR sensors were often triggered by bright sunlight, and frequently found them already running when I returned to my bicycle at the end of the day (Partially covering the sensors with electric tape solved the problem.) This synching and the fully-waterproof enclosure were two areas that the Monkey Light still lags behind. Perhaps next revision.

Staying safe:
The Monkey Light is significantly brighter than the Hokey Spokes (I included a direct comparison photo in the gallery above.) So to the extent that higher visibility means increased road safety, that’s good. I’m a bit worried about the swirling color light show being too visible, and causes a distraction to drivers, so, for the time being, I’ve been setting it to a single-color (orange.)

Summary: If you are concerned about cars not seeing you at intersections, the Monkey Light is a remarkably bright wheel-based light set. The customizability, hackability, and color variations may be unnecessary for a visibility-focused commuter, but hey, they definitely add to the fun.

You can purchase the Monkey Light through Amazon.

I spotted this clever website today (via), which plots the number of Google results for various spellings of one particular expression.

I, too, have generated statistics on various spellings of particular words, and have just yesterday posted them online. This includes about 100,000 spellings of about 3,000 English words, collected through the SpellBEE activity, as part of my dissertation work. So if you’ve been wondering about the relative frequency of various misspellings of the word “accommodation”, you can now rest easy: check out spellbee_errors1.txt. Details, descriptions, and downloads are here.

Several months ago, I wrote about the iHome iH85b (aka the “cycler”, the “Bike to Beach Bicycle Speaker for iPod”, or the “iHome2go”.) I continue to use this speaker during my commutes, and still highly recommend it. But that’s besides the point.

There are only three spots (that I can think of) to reliably mount a peripheral onto a bicycle: on the handlebar, on the rear rack, or in a water bottle cage. The front bar is a good spot for smaller trinkets that require attention, such as lights, bells, and electronics. The rear rack is a good spot for mounting assorted cargo, either in a milk crate, kitty litter buckets, or in plain old panniers. The water bottle cage, with one exception, is really only good for carrying one thing: a water bottle. The exception? When you bike sports a second cage.

A second water bottle cage opens up a slew of new possibilities. The iPod speaker is but only one option. There are all sorts of other creative uses for this space, ranging from home-brew lighting upgrades to a repair kit to the “Gadget Bottle” to other fully patented inventions. Know of others? Leave a comment.

What I like about these various designs is the creative use of the fixed space. iHome cheated a bit by shipping a larger-sized cage with their speaker, but in general, the size is a hard constraint. This reminds me of the large number of creative uses of Altoids tins in electronics projects, ranging from the MintyBoost to hundreds of Altoids tin projects posted on Instructables.

So what’s the right bottle to house your next DIY bike project? After some quick browsing on Amazon, my best find is this one from 3dRose LLC.

Related Post: My review of the iHome iH85b iPod Speaker.

Chris Seibold’s new O’Reilly book, the “Big Book of Apple Hacks,” is now available. While I haven’t seen it quite yet, I am familiar with at least one portion of the book: My blog post on User-Initiated Privacy for Web Applications is included.
This contribution describes a simple way for end users to maintain the privacy of their personal data when using web applications. Page Axe is a small program for Mac OS X that offers this, but the idea is not platform-specific.

I’m looking forward to see what else is in the book!

After successfully defending my dissertation yesterday, these new socks fit well!

For those that missed it last year, a very crafty idea emerged from the MBTA’s Orange Line: the CharlieCard Mitten. Colleen Meagher‘s idea was to sew a pocket on a mitten, sized to hold one of Boston’s new transit smart card. Clever.

For the bicycle commuter who owns (and occasionally drives) a car: Looks like there will soon be an option for pay-as-you-go car insurance. Milemeter appears to still be a few months from opening up shop, but the description posted on O’Reilly Radar makes it sound very promising. Worth keeping an eye on.

Another option for part-time drivers is to have a membership in a car-sharing program like Zipcar. I found this to be a great first step after getting rid of my own car a few years ago. I’d love to seem them provide a few more steps for recovering car owners. Perhaps by adding some utility bicycles, folding bicycles, and electric bicycles to their neighborhood-wide sprinkling of vehicles?

REI.com is now selling a Dahon folding bicycle, branded as the Novara Buzz Fly-By. While it’s missing several commuter-friendly features that some other Dahon models offer (e.g. chain guard, rear rack, hub dynamo-powered lights), REI does provide an unbeatable guarantee on everything they sell. It worth a trip to one of their quarterly Garage Sales to fully appreciate this.

Finally, for those of you wondering if you should keep waiting for the bus or give up and start walking, a recent paper might provide some direction. Longer answer: Read the full paper. Shorter answer: Stay put.

I’ve seen several web-based tools for cyclists to keep track of their rides, but rarely see one designed specifically for commuting. A recent post by Noah at Commute by Bike described the spreadsheet that he uses to keep track of his bicycle commuting. If you take a look at the spreadsheet, you’ll find the following columns summarizing each month of riding:

* Car commute days: I want this number to be as low as possible for 2008!
* Bus-assisted multi-mode commutes, which are a blessing in the winter
* Separate mileage counters for commuting, errands, and recreation
* Separate mileage counters for each bike for maintenance purposes
* Temperature extremes
* Cold weather clothing logs to help me fine-tune my attire for those really chilly days

Particularly in the month-by-month sheets, I like the focus on mode of transportation for the commute rather than on speed or purely on mileage. I’d actually drop mileage entirely, and focus more on weather conditions (rainy? headwinds? icy? sunny?) and cargo weight (none? a box of books?). I do like that the AM and PM commute are tracked separately. Add a bit of code, and your spreadsheet can email you when it’s time to recharge the batteries in your lights and sound system.

The Innovate or Die pedal-powered machine contest was

designed to inspire innovation and environmental change by highlighting the benefits of cycling in an unprecedented way. The challenge is to invent and build machines that transform zero-emission human energy into new and useful purposes, one pedal stroke at a time…

All entrants uploaded videos to the contest’s YouTube group, so anyone can take a look. Looks like 102 entries were submitted. Kudos to all of the entrants!

Earlier this week, I posted about the group of MIT students who pedal-powered an energy-efficient supercomputer. They “spun” this as a new record in human-powered computation. My thought is that the performance of humans powering computers should be measured in FLOPEBs: Floating Point Operations Per Energy Bar. Here’s their entry.

Pedal-powered supercomputing aside, I was most excited about the projects that involved bicycles that move. Stationary pedaling is just not my style. Of the entrants focused on bicycles for transportation, my favorites were the human-electric hybrid and the solar gondola. Both look like fun to drive.

The bicycle ambulance entry is also transportation-oriented, and is very purpose-driven.

I’m a big fan of safely listening to music while pedaling (see my iHome bicycle speaker review,) and so was very impressed by the video of the Choprical Fish (Human-powered party bike). If you haven’t seen it before, be sure to see the demo.

I liked the City Cycles entry, which described a young business focused on offering software (bits!) and consulting services to organizations interested in establishing bicycle lending programs.

Finally, I’m a big fan of the entry prototyping a low-tech approach to pedal-assist. Check out the video of their rubber band powered bike.

In a new twist on Human Computation, a team of 10 MIT cyclists pedal-powered an energy-efficient SiCortex SC648 supercomputer for 20 minutes, as a stunt related to their entry to the poorly-named Innovate or Die contest.

From the article at xconomy:

Their bikes were hooked up to generators, and as the team members pedaled, they produced direct current energy. The generators, in turn, were connected to a converter that transformed that energy to alternating current, which was used to power a couple of small SiCortex supercomputers, which were running an application that simulated a fusion reaction.

A version of this blog post is included in an Chris Seibold’s new O’Reilly book: Big Book of Apple Hacks.

Web-based applications are becoming increasingly popular, offering a variety of compelling advantages over desktop-based applications, both to developers and to users. These applications are platform-independent, accessible from any Internet-connected computer, offer offsite data storage, and often provide integrated tools for collaboration and sharing. One major tradeoff, however, is a loss of privacy. As users adopt web-based applications, their personal data (e.g. emails, address books, calendars, to-do lists, etc.) slowly migrates from the privacy of their computer to instead live on various web-app provider’s servers scattered across the Internet. While some of these web applications allow a user to flag certain data as “private”, this is a very limited notion of privacy, referring only to whether the web-application provider will share user data with other parties (such as other users.) The implicit message here is that the user’s data is always accessible (i.e. not private) to the company or individuals providing the web-application. This is a step back from the level of privacy afforded by desktop-based applications and should be recognized as such. But this doesn’t mean that we need to give up on privacy (or give up on web applications.) We just need to think more creatively.

After reading Peter Wayner’s book, Translucent Databases, on Jon Udell’s recommendation (see Achieving translucency), I saw that “translucent” database designs (?) could directly address this issue. Unfortunately, many (most?) web-application databases are not being designed translucently (more by Udell here and here). But if your web-application’s database wasn’t designed for translucency, is this a lost cause? I’m going to argue that it isn’t, and will show how you, the user of web applications, can initiate database translucency yourself, and thereby protect the privacy of your hosted personal data whenever you desire.

What do I mean by user-initiated database translucency? Think of it as BYOC: Bring Your Own Crypto. The idea here is for you, the user, to encrypt your personal data before it finds its way onto the web application server. As long as the encrypted data is considered valid by the application (e.g. doesn’t violate string-length or legal-character limitations), the application will continue to work as it did before, but the personal data will remain private. Then, when you’re later interested to view some of this data, the decryption and viewing can be done offline. If you do this right, your data will remain usable to you in the context of the web application without ever being visible (unencrypted) to the web application provider.

I’ll describe one approach to implementing this idea, which you can download and test out. Many others approaches are possible, and I’ll throw out a few ideas to get things started. If you implement one, please email me and post a comment below.

Page Axe (http://code.aribadernatal.com/PageAxe/) is a Mac OS X (i.e. “offline”) application that I wrote to demonstrate this idea. Upon running for the first time, Page Axe generates and saves a randomly-generated 256-byte key (via openssl rand -base64 -out /path/to/key 256). After that, any text typed into the Page Axe text box is encrypted with this key using the AES-CBC cipher algorithm (via openssl enc -aes-256-cbc -a -salt -pass file:/path/to/key). This encrypted text is copied to the clipboard, ready to be pasted into a text field in your web application. Page Axe also allows for viewing of this encrypted data. Copy and paste the encrypted text from the web application to Page Axe, and the text is decrypted (via openssl enc -d -aes-256-cbc -a -pass file:/path/to/key) and displayed for you to read again. At it’s core, it’s simply moving text between trusted desktop-land and untrusted browser-land in a way that guarantees that data privacy is maintained.

Here are a few screenshots of the Page Axe application in action:

Simple interface for encrypting and decrypting text.

Encrypted text is pasted into a web application.

The encrypted text can then be decrypted offline. Select a block of text from the web application that includes encrypted private data, and Page Axe will locate, decrypt, and display the private data in the context of the entire text block using Growl.

Alternative UI hooks are possible, such as this Quicksilver trigger for text decryption.

Page Axe is only one implementation of this concept of user-initiated privacy for web applications, written as a full-blown desktop application. Alternatively, one might alternatively figure out how to implement this as a Firefox Add-On, a bookmarklet, a platform-independent Java application stored on a portable USB (flash) drive, or perhaps something else. As long as the user’s private data is never accessible through the DOM to the “untrusted” web application, you’ve got a valid implementation.

I think one fascinating possibility here would be to incorporate this technique into applications designed to automatically sync offline and online data. Consider, for example, Spanning Sync, an application designed to provide two-way syncing between Apple’s iCal desktop application and Google’s web-based Calendar application. Imagine a new “Keep data private” checkbox, which causes offline data to be encrypted before being uploaded to Google’s servers and causes online data to be decrypted again after being downloaded. (For access to Google’s web application data on-the-go, a mobile implementation like Page Axe would provide access.) This example shows how data translucency can be initiated post-hoc via the web application’s published API! Many interesting possibilities exist here.

In summary, the move towards web-based applications comes at the expense of our privacy, but with the techniques outlined here, you can reclaim the privacy of your data any time you like!

I’d argue that the particular bicycle that you own is much less interesting than the way that you choose to use it. And there is no shortage of different types of bicycle usage (check out the lists compiled by Momentum Magazine and the CTC.) I use my bicycle primarily for 70 pound commutes. Which suggests that I’m not interested in carbon fiber components or in clever weight-shaving tips. So what am I interested in?

I want my bicycle commute to be as safe, practical, and as enjoyable as possible. This is, and will continue to be, the underlying theme of the bikes portion of Bits and Bikes. And this is also the criteria I use when deciding what to bring along while commuting. If the result weighs 70 lbs, so be it.

——

Practical:
Old 21-speed mountain bike
full fenders (for rainy days),
rear rack and panniers for carrying my cargo: clothes for the day, laptop and accessories, assortment school books and papers
rain gear for me and my cargo (forecast dependent)
glasses (sun and clear)
U-Lock and 6-foot cable

Safe:
helmet
water bottle
LEDs everywhere: front white light, rear red bright LED, side lighting (i.e. Hokey Spokes)
reflectors and tape, plastered everywhere.

Enjoyable:
Being dressed appropriately for the weather
Powergrips up or down, depending on the day
And a nice sound system!

Berry turned out to be several things: an exercise in software architecture, a taste of the frustrations and joys of Applescript Studio, a victim of feature creep, a lesson in interface design, a waste of time, and a whole bunch of fun.

Berry is lighter fare than my Coevisualizer research software framework: Its original purpose was to let me run certain small scripts on my home computer from my very low-tech cell phone. From here, Berry (originally Hackberry) eventually grew a full syntax for requests, a nice GUI, an SDK, a security model, and many new ways to connect. In addition to the original SMS communication channel, six more input channels and nine more output channels were later added (e.g. IM messaging, Skype, Quicksilver.) Talk about feature creep.

The general idea here is not new or unique. You can find software aiming to reach the same goal in many places, from startups (e.g. Soonr), shareware developers (e.g. Share), and even open source projects (Telekenesis). Now that I’m posting screenshots of Berry, we can add a “vaporware” category to this list.

Here are a few screenshots. I’ll try to add some annotations later…

An enabled Receiver will listen for Berry-formatted requests, and will ask Berry to process them.

An enabled Action can be performed by specifying it in any Berry request.

An enabled Responder can be used to send back the results of a Berry request.

Notice that I haven’t updated the code in a year and a half.

The internal/development interface is packed with a few example Berry requests.

I think you’ll agree that the best driving route from Point A to Point B is not necessarily the best biking route. But when it comes down to characterizing just how good a particular road is for bicycling, things get complicated. While I’ve made good use of Rubel’s waterproof Boston Bikemap, my ideal bicycle map would give me answers to a whole slew of questions:

• How popular is the road with other bicycle commuters?
• What are the specific traffic dangers? Car doors? Alleys? Buses?
• How fast are the cars moving? How much traffic is there?
• How much space separates bicycle from auto traffic?
• Who/what else do bikers share this space with? Piles of debris and leaves?
• Has the road been the site of previous accidents?
• Is there a bike lane? Do drivers respect it?
• How smooth is the ride? Do you need to swerve frequently to avoid potholes?
• How well lit is the road after dark?

What would such a map look like? I’m not sure. I’ve run across attempts at one of these or another:

• Bikely lets users upload their own favorite routes, which can be searched by location.
• The Oregonian maps the frequency of where cars and bikes collide, and Transportation Alternatives collects data on NYC crashes by borough.
• Denis Wood mapped streetlights (sans streets) in his neighborhood
• Noah Vawter offers one approach to quantifying ride smoothness.
• byCycle’s Trip Planner colors streets based on traffic volume and speed.
• Cycle Path notes peak hour traffic and strategic shortcuts in their bicycle commuter map of Athens, Ohio

If you have others, please leave a comment. I’m very interested in leveraging technology to make bicycle commuting more approachable, safe, and enjoyable. A (cycle-specific) mapping and routing system affects all three, so it’s definitely on my radar.

My first cell phone purchase was based on David Pogue’s 2003 recommendation: a Kyocera 2325. And last week, after over 49,000 minutes of talk time, it finally stopped working.

I was waiting for the call time to hit 50,000 minutes to take a picture, but the screen didn’t quite make it. Cell phones pricing is generally tied to a service contract, so cell phones are frequently dumped after a year. I’d like to hear from people who have made the most of a well-made phone. Have you hit the 50,000 minute mark? 100k minutes? More? Please share.

Which phone did I replace my Kyocera with? Thanks to the ebay resale market, another Kyocera 2325, with only 20,000 minutes already on it.

There are plenty of ways to shave ounces off of a bicycle, to make it that much faster for the next race. I don’t care much about those ways: My commuting setup weighs 70 lbs. Let’s just say that I prefer to ride prepared and comfortable to fast and furious. My commute is 7.5 miles in each direction, which generally takes about 45 minutes at my leisurely pace. Enough time for me to want some music. Earbuds are not a viable option for commuters, so I explored some of the other options out there.

The Soul Cycle mobile audio systems look excellent, but are clearly overkill for commuters (at $475 for a head-unit that still requires speakers, or $3200 for a complete Soul Cycle Classic). I also liked the idea of a DIY solution, like the Bike Stereo instructable, but I’m always skeptical about how the DIY projects and kits will fare in commuting conditions (jostling from bumps on uneven roads, moisture from rain and snow, etc.)

Enter the iHome IH85B Bike to Beach Speaker System for iPod…

What is this? First and foremost, the iH85B is designed specifically for an iPod with a dock connector. This is the only audio interface, so if your music is on a Zune, Blackberry, or even an iPod Shuffle, there’s nothing to see here. This is an iPod speaker for your bicycle, and not a bicycle speaker for your iPod. Two aspects of the design are bicycle-specific. The speaker itself has been designed to fit in a water bottle cage (either your own or the one provided). And the iPod can be controlled with a wireless remote that is handlebar-mounted (but removable for when you park your bike.) The remote includes all of the standard buttons: play/pause, previous/next track, volume up/down.

I’ve been using this speaker for about a month of commuting, and am happy to report that it has been a fantastic addition to my day. Music plays loud and clear, the handlebar-mounted controls are easy to use (even with gloves on!), and the attention to design is clear. Including batteries and my 4G thick iPod, the whole setup weighs just over 2 lbs. But these are definitely the most fun 2 lbs that I’ve added to my (70 lb) commute, so the weight has been fully justified.

Functionality:
The iH85B speaker itself only has a single button (power on/off). I was pleasantly surprised to find that turning the speaker on also turns on the iPod (and starts the music playing). Turning the speaker off also turns the iPod off. Nice! The controls on the remote are well-designed and can be used without looking down. The remote communicates with the speaker wirelessly, and I have noticed occasional problems with the connection dropping (and the remote being ignored.) I think that adding audio feedback (a beep or blip) when a button is pressed would help here.

twist it open to set up the iPod

the wireless remote clicks into a handlebar mount

Power:
This speaker runs off of 4 AA batteries, which makes it sufficiently loud for most commutes. I’ve never needed to turn the volume up to the max limit, which is great. The box includes an AC adapter plug, which simultaneously powers the speaker and recharges the iPod inside. Sounds great, but this is of little value to the bicycle commuter. It means that you can use it as a speaker at home, but if you already have a good sound system, this will power adaptor will likely end up in a drawer (along with the included case and extra iPod inserts.) I haven’t tested the limits on battery life, as I generally recharge mine over the weekend. I’d love to see a version that runs on a battery pack, that recharges using the included power cable. If it didn’t affect the price much, that is. The only real drawback I found here is that the remote control runs off of two CR2032 coin cell batteries, which cannot be recharged. I haven’t had to replace these yet, but once I do I’ll add an estimated lifetime here.

inside, iPod docks on one side, 4 AA batteries sit in the other.

Fit:
I found fit to be a weak point. The speaker can be squeezed into an existing water bottle cage, but you’re much better off installed the included plastic cage, which is slightly wider. I initially installed it on my seat tube (I prefer to leave the down-tube for a water bottle), but found that the snap-closure mechanism on the new cage couldn’t quite clear the position of the other cage. I swapped the two, giving me a setup just like the bike diagram above. I’d like to see future versions of the cage allow more clearance for double-cage use, ideally allowing for seat tube mounting. I’ve also had some trouble with the remote. Removing it from the handlebar mount is often quite difficult, due to a poorly-cut corner on the mounting. Are others having this same problem? My favorite aspect of the design is that it can be carried easily off-bike. The remote control “puck” snaps into the main unit, simultaneously protecting the speaker grill and the remote buttons. I stick the whole thing in the side of shoulder bag, where it fits perfectly in the water-bottle side pocket. Nice!

cage design should be revised to sit higher on tube

It fits nicely anywhere a water bottle would!

The remote doubles as a cap for the speaker grill when not in use!

Overview:
Overall, iHome hit on a great idea here, designing a wire-free sound system that can easily attached, controlled, removed, and carried. The wireless remote is great (as long as it works), and the overall design feels rugged and commuter-ready. How could this product be improved? Fix the location of the cage mounting holes, slim down the unit (if possible, to fit cleanly in an existing cage), add some audio cues to the remote button presses for feedback, and of course, make it more visible. I stuck a few reflectors on the sides of mine, but would really love to see a version with LEDs built into the sides of the unit, pulsing lights to the beat of the music.

Purchasing an iHome iH85B speaker through the Amazon links provided in this post helps support the Bits and Bike blog.

Recently I’ve been spending time experimenting with (and extending) my coevolutionary simulation software, Coevisualizer, which I now use to Teacher’s Dilemma-driven learning. The blue line represents the increasing ability of a learning student, and the red marks the distribution over difficulty of problems posed to that student by a teacher who is motivated by the game-theoretic structure of the Teacher’s Dilemma. The result? The teacher ends up consistently providing “appropriate” challenges for their student, even as the student’s abilities change.

More about Coevisualizer (including download)