I was recently asked via email what training or whatnot I would recommend to bring a programming team up to speed on Java.

A couple options come to mind – depending on the overall scope of your programming team and their past experience (if I can ask – what is your past experience?) but, I generally recommend the following progression of reading (note – this is probably about 6 mo of reading, if you like reading):

1. Pragmatic Programmer (non-language specific, but the best beginner book I’ve found)
2. Headfirst Java (for basic/core Java)
3. Effective Java, by Josh Block (Josh was the Architect of the Java Collection Framework)
4. Headfirst Design Patterns (I actually love this whole series)
5. Spring in Action (I think the latest edition was updated for 2.5)
6. Java Puzzlers (Josh Block, & I think Neil Gaffer)
7. Domain Driven Design, by Eric Evans

In terms of classes/training – general Java classes can be useful, but I find they generally tend to focus at too low of a syntactic/language level (understanding core concepts is important) – effective Java will give you a good feel for some of the oddities – but that your best bit tends to be to get enough to bootstrap you and start coding/testing/working.

Of course, my employer (CampusEAI) does provide focused training on topics like Java Development or Portlets, which since I had a hand in designing the modules I think hit the mark fairly nicely…

ландшафт. the exhaustion that was the combined CampusEAI Portlets2008 and Annual conference is now behind us, and it seems like time for some reflections and observations. Hopefully some of these items will be items which I expand upon at a future date, but in no particular order, dumped straight from my brain:

• JSR-168 is here! Everyone really wants to write good standards compliant portlets. Architecture and engineering is a harder sell (or at least the time/cost trade-off) but there’s wide consensus that standard portlets are the way forward — at least excepting a couple of us widget fans
• SOA is something people are interested in, but that there’s been relatively little forward progress on. Some is governance. Some is tools (SOAP, WSDL, and what’s this REST thing?). Some is just that it’s big and strategic, and there’s many tactical must haves. I suspect some of it is also that much of our interesting data/services are locked in vendor platforms that have shown little interest in opening up. Though, a small trend does exist of creating SOA-style services to reach into vendor platforms and extract data from them
• Mobile wasn’t as big as I thought it would be. Not sure why. Most people seem to be interested in the abstract, but with few concrete plans. Maybe my iPhone has clouded my vision, but I do wonder if we’re going to get blindsided come fall — our target demographic is basically 18-22 year olds, afterall…
• AJAX in portlets is still hard. There are some tricks like wrapper divs, namespacing, and builtin support and integration patterns, but it’s still not a common practice.
• Identity Management is big. Governance is a big thorny issue, though many IT departments are rolling out vendor products from big players (Oracle, Sun, a little IBM) in the interim, tho ugh the exact scope of those items is somewhat unclear.
• Oracle is really putting portlets in lots of interesting places. Webcenter. Product mashups. Inside BI tools, and other GUI devices. I think they’ve probably embraced the architecture more than any other major vendor which is an interesting trend.
• Lots of awareness, and wanting to look at uPortal 3. Ooohs and ahhs over both the AJAX D&D, and maybe more importantly the new content adding UI — good going Jen!
• Really beautiful portals — some, though not all new portals really seem to be breaking out of the lots of boxes approach, or at least wrapping it in neat functionality like Boston College’s Agora design. Nifty trend. Sign of maturity?
• Community Development is hard. Aligning roadmaps, agreeing on implementation strategies, and putting all the pieces together is challenging. Even more so, justifying “doing it right” (and fit to share) versus quick and dirty, or getting a student up and running was a big trend. Makes my inner-engineer quail, but my inner-economist says that throw-away code lowers the barrier for solving problems, which is a good thing. Evolution isn’t always pretty and all that.
• Lots of desire for training, best practices, and advice on policy and governance. Real role for communities of practice, not just code and software.
• Increasing interest in “Enterprise Learning Management”. Lots of worries about migration, but the beginning of seeds wondering whether our current platforms are sufficient for a foundation for the next 10-15 years, and University strategic goals. Of course, some of this is the “enterprise IT guys” getting pulled into the LMS discussion for perhaps the first time in many places.
• Good beer is key to facilitating interesting non-session discussion. Content is king on the program, but largely only because it gets people in one place and produces interesting spontaneous interactions. Hands-on is something everyone wants, but it’s not clear a conference composed of many 1 hour sessions is the right format to deliver it.
• University IT teams wear many, many hats.
• British Universities seem to have a much richer and more abundent IT project management structure than (most) American schools. Really interesting thread about Imperial College in London blending ITIL and Agile methodologies.

