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.

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...

Mainstream hosting versus rolling our own: availability for mashups?

One interesting thing to say about the Ohloh service is that it demonstrates the difference in consequences between using mainstream project hosting and rolling our own project hosting infrastructure in JA-SIG.

Projects hosted on dev.java.net are indexed and included in the visibility in ohloh.net, whereas by squirreling our code out into our own ja-sig.org infrastructure, our code isn't available for first pass indexing.
This is not the end of the world, of course -- presumably ohloh can and will eventually get around to indexing Sakai and uPortal, but the CAS Modules and Spring project and so forth show up immediately, thereby getting better visibility in these mashups, or even just when someone searches dev.java.net or sourceforge.

Sakai is present on dev.java.net but there's no code there so Sakai's ohloh.net entry is dopey by default.

uPortal isn't even on the radar at ohloh.net because it's not on one of the hosts being indexed. So if you search for opensource portals there, uPortal won't even show up.

Job Opportunity at BU

BU's School of Management is now taking applications for a Senior Software Engineer position (see entry 3175/G256 on the university's IT jobs page).

We're especially interested in the sort of facility that comes from healthy experience in open source endeavors, so it seems fitting to circulate the announcement here. Feel free to contact me for any further details:
clayf AT bu.edu.

As posted on sakai-announce.

How to make the varsity team

Sadly, uPortal didn't make this list of recommended portals. Why? Well, the categories of recommendation are a little elucidating. uPortal needs to be better at:

1. Ease of installation


2. Number and usefulness of included portlets


3. Extensibility of architecture

I would have thought that uPortal was already way ahead on "extensibility of architecture", with XSLT templating technology, exceptionally powerful groups and permissions, an excellent and pluggable DLM layout manager, and ever increasing Springy declarative configuration, with a rosy expected future of all-Spring-all-the-time in uPortal 3, Peter's highly pluggable rendering pipeline, and Mark's pointedly pluggable parameter processing pipeline for the next rev of DLM. And of course pluggable error rendering, still one of my favorite features ever. Awareness of the extensibility of uPortal is less than it ought to be and there are things we could do in the documentation and web presence to raise awareness of the uPortal strengths.

Far to go and much to learn. But uPortal is still an excellent portal as is and I would have liked to have seen it make the list.

How UE designers can help with uPortal

Someone recently emailed me to ask about getting involved with uPortal. I answer here in the interest of transparency and getting word out that your involvement is welcome.

Hi, I'm a Graphic Designer/Developer. I currently create Web Based Training for [a large organization]. I came across uPortal and noted the need for UE designers. I would like to know more about what the project needs and see if I can help at all.

Welcome! I'm sure you can help.

The case for englightened self interest:

I'll address the question of what the project needs, but let me first articulate this: the project needs what you need. We're not looking for martyrs to do a lot of work out of the goodness of their hearts (any would-be martyrs are welcome, but you're not what we're building this project on). What is needed, what is sustainable and what works, is for people to do work that makes sense from their own perspective.

It's a matter of a community of collaborators acting under an approach of enlightened self-interest, rather than a centrally organized commune.

So, for instance, you might need a portal. And you might need that portal to not look brown and drab, you might need it to support drag and drop user experiences for portal customization, you might need it to use nested divs instead of nested tables, and you might need it to support interesting ajax callbacks. Or maybe you just need it to have a little spiffier documentation. It turns out, there are lots of other people who need these things too. And if you speak up on the list and find some of them, they may be available to collaborate and help design/work on/QA these enhancements. Or you may develop them all on your own but then seek to re-integrate them with the core uPortal so that others will help maintain them and you'll experience a lower total cost of ownership of your portal.

Or maybe you don't immediately need a portal, but you're looking for some interesting projects and an opportunity to collaborate with the smart, fun, and good-looking JA-SIG community. It's a little harder to tell collaboration stories that work when you're not looking to yourself put the portal into production, but this can work.

So, as you read through some descriptions of what uPortal needs, be sure to think about what you need, what needs you think are shared between you and other uPortal deployers, because really, uPortal doesn't need from you anything more than the intersection of what you need and what our current and would-be deployers need.

