Long Time No Blog

To anyone who missed out on uPortal thoughts being posted here over the last month, I apologize. I've been creating content on Unicon's new support website and so have been distracted from keeping this space up to date. I do appreciate Blogspot's hosting blogs here at Blogger/Blogspot, and I suspect someday I'll be back here blogging along, but now I'm trying to draw eyeballs to Unicon's exciting new support website, so my blogging is currently happening there.

Here are some teasers for recent blog posts available on the new site:

• I start with the obligatory meta-discussion of blogging and of the new website. (It's interesting, my cube-mate on the Sakai side of things dived right in with discussion of term-based site filtering in Sakai. I'm occasionally accused of being insufficiently technical and there's probably some truth to it.)


• I've started a series of blog posts on favorite uPortal features. So far I've covered addressing channels by functional name and pluggable error channel rendering.


• There is a post discussing the provisioning and use of channel controls.


• Another post motivates why your campus desperately needs a portal anyway.


• And CWebProxy is a favorite uPortal feature in a class all its own, so it rated its own blog post.

Please, drop by, read what you may find useful, and feel free to avail yourself of the commenting feature to let me know what you think, tell me to be more technical, or more generally guide what kind of posts would be welcome.

A New Level of Unicon Coolness

Yesterday, my employer attained a new level of coolness: Unicon has posted a position on jobs.joelonsoftware.com. You should check it out and think about applying.

Programmer/Analyst Position at JHU Libraries

What follows is a copy and paste from a post on jasig-portal.

Johns Hopkins Sheridan Libraries is looking for a Java Programmer; what follows is copy and paste from the job requisition:

The Sheridan Libraries at Johns Hopkins works on several, leading edge digital library initiatives, with content ranging from astronomy to sheet music, and application work that encompasses e-publishing and e-learning systems such as Sakai. This programmer would play an integral role in supporting these digital initiatives, and enabling new projects and activities.

General Description: The Sheridan Libraries at Johns Hopkins
University is seeking a motivated, energetic, results-oriented individual to join the Library Digital Programs (LDP) as a Programmer/Analyst. In response to requirements and policies that focus on user needs, the LDP leads the technical development of an institutional repository that represents the foundation for digital library collections, services and infrastructure that support learning, research, scholarly communication and preservation. The Programmer/Analyst will work on the Libraries’ repository application implementations (initially, DSpace and Fedora), administer the repository’s cocoon and/or tomcat architectures, build interfaces both to enable end user access and to integrate systems (e.g., modify an application to work with a repository).

Work is complex and varied in nature. Defines and discerns key aspects of a problem and develops an integrated solution within a broad technical and business context. May provide guidance/training to more junior staff; Advise supervisor of priorities and proposed solutions; Designs and writes programs to support activities of the institutional repository; Applies system analysis techniques and procedures to determine software and system functional and technical specifications; Analyzes, designs, develops/maintains, documents, and tests new or existing programs based on approved functional and technical system design specifications; Performs complex, intricate and important programming tasks; creates and/or modifies, and tests computer systems or programs; Uses programming knowledge and critical thinking to evaluate and resolve technical or procedural problems within the scope of assigned tasks; Develops, or reviews, technical documentation, recommends product fixes and enhancements (e.g., source code comments, wiki updates).

The Sheridan Libraries encompass the Milton S. Eisenhower Library and its collections at the John Work Garrett Library, the George Peabody Library, and the Albert D. Hutzler Undergraduate Reading Room. Its primary constituency is the students and faculty in the schools of Arts & Sciences, Engineering, and Professional Studies in Business & Education. A key partner in the academic enterprise, the library is a leader in the innovative application of information technology and has implemented notable diversity and organizational development programs.
The Sheridan Libraries are strongly committed to diversity. A strategic goal of the Libraries is to "work toward achieving diversity when recruiting new and promoting existing staff." The Libraries prize initiative, creativity, professionalism, and teamwork.

Qualifications: Bachelor's degree in Computer Science, Engineering,
Information Science, Library Science or related field. Three or more years of significant development experience in an object oriented development environment such as Java. Additional experience may be substituted for education. Experience with repository software (such as DSpace of Fedora). Understanding of Java application frameworks (e.g., Spring, EJB3), Java servlet container or application server environments (e.g., Apache Tomcat, JBoss). Experience with XML programming in Java.
Experience with OR/M persistence technology such as Hibernate.
Experience with source control management. Demonstrated experience with the Unix operating system and environment and multiple programming languages. Demonstrated proficiency using Java to parse XML either using JAXP or binding/serialization frameworks such as XStream, JAXB, etc.
Strong analytical and problem solving skills with the ability to evaluate options, develop and recommend solutions. Ability to work independently and creatively within a collaborative, dynamic environment. Excellent oral and written communication skills and interpersonal skills.

Preferred Qualifications: Master’s degree in Computer Science,
Engineering, Information Science, Library Science or related field.
Experience with IT in a higher education environment. Experience with Java build tools such as Maven or Ant. Ability to work in an API environment and experience with SOAP and/or REST. Experience with information retrieval technologies (e.g., Lucene), and programming best practices, including design patterns and unit test development.
Experience evaluating new technologies and developing functional requirements through use case analysis. Familiarity with metadata formats (e.g., Dublin Core, METS). Ability to communicate with technical and non-technical individuals, including the ability to prepare project documentation to support training and best practices.

NOTE: The successful candidate(s) for this position will be subject to a pre-employment background check.

Tucson JUG

I drove down to Tucson this evening to attend the Tucson JUG holiday dinner at Feast. The food and company were excellent. I may have to find time to head down to Tucson each second Tuesday.

Wanted: uPortal and/or Sakai developer

My employer is hiring for a uPortal/Sakai developer position. If you are a uPortal or Sakai developer, take a look at the job posting.

Compelling Unauthenticated uPortal guest layouts

I've posted the PowerPoint slides from my JA-SIG Atlanta 2006 talk on compelling unauthenticated uPortal user experiences. I took some pains to thoroughly annotate each slide, and I hope this results in their being more helpful to folks who couldn't make it to the conference.

Browsing Available Maven Artifacts

Instead of browsing ibiblio directly, you can use a pretty good web tool for this.

Jason Shao's Identity Management Presentation at JA-SIG Atlanta 2006

Jason's presentation was excellent. I particularly noticed

• The presentation was well-connected with and included a lot of real experience


• The slides were absolutely excellent. Crisp, clean, minimalist, and very effective. Pacing was impressive, kept a feeling of momentum.

IChannel or JSR-168

(Reposted, edited, from something I wrote on the jasig-portal list).

Should I write an IChannel or a JSR-168 portlet?

You should do whatever makes the most sense for whatever it is you're trying
to accomplish. Which is a fairly generic meaningless thing to say, but I
think it's the truth.

If you care about cross-portal, if you're building the portlet to end all
portlets and you want to run it anywhere, if you want to run it in uPortal
3, if you're building something sufficiently generic that you'll want to
share it with or collaborate on it with folks using other portals, if you're
looking to use JSP or some other templating technology other than XSLT, if
you're looking to maximize the re-usability and value of your learning
investment, or if you're looking to take advantage of an excellent MVC
framework (Spring PortletMVC), then JSR-168 can be a good choice.

If you're writing a quick one-off, a throwaway channel, something that will
run afoul of known uPortal JSR-168 support eccentricities (bugs?), then
IChannel can be a good choice. IChannels can better implement
unauthenticated portal page use cases and multiply subscribable widget use
cases. IChannels can incur less configuration pain, being multiply
publishable via the uPortal UI rather than requiring portlet.xml files.
JSR-168 portlets typically incur an additional web application on your
server, and get their own classloader, which is really neat isolation unless
it isn't that neat because it's getting in the way of something you want to
do, like share services between portal and portlet. And sure, you can solve
this via putting services in shared classloader locations etc., but it can
get complex. Channels have a few neat tricks up their sleeves, such as
ability to register IPermissibles with the PermissionsManager and delegate
to the GroupsManager and PermissionsManager servant channels. For specific
use cases where this accomplishes your goal, this can be pretty neat.

And often, a good choice is to write neither, and instead host the
applications or content remotely from the portal and use a web proxy
(CWebProxy) to proxy it, thereby keeping the software outside of the running
portal. This can ease the complexities of rolling new versions of the
widgets in your portal into production. With customer JSR-168 or with
custom IChannel this requires coordination with portal server maintenance.
When proxying remotely hosted content, the particular remotely hosted widget
can have independent outages, upgrades, and all that is affected is that one
widget. And, of course, the proxied application could be implemented in PHP
or Ruby on Rails or Spring WebMVC or really whatever is most convenient.
Judicious use of proxies can also reduce load on your portal server itself.

Which of these options is the "right" answer in any given case depends. I
don't think you get any bonus points for doing JSR-168 where it doesn't
actually buy you anything you want. However, there are some significant
advantages of JSR-168 *if* they are advantages for the particular problem
you're solving.

International Hug a Systems Administrator Day

No, it's not an official holiday, but it should be.

This industry seems to think that software developers, the programmers, are more important and more valuable than other information technology professionals, such as database administrators, systems administrators, deployment engineers, software configurers. I've seen this often reflected in differential salaries, but I see it even more in the respect and attention afforded people. The programmers often get to be the rockstars.

I think we would do well to remember that software developers can't do what they do without the support of excellent database administrators, systems administrators. Installing and configuring systems is what makes them go and deliver actual real value to an actual real client. Until that happens, software is the heady stuff of platonic forms, interesting abstractions without a connection to the real world.

I've been blessed with a number of excellent systems administrators and operations professionals in my short programming career to date. In my gig at Yale's Technology and Planning group, I had the privilege of working with Drew Mazurek, who has since moved on to other interests. Besides being a programmer and filling other roles, Drew was the go to systems programmer and administered the group's internal systems and played a role in administering external systems. His competence was extraordinary. In the systems administrator role he was a value multiplier for the those playing the developer role. And he saved my bacon that time I trashed the CVS server (sorry, Drew.)

In support of production applications there was the production services group. They administered and instrumented the production servers and saw to it that they were regularly backed up and restorable. They drilled some of this, and developed prepared procedures for all of it, so that when things go wrong, the first steps of response are pre-baked. They rolled new software versions into production with grace. They provided critically valuable diagnostic and troubleshooting services.

And I've gotta say, those regular backups and ability to restore from them, those are a mighty fine safety net for the programmers doing the production software tightrope dance. Log rotation. Load monitoring. Intrusion detection. These are things you sure wish you have in a pinch.


Human beings make mistakes. It is in their nature. It is inevitable. Things will go wrong. Rare is the day when i don't do at least one stupid thing that would have bitten me but for the ability to "undo" on some scale, whether it's a menu bar command, a source control revert, or rolling back to a prior database snapshot. It is not appropriate, or fair, or realistic, to construct your expectations around people never making mistakes.

Systems administrators are the folks who mitigate peoples' mistakes. Whether it's a developer who accidentally trashed the CVS server, or a developer who introduced a subtle bug that causes the software to leak connections, or a power outage, or spilling the coffee into the web server. How bad it is when Bad Things Happen is in the hands of the systems administrators.

I'm very grateful to have worked with a number of talented, caretaking, proactive systems administrators.

Developers more important than systems administrators? Bah. I'm the guy that writes the buggy code. They're the ones who make the buggy code work in production and solve real problems. I ask you, which is more noble?

I've met more than a couple talented systems administrators, and I mean really talented diamonds in the rough, who tell me they aspire to be Programmers. And I've gotta ask myself, why? You're already doing the most incredibly valuable thing you could be doing. And I'm very grateful you're doing it. And not everyone can do it the way you do it.

Oh, sure, I can fumble around in grep. And absolutely, it is quite possible to become a capable, competent, valuable systems administrator by hard work, practice, and care. But there is nonetheless a spark, a gift that some people have for this role. I don't have it. I have no doubt I could fill the SA role if slotted into it, but I know I'd never be as excellent at it as these systems administration rockstars. I'd be too inclined to get distracted and go scribble on a whteboard or explain excitedly about some software or project, preferably while talking with my hands, to give the log file rotation regime and failover procedures the full and careful attention they deserve. So how do we (should we?) entice the exceptional systems administrators to stay fulfilled in that role?

Perhaps as an industry we need to have more respect, appreciation, and yes, compensation, for the systems administrators.

You can start by seeking yours out and applying a hug. If your next big mistake is going to be a little less big because of the hard work and care of someone else, I think it's fair to advance a down payment on the gratitude you can expect to have the opportunity to feel later.

Mistakes are inevitable. It's the consequences of the mistakes that can be mitigated.

Atlanta JA-SIG Conference Calendars

I've created Google Calendars representing the Pre-conference seminars, Birds of a Feather sessions, plenary sessions, kiosks, mini seminars, the Projects Applications and Solutions track, and the technical development track. (All of these links are to add the calendars to your calendar, and none open in new windows, so right-click.)

This was pursuant to my figuring out what I'm going to attend at the conference.

Old Spring Presentations

Opensource is a good thing.

It means that, because I chose to put some powerpoints I made once upon a time on the web such that they were publicly available, other people archived them for me so now I can find them via a Google query and recover the Spring slides from yesteryear that I thought I had lost.

There's an efficiency to be had in just putting it all there. Anything that can be public, should be public.

uPortal is popular

According to Yahoo Site Search, there are 4,479 pages on the web that link to uPortal's main webpage. 4,450, I suppose, once this blog post is indexed.

That sounds pretty darn popular to me.

What does this mean? Well, Yahoo Site Explorer credits Sakai's main webpage with a comparable 4,653 inlinks.

Available Position: Sakai Support Specialist at Stanford

Open position: CourseWork (Sakai at Stanford) Support Specialist.

Your campus needs a portal

Sometimes people ask me why a higher education campus needs a portal. Financials software, learning management systems, the value proposition is more tangible. But a portal? A meta-application that itself doesn't do much? Why do I need that?

Here's the relevant problem universities have: they're complex, there's a lot going on, there's a lot of noise, there are all sorts of services dribbling all over the place. This is a source of stress. People miss opportunities. How many people wish they could go back to college and take one more class, attend one more guest speaker, get just a little more involved in some activity? I bet basically 100% of college graduates.

Those are the opportunities JA-SIG software helps people realize. Because by virtue of the Central Authentication Service) you spend less time mucking around with lots of different accounts or having your online identity stolen you're less stressed and more able to take advantage of university. Because the portal helps you to be aware of events and requirements and opportunities, you're able to plan more effectively and better use your time. Sakai as learning and collaboration system facilitates doing the real work of learning.