Clay from Georgia Tech shot me an email recently which spurred me to try and put to words how my thinking has evolved about the relationship of an enterprise portal and Sakai, and where these technologies and communities are heading.

In general I think the focus of “enterprise portals” has always been one of integration and convenience, and as a result these products are moving towards being the place that knits together all the attention streams a user might have across the digital (and non-digital) campus. I think there’s a couple key use cases, some of which have more successfully been deployed than other.

1. One stop shopping (typical) + SSO
2. Summary Views & Aggregation

Less commonly actually implemented, though often talked about/pitched: 3. Dashboards 4. Actionable Intelligence (you have overdue books, return them!) 5. Deep aggregation (e.g. pulling in all the announcements from different systems and putting them into one stream)

In addition to portals focused on horizontal integration, I think we’re starting to see vertical integration around “portals” in Learning, Collaboration, HR/Admin, SIS, Libraries? and other clumps of functionality. Some of the goals around bundling related tools together are similar, but focused around a particular toolset, or context. At some point these could probably decompose into the “lots of tools/portlets in the uber-portal” that I think represented the portal thinking years ago, but I think the reality is market forces, as well as organizational and reporting structures make that unlikely to happen any time soon.

I suspect the interrelationship w a product like Sakai to a portal is mostly as a provider of information/data — pushing out items like announcements, scheduling, files in resources, and exposing them in a different context. Ideally if we shift our thinking more along the line of wire protocols (RSS, Real SOA, RESTful APIs) this I think positions us to also start doing “network integration” where Sakai can also start talking with and working with say Banner, or Kuali FS, or Facebook, or whatever platform. I’m very impressed with CARET’s mySakai work, and think John Norman’s vision on this is similar to the kind of plan I’d outline as benevolent dictator of the Sakai universe.

Along this line, I’ve scheduled another LMS-Portal integration BOF for JA-SIG and would like to use this project as the testbed for both a WG, and an incubated integration project within JA-SIG. I think a lot of the architectural level aspects should really span LMS’s — e.g. if we do it right, ANGEL, D2L, BB, and everyone should be able to use the same protocols, though Sakai seems an ideal reference implementation. I admit to being weak on knowledge of the IMS-spec side, and am not sure whether there’s work on that front we can leverage as well. So far what I’ve seen at least on the TI front has been less API/Data centric than I think we need to go though, though Enterprise seems promising.

One particular short-term item I’d like to see Sakai expose more broadly is the group contexts expressed in the form of class enrollments & particularly ad-hoc groups represented by project site membership. In many respects I think this is the most useful data in Sakai — it’s a social-network like context that integration with and hooking other systems into seems quite valuable. Enterprise grouping systems like Grouper while promising architecturally seems to have had slow adoption, and I suspect fitting systems like Sakai with something like OpenSocial or Google Contacts-like APIs to mesh groups together may get us farther faster in the short run.

JSR-286 (the next generation Portlet specification) was approved last week.

The major new features of version 2.0 include: * Events – enabling a portlet to send and receive events and perform state changes or send further events as a result of processing an event * Public render parameters – allowing portlets to share parameters with other portlets * Resource serving – provides the ability for a portlet to serve a resource. * Portlet filter allowing on the fly transformations of information in both the request to and the response from a portlet

I have to admit I have mixed feelings on the spec. It certainly adds a number of features to facilitate inter-portlet communication, and messaging which were commonly requested. Part of me does wonder though if Gadgets, Widgets, and platforms like OpenSocial are going to leap past the Java Portal space. The aggregation and plumbing aspects which we’ve really focused on in many ways seem much less interesting than standardizing the data model behind obtaining presence, personal, relationship, and other data — something that the social networks seem to be moving full speed ahead on.