What uPortal needs from User Experience developers:

uPortal needs a more attractive out of the box skin. Jason Shao and others have worked on this for uPortal 2.6 (the current HEAD of the portal CVS project) -- that work needs engagement and validation by additional developers and the issue of whether and what to do about the default skin in uPortal 2.5 is certainly still open for discussion. For the right skin, I think it absolutely would be worth the pain of a skin upgrade in the patches branch. A modern skin would improve the marketabilty of uPortal.

uPortal needs more attractive optional additional example skins, ideally with good instructions and an easy migration path to turn them on. More showcasing of what can be done with uPortal.

uPortal needs to close the gap between DLM and ALM and SLM theme transforms and more generally improve the pluggability and re-usability of skins. It would be oh so awesome if skins were modularized such that we could just pass them around, at least for the 80% most modest theme transform needs. There will always be the opportunity for advanced hacks to produce cooler user experiences, and that's a good thing, but the majority of sites should be able to settle on a common set of user experience functionality and share neat skins.

uPortal needs more and better how-tos and documentation for producing these awesome skins. It needs UE people to come to our conferences and developer meetings en-masse and form a more visible and active presence in our community.

The uPortal project itself needs improvements to its web presence, and there's a jasig-webpresence email list for discussing and working on just this topic. We need User Experience exports to join in those dicussions and pick up some of that work. What would a compelling and inviting developer.ja-sig.org homepage look like? While I appreciate the efforts of those who have set up what we've got, what we've got isn't it. We need User Experience experts to help us make our Wiki more usable and our website more compelling.

We have a new and growing process for accumulating, prioritizing, and matchmaking around requirements, and we need articulate, thoughtful, excellent User Experience requirements to go into that process. Yes, we all know we need Drag and Drop. Now what does it really look like? How does it feel? What really neat user experience stories could go into this process that would get people excited?

And in the meantime, are there pokey corners we can easily round to ease the user experience of our product? We need bugs fixed and minor enhancement requests worked on, and while many of the bugs are Java bugs that require java developers, some of them can be addressed in XSLT, which is sometimes the domain of UE developers, and many of the issues could benefit by the input of UE designers to ensure that what is produced is not only functionally complete but also usable.

One of the tragedies of our project is that we standardized on a layout manager that fails to showcase some of our best features. User experience designer input could have brought about implementing a UI for configuring those pesky restrictions and prioritizations of fragments, for subscribe time parameter value solicitation from end users. Let's not make that mistake again: user experience experts can help the project put its best foot forward in showing off the powerful capabilities that lie beneath.

We need user experience input and work both in uPortal 2 and in uPortal 3.

But mostly, we need what you user experience designers need: a flexible and powerful portal platform in which the shared problems are solved via collaboration and the extension points and support is there for you to fly free in solving your local problems and adding your branding and local value-add. We need your help to be the portal that you love to use. And you need to help because you'll love to have a better portal.

A reminder that uPortal is best discussed on the uPortal project lists:

While I try to be available off-list and politely and usefully answer questions sent my way (trying to get better at this), really the very best place to discuss uPortal is on the project lists. We have a list jasig-portal for general discussion of using uPortal, and a list jasig-dev for discussion of active development on the uPortal project itself. We also have a cluster of fringe lists for discussing user expereince, the JA-SIG web presence, uPortal 3 as it exists in the sandbox, and JA-SIG operational issues. If there's a niche for discussion that we don't yet have a list for, let's make one and start discussing and building an archive that can be valuable to others even after the discussions conclude.

While off-list discussions are often useful, they are a tool to be soberly considered because they often miss opportunities for wider involvement, transparency, and archival for future interest.

Power law of participation

The Power Law of Participation provides context to describe what we're trying to do in JA-SIG, and for describing our challenges. How do we make the shallow end of the curve less steep, and better enable casual participation? How do we make it attractive to draw further up the curve into more active participation?

Injecting Spring managed beans into IChannels

Someone wrote me to ask my thoughts on injecting Spring-managed beans into IChannels. This is what I had to say.

I've been playing with using your PortalApplicationContextFacade to acquire Singleton Beanfactory references to acquire Spring Managed beans implementing middle tier operations into my channels. Thoughts?

