Friday, January 23, 2009

Munich soon

I'll be in Munich for a few days, riding my wife's coat-heels to the Digital, Life, Design (DLD) conference. I'm really looking forward to it! This conference precedes the World Economic Forum's annual meeting in Davos. I've been hearing about DLD for a few years now and frankly the DLD looks to be filled with more of my kind of people ;)

I've never been to Munich; perhaps the airport once or twice. Does the Lazy Web have any suggestions for Casey's Munich wanderings?

I have a waterproof GPS loaded with data and good boots!

Wednesday, January 21, 2009

pondering WebappToolServlet

In my intermittent work on the Sakai tool side, using the Eclipse Sakai plugin, I have seen references to WebappToolServlet in the generated web.xml.

Clearly it's the first stage in handling requests. Stuff worked so I haven't worried about it. However I poked around a bit and found this:

WebappToolServlet is a CARET invention (pace Andrew Thornton)
that was created to allow other Java view technologies than JSF
to work in the Sakai dispatching environment.
[snip - about going to conferences where all this is discussed - casey]
Without WebappToolServlet the context path part of the URL will
be mapped incorrectly, as well as various other parts of the
request object being empty. This correction cannot be made with
a simple filter, since on initial entry to the context there is
no valid URL.
Yes, Spring is meant to avoid all dependence on the container, but
this is plain JSPs here. This is no kind of supported option in
Sakai - you are basically "on your own" - although I'm
sure the few folks that have done JSP work in Sakai (Andy, Ian)
will be glad to help you out.
The supported/recommended option in Sakai until now has been JSF,
which is what the dispatching environment was designed for.
We are expecting a transition to RSF underway over these few
months.
The most direct step towards sanity you could take if you insist
on sticking with JSPs is to move to SpringMVC. This defines
various taglibs that should let you resolve beans as variables.
As a "framework" it's pretty useless however (naturally I would
say that...)


whcih explains enough for me. Since I just want to use something to bootstrap the GWT stuff and move forward I'll no longer ponder WebappToolServlet.

DayOfService-2009-01-19

The crew stretches down behind the point where this picture was taken.

DayOfService-2009-01-19 14-21-47

Joining the Planters doing restoration in Golden Gate National Park.

Monday, January 19, 2009

Day of Service

Today I met up with a couple hundred strangers and worked on restoring native plants to some CA shoreline.

Lucky for us it was a drop-dead robin's egg blue sunny day. Up on the bluffs above the Pacific Ocean in January can be a deeply chilling experience.

I took a polaski and trenched ahead of Mitchell and Jarett. Mitchell had a rock pick and cleaned up my work. Jarett also had a rock pick and knocked the seedlings out of their container and finished up.

The organizers, rangers and volunteers from the National Park Service, had laid out rows and rows of seedlings. This allowed all the newbies to simply 'plow along' the hillsides and get the plants in.

It felt great to do this. I always have enjoyed volunteer trail work. I guess it reminds me of my childhood doing in-voluntary trail / field / woods / farm work. What a pathetic romatic I am.

Jarett and I have agreed that if we stop at Peets after our Saturday trips to our respective gyms we can dash out and join this crew for their afternoon sessions. This is a sneaky way for dad to get his kiddo used to miserable outdoor adventures.

Wednesday, January 14, 2009

A bit of GWT in Sakai - StringReverser


StringReverser
Originally uploaded by badubadu
Here is a screen shot of the StringReverser Hello World tutorial wrapped up in Sakai via the Sakai App Generator and some wrangling.

GWT in Sakai, Hello World.

You may recall that I totally mongled the back deployment of the IPBUserManager. What I didn't mention is that I also hand built another Sakai tool but had all the useual grief with tool registration and all that miserable stuff and tried to merge the IPBUserManager GWT stuff in there. But Sakai's kung-foo was too powerful for me.

Punt!

I used the Sakai App generator to get a skeleton of an app. I should of used this in the first place. I generated a JSP "hellow world" app - all I wanted to do was to get a tool in place at this first step. And I want the tool to present a web page containing the GWT Application, for Sakai to serve up unto that web page all the GWT bits, and for those to make their way back to a servlet .

Aaron's plug-in slams out the framework.

So I dug up a clear GWT example from somewhere. I had been plowing through GWT In Action but had found the sequence of that book awkward.

Exactly, where?

http://developerlife.com/tutorials/?p=125, which is titled "Building a GWT RPC Service." It was a clear and easy to follow mini-tutorial.

then it was mixing and munging.

I copied the String Reverser bits into the generated Sakai app directory. The various GWT generated cache bits in the web-inf directory, the client, public and server directuries under the web-inf/classes directory, etc.

