Listening to Scott talk about CAS4 work and effort. Core items he’s mentioned look to be:

• Redesigned to better support non-CAS protocols (e.g. SAML, etc.)
• Increased emphasis on SAML as a product
• Better admin tools (service administration, workflow for registering services)
• Eased configuration (w/o needing to edit deployerContext.xml)
• Better extension points: captcha, “password expired” messages
• Governance and other changes

Scott’s mentioned the timeframe is end of this year, with Rutgers looking to go-live over the summer. Cas 3.3.x is still the production maintenance release, and there are intentions for a transition period, though some of the details have not yet been worked out.

Well the questions are pouring in (mostly due to my tardiness in writing this kind of announcement) and so, without farther ado…

What Happened?

While it still feels a little strange to say it, as of 2 Fridays ago (2/8) I am no longer employed at Rutgers University. Over the last 9 years as first a student, then staff member, I’ve had the chance to: first study under, and then work with some incredible people. I’ve gotten to watch projects and services grow and evolve into solutions that are used every day by tens of thousands of students, faculty, and staff.

Before addressing my personal situation, I feel the need to speak a bit about the Rutgers Sakai deployment which up until now has occupied so much of my thoughts and energy. I was fortunate enough to see myRutgers grew into a service providing tools and services to every student at Rutgers. Sakai usage is currently somewhere on that curve, with usage growing by leaps and bounds. This Spring’s semester in many ways feels like a qualitative shift in the nature of the service — marked by a huge increase in the number of students asking “where’s my class’s Sakai site.” This semester these questions are particularly significant, as many of them are coming from students in classes where either:

1. Class was not yet in session. This is a big change from the dynamic in previous semesters where students typically visited the first meeting of their class, and were then directed to visit the Sakai site. Now students are looking to visit the Sakai site to see the syllabus, readings, and get a leg up on going to that first class.
2. Their instructor had not created a site. Sakai seems poised to make the jump into ubiquity, as in some students minds it’s already there.

Now to handle the really common question — if the Rutgers Sakai deployment is so clearly poised for greatness, where am I going and why? Well…

Starting this past monday (2/11) I have taken a position with the CampusEAI Consortium, where I will be serving as the Director of Open Source Solutions. Recent years have seen a huge upswing in the popularity, and visibility of open and community source solutions in Higher Education. Sakai, uPortal, CAS, Kuali, and othes have garnered attention, awards, and deployments. Due to significant interest expressed by member institutions, CampusEAI is looking to complement its existing strengths on the Oracle platform with broader offerings in the open-source space.

Answers to some personal-ish questions:

Are you moving to Cleveland?

No, I’m going to be based out of NJ, though Continental is certainly getting a good chunk of my time for the next few months as I schlep back and forth.

What does Lisa think?

She’s excited. Well, more excited when I’ve been gone < 2 days as opposed to > 3 days…

What do the kids think?

The kids are still getting used to not picking me up at Rutgers. They think it’s really funny that daddy works somewhere they can’t see. Sunday nights are hard. Phone calls are bittersweet. Coming back is good.

Aren’t you on the JA-SIG Board?

Yes. When my career change became definite I notified the board at the January video call. JA-SIG has always been a community of volunteers (stellar volunteers more often than not) and particular given my new employer’s willingness to continue backing my involvement in JA-SIG it was felt that there were no significant barriers to my continuing to serve in this capacity. As always, JA-SIG

So… is your Rutgers job open?

Yes. Though (see below) I’m hiring too…

What’ll I be doing?

So what does this mean in concrete terms? My personal definition is pretty simple. We’re looking to help members deploy solutions built on open source software. Given my background, Sakai, uPortal, CAS, and maybe even Kuali are obvious possibilities. I think however, that it’s a broader story than just support for deploying a few specific products. Many institutions have experienced challenges in building around open-source due to shortages in staffing or specific skill-sets. Others have successfully deployed open-source solutions, but been burned trying to deepen integration, or due to staff turnover (a problem which I should note also happens around commercial solutions). So the goal of this new unit is to make deploying solutions built on open-source:

1. Easy
2. Cost Effective
3. Low Risk
4. Sustainable
5. Did I say easy?

Basically the goal is to allow schools to leverage the strengths inherent in the open-source development model:

• Try before buy
• Rational licensing and cost-containment (instead of getting wracked with heavy licensing burdens as you get “too successful”)
• Open implementations, generally of open standards
• Economy of scale versus custom developed institution-specific software
• Freedom from vendor roadmaps and strategy shifts — even to go as far as obtain competitive bids from multiple vendors on the same solutions
• Peer interaction with really bright people working hard to solve the same problems you see

So that’s the goal. Make open-source easier, removing barriers for schools large & small — the kind of topics that have continually been commented on lists, in journals, and at conferences. Reducing installation pain. Helping with patch management. Providing support and training. Taking the pain and risk out of going open-source, all while working to make strategic contributions to enable the production of more good software.

It should be exciting.

P.S. Did I mention we’re hiring? Drop an email talking about your love for open-source, and how you really want to join in making it easier: jason_shao@campuseai.org. Oh, and mention you saw the posting in my blog

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.

