Category: Method

I’ve been playing around with using Big Blue Button [1] while teaching my PHY1308 introductory physics course. I used it for virtual office hours during the Dallas ice storm. For the past few weeks, whenever I setup for actual class I also log into my virtual classroom as the moderator, upload my slides, and use WebCamStudio [2] to create a virtual camera device that allows me to switch between my laptop camera (for the blackboard) and an external camera (for demonstration equipment viewing). Essentially, I have an open source TV studio in my classroom.

On Thursday, I had my first attendee: my father! He had expressed interest in seeing how BBB worked in the teaching environment. After seeing me on camera, he entered into the chat window, “Get a haircut!” Oh, parents.

Ribbing aside, my father reported an excellent experience with the class. The sound of my lecturing was good, though he couldn’t hear student questions. I hadn’t been able to bring my conferencing microphone to class that day, so I had to rely purely on the built-in mic on the laptop. Considering that, I’m impressed my own lecture sound quality was good enough. The switching of the video was good, he told me. It was hard for him to see everything I was doing at the board, but primarily that was because I can’t get a wide enough shot of my blackboard with my laptop camera. I’ve also noticed that my Quickcam Pro 9000 resolution is limited, I think by either the UVC driver in linux or WebCamStudio (I can’t track it down). Either way, it was a largely positive experience reported by my father. Now he wants a BBB appliance for his own classroom.

The next step is to try BBB with a more “volatile” situation to see how it reacts. This coming Monday, the department seminar (which was going to be a video seminar anyway) will use BBB. The speaker, from Michigan, will dial into the virtual seminar room and I’ll make him the presenter. At that point, he’ll be able to upload slides, share his desktop, etc. I’ll have a camera on the audience in the seminar room, and my proper conferencing microphone. I’ll report the experience here. But, given our recent bad experience with EVO for a similar video seminar (jerky video that couldn’t keep up with the speaker, audio devices randomly switching from external mic to internal mic) this will be an interesting contrast and another data point for the BBB portfolio.

[1] http://www.bigbluebutton.org/

[2] http://www.ws4gl.org/

Here is my existing (and still growing) collection of math tips. These were developed for the students of my General Physics (Electricity and Magnetism) class.

This past week, I got my SMU-provided desktop PC. The first thing I did was to install VirtualBox and then install a virtual Ubuntu 9.04 system inside VirtualBox. The default desktop installation was Scientific Linux 5. While this is an excellent platform for research, it’s terrible for the  desktop. This machine will be my primary means of desktop work – writing, graphical editing, handling documents. SL5 sucks for this work. Ubuntu rules.

As soon as I got the system setup, I realized I wanted a way to edit my electronic logbook seamlessly between my laptop, the desktop, and any other machine. A while back, I mentioned a few e-logbook models I had tried [1]. I settled on TiddlyWiki for several reasons. It has journal entry built right into it. It allows new “tiddlers” to be created and linked to journal entries; for instance, a tiddler about a specific to-do item. It’s also a plain-text HTML file incorporating javascript code, which means it can be hand-edited and (more importantly) managed using something like CVS.

The challenge with TiddlyWiki is that I can’t find a reliable way to host the wiki through a central server. Doing so would allow me to edit the wiki from any machine with a web browser, asynchronously. There are external websites that will host your wiki, but the point of a logbook is to have it under my control. I decided instead to manage the logbook with Git.

Git is a software collaboration system used to manage the Linux Kernel. It feels similar to CVS, but is supposed to provide much better control over patching, branching, and other collaborative software development needs. I chose it because (a) I have never used it before and (b) if it’s good enough for Linus Torvalds, it’s good enough for me.

I copied my existing logbook directory (Notebooks/) to my home server. I then initialized the directory tree as a git repository (“git init”). I then added all existing files to the repository (“git add .”, followed by “git commit”). Now I had a central copy of the logbook capable of being pushed out to my laptop or desktop.

Let me pause to discuss how I structure and manage my logbook. I have a top-level directory called “Notebooks/”. I decided to keep one logbook for all my projects, rather than one per project. I can then tag tiddler journal entries with names like “babar” or “atlas” to know whether they are relevant to different projects, and search by tag. This was better than having lots of directories.

I did choose to keep one separate logbook per year. This is similar to what I did when I kept a paper logbook. I have a subdirectory called “Notebooks/2009”. I then had to make one more decision: how to handle media. I decided to keep subdirectories that are “MONTH/DAY” for media. For instance, if I need to put an image of a chart in my logbook on 09/01, I make the subdirectory “Notebooks/2009/09/01/” and put the image there. I then link to it in my  TiddlyWiki, and the image appears in my logbook. This may be hyper-organizational, but it allows two things. First, it relieves me of the conflict of similarly named files. If I have two graphs from the same source, one a revision of the previous, then I don’t have to name them differently (assuming the change happens over longer than a day). Second, it lets me associate date with result, and I can really think back by time index in my head to find something.

Finally, I like to have my default TiddlyWiki view (the “DefaultTiddlers” tiddler) be “[tag[journal]] [sort[-created]]”. This puts the journal entries on the inital load of the logbook, in order of date  from newest to oldest. This is more like a real logbook. When you open it, the most recent entries are closest to where the current entry is added.

Back to Git. Now, I can create the Git repository on my desktop or laptop for the Notebooks and pull the central copy to the desktop machine. I can then edit and push changes back to the server, to be picked up by my laptop. So far, I find this more than sufficient for my editing needs. We’ll see how this goes when I am on the road.

This is my current model of managing a logbook. I’m a pragmatist at heart. If this is clunky or cumbersome in the future, I’ll find a new model.

Useful links:

TiddlyWiki homepage
Git Homepage
Everyday Git Commands

[1] http://steve.cooleysekula.net/goingupalleys/2009/03/26/electronic-logbooks/