Classroom Clickers

Classroom Clicker is a great idea that will change classroom education forever, particularly in countries like Korea and Japan where classrooms are as interactive as TV is, meaning not at all. Like TV remotes, these clickers will let students change the channel.

The orange clicker is made by Hyper Interactive Teaching Technology from Arkansas. Dialpad-like clicker in the middle is made by GTCO CalComp of Maryland. Simplest looking blue clicker is made by eInstruction Corp. of Texas.

Eclipse Performance Bloopers

While reading about new and noteworthy features in Eclipse 3.1M7, I ran across Eclipse performance bloopers page which I found interesting.

For example, I didn't know that String.substring().intern() can prevent garbage collection of original string's character buffer because substring() grabs a reference of the buffer which intern() adds another reference at that won't be released until VM shutdown. I think some XML parser, DOM, and XSLT implementors might be doing this unintentionally.

Another blooper is, IMHO, a general design problem with Java stream I/O API. Specifically, there is no direct way for library implementors to tell whether an InputStream or OutputStream passed into their library (i.e. XML parser) is buffered or not.

If the implementor assumes it is and the caller forgets to buffer, then I/O performance crawls. If the implementor always buffers and the caller also does, then I/O performance suffers again. Of the two evils, double buffering is better than unbuffered I/O but, if you have N layers of libraries, you could end up with N buffers.

IMHO, the code that creates a stream should buffer the stream as needed. Libraries can also use markSupported() for input treams, which returns true for most buffering input stream implementations, to decide whether to add buffering or not. For output streams, you are out of luck.

Conference-jacking

A cool suggestion was made in comments to Dave's rant against IDG's Syndicate conference organizers' unreasonable demands: conference-jacking!

The way I interpret it, the idea is to use conferences as a tag of sort to hang podcasts off of, effectively creating alternative conference tracks anyone can contribute or listen to for free from anywhere anytime.

I've felt that most of the available podcasts were too radio show like, meaning they are pumped out everyday on whatever topic each podcaster is interested in. So topics are scattered and so are the podcasts.

Conference-jacking brings the podcasters together to a single location (a wiki + an OPML feed would work) to talk about a small focused set of topics that coincides with a meatspace event that someone else organized and spent money to publicize.

Radical!

Update:

I've registered alterence.* domain. Looks like Tyler Karaszewski couldn't resist either. He registered openconferences.org.

First BayPay Meeting

I attended the first BayPay meeting at Stanford yesterday. The meeting room was full and presentations were, surprisingly, not boring. There were enough people from all sides although I think more merchants needs to join so we can hear their perspectives.

Anyhoo, I can't talk about what I heard at the meeting but I came away with the feeling that I could hang with this group for a while.

RFC 2616, Section 9.1.1

Some folks keep pointing to section 9.1 of RFC 2616, the HTTP 1.1 spec, as the reason why they think Google is right and unsafe-GET websites are wrong.

From the mentioned section:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".

In my view, SHOULD NOT is not MUST NOT. Being a web developer is also not a binding promise to obey and defend RFC 2616. As developer, however, we need to protect ourselves from attacks and misdoings. Clearly, both sides failed to do that.

Note that the same section also states:

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature.

The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

So even the HTTP 1.1 spec states that it is not possible to ensure that all HTTP GET requests are safe. Yet GWA seems to assume otherwise. Are programs like GWA accountable? While others may feel otherwise, I think they are because it is GWA itself initiating the request blindly, not the user. Is the user giving GWA permission to make false assumptions on behalf of the user by installing the software? Even offered as-is, I think not.

Google Web Accelerator

Kids shouldn't be playing in the streets yet they do despite what we tell them. When a car runs over a kid playing in the street, what should the parents do? Spank the kid and let the driver go because kids shouldn't be playing in the street? IMHO, this is what happened with Google Web Accelerator (GWA) and Signal37's web applications.

So what should we do? Throw the driver in the slammer, warn the kids again, put up roadsigns and speedbumps. Alternatives are break every kids' legs so they can't play in the streets or turn roads into playgrounds.

Update:

See RFC 2616, Section 9.1.1.

Fixing BzzAgent

I've been thinking more about ways to fix BzzAgent. Well, it's not really fixing because I have not taken into consideration how much I could bend it without breaking it. I've just taken the core idea and tried applying it different ways. For now, I am going to talk about just one of the ways.

BzzContest

The idea here is to turn BzzCampaign into BzzContest among BzzGamers who compete for BzzPrizes. Control elements are divided into game rules and hints. BzzGamers win by gathering enough BzzPoints to be the top N players. Pro-bono campaigns are launched by having individuals and corporations donate prizes.

As to the exact form of the contests, it's could be a signup contest, variations of scavenger hunt, funniest video contest of people singing product jingles, or some new wild games like flashmob (i.e. get people to show up at Best Buy at a specific time). Just add a suggestion box and I doubt there will be a shortage of contest ideas that just happens to promote whatever.

As long as the contests are fun, rewarding, and not creepy, it will create buzz and attract marketers.

BzzAgent? More like WzzAgent.

I've heard about the idea behind BzzAgent a while back and thought their idea was a pretty interesting one. But it wasn't until the recent controversy over BzzAgent helping Creative Commons that I've looked closer. Just visiting their website was enough.

I don't know what they were thinking but their website seems to me as if they intentionally designed it to creep out visitors who are not marketers or mindless freebie seekers. Simply unbelievable. The only possible explanation is that they let their Bzz get to their head which made them blind to their mistakes.

Unless they review and overhaul their overall strategy, I am afraid whatever gain they make will be at the expense of their reputation and the status of BzzAgents not much higher than door-to-door salesmen.

What are you, a BzzAgent? BzzOff!