Colleges need to be on opensource because life is too short for artificial constraints, for a vendor telling you what you are and are not allowed to do. Opensource frees colleges to go after the services and integrations that will actually deliver value to their constituents, or at least help the technology get out of the way as much as possible, and it is that that will make the educational experience better. It frees them to choose the locally-appropriate spot on the edginess curve, whether they want to be very conservative and limit risk or want to be on the edge with lots of cutting edge code.

Enterprise portals are for "members" of the University community. Who play lots of different roles and have many different activities and needs. They are sometimes very serious and studious. They are sometimes playful. They are sometimes collaborating in ad-hoc groups. And sometimes they're just trying to navigate bureaucracy. uPortal and Sakai are flexible enough to accommodate all of these roles and behaviors: uPortal is all about gathering user attributes and using them to understand groups and roles and to provide appropriate content. It's all about aggregating relevant information to help someone stay on top of the game. And Sakai is both a relatively serious pedagogically-driven LMS and a platform for more adhoc collaboration. In addition to offering course-related sites, you can create sites in Sakai for various groups on campus to collaborate outside of the context of courses.

The software is complex but that's because it's modeling a university that is necessarily complex. This is complexity that is doing work.

Getting portal groups and user attributes to portlets

The package esup-portal-ws provides a web service to retrieve uPortal group and user information from portlets.