I hacked up the generated app's web.xml
  1. to include the references to the tutorial's StringReverser servlet.
  2. to use the tutorials StringReverser.html as welcome-file
I had a couple of typos and all that, but hey.

This manual wonkery worked.




I'll now see what I can do to make it useful. One of the more useful things will be to make the canonical Sakai User Directory Service call, which we see in many Hello Sakai apps.

GWT in Sakai, onward!

After thoroughly confusing myself with the the IPBUserManager Sakai 2.5 example I decided to relax a bit and reset.

After ensuring that I had Aaron's Eclipse Sakai App Generator plugin I went up to the kitchen.

I pulled out my handy Santoku and a larger knife we call "the Angel of Cut." Learning to use these knives I picked up many small cuts, so it's well named.

There I frenched some lamb ribs and rubbed them with a garlic and curry like dry mix. These were set aside atop the kitchen Mac mini to come up to room temperature.

I grabbed a big bag of Russian fingerling potatoes and another bag of carrots and proceeded to scrubbing. Scrubbing needs music so I put on "Pioneers who got scalped" by Devo. After all that's how they day went, eh? After cleaning up the rooties I tossed them in the nuke to pre-cook them a bit. As the floor and kitchen counter was soaked with water I went with the flow, cleaning and prepping a green salad by mixing in some julienned green onions and some great cherry tomatoes. The Angel of Cut came into play and I took apart some sweet red onions into large chunks.

More carrots were tossed into a blender with some ginger and left over chicken-vegi broth for a soup. Just keep the blender running and toss your veggie scraps in. Your guests will never know.

The nuked rooties were pulled out. I got a big jar of olive oil and some rock salt and lightly coated the rooties. The deal is to use the rocky salt; it'll help keep in the moisture for the next step. Don't go crazy with it tho! I tossed in the onion chunks. I did not wear a diving mask, BTW, nor did I listen to polka during this step. Thyme is also driftled across the mix.

Then I grabbed a Full Sail Ale from the fridge and set the oven to 500F. This is pretty hot, but don't be afraid of it or you will burn yourself. The racks go all the way down. I also checked in on the carrot/ginger soup. As it got up to speed I spread the rooties'n'onions in a pyrex baking dish thingy and put the lamb on a rack on top. I left a little fat on the back of these, and the fat points up. The deal with this is that the lamb juices will be injected into the underlying rooties, which are depending on them for flavor.

Jeez I forgot about the child creature! I nabbed some fish-sticks and some alpha tots from the freezer. These went on a baking tray on the bottom most shelf. The veggis and lamb go on the next shelf up.

Cook the mass for about 15 or 20 minutes. The fish sticks and such have to be watched as they are being cooked at a higher temperature than their instructions call for. Smoke is a good indicator of overcooking.

Nuke your plates and bowls to heat them ( it's too hot in the oven, remember? ) and serve the soup. You may want to put some Balsamatic viniger on the top of the soup, but that's pretty frooey.

Accompany with Veuve Clicquot Ponsardin and have at it.

After being thusly fortified return to work!

Open Syllubys Guys! come back!

Hey Open Syllabus Guys - you posted a great and exciting comment which, as I was reading, I accidentally in my great excitement deleted! ARG.

The core of your comment was that your team was thinking, or doing, a flesh out of the HelloWorld example. Apparently you have a spike?!

If you come on back and re-comment I will go away and get a cup of coffee to help ensure that I don't erase your comment next time.

> how embarrassing <

sorry!

Monday, January 12, 2009

Let's see about this GWT in Sakai stuff

Now that I have the SOPI Swing app talking nicely to Sakai I need to build a Sakai tool for setting some site properties and monitoring student progress.

Being more of a on the server and in the plumbing type of guy I don't have tons of experience with modern front end technologies.

This give me a chance to investigate GWT in Sakai.

I'm starting off with that interesting post from Luis of last year ( http://www.nabble.com/Re:-GWT-Sakai-Development-p16124688.html ) and starting from there. I need a hello-world for Sakai / GWT / Eclipse and I have concluded that the OpenSyllabus folks are too busy to finish up the one they started in the Sakai Confluence area. The Davis folks are apparently plunging along but no cycles have been spared for more than a few tasty public postings.

off I go!

1) get gwt - http://code.google.com/webtoolkit/download.html I expand this and drop in in my development area. I kick the mail sample. it just works. love this just workingness. but heck the app engines just about just worked too.

2) Oh I better get Luis' IPBUserManager dealy. Use the Nabble link above. I expand this and put it into my Sakai Eclipse workspace, and then import it into Eclipse. Of course it's a bit confused.