More soon…

So, the JA-SIG un-conference (even the working sessions) is over, giving me a chance to do some thinking and reflection about the event and its aftermath.

Overall, the attendance, interest, and excitement demonstrated by all of the participants was pretty overwhelming. We had both more individuals, institutions, and organizations represented than we ever would have anticipated for an inaugural event. Even JA-SIG product deployers like Collier from UMBC and FLUID were well represented. While everyone undoubtedly came away from the event with different thoughts, two items struck me as particularly exciting.

MyUMBC

Collier demonstrated the MyUMBC work he’s been doing. While not uPortal based, the reactions related to the functionality of his portal ranged from “wow, I want it” to “you built that yourself?” to “don’t show that to my users or they’ll want it.” A couple of thoughts on why everyone in attendance found Collier’s work so compelling:

• Presentation: Collier threw away the assumption a portal must allow users to add/remove/re-arrange content. This dramatically simplified his problem domain, and allows him to capitalize on web-design techniques to tune his layout and presentation.
• Focus: MyUMBC is focused on end-user tools, not building frameworks. While in many portal project 75% of the time seems to be spent bringing up the platform, and making changes there, Collier spent 75% of his time building tools for news, events, favorites, etc.
• Integration: MyUMBC has a number of tools and concepts that serve to knit the experience together — the favorite stars, the dashboard on the start page, navigation cues all make the experience feel integrated
• Feedback & Monitoring: MyUMBC built a feedback system integrated into every page, and a lightweight dashboard to extract key statistics from that system. As a result, feedback is easy (~6000 in less than 6 months) and mining the data for trends is also correspondingly easy. This combined with standard tools like Google Analytics support a nice feedback-response loop while requiring minimal custom tooling.

Portlets

JA-SIG and uPortal have always been very focused on building out uPortal as a portal Framework. A consistent thread throughout the un-conference however (partly sparked by MyUMBC) is a bubbling thread of focusing on portlets and tools. I think there’s a growing recognition in the community that the tools are what users are visiting a portal for in the first place — and an area we have not focused as much attention on in the past.

In particular, collaborative efforts in the portlet space received a lot of discussion at several different sessions. LMS, SIS, Library, and other areas all seem to be places where schools have repeatedly re-invented the wheel. Collier’s demonstration of the return from focusing on tools, and the timing related to the talk on JA-SIG project incubation I think have all contributed to an atmosphere where people are highly interested in collaborating higher up the stack.

Chuck is talking a bit more about his experience with portlets, and the implications for uPortal, Sakai, etc.

Sakai portlet notes: * Preferences – site.upd to change * Edit Mode – site.upd again * isUserInRole() mapped to Sakai permissions site.upd, content.read, etc.

The isUserInRole() mapping seems a little counter-intuitive — seems like really portlet.xml should be mapped to a particular Sakai role, and that the portlet implementation should decide whether to hardcode the semantics of that role, or look them up based on sakai permissions, or another approach.

Chuck is again advocating JSR-168 as an alternative to the Sakai tool API. At the end of the day, I really feel like the most interesting model might be building Sakai tools that use JSR-168 as the view API. So you throw away the cross-platform promise, and just rely within Sakai on JSR-168 as a well-defined, nicely separated tool component API. Though, he had a note on the end about Sakai-specific portlets, but I don’t think he’s sold yet.

Chuck Sev. is doing a demo of some of the new features that have been ported into Charon Portal in trunk. Additional hooks in Ian’s new portal Impl support multiple Velocity

Features

• Hierarchy – sub sites, NO INHERITED AUTHORIZATION, velocity templated
• Single Tool View – edit Page order, and the toolbar/nav disappears so that you’re focused on only one tool — e.g. wiki, others. Also playing with using a iFrame tool, and point at another Sakai instance, inside the iFrame.
• Display icons for tools
• **iFrame-free View
• Size features detection

ToDo:

• Federated
• OSP Convergence
• WSRP Producer
• Sakai-Portlets
• iFrame Replacements
• Nav
• Portable Portlets
• iFrame Replacement
• WebProxy