So I finished merging in the Samigo 2.4 changes to the Rutgers code base yesterday the instructions in the wiki were actually very good — one small mis-merge on my part, but aside from the self-imposed pain the merge went quite smoothly.

So far, the defaulting to off of the rich text areas is a huge improvement in useability (though, really it would be nice if sakai had a nice “minimal” mode or something) though I wonder if it should be labeled “show toolbar” and hide the switching editor modes from the user?

The “retract now” button is also a nice touch.

At some point, organizing the list of posted tests, and finding someway to hide, move tests that were retracted without anyone taking them would probably be a big plus.

Much of August is likely to be spent load-testing (and creating infrastructure to load-test) to validate performance of the upgrade in the Rutgers environment, but the results from Michigan/Stanford’s testing look very promising, and we are planning on being on Samigo 2.4 for the Fall semester.

bolster the possibility of using something like the wiki or other tools as I would expect they could be used. bolster the possibility of using something like the wiki or other tools as I would expect they could be used.

Soo… yesterday I completed my 2.3.1 Sakai vendor branch merge, and it’s now up on a Rutgers test server. It’s been sanity tested, and is ready for further banging. Speaking of banging… it did take quite a few steps to get to this stage…

Note: 2.3.1 is a small merge, I think it was only about 15-20 affected files. Having said that, it took almost 3-days to get this working right, and do the merge using SVN’s tools, both because of my relative inexperience with SVN and the way Rutgers initially setup our repository. Having said that, I do believe that going through this pain will make the next larger merge (2.4? 2.5?) easier, as well as being good experience to ease migrating to Samigo, Melete, and JForum 2.4.

Notes

• I used Glenn’s .subversion/config for things like auto-props and eol conventions. SVN sets a lot of commit preferences on the client side, so I’ll commit this as well, and we should try to sync up on a common configuration
• Keyword substitution had to be turned on in our repository (svn:keywords) in order to get svn diff and svn merge to work as promised and omit spurious conflicts caused by keyword substitutions — this especially hurts if your files use the $URL$ keyword and come off of a SVN tag…
• I had to do a clean import of 2.3.0 into our vendor tree in order to get clean diffs when I pulled in 2.3.1, since keywords had to be substituted for both imports
• I had to use the trunk version of svn_load_dirs.pl and patch it — see Bug 2789 — to get the vendor branch to work
• /sakai/trunk in our SVN has been updated to point to the new code, through externals mappings, though given my experience with SVN merging we will likely move to a fully realized trunk in the not too distant future.
• /vendor/sakai/current is an exact replica of 2.3.1 minus 5 files that SVN would not import correctly (1 croation js calendar localization and 4 docbook XML files)
• Then I ended up merging changes from 2.3.0 -> 2.3.1 module by module into our local Sakai repository

That was it!

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.

ongoing · OpenID at Work – This caused a GIGANTIC thread on the identity-gang list that got back to the question of implicit authorization off of an authentication source. I know when I was looking at Rutgers IdM infrastructure, assumptions about what having a credential meant was a serious barrier to then expanding issuing of credentials/access to a wide variety of useful groups (prospective students, alumni, parents…)

Faizan got PersonDirectory working — after several updates and IRC exchanges with Eric. So uP3 now hits Rutgers LDAP to retrieve a mapping of our person attributes. Hard to test since the Portlet spec makes you explicitly declare the user attributes a portlet recieves. Probably privacy friendly, though writing a “show me all the attibutes” portlet is harder. Hmm… webproxy a JSP that calls the PersonDirectory service directly?

Published a couple of sample portlets (again after much wrangling with the provided UI and an interchange with Eric). The Pluto/Portlet view of the Universe makes sense in a convoluted manner, but probably needs to be hidden more closely from the user and maybe even administrator. It seems like administrator roles should be separate enough that they get a dropdown list of the deployed “portlet applications” and just deal straightaway with defining subscribe-able portlets. That and clicking on hyperlinks to do stuff/submit forms feels very odd to me and took a while to get.

Continue Reading »

Project looking to provide a super-inbox for important notifications. Using the Kuali Enterprise Notification service – again use cases look a lot like the myRutgers Alert system. Actually, sounds like the vision of our alerts combined with announcements combined with other things.

• avoid the overloaded email box
• integrated with workflow
• user & group addressing
• audit trail

I wonder – sounds like creating basically a Institution email type messaging box. Are users going to use a separate box? Staff probably, but students? The range of events sound like they could generate a high noise ratio.

Continue Reading »

Building components aimed at serving needs of Kuali (Finance, Research, Student?), but hopefully reusable in other contexts. Kuali Rice – middleware to facilitate workflow, ESB, notification “Nervous System”

“Rice Client” tied into ESB to pass around real-time messages and communication. One of the goals seems to be to limit the amount of Java code in a client through a service layer, supporting RAD against this framework. Then you plug into the bus which provides service registry, remoting, etc. Sounds a lot like the RMI use-case is a key consideration. Client should support a lot of the service wiring and other connection details. Pushing to looslye couple separate products, and provide technical consistency.

Continue Reading »