This looks like an alternative to the classloader games we sometimes play.

In the words of Pascal Aubry (as posted to jasig-portal):

One of the main issues we encountered when developing portlets is that the portal and the portlets run in different Tomcat contexts, which prevents from accessing the portal objects from the portlets, in particular, the groups and the user attributes (Note: hopefully this separation has many advantages).
The package esup-portal-ws solves this issue by providing a web service (executed by uPortal and interrogated by the portlets) which gives access to the portal groups and user attributes. We think that this project can be useful for the whole JA-SIG community, especially the people who develop portlets or port existing uPortal channels to portlets, and who want to keep a close integration between their portlets and the portal Information System.

Groups and Permissions

GaPs is "Groups and Permissions". It exists as a general framework embedded in uPortal 2 and, separately, as a standalone project that is used in uPortal 3. It is likely that uPortal 2 will evolve to drop its embedded GAPs code and instead use the externalized GaP. They are very similar.

http://www.ja-sig.org/wiki/display/GAP/Home

PAGS ("Person Attribute Group Store") is just one group store implementation that plugs into GaPS. Person Attribute Groups are clever just-in-time groups that are defined by logical expressions on user attributes. (A Group "Class of 2004" could be defined as all users such that their classYear user attribute is "2004"). This allows you to leverage user attribute stores such as LDAP to define groups for use in the portal.

