Surround and define the edges of a subject, giving it shape and volume

Month: August 2010

Post navigation

My hair is long since “beginning to grey”, which is becoming a cause for concern. My wife has always said that if my research funding dried up I could always jump to some other job programming. But the article linked above suggests otherwise. Even though I got carded yet again at Trader Joe’s last week, Brooke’s worst case scenario probably is going to be worse than she expects. As I march towards mid-forties and beyond, I’m also in a march towards being unemployable.

While I am not expecting to lose funding for my job in the immediate future, I’ve decided to start making plans for a career path that doesn’t include being a transportation researcher forever. This will hopefully mean that my fallback plan in case of immediate layoffs will get better than some nebulous “something in web tech or programming”. Continue reading →

Quick post that the “Asynchronous architectures with the CouchDB _changes feed” webcast hosted by O’Reilly Media was good. Unfortunately, what I really want to do is not yet possible out of the box. I want to use the GeoCouch indexer to filter the changes feed. So for example (and liberally inventing the ‘&&’ operator that mimics the same operator from PostGIS)

Then a map application could update, say, traffic conditions for the current viewport, rather than sifting through possibly millions of traffic events every few minutes just to find the handful in my area.

The hooks are there, and it might be possible to do a workaround, but I’m not seeing it yet.

I also thought I wanted reduce in the filter, but thinking about it I’ve changed my mind. Taking the Focus app as an example, suppose I want to see who has been active recently, not the actual posted tasks. A reduce in the filter could bundle up just the people making changes, while skipping the actual changes. But I think I understand enough of the underlying architecture of CouchDB to know that there probably isn’t much advantage to computing map/reduce b-trees for changes…by definition these things are changing. If such a thing were really important, one could use the changes feed to populate another db with appropriate documents (and the change timestamp and ordering), which in turn would have whatever map/reduce stuff I need to run.

A new project we are trying to get going here at the newly re-christened California Traffic Management Labs is an information portal that documents everything related to transportation modeling. While this is really great work for us academics, it presents some interesting problems. On the one hand, it is simple. All we have to do is write down everything we collectively know about all the relevant papers, research, programs, and practice, and then put hyperlinks on everything, and we’re done.

I did this sort of thing once before. A while ago I developed a system I called Academic. Academic was a bunch of perl and mysql running on top of slashcode…yes the same code running slashdot, circa 2003. It died because a hard drive crashed, slashcode is a nightmare, my database schema was too inflexible, and I found a leech was logging into the system and poaching my work (I naively expected people would contribute as much as they took away, but there is no GPL for research synthesis). In short, I never once considered actually unzipping that code, but having done a project once you have a feel for how to do it better the second time around.

So the details of how to load up academic references and how to physically links files and topics and tags is something I know how to do. (I actually have a new version running on top of CouchDB). The central problem is not the web site design or the database backend, but how to organize knowledge. We’re making a library of sorts, but by removing the physical limits of bookshelves and rooms, we can conceivable have everything just a click away from everything else. But too many things to click on a page is about as enlightening as showing a blank page. We need the system to enforce some discipline on the information content so that relationships actually mean something.

I am taking the approach of deferring as many choices as possible, and striving to allow those who populate the site (me, my colleagues, some hand-picked grad students, anybody who grabs the code once I push it out to github, …) to make the important choices about what relates to what. But I want to avoid the problem that seems to crop up in “everybody can edit” wikis of lots of similarly named and yet different pages. To that end, I’ve decided to organize the information around the idea of topics. A topic is more than a simple definition (although every topic has a simple definition). A topic is closer to a white paper or a survey paper. When one calls up the “Transportation Modeling” topic, the site should display a reasonably complete paper describing what transportation modeling is, including it history, current trends in the practice, active areas of research, and so on.

But the opportunity for disaster is right below the surface. In my current system, I am creating topics and forming generic links between topics. This is nothing nearly as sophisticated as a topic map, but maybe it needs to be. My idea is to use the relationships between topics to pull up material that might be related to the topic in question. The problem is that if a topic gets too broad, then the list of relevant resources will become unusable. For example, because the site is intended to document transportation modeling issues, the topic called “Transportation Modeling” should relate to pretty much everything else in the site. The information content of such a page is about equal to white noise.

The simple solution is to just make subtopics of big topics. We might have a section on “pricing models”, and another on “microsimulation models”, and so on. But the danger is that at some point down the road somebody is going to create a topic called “microsimulation of road pricing”, and link that topic to “microsimulation” and to “pricing”, and boom, the new topic is white noise, and even pricing and microsimulation are now less useful because they will start pulling in resources from the new hybrid topic(s).

We need to be clever about that eventual use case, so that new topics that relate to many other topics might start out with useless jumble of possibly related content, but the jumble can be quickly sorted into relevant and irrelevant material. In fact, most of my thinking about this project revolves around making this case easy to handle.

I made a screencast under OSX using the built in version of quicktime. I recorded screencapture in one process, my voice and face (from the iSight cam) in another process, and merged them together in the movie editor. The lame result is on youtube complete with utter failure at the end. Makes me laugh when I see it, and it is a word of caution to use a script, not go off the top of your head.

Anyway, that’s not the point of this post. My point is getting the macbook pro internal mic to work under Linux. I ran across several tips and howtos on using ffmpeg to record the screen and capture the iSight input, so I wanted to do that rather than boot into OSX. But for some reason, no matter what I did the recorded sound was in mono and only on the left channel. Immediately I unfairly suspected that my Linux software was to blame, but found nothing on the interwebs about such an issue. I recompiled the kernel, downloaded and installed PulseAudio and all its dependencies, and so on, with absolutely no effect. The only thing I could do was make the input sound worse by using arecord directly.

Turns out, there is no such thing as stereo input on the MBP 5,5 — at least, none that I can find. Under OSX, it appears that “stereo” is actually mono piped to two channels. To test this I made a little audio recording using QuickTime and snapped my fingers right and left. No difference in my headset during playback, just a snap right in the middle of my brain. And if you look up the specs on the Apple website, you’ll see “Omnidirectional microphone”

So the only problem with Linux is trying to mix the left channel to both channels.

We are searching for a new name for our physical and intellectual resources here at UCI. We have a real-world laboratory in that we have streets and highways that are instrumented. We used to call ourselves “ATMS Testbed”, and we still call ourselves Testbed, but we’re trying to push the notion that we aren’t ATMS. ATMS stands for Advanced Transportation Mangement System, but it has been usurped by its association with the software that is used to run the modern traffic control centers. So ATMS sounds like we just work on the ATMS software, but we actually do almost nothing with the ATMS software!

So we kicked around some names on email, and had a meeting this morning to discuss the name, and we very quickly settled on California Traffic Management Labs, in less than an hour! Magically, CTMLabs.org, .com, and .net are all available, so we got them. We decide to use http://www.ctmlabs.net as the primary site, because hey, “net” is like network, which is what we do.

So, once we get our website up and running at the end of the summer, if you want to do traffic management research and deployment, come to http://CTMLabs.net and see what we have to offer.