Tedious but necessary

I’ve found that I prefer making things to maintaining things. My wife will testify that tidying up is not my forte, but that I don’t mind the most laborious cooking task.

Back from vacation

Twitter’s insidious influence on my brain has me jotting things down in short phrases.  Postcards to myself.

Back from Hawaii.

Got some knitting done on Emma’s sweater (sleeve 1 is done, sleeve 2 is 80%).

Got some sun.

Got some food poisoning.

Got a clue that I definitely hurt my hip over Easter by swimming.

Got behind on my work.

rockwall

So Grace is signed up for the kids rockwall class.  Hopefully she has as much fun as she had Sunday.

Maven skipped out on me in Eclipse!?

Strange as it may seem, Maven decided to stop working in Eclipse. I was trying to get an old project up in Eclipse to edit it to use the new Sakai K1 code, and couldn’t import it as an existing Eclipse site.  So I used the Maven import function, but had problems (it kept insisting on making 5 projects instead of one with 4 sub projects).  I was also having problems with my pom.xml files, so I decided to turn off some options with Maven in the Eclipse settings.

That was my mistake.  Something about what I did with the options was very bad, and Maven entirely disappeared from my Eclipse install.  No menu, no Window-> Preferences -> Maven category, no resolution of Maven repository, nothing.  I tried ripping out maven and reinstalling it, but no joy.

So I just deleted .eclipse from my home directory, and have to start over.

Sometimes I wonder if Eclipse is worth it.

update, the sakai app builder might be the culprit here

Good times

I remember when the Good Times email virus hoax hit my old company.  Ah those were the days. 

Cow Chap

Digesting Couchapp.

Such a tool …

After a long hiatus from programming Sakai tools, I once again find the code base an opaque nest of terms.  Gotta get back into the Sakai way of thinking, so I’m going to write up my thoughts to make it easier the next time I take a break and get back into it.

What I want to do is properly integrate my couch glossary with Sakai.  So what I need is a java wrapper around the couch access.  I want the wrapper to accept simple jsonp calls, and emit json responses, just as the current couchdb-native glossary does.  I’m even up for serving the widget from a doc attached to the design doc, just as in couchdb-native.

So this has to be available everywhere, so it has to be a service.  I think.  Here is where sakai terminology just numbs me.  There is nothing in the Sakai confluence site (nothing recent, that is) describing how to program a simple service.  There is lots of awesome stuff up there to make writing tools easier, but I don’t want a tool.  A tool gets stuck in a site.  A site exists all by itself.  I want a service with a public stub inside Tomcat, I guess like the library?  Except library can be seen always.  I want a real webapp.  Just not a tool.

So I think that is a good start for how to code this up in Sakai.  Use the app builder to make a tool, just get rid of all the tool stuff, and pay close attention to getting in and out of the app from the web.  Make sure all access is mediated by the authorization service, and that should do it.

Close still doesn’t count …

… except for nukes and bocci.

I can *almost* make bootstrapping work, but not entirely within couchdb.  I am going to have to do external processing.  Which is probably fine. 

More thoughts on using bootstrap

Closer, but still not yet there using bootstrap sampling in Couchdb.   My prior post was mostly thinking out loud.  I’ve tried some things since, and this post is an attempt to organize my thoughts on the topic.

Trevor’s Autonet paper published

Trevor’s Autonet paper finally got published, and we’ve gotten a small bit of press.  Funny how that works.  Do research and build a prototype.  Write a paper or two or four, apparently get no interest.  Project mostly trickles off.  Then one paper finally gets published by a slower journal, and hey, everybody is interested.

While the ideas are good, and while Trevor and his team did a great job with the prototype and got a working system running, I think the real barrier to something like Autonet taking off is the difficulty in getting  a local area wireless connection up and running.  Not from a technical, bit/bytes/hand-off/Doppler-shift point of view.  Rather from a non-technical user’s point of view.  It is quite difficult to set up a device so that it both blabs and listens on some open wireless channel without requiring careful attention from the user.  Most wifi links, in contrast, are pretty simple to use because there is a defined server and client. But even then most dialogs ask the user to select which host to access, and some require some sort of password or access code.

In the intervening years between working on that stuff and where we are now, we’ve sort of come to the conclusion that the data channel isn’t as important as just freeing the information from the automobile.  From the person traveling, really.

The primary advantage of a local area wireless connection is that, well, those cars and devices you can talk probably have data that are relevant to you too, because you’re all sitting in the same spot.  The local area wireless link acts like a spatial query on the huge mountain of traffic data that is available.  The disadvantage is the need to configure your wireless device in a secure, user friendly way, and needing to develop some sort of protocol to query distant locations.

On the other hand, a cellular link does not have automatic spatial query on the data.  Of course you can *do* a spatial query, but that costs some cpu cycles, whereas with the Autonet idea, you’re *only* querying geographically proximate neighbors.  You’ve also got the problem that the wide area wireless links cost money to use.  Cellphone companies are known to charge outrageous rates for data transfer, and in fact, AT&T specifically forbids using their data connection in the manner in which we would *like* to use it.  To quote from their service agreement terms and conditions:

Prohibited and Permissible Uses: Except as may otherwise be specifically permitted or prohibited for select data plans, data sessions may be conducted only for the following purposes: (i) Internet browsing; (ii) email; and (iii) intranet access. …[T]here are certain uses that cause extreme network capacity issues and interference with the network and are therefore prohibited. Examples of prohibited uses include, without limitation, the following: (i) server devices or host computer applications, including, but not limited to, Web camera posts or broadcasts, automatic data feeds, automated machine-to-machine connections or peer-to-peer (P2P) file sharing; …

So, an app that automatically uploads location and speed and queries traffic conditions every few seconds is out, but an application that “browses the internet” is okay.   So an application that responds to user input to “browse” the internet with a heartbeat ping is probably okay, but making it a daemon that bleeps every few minutes is not.

Gotta get us some iPhones so we can test this stuff out, I guess.  Which means we have to get funding.