Portal Implementation

Various API’s and influences provided for extension points — RenderEngine, Providers other pieces. Should support hot-loading from WAR/JAR files, or in the VTL. PortalHandle can be implemented to do URL handling and other pieces.

OSP Portal

• Sites grouped by site type – e.g. courses, projects, semester? (IU)
• Tools in categories – collaboration/communication/admin? Also, the OSP portal changes allow things like contextual help/descriptions. I wonder if this might be an answer to our teaching pedagogy focused help — maybe the help becomes embedded in the tool selection screen.
• Tools hidden based on permissions – site-editor hiding usage scenario
• Breadcrumbs -
• Category screen w/XHTML templates
• Portable rendering skin-able by XSLT

Plans to bring the portal forks (Velocity, OSP, etc) back together… using Ian’s pluggable extensions points — targeted for 2. 5

One concern I would have about the variety of portal “skins” using different templating engines is that it seems likely to produce forking in terms of CSS and designs, making it harder to share design elements across sites.

Single Mind Consulting – Summary of Sakai

Furthermore, Sakai is designed as a series of independent tools built upon a robust, standards-based framework (uPortal).

<snip />

Sakai’s uPortal is a powerful portal environment that utilizes the portlet specification to ensure interoperability.

This particular perception – that Sakai contains an embedded uPortal instance which it uses to do the aggregation of tools and services is not correct — (though it’s understandable given historical context — see below). Sakai actually includes a custom developed portal engine “Charon” which is used to handle site aggregation and display. In the 2.4 branch, Charon has some preliminary integration with Pluto 1.1 to handle rendering JSR-168 portlets. While this is the same approach taken by uPortal, the integrations don’t share implementation details beyond the common adoption of the Pluto portlet driver.

The original Sakai vision (I wasn’t involved at the time — this is just my perception/understanding) was for Sakai to just produce a collection of instructional tools. The uPortal angle is that the tools were going to be implemented as JSR-168 portlets, with some framework-style glue to support integration and common functionality, but leveraging the portlet spec to provide isolation, separation, and markup aggregation.

This plan resulted in discussion about partnership, and resulted in a portion of the initial Sakai Mellon grant being allocated to uPortal for development of the PortletAdaptor for uPortal 2.x, as well as creation of uPortal 3 — a rewrite of the uPortal framework intended to enhance/provide native JSR-168 portlet support.

During the course of development of both projects (Sakai & uPortal 3) however, delivery pressures and emerging understanding of the needs of both camps caused development efforts to drift apart. As a result, Sakai 1.0 shipped with a custom portal which I believe was a derivative of CHEF’s portal infrastructure (based on JetSpeed1?). As Sakai has evolved, a number of Sakai-specific metaphors like site-membership have been introduced, further splitting the functionality of Sakai and uPortal.

Currently efforts are focused more on integration between Portals and Sakai. Chuck Severance has done a large amount of work on summary views and other proof-of-concept exercises, and Sakai 2.4 ships with an enhanced Charon portal which supports alternate views like RSS which are intended to aid integration.

Hope this helps clear things up…

Tags: sakai uportal

At Portlets2007 I was talking with Greg from St. Thomas about Rails, and he showed me a Rails app he had deployed out using JDeveloper and OC4J — basically Rails inside a WAR file. Very cool — and apparently easy enough to do that he got it working during my session on PortletMVC. Not sure if that means it was really easy, or my session wasn’t that interesting

This seems particularly relevant given Thoughtworks announcement that their new Mingle Agile Development product is a RoR app that they’re planning on deploying using JRuby — initially with an embedded Jetty as an app, but for 1.1 as a WAR file. Going forward, I wonder if this kind of ‘blackbox’ approach will allow Ruby to start penetrating the enterprise. Afterall, even Rutgers which likes to take enterprise apps and muck with them all over the place bought some .Net and PHP apps and treated them like appliances, which seems to be a growing trend.

Update: http://blogs.sun.com/arungupta/entry/mephisto_on_glassfish_v3#comments has a demo of getting Mephisto up and running on Glassfish — so this definitely seems to be getting traction.