Sakai Programmer Jobs at Yale

Yale University has two new programmer positions in their Academic Media & Technology unit. The focus of these positions is the development of
teaching and learning tools that integrate with Yale's Sakai-based learning management system Classes*v2.

Details for the positions are available online.

You can also contact the hiring manager Michael Appleby

As posted by Chuck Powell to the Sakai Announcements email list.

Yale's a really neat place to work and New Haven an awesome place to live.

On the use of Hibernate

Someone asked me today whether uPortal uses Hibernate. Per my preferred approach of being as open as possible about as much as possible, this is mostly what I said:

No version of uPortal 2.x uses Hibernate for anything and therefore no uPortal 2.x release of any flavor includes it.

The quickstart (and the slowstart) versions of uPortal 2.x for as long as I can remember ship with and use by default HSQLDB, an in-memory database, for demonstration purposes.

A pain point in uPortal 2.x is its *not* using an ORM framework like Hibernate and therefore its baking-in of hard coded SQL statements. It does some heroics to provide a general XML language for describing the desired initial schema and data content of the database and to provision that database. There are advanced features for upgrading the database automatically.

Frankly, this is the kind of academic brilliance that is both uPortal's strength and its curse. I wouldn't trust these advanced upgrade facilities without paying a whole lot of attention to the log of what they did, and with that amount of attention I can just perform schema updates manually.

A fine alternative to automating the schema and database update process is to carefully craft upgrade SQL scripts for each supported platform. The schemas don't change enough for this to be prohibitive, and when they do change, it's worth being very sure and careful about that change. You're typically supporting uPortal on a few (one?) very specific platforms through a few very specific upgrades.

In any case, in uPortal the DBLoader functionality handles cross-database initial provisioning, and adding another supported database for initial provisioning is not hard.


At runtime, uPortal also does some heroics to flavor-test the underlying database and to choose SQL syntax -- join syntax and the like -- and in some places outright chooses among multiple available SQL statements to work in whatever RDBMs we're running against.

This pain point is real -- if you point it to another database, it probably won't work until you go adjust the SQL -- and yet it is one that I think is greatly overstated. The introduction of DAOs and a wiring framework to choose DAOs that fit with the chosen database is an excellent architectural step forward and would allow the framework itself to support wiring in different DAO impls where that non-lowest-common-denominator-SQL really is buying something.

However, doing this for uPortal 2 would not be hard and would be valuable. It might not look very pretty especially first off. First off we do something awful like externalize the SQL and let people swap properties files. This fixes the problem at the expense of locality -- I'm convinced by the points in Rod Johnson's book on this topic. So the next step would be to re-embed the SQL in DAO implementations that are generic or specific and multiple as necessary. And adopt Spring as the sane wiring mechanism to choose among these.

We're still not talking an insurmountable work, but there we have a solution wherein you can rapidly follow a recipe to choose the impls specific to your database yet replace any given impl. If you've invested in an Oracle database and want to get actual value out of that massive investment by composing stored procedures and views and the like, this is how you do that.



uPortal 3 adopts Hibernate, behind Spring-wired DAOs so that you could still replace any given hibernate-implemented DAO with an RDBMS-specific DAO implementing institution-local data access behaviors, such as accessing that expensive database's stored procedures. It still uses Dbloader-improved functionality for seeding the database. Hibernate solves the cross-platform data access problem.

uPortal 3 also introduces a comprehensive caching layer wherein almost all DAOs are fronted by "Registries" that implement caching, such that many queries will not hit the database. Ideally all caching occurs at this layer and fronting code always consults the Registry, solving another pain point of updated data not being reflected in some places in uPortal 2 without a restart. (Under the uP3 approach, just flush the registry using a convenient administrative portlet).

Unicon Wins Campus Technology Magazine's 2006 Innovator Award

Hurray! Unicon won Campus Technology's 2006 Innovator Award!

On Googleability and Hyperlinkability

This is something I wrote some time ago when I was at Yale University's Technology and Planning group. Note that gmane has addressed some of my concerns.