2.1) As Luis described in his email the include-sakai directory is empty in his package. He did us all a favor by not populating it and attaching such a giant wad to his email. A WHAT_WAS_HERE.txt file explains the deal. As I'm developing against Sakai 2.4.x I'll have to wing it on the various M2 versions. So I get busy updating the include-sakai directory based on the shopping list. I do this by ransacking my local maven repo and populating the IPBUserManager's include-sakai directory.

2.2) don't forget to update Luis' (it's easier to type Luis than IPBUserManager) build.xml. You'll need to update locations to reflect where you've dumped the GWT and to update the platform info to reflect your development platform. For example Luis is using Linux, so his gwt.dev.jar is gwt-dev-linux, right? swap it for whatever platform specific value you need.

2.2.1) the Ant I'm dorking around with on this G5 isn't wired up to use the tomcat administration bits, so I comment those out.

2.3) compile the bits, package as a .war, and drop into my dev instance of Sakai. Let's see what we get. I fire up the VPN, restart the sakai, and wait...a while. This isn't the fastest way to work with sakai - a VPN'ed database out through DSL. snore. Then I make a mistake of clicking on a course site which must be an old load testing site - it has scads of users and so it starts off doing scads of LDAP and Kerberos lookups! oops. I pick another site, go to Site Info -> Tools and find the IBP User Manager tool. nicely.

2.3.1) Ok I have it now in a page in a course Site. I get a big exception when I go to actually use it. the exception is from the portal, and it's throwing a NPE. OK I probably missed a step or a dependancy.

org.sakaiproject.portal.api.PortalHandlerException: java.lang.NullPointerException
at org.sakaiproject.portal.charon.SkinnableCharonPortal.doGet(SkinnableCharonPortal.java:718)
caused by: java.lang.NullPointerException
at org.sakaiproject.tool.impl.ActiveToolComponent$MyActiveTool.forward(ActiveToolComponent.java:441)
at org.sakaiproject.portal.charon.SkinnableCharonPortal.forwardTool(SkinnableCharonPortal.java:1099)
at org.sakaiproject.portal.charon.handlers.ToolHandler.doTool(ToolHandler.java:163)
at org.sakaiproject.portal.charon.handlers.ToolHandler.doGet(ToolHandler.java:86)

The portal isn't having much fun getting the tool placement together.

I wonder if this only works with Spring 2.0? Because I also see that org/springframework/web/HttpRequestHandler is missing. I don't think that was part of spring 1.2.8, which is the Spring in this Sakai.

That's got to be it; I bet this example works in Sakai 2.5 or a Sakai 2.4.x which has been mutated to use Spring 2.0.x.

Time for lunch and then I'll be back at this! I'll just dork up the dispatching.


3) Luis mentions a plugin from Cypal. I think Thomas has mentioned it as well. While I know this won't help with my Placement problem I go off and get that: http://code.google.com/p/cypal-studio/downloads/list with documentation: http://www.cypal.in/studiodocs

Monday, January 5, 2009

a great break...

This has been a very relaxing holiday break.

I don't think I turned on a computer other than to check weather (skiing / biking / hiking / gardening-hillside erosion control), photography, gaming with kiddo, or to chat with friends far and wide.

Nicely.

Infact I'm going to head out for more skiing tomorrow! bwa-ha-ha-ha!

But for now I will return to my Java / Quicktime /XP problem - why, sometimes, does Java grab all the available disk space when creating temp files? I've only seen this in XP, but it's a machine killer. XP hates having all of its spare disk space eaten up.

The file is finally saved to a normal size at the end of the processing, when I close the file - if the XP box lasts that long.

As this is an intermittant problem it's really freeking >pesky< to deal with.

So today I'll investigate various hacky gymnastics. such opening and immediatly closing, and then reopening the temp file. or not using the temp file libraries when in XP... or in creating a virtual disk for the temp file (!?) of a constrained size. madness.

later - from http://lists.apple.com/archives/QuickTime-java/2007/Aug/msg00001.html

Thanks very much, Jeremy, adding those flags (especially the UNDOCUMENTED seqGrabDontPreAllocateFileSize
constant) seems to have resolved the huge file issue. That's a big relief for me.

I of course scoured the web and StdConstants files looking for something that suppresses the pre allocation of the file, and a constant with a name like that would have jumped out at me. I'm sure other people have done ths same thing. Hey, QT Engineering: how much engineering and QA effort does it take to define a new constant?

Thanks again, Jeremy!

-Michael



great gizzards. I have to second this Michael's suggestion to the QT team.