It's an approach. Channels are tightly coupled to uPortal anyway, so being tightly coupled to the context façade and looking up magic beans by name isn't the end of the world. This approach has the advantage of feeling a lot like our crufty static services invocation approach to life -- the Lookup (anti-)pattern.

Is there a better way?

I'm very attracted to going a step further and using ChannelToBeanProxy where the proxy IChannel looks up a named IChannel bean from the PortalApplicationContextFacade. Then you can wire in your Spring-managed beans to the channel, potentially wire in different service realizations or different proxies on top of services into different channels, etc. Gets a little closer to dependency injection.


Whether you inject into a Spring-managed IChannel instance or you write an IChannel that looks up the beanfactory and beans it needs probably isn't that different, though.

I've been digging for a way to get a startup contextListener to bootstrap the singleton beanfactory and maybe use the factory facilities to have it manufacture beans from the same context in both Spring managed and static contexts, but just thinking about it is so ugly...

It's not that ugly, and we really need to get there. Step one was what we did. Next step is to really buy Spring, use a Spring-provided context listener to bootstrap, and then use a uPortal-provided secondary context listener to expose that Spring-created application context behind the PortalApplicationContextFacade, and this *just doesn't work* outside the context of a running uPortal in a servlet container. Let's get firm about that: that what we're writing is objects and services that run in a running portal, and anything else (Ant tasks?) doesn't belong in the same source tree and can't use these services that legitimately only exist in a running portal except by remoting to the portal. And then go after building and wiring and configuring the services that those components will use -- I don't object to their existing, but it's a serious problem that they basically "happen to work" in the current implementation based on classpath magic and rdbm.properties happening to be in the right place. So, concretely, if you declare a Spring bean that depends on JNDI, and an ant task runs and touches something that touches the PortalApplicationContextFacade, it blows up because the JNDI lookup fails outside the context of the portal running in a container. Which exposes a deeper design problem of running portals and outside the portal tasks trying to use the same services and configuration. A recipe for complexity.

So we drop the requirement of running outside a servlet container. We re-approach those problems and come up with things that intentionally work outside the container, either by having their own configuration or their remoting to a live portal or their using services explicitly designed for that context or whatever it's going to be. Write the uPortal-user-provisioning-tool-as-Eclipse-plugin. But if it touches PersonDirectory, have it do so be deliberately and be very sure how that is going to be configured is worked out.

In the servlet container, we embrace being in the servlet container. Install and rely on that context listener from Spring.

Okay. That was step two.



But we really need to get to step three, which is not only using the Spring context listener, but also using Spring WebMVC. Slam everything we got into a couple controllers, fine. But open up that potential for adding more parallel controllers, for starting to use Spring WebMVC error handling, slapping interceptors and aspects in.

Peter's rendering pipeline plugability and so forth for uP3 is great. But I want it crunched into a Spring controller.



Now I'm out of steps and just observing:

Firstly, uPortal's channel manager really wants to be a Spring bean container. ChannelToBeanProxy is cute and I'm convinced it's useful, but I think it just exposes a deeper realization that ChannelManager should be implemented in terms of a bean container. Channels are beans. The get their configuration wired in. But get them from a bean container that's able to differentiate prototypes from singletons and wire in richer dependencies and apply aspects and so forth. What we've proven with all those static factories and portal.properties properties is that we need to configurably wire services into channels.

Has anyone written the RBDMS-backed bean container?



Second, as cool as it is to wire services into channels, wouldn't you much rather be writing a portlet and use Spring PortletMVC? Wiring dependencies into channels only gets you so far, you're still stuck with the lack of compelling MVC framework and pluggable view technologies for channels. So we keep reinventing it. CWebmail has IXmlMethod. Other channels do other things. Over and over we re-implement grabbing parameters from static data and runtime data. I've kicked around the idea of writing Spring uPortalChannelMvc, which would look a whole lot like Spring PortletMVC except work for channels, binding runtime data to command objects, doing the validation thing, bringing in pluggable vie technology. My thought was that it would be great fun and ultimately low value because I should just give up and write Spring PortletMVC portlets.



