Over the weekend I was writing some code in Google AppEngine and had a need to loop through all of the incoming request parameters so automatically update the contents of a model when there were request parameters which had the same name as the model attributes.

When I wrote the very first version of the AE chapters for the class – I had this bit about dumping parameters in one chapter. In the rewrite to send the book to O’Reilly, I felt that this detail was too much so I cut it out about a month ago. I also cleaned up old copies of the chapter on my hard drive and on the appenginelearn.com site.

So on Saturday, I am sitting here peeved that I had this all figured out once and had even written it up once – exactly what I wanted – and then lost it.

I figured that I had researched this once before – so I could figure it out again. I remember that there was no real documentation and I had to write stuff like dir() to hunt through methods. It was painful but I figured I could do it in an hour.

So I typed the following into Google:

appengine looping through request variables

I looked at the text of the second hit and it looked promising. Then I noticed the word “Michigan” in the text and then I noticed that it was *my chapter*. The lost chapter. So I clicked on the link (the PDF) and scrolled down and had my answer in about 45 seconds!

I had forgotten to remove the copy on my Michigan personal AFS space – which I had used while teaching the class – Google had found it, indexed it and knew *somehow* that it was what I needed.

Sweet!

Continue reading →

On Jan 9, 2009, at 10:02 AM, Clay Fenlason wrote:
You’ve recoiled a bit from the negative formulation of my post, and
I’m afraid this has led you to react against a position in which I
can’t recognize a view I actually hold. You may be making a good
argument against someone; I just don’t know who that person is. Some
of that I’ll blame on my own proclivities: a critical frame of mind,
and a tendency to find bracing clarity in starker terms.
——-
I think that you hit the nail on the head. I agree that we can and should talk about a lot of things and always be looking for ways to improve. However – the length of your note, the fact that you were tying a lot of threads together, and seeming to move toward a pretty significant conclusion – it started to sound like a “plan” rather than a discussion. So I reacted and said “no” to the plan that your note kind of laid out.
The part of your note I like the best is the notion that the future in 5-6 years in the use of technology for teaching and learning might be quite different than today – and the development environment might be very different – and indeed by that time – things like the Sakai Kernel might emerge and be broadly available in such a way to make building tools light and fun – and it will work *really* well – and we will have a zillion new ways to teach.
Frankly I have been pushing this and writing about this for years – so I like the notion of thinking about what Sakai 4 might look like – and enjoyed reading that bit of your note.
If Sakai 4 ends up being built on some glorious framework that we don’t have to build – that framework will not likely come from Kuali or Spring – or frankly any of the patterns we are used to seeing and using. The Google AppEnine is the closest thing to such a nirvana – it is a framework – it is a kernel – software and hardware magically scale somewhere in the cloud – we write little widgets and mash them up.
Part of my comments on Sakai 3 suggest that we are not thinking about a few issues of hyper scalability needed to go 4akai. I got these ideas as AppEngine sinks into my conciousness:
http://www.dr-chuck.com/csev-blog/000578.html
Perhaps my ideas of sharding and read-only replication are before their time for 3akai – I accept that in time a wise crowd will see and do the right thing – and do it at the right time.
Google AppEngine is likely to see competitors in the next 2-3 years from Microsoft and Yahoo – and perhaps while AE may not be the be-all and end-all – as the market for cloud services matures – I bet things will turn out pretty nicely and support the model you propose. And as you suggest – at that point “Sakai” will be a “different thing” – the cool thing is that we will likely still be a bunch of great people working together around teaching and learning.
And by then, we might be the #1 vendor across both the commercial and non-commercial sector. Not by our clever project management – but instead because we simply out-innovate everyone else by experimenting with everything at the same time.
Just as some experiments, I wrote a book on Google AppEngine that will be published by O’Reilly (www.appenginelearn.com) and have an independent study course with seven graduate students experimenting with building learning tools using IMS Tools Interoperability and Google AppEngine and seeing how these things mash up. Of course since Sakai already has superb support for IMS Learning Tools Interoperability and it is in production at UM, these tools can be dropped into a course in the middle of the semester or even the middle of a weekend.
The first tool I will be writing in this new environment will be a “Wisdom of Crowds” tool so I can do live experiments in my classes to demonstrate that wise crowds are smarter than wise individuals. I need it to be written and in production and deployed into CTools by Wednesday morning.
/Chuck

Now that the first day of class is over, I have a few minutes to respond to Clay’s recent advocacy post. To me there are several themes in the post that I want to react to. Clay implies:
– Things are not working so well in the Sakai community – so we should think outside the box and entertain the notion of radically different approaches to how we do things.
– It seems as though our coordination is not working so well – we just can’t seem to muster enough resources to accomplish board initiatives in a timely manner. So perhaps we need a different form of government – perhaps more like Kuali where the Kuali Board (or sub-boards) *own* resources.
– Since we are not so good at board initiatives, perhaps we should outsource the Kernel work to a better organized group like Kuali Rice or Spring and focus on making really cool widgets on the Rice infrastructure.
I will respond to each in turn. (Note: I revised the following text a bit to back off where I oversimplified some things too much.)