Other currently implemented group stores include the uPortal database group store and a couple LDAP group stores.

In theory one could write a Sakai Group store that is backed by Sakai web services and exposes Sakai course affiliations as groups.

Group stores can be manageable via the portal (read/write) or not (read-only). They can be enumerable (e.g., a database backed group store) or not (in PAGS I can only ask the system what groups a given user is in; I can't ask it for all members of some particular PAGS group).

For instance, plausibly a Sakai group store would be externally managed (read-only) and enumerable.

Permissions are distinct from groups but use groups. Roles are not a separate data structure, but it is a typical practice to create a group for a role.

Permissions take the form of is allowed to on . E.g., Students are allowed to Subscribe to the Campus News Channel. Various modules can register permissions to be managed by the Permissions Manager. When you create an announcements topic in the Columbia Announcements Channel, this brings into existence permissions for who can create announcements in the topic, delete announcements, etc. Zero or more Groups (and/or individuals) can be granted each of these permissions.

There is a hierarchy and inheritance scheme for permissions; I'm not prepared to speak to it authoritatively off-hand. It's fair to say that it's less well-understood than it should be.

Dan Ellentuck is the authority and primary developer of uPortal / standalone GAPS. He has been working to take the "standalone" GAPS to releasable state. uP3 developers have been pitching in, particularly to use this in uP3 and develop uP3 UI around it.

"Standalone" needs to be in quotes because while GAPS becomes a standalone library with this refactoring, it does not provide its own UI. Both uPortal 2 and 3 provide UIs for administering portions of GAPs. (Other portions use file-driven configuration).

I hope these notes prove helpful. Dan Ellentuck is really the person to approach about this.

WSRP in Peoplesoft

Someone wrote me regarding WSRP advice. As often I'm reluctant to answer questions without answering them out loud and in public where others can see what is being said and either use it or disagree.

I've been developing JSR-168 Portlets for uPortal for a while and our management decided to change our portal framework from uPortal to PeopleSoft Portal. I'm hoping to reuse some of the work we've done by using WSRP. I know that uPortal has supported WSRP (except for hiccups). However, I'm having touble finding any technical information on developing a WSRP portlet (seems that there is little on the web or in printed material showing examples of WSRP code). I was wondering if you could point me towards some information regarding developing WSRP producers.

I'm reluctant to recommend WSRP as a solution to any real problem.

PeopleSoft does expose WSRP and so I suppose one could decide to
consume that WSRP in a portal. My gut reaction to the whole thing is
that it would be better architected if PeopleSoft had delivered
JSR-168 portlets that consumed domain-specific web services under the
hood. WSRP fundamentally is a protocol for remoting the production of
portlet *markup*, and that's strange.

You've articulated a different problem. You have a WSRP consuming
portal (PeopleSoft) that you'd like to get content into.

Michael Ivanov, Matthew Dovey, and others have been more involved in
uPortal WSRP.

I hear this is easier over in the .NET world, writing WSRP producers.
Don't know much about that.

In the Java world, what you do is you write a JSR-168 portlet and then
front it with WSRP4j to expose the portlet. uPortal 3 also has WSRP
producer infrastructure, such that it can produce WSRP around portlets
running in it. Sakai also produces WSRP. All of this either is or is
built on WSRP4j.

In theory you could run uPortal and use it to serve JSR-168 portlets as a WSRP Producer to a PeopleSoft portal instance which would present them to end users.

uPortal 2.5.3 now available

uPortal 2.5.3 is now available for download.

Included in this release:

• WSRP consumer restored to functionality


• DLM infinite recursion fix


• JSR-168 multithreaded rendering fix


• lots of other fixes

Take a look at the latest release of the most flexible opensource Java portal implementation available.

Resourcing Designers

Gary Gilbert raised an interesting point this afternoon talking about design in the context of uPortal. He pointed out that sometimes the problem is that the designers don't have the ability themselves to implement their design improvements and don't get enough time and effort and attention from the developers.

Well, what if we gave the designers some developers? Not just discussions, not just a chance to convince the developers to do things. No. Real actual resources - developers who make reality the vision of the designer.