The most important, transformative feature of uPortal 3 is pervasive Springiness, and while you can be better or worse at teasing out those extension points and defining good interfaces, more or less you can't help but produce a pluggable architecture if you use Spring properly, and it is this sustainably pluggable architecture that will be the single greatest contribution of uPortal 3. Let's really go after open-closed in the context of uPortal the way Scott has in CAS.

JSR-168 and JSR-286 are uninteresting from the perspective of JA-SIG. They don't matter. Don't go write a JSR-168, and don't worry about what features will be in JSR-286. These standards are the necessary evil that makes frameworks like Spring PortletMVC possible, and once that's possible, the productive thing is to jump on that. What we should all be doing is taking a look at Eric's Bookmarks portlet, articulating what extension points it needs to be an asset to MyRutgers, to Academus, to MyWisc. And then going after the open-closed core that works for everyone and local plugins that make us happy. And that's all about Spring PortletMVC and a domain model and good interfaces, and has very little to do with JSR-168.

JSR-168 is better than IChannel because it gets you to Spring PortletMVC. JSR-286 will be valuable only inasmuch as it allows SpringPortletMVC to be better. I'm interested in what I can do with PortletMVC and the opportunities it gives us to share controllers. I'm not interested in 286 for its own sake since the most productive thing to do is to jump on the PortletMVC framework.


I see the value of injecting spring resources into IChannels as allowing incremental decoupling and Springification of channels, allowing you to demonstrate incremental value or at least progress. The natural outcome is an eventual realization that all that's left in the channel is controllerish stuff, that all the services and domain have been extracted. But then the next step is to move the service and domain into a Spring PortletMVC portlet and re-implement the controller in that richer environment, continuing to realize incremental value in terms of not being forced to use XSLT as the view layer, etc. etc.

Messy Desktop and the Ajax enabled portal

This video talks about organizing documents, but of course the same kinds of techniques can (and should) could be applied to interacting with portlets.

Getting beyond tabs and columns. Way beyond.

Re-using an existing web application as a Sakai tool

Another step closer to being able to drop in an existing web application as a Sakai tool. This feels a lot like uPortal's CWebProxy.

Sakai emblem

A truly beautiful Sakai emblem out of ASU:

Too many ideas

Cleaing out my desk at Yale Technology & Planning, I came across some index cards of ideas we didn't get a chance to implement for YaleInfo. We used index cards taped to a door in priority order for project management some of the time. Pretty effective and concrete, with the ability to take a card, split cards, merge cards, hand cards -- a lot like Extreme Programming story cards.

Anyway, here are some of the cards I'm throwing out as a I tidy up and move on:
* Put sitemap in Guest header (theme stylesheet)
* Hover help for tabs
* Central backup channel
* Meeting maker basic channel
* most recent effors overall / error report
* ITS status with limit on number of items (display most recent 4 items) (implement by adding max feature to RSS)
* How to maintain Yale College Calendar channel
* Test DC on https URLs
* OPA wsbapp event feeds

uPortal 4 now available

uPortal 4 is now available. It is a flexible framework for developing your institution's portal. This is the most flexible version of uPortal yet, overcoming the limitations of coding to particular APIs and adopting particular libraries to deliver maximum options to the implementor. Continuing with the best practice of using external libraries rather than inventing new code, uPortal 4 has less custom code than any prior version. In keeping with the best practice of loose coupling, no uPortal-specific code in uPortal 4 is coded to concrete classes.

For a powerful, loosely coupled, infinitely flexible portal framework, look no further than uPortal 4.