Continue reading →

This blog post got it so my experimental learning application tweets. Uh – this was amazingly easy.
http://woork.blogspot.com/2007/10/twitter-send-message-from-php-page.html.
It s no wonder that Twitter has performance issues. With such a clean, simple, and elegant API – virtually anyone can build Twitter into their application. And with a little help from Antionio Lupetti.

Well I have totally tricked-out my Sakai course sites for this semester using the new “htmlInclude” feature in Sakai! Last semester, I used I used Sakai’s pseudo-hierarchy feature to link my main course sites to the Discussion sites for each GSI (Grad Student Instructor). Now I have added real-time chat from hab.la. I am making use of a new feature SAK-15097 – the ability to add HTML in to a background document.
So I added hab.la’s JavaScript based chat to my course sites so students can find me and talk live to me. Hab.la augments presence and allows the instructor to be as available as they want to be to their class – without adding the whole class to their buddy list. Here is how it looks to the student:

The chat window appears when you come to the site. If the instructor is available you can chat live with the instructor without leaving the site – you can even navigate between pages in the site and keep the chat up. The instructor actually sees as the student moves between pages (it would be nice if Sakai had more rest like URLs :) ).
You also can see the hierarchy bit as the SI502 staff is a sub-site under SI502.
This is a really cool feature and my guess is hab.la is just the beginning – you could google analytics or really any widget that was smart enough to float over top of content.
The feature is in trunk but missed the 2.6 freeze. There is a 2-5-x patch in the JIRA – this is what is running at Michigan in production. I think that it should go into the 2-5-x branch and into the 2-6-x branch – it is a safe, simple patch with no performance impact – and it uses a site property (sakai:htmlInclude) – so unless you set the property, the UI is completely unaffected.
I am working with the folks who own hab.la to experiment with better integration with Sakai – so you could see the course and user name. I am also talking with the hab.la folks to see if they might sell a school a dedicated hab.la server so the data did not have to leave the schools “owned” servers – if a school wanted to deploy this on a large scale.
I need a big thank you to John and Matt and the folks at UM who got this into the UM production so I could play this semester – I owe you folks a beer.
If you have any questions or interest – let me know.

I was asked recently by a friend to summarize some of my approaches to teaching. Like most situations when I am asked a question I really like – I probably wrote too much. Here is my response.
Technology as

I have been chained to a keyboard for most of December so I could finish the first draft of my AppEngine book before the next semester starts. So I left this on the back burner for a while. But now I am catching up.
I really like the Sakai 3 Proposal. The document does a good job of pointing out weaknesses in the current architecture and approach and lays out a good plan for addressing those weaknesses building out on the Kernel 1, Kernel 2, and the UX work to produce Sakai 3.
I also am really impressed as I played with the prototype server. The widget environment was quite nice and the new UX work is very solid – I particularly like the blend of the old and the new. I really liked how the “old tools” were given the entire width of the screen – this is something that I tried to introduce into 2.x but there was no interest. I think the future of LMS UI is to have the LMS take less and less of the screen when the students are doing their learning. We are at a point where folks *know* how to use an LMS so we don’t need to waste 1/3 of the pixels with the LMS UI drawing attention to itself and its features.
Just one funny example of how cool the UI is: I was not happy with the tool menu on the right side of the screen – I figured moving the menu from left to right was look/feel fluff that reduced usability – after using it for a while and grumping to myself – I just decided to see if I could drag it to the right – and of course I could!. I also was a bit concerned because the front page had a social gadget on it – while I like social features – it seemed that using 20% of the main dashboard for the social bits was too much – then I realized that this was just a sample – and poof! The social gadget was gone. Flexibility is *sooo nice*.
Technically – I love the switch to Jackrabbit as Content. I love rethinking Authorization influenced by Bodington. I love the notion that groups are a first class citizen and not part of a site. Sites are cool and need to be retained – but not as the container for everything else. It is better to think of pages and nodes and “nexuses” and let we teachers add site-semantics to those places we conceive as a site. Hierarchy from the get go is a big win.
The Sakai 3 Vision document clearly shows that it is based on a careful analysis of the strengths and weaknesses of Sakai 2. It is not just complaining about the shortcomings of Sakai 2 – it is providing the solutions to those shortcomings.
So overall I love it and am very confident that it will be successful in time. As one of the folks who conceived and executed Sakai 2 – and then had to live with the consequences of early decisions for a long time – I do have a few comments and suggestions to the 3akai team in terms of approach.

Continue reading →