Chrome OS?

Sometimes don't cha have to wonder?

Google Chrome OS. is there some mad splintering going on?

notes: svnserver on os x

I suddenly had an unplanned gap in my summer dad duties so I turned to my long list of neglected nerding.

I have been able to cajole my random-number-of-charges to help with installing Ubuntu on a stack of old machines prior to donation (5 so far!), taught some of them how to solder, and exterminated a horde of vermin from the call center, but no real traction. That will wait for summer camps to start!

After the last Stanford project I promised myself I would jump ahead from the 2.4 era of Sakai Stanford has been using. I took a peek at the K2 stuff - The white paper was sensible, Zach's notes useful... so I finally picked up Maven 2 and git. Too bad today was the same day the Sakai confluence was down for a brain trainsfer. I commenced to downloading the current binaries.

Onward!

One goal floating around is to upgrade the kitchen Mac Mini to an Intel based Mini. The current Mini becomes a server in the call center. I wanted to run a CZWXLLC svn server outside of the graces of Stanford, and so went through the steps to get a svn server on the G4 mini. I did the simplest possible thing I could do. That is to get the server deployed running via the svn:// protocol and constantly accessible from within the imperial home network.

It wasn't that bad. Here is a rough outline:

1. install the SVN package somewhere sensible. I used /usr/local/bin. that may not be sensible to you, but it was sensible to me.
2. figure out which user is the 'login' user, if you have one. The Kitchen computer happens to have one - we want Skype up when Mitchell is on the road, so it's always ready to go.
   
3. use svnadmin to create a repo directory somewhere where the login user has rights. I just used the user's home directory.
   
4. update the user configuration files with your various users and assign passwords
5. start svnserve

Now, this last bit is a bit trickier. You probably know about svnserve -d -r /path to repo and all that stuff. Firing up your svn server that way, as the login user, gets everything hopping along. Until restart.

To get your svn server to start up after a restart is the real goal. To do that you're going to have to use the Mac OS launchctl tool.

launchctl is used to configure the launchd daemon. The idea is that you want the box to boot, scoot through a set of 'scripts' and fire up basic services. init.d stuff like stuff.

The 'scripts' are XML configuration files. They are stored in /Library/LaunchDaemons, and by convention are '.plist' files. These contain a namespace registration mechanism and a way of passing in command line arguments. Take a look at the files on your own machine - it's pretty straight forward, yet as with most of these abstractions rather opaque - what the heck are the options? the options for svnserve itself are fine, but what about the OS?

For svnserver I used one found here. Be sure to change the path to the repo, the user and the user's group as necessary for your machine.

More sophisticated schemes would have non-login users, separate groups, etc., etc., but I didn't think that was necessary for getting off the ground.

As this repo is behind the CZWX firewall this is as far as I've gotten. If I put it into the DMZ when I drop it into the call center I'll have to upgrade the connections to SSL and all that jazz.

Onward! Next steps are to get the most recent Sakai checked out as well as the K2 stuff and see about getting some edgeless administration stuff going on these phones.

Just a note:

I've succeeded, after a Firefox upgrade, in slipping a Google Wave into the Blogger template.

http://caseydexperiment.blogspot.com/2009_06_01_archive.html

the Wave embedding example worked fine.

Should work anywhere ;)

Desktop integration with Sakai

There has been a good stream of articles describing Sakai's web services lately. If you're doing work with Sakai you can quickly come up to speed with this very useful functionality.

I'ld like to give an example.

Over the past Stanford academic year I built a desktop Java application designed to provide high-stakes language skills testing. The desktop application is tightly integrated with the Stanford University deployment of Sakai, Coursework.

The test is called the "Simulated Oral Proficiency Interview" (SOPI) and is administered by the Stanford Language Center. This rSmart newsletter has background information on SOPI.

I'll cut to the chase.

The SOPI test is administered under highly controlled conditions. The student only gets once chance, ever, to take the assessment. The assessment materials are so tightly controlled access is denied to the instructional staff. There is all sorts of complex authorization requirements for this project.

Sorta tricky to have a Sakai site where the instructor can't get at the materials, eh?

The assessment takes the form of a series of Quicktime movies. Each movie presents a question to the user. The user's response is recorded in a Quicktime movie, which is stored away for review by the instructional staff. The sequencing of the assessment is structured through an awkward XML file. To hit the schedule for the 2009 SOPI assessment we decided to leave the XML format as it was - there is lots of room for improvement.

The SOPI Application is written in Java, using the Swing Application Framework (JSR-296), Axis, and Apple's Quicktime for Java. A desktop app was written to avoid all the Java / Quicktime / Sandbox / multi-Browser issues, and to push security up several notches. It does all the things you expect - pretty boxes with movies, live audio waveforms, etc. I've a writeup in the works over at www.czwxllc.com, my companies site, and I'll put up one of the screen play movies used during development so you can see it.

To support the (baroque) security requirements the SOPI assessment resources are not stored in the Language Classes' Sakai site. Rather a 'sister' site is created. We called these Sopi Resource sites officially, but most often just 'sister-sites.' This is a custom Sakai site type with a new role, the standard Resources tool, and a real-time monitoring tool created by Zach Thomas of Aeroplane Software. Sakai site properties are created which provide references to class site sections - a single SOPI Resource site can provide content to rosters from various class-site sections.

The test is given in a controlled lab. 20 to 40 students may be starting the test simultaneously.

Stanford is running a modified Sakai 2.4.x

The SOPI Application uses Sakai webservices to

• support 2 user sessions, a super-empowered 'agent' and the end user
  
• determine which SOPI assessments are currently enabled
  
• to get user site membership information
• to get user Stanford affiliation information, which changes the desktop app's UI
  
• to store user progress, including resume state

The SOPI App uses Sakai REST tools to support

• pulling of XML and Quicktime movie content from the Resouces tool
• pushing Quicktime movie content into the Resources tool

The App pulls down the XML, validates, and then pulls down all the Quicktime movies. At that point a second validation is performed to see if the movies are in a valid QT format.

As the user proceeds through the assessment the responses are queued up and asynchronously uploaded to Sakai as the assessment plows along. The load-balanced pool of Sakai servers does pretty darn well in accepting 30 odd movies all at once.

The major changes to Sakai to support the SOPI assessment were

• modifying the Resources 'webservlet' tool to not swallow all sorts of sensible exceptions, such as quota violations. These are now reported back as HTTP RFC responses to which the App responds.
  
• using a locally developed version of Sakai login which has far less overhead. We wrote this code during our first rollout of Sakai at Stanford long ago.

which aren't really all that major, are they ;)

I found this model of Sakai development, that of using REST and Axis, to be really fun and efficient. The more recent versions of Sakai would of made this even easier. I look forward to catching my dev environments up to the most recent Sakai and seeing what drops out of the SOPI codebase - less code, less to break.

My next experiment is to create a language assessment app which uses a cell phone. How could this not be cool?

Onward!

the proper way to get that boom shot

Wave II.5

I find it funny that the google email with my wave ID was stuffed into my gmail spam folder.

I'm caseyd@wavesandbox.com

There is a sandbox upgrade today, so I'll not be hanging around in the wave client too long.

later: commencing to tinker. note to self: tinker on a fast machine.

7 years of Mozilla!

Today is the 7th anniversary of Mozilla.

Getting Mozilla rolling was a very iffy proposition.

And it's taken a lot of work - I doubt people realize how much has gone into simply surviving let alone prospering.

Just look at the mad stuff emerging from the Labs.

Not to mention the standard "We'll make you incredibly rich, just sign here..." opportunities walked away from.

Congratulations Mozilla!