(Happy April Fool's).

Yale Technology & Planning Jobs

Yale University ITS Technology & Planning has two -- count 'em two! -- openings listed. Technology & Planning is a great place to work -- awesome coworkers, good working environment, neat projects. Be interested in these jobs.


Systems Programmer I Requisition #: CCRF33463
Posting Date: 3/15/06
Department: ITS Technology & Planning Work Site: 175 Whitney Avenue
Salary Grade: 24 Duration: REGULAR - 12 MONTHS


Schedule/shift: Full Time - 37.5 HRS; Weekdays 8:30-5:00
Internal applicants send bids to: Corey Rossman, 155 Whitney Avenue

Job Description:

General Purpose
Work with a small focused senior ITS professionals that develop strategic technical directions for the University and explore emerging technologies.
Essential Duties of Position
1. Work in a collaborative fashion with a broad range of IT professionals to establish both needs and opportunities for emerging technologies.
2. Participate in large scale multi-University development efforts that utilize a fluid mix of both new and legacy development methodologies and technologies.
3. Track and evaluate emerging technologies in fields that include (but are not limited to) software development languages and environments, network, information security and telephony.
4. Produce technical white papers and presentations for consumption within Yale's ITS organization and at national conferences.

Education and Experience
1. Bachelor's degree or equivalent experience as well as a minimum of two years experience developing software in Java programming language.
2. Experience developing middle-tier applications utilizing Java Servlet/JSP technology. This experience should include familiarity with current design and coding approaches and methodologies.
3. Documented record of software development experience in either a corporate or university setting is necessary. Code samples may be requested and reviewed with the candidate.

Skills and Abilities
1. Demonstrated track record of inquisitive self-direction and the ability to learn new things rapidly and completely.
2. Familiarity with the basic principles of relational database design.
3. Experience with at least one other high level programming language is desireable but not required.
4. Technical familiarity with one of the following operations systems is additionally desireable: Unix/Linux, Microsoft NT/XP, Mac OSX
5. Excellent written and verbal abilities.



Systems Programmer III Requisition #: CCRF33464
Posting Date: 3/15/06
Department: ITS Technology & Planning Work Site: 175 Whitney Avenue
Salary Grade: 26 Duration: REGULAR - 12 MONTHS


Schedule/shift: Full Time - 37.5 HRS; Weekdays 8:30-5:00
Internal applicants send bids to: Corey Rossman, 155 Whitney Avenue

Job Description:

General Purpose
Take a technical leadership position working with a small focused staff of senior ITS professionals that develop strategic technical directions for the University and explore emerging technologies.
Essential Duties
1. Facilitate and lead in collaborative fashion projects involving a broad range of requirements as well as customers.
2. Participate in large scale multi-University development efforts that utilize a fluid mix of both new and legacy development methodologies and technologies.
3. Work with the University IT leadership to establish goals and directions for foundation technology that serve us into the future.
4. Track and evaluate emerging technologies in fields that include (but are not limited to) software development languages and environments, network, information security and telephony.
5. Produce technical white papers and presentations for consumption both within Yale's ITS organization and at national conferences.

Experience and Training
1. Bachelors degree or equivalent experience as well as a minimum of 6 years experience developing software in the Java programming language.
2. Experience developing middle-tier applications utilizing Java Servlet/JSP technology. This experience should include familiarity with current design and coding approaches and methodologies as well as a concrete and demonstrated ability to evaluate, adopt and fully understand complex software frameworks and architectures.
3. Experience with at least one other high level programming language
4. Experience with the management, performance characteristics and basic principles of operation either Unix/Linux or Microsoft's NP or XP operating environment.
5. Familiarity and practical experience with project planning approaches and the ability to budget both temporal and fiscal resources.
6. A documented record of software development experience in either a corporate or university setting is necessary. Code samples may be requested and reviewed with the candidate.

Skills and Abilities
1. Demonstrated ability to lead a technical team effectively.
2. Complete understanding of relational database principles and design.
3. Excellent written and verbal communications skills.
4 Demonstrated track record of successfully identifying, promoting and deploying products and services that represent long term value to their employer as well as providing bedrock technology upon which additional services are built.

Portlet paper in German

It's enough to make me wish I knew German.

On Walled Gardens

The first issue is whether there is justification to try to reimplement an “educational” version of software when a perfectly good and popular generic version already exists.

It's important to be cautious of walled gardens. On the one hand there is the value of building a component in a tighter knit community where it can be more easily steered to meet very specific needs of the community and where the bandwidth of collaboration is limited to a manageable level. On the other hand there is the value of wider collaboration and thereby drawing a larger pool of contributions and interest.
As Michael Feldstein notes in his blog, there are times when higher education has unique needs and something to contribute by going after a need in a by, for, and about higher education way.

I worry too much. Lately, I've been worrying about two things in JA-SIG and uPortal. One of them is going after non-higher-ed-specific concerns in the context of JA-SIG. Yes, uPortal should have an awesome syndicated feed reader JSR-168 portlet. However, every other JSR-168-supporting portal on the planet has exactly this same need. There's nothing higher-education-specific about a syndicated feed reader. Therefore, the way to get the most participation, mindshare, involvement, etc., for such a portlet is outside the context of JA-SIG, is it not? Would it not be best to fork a SourceForge, Java.NET, JavaForge, etc. project wherein interested uPortal, LifeRay, JetSpeed 2, StringBeans, and other portal deployers with this need can collaborate on a single excellent syndicated feed reader portlet for use in all these portals? Or on several of them. There may be be room for several syndicated feed readers with different feature sets, but I don't think their adopters will be neatly partitioned by portal platform or even by higher ed vs. commercial. There are opportunities here.

Another worry is not going after higher-education-specific concerns in the context of JA-SIG. Java really is an architecture that can be used effectively in the administration of higher education. We've got to have some shared needs that are higher-education-administration but not pedogogical tools (teaching tools intended for use in the context of particular courses are likely most appropriately implemented as Sakai tools). What are they, and how to can we effectively pursue them in the context of JA-SIG to everyone's benefit?

uPortal Developers' Notebook

There needs to be a uPortal Developers' Notebook style document, a guide to understanding the uPortal code.

"As a beginner, after I went through the installation of uPortal with Oracle support, implementation of related portlet, CDK in the tutorials, I want to go down to the code. But the source code looks overwhelming complicated that I lost my direction quickly at "redirectString" of "loginservlet".

Is there any way that could be used to alleviate the pressure of understanding the system? Thanks!"

- A newcomer comment on jasig-portal

Designing a next-generation portal

We have created an open platform for true enterprise integration, based on a component architecture and Java standards. I am excited to start developing applications with NewPortal. The end result is an integrator's dream enterprise portal. Portals are the ultimate end-user integration points for communities or businesses. NewPortal makes integration as easy as selecting portlets, customizing them live, and dropping them in to your portal for immediate use. For those needing more complex integration, the NewPortal API provides the clear assembly and interception points for component building and integration.

Since our components are simply ... dependency-injected Spring components, integrators with Spring experience will immediately be up and running. This is where NewPortal really shines for system integrators. We have found that every portal requires integration with existing business processes. Typical cases are integrating user attributes from diverse applications, web content and service integration, authentication (SSO) integration with existing LDAP or other commercial databases, and complex authorization rules based on access control lists. NewPortal clearly isolates these integration points in the NewPortal API, based on existing Java standards. This is where NewPortal provides a clear and open advantage.

This quote is discussing Jetspeed2. How do the goals for which Jetspeed2 was designed relate to the goals of the next generation of uPortal?

University of Manchester seeks senior Java developer

The University is seeking to recruit an experienced Senior Java Developer to join a development team for the university portal.

Funding Opensource Development

What is worth learning and emulating from the School Tool project?

Portal conference @ Gettysburg June

A portal conference at Gettysburg right after the JA-SIG uPortal conference this summer. I hope uPortal will be represented and considered at the Gettysburg conference.

Decline of portals?

It's clear that the framework, the portal platform, will have to do more. It's not going to be enough to just be a boxy view on the world. Context is important and can drive providing the maximum value on that zeroth click. And sure, tagging and social networking will be ways to make intelligent predictions about what content the user will most appreciate having highlighted.

This doesn't mean the decline of portals. It means a whole new generation of smarter, better portals.

Portlet training

Unicon will be offering three portlet training courses hosted between February and March, at Randolph-Macon Women's College in Lynchburg, Virginia and at the University of Manchester in Manchester, England, and in Florida this winter.

What version of uPortal should I deploy

People continue to ask me what version of uPortal I would recommend they consider for near-term deployment. This probably means that the uPortal project could better communicate about deployment recommendations.

My answer to the question from April 2005 still feels right.