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.