The Sakai Communications Working Group recently polled a list I'm on for feedback about the tools in support of collaborating on Sakai. This is what I had to say:

Please contact the Sakai Communications WG at sakai-comm@collab.sakaiproject.org with any comments. Thanks in advance for any feedback.

Most importantly, we want to know how you use the current collaborative tools available to the Sakai community (Confluence, Jira, SakaiCollab, Project MatchmakingTool, etc.) What do you like or dislike about the current format? What is the most important feature for you in collaborating with others?

My comments are specifically about googleability and hyperlinkability as important features in collaboration software in support of Sakai-related work.

Email archives within Sakai currently lack several key features. Firstly, the archives are not Google-indexable. This means that content on otherwise public lists (such as sakai-user, sakai-dev, sepp-ent, etc.) to which anyone can subscribe and which anyone can browse by creating an account on collab.sakaiproject.org are not searchable via a generic web search, e.g. from www.google.com.

Secondly (and technically related), these archives are not hyperlinkable. I can't (or at least, I don't see how to) produce a hyperlink that will take you directly to an archived message.

The combination of not having these two features makes Sakai email archives less valuable than they might otherwise be.

Other list archival software has these features.

1. JA-SIG uPortal developer list archives


2. CAS user list archives

It would be an improvement for the public Sakai email lists to have archives with these features. This can probably be accomplished as a supplemental email archive driven by an archival user / email address subscribed to the lists.

The advantages of Googleability and hyperlinkability of email archives is that the conversations on the email lists can later be used with minimum additional effort to answer questions on list (Your question was answered in this email thread) or to avoid questions needing to be brought up on list again, because answers are found via Google searches.

Making conversations on the email lists transparently and automatically made Googleable and hyperlinkable frees the harvesting of information from the list archives into places like the SakaiPedia to be more of an adding-value effort of organizing and refining the product of discussions on the list, and less of a required effort to make content Googleable and hyperlinkable.

Using Sakai Resources as the mechanism whereby PDFs, Word documents, Powerpoints, and other documents are distributed does currently offer hyperlinkability.

This link will take you to a particular Minutes of the SEPP-Enterprise working group:

A minutes of the SEPP-Enterprise working group

However, such links do not often become Google indexed.

Contrastingly, placing documents in a publicly-accessible Apache folder, for instance, does make them available for Google indexing:

Dr. Chuck's talks

A powerpoint from among Dr. Chuck's talks

I'd suggest that publicly available documents used for Sakai collaboration that are currently stored as archived attachments to email messages, as Resources in the collab.sakaiproject.org Sakai instance, as attachments to Wiki pages, would ideally be presented at URLs such that Google is able to index them and they can be included in Google search results. This gets maximum value out of a document-production investment.

One way to go about achieving this would be to make Sakai able to produce Apache-like directory indexes of content.

http://collab.sakaiproject.org/access/content/ 

Would produce a directory-index-like list of links to corresponding to sites with publicly available content. Those links might look something like this:

http://collab.sakaiproject.org/access/content/group/1103227538796-57571/ 

and would produce a directory-index-like list of links to folders of content, the content tree, ultimately providing links to actual entries.

Google's entry point becomes

http://collab.sakaiproject.org/access/content/ 

from which it can find and index all the publicly-available content.

In general it's important that as much content as possible is available without logging in, at URLs that Google can find, follow, and index, and that can be bookmarked, shared.

Our goal is a simple way to access and learn about existing projects, to start development on new projects, and to disseminate information to the community. This environment will give the public a straightforward way to browse existing Sakai tools and participate in tool and/or core development. Our goal is to have a board approved tool and model by December the latest.

Best wishes in this endeavor. I hope these comments will help inform the effort.

JA-SIG favorably mentioned in Campus Technology

JA-SIG was favorably mentioned in Campus Technology magazine.

For colleges and universities interested in learning more about open source, fear not: There is an organization to help. It is JA-SIG, an international consortium of higher education institutions focused on promoting and sponsoring open source projects that serve colleges and universities...