Monday, December 6, 2010

Hobo: Play play play, edit edit edit, do stuff...

So, I'm about ready to do something grounded with the Hobo/Heroku/Git/RubyOnRails/Rails technology stack.

One of the really sad things about the present state of Web technology, is the amount of preliminary technology stack setup that has to go on just in order to get to the starting position. That's another series of posts right there, but I digress.

A cool thing about OSX is that it allows terminal sessions to be pre-configured to launch commands, then bundled into groups, so I can launch (a) a regular command window in which to run shell commands or rails consoles (b) a terminal in which to run the development server (c) a terminal in which to run Jasmine (d) a terminal in which to run rake, rspec, steak, cucumber, etcetera and (e) a MacVim with NerdTree; and have them all pre-configured with the right shell, Ruby, and Gems.   A featherweight setup for development of a specific application can be configured within a few minutes and launched with one click. But again, I digress.

Start up the server for Leapercan; oops -- my other logged in user has a Rails 3 app running on port 3000 -- need to use -p option to make this one run on, Idunno, port 3030.

/script/server -p 3030

Huh. MySQL gives an error:

Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

OK, this isn't the first time MySQL has gone AWOL under OSX. I'm still wondering why this is happening. Workaround seems to be: ps -ef|grep mysql to get the PID of the MySQL server, then kill $PID or kill -9 $PID to force the service to start a new process. Of course, MySQL has been installed to load automatically as a process upon boot, and to restart if it is ever killed. Killing the MySQL process works.

Ah, but alas, now it is really late, and I've got to pause again. Perhaps the next thing I'll do is create a questionnaire application -- something to play out 25 questions or so in order, and capture the results in a simple table. I'll use a one-time-pad to provide some measure of scope of access, to limit the visibility of the questionnaires to just those who should be authorized to fill one out.

I'll also need a time-limited list of authorizations -- basically just a mapping of user identities to scope identifiers.  Both elements of the mapping could be opaque, but the user identities should be supplied externally. The idea here is that an institutional user should be able to load up a list of authorizations for a one-time use.

Another aspect of the system: the user interface should be Web based and targeted toward mobile platforms, particularly the iPhone/iPad/iPod Touch or similar Android devices. It should not give any special consideration toward working on an IE browser or any other insecure platforms.

No comments: