Google releases Wave protocol implementation source code – Ars Technica: “At the Google I/O conference earlier this year, the search giant revealed an intriguing new communication service called Wave that aims to deliver concurrent messaging and collaborative editing in a single cohesive environment. The underlying Wave Federation Protocol is designed to make it possible for third parties to host their own interoperable Wave instances. Google intends to open the source code of its own implementation in order to encourage widespread adoption of the protocol. The company took its first major steps in that direction on Friday by releasing the source code of its Operational Transform (OT) code and a simple client/server reference implementation that is built on top of the protocol. This code, which is available under the open source Apache Software License, will give developers a way to start experimenting with the protocol and potentially even building their own Wave-compatible services.”

(Via http://arstechnica.com.)

I hate to hop on the bandwagon, but I have to admit – Wave looks like the most revolutionary item I’ve seen in a while – in a full-on game changer sense. Not so much just because of the cool widgetry that Google’s built, but because it’s a protocol – with the flexibility and potential that implies.

Building on some of the interactions we’ve seen with IM, Blogging/Trackbacks, Twitter, and other messaging, Wave looks to standardize, federate, and embed real-time, multiparty communications to the point where it will become part of the fabric of the web. If Web 2.0 = comments and trackback conversations – this feels a lot more like Web 2.5 – the implementation we really wanted when we first tried to take the web from a document-based publishing platform to a conversation-enabled collaborative medium.

And… Open-Source production-quality reference implementation – what could be better. I have to say, not an small number of my off-work hours are going to be spent looking at embedding Wave into… everything… Particularly given that Federation (though still a little nebulous) is a first-class citizen in the platform.

We’ve been looking at expanding our development team (contact me if you’re an awesome developer, passionate about what you do, and like people and work) and so I’ve been screening a lot of resumes and CVs recently. If you’re a candidate, keep reading and tell me in your interview you read this. If you’re just interested, keep reading, though this is really just my opinions, combined with some rants.

Things I look for in resumes:

• Strong command of written & colloquial English (see below for more)
• Experience spanning multiple vendors, platforms, open-source, etc
• Specific accomplishments (less ‘managed/coordinated’ more ‘wrote/implemented’)

Things that are likely to put me off:

• Excessive keywords/technologies (with no examples)
• Cut and pasted roles/responsibilities for projects (e.g. every role listed)
• More experience with a technology than it’s been in existence
• Obvious grammatical/spelling/usage errors

It somewhat surprised me after thinking about it how little time/credence I give to scanning technologies listed by candidates. (I do read them, but mostly looking for items that show strong willingness to explore or personal preference; e.g. Grails, Git, IntelliJ). What really excites me for hiring say a Java developer is someone who’s also done, say Javascript, Ruby, scripting, C++, and has some great project samples of things they’ve done for projects where they came up with something clever, or leveraged a neat toolkit to solve some problem.

Really what I’m looking for generally boils down to 2 main factors: communication skills and passion.

Communication Skills: I increasingly view resumes/CVs as an expression of an individual’s ability to communicate in a technical forum. The quality of your resume reflects your ability to write requirements, express technical/design concepts, and communicate with customers. We work in an environment where the first impression people have of you increasingly comes via email, a written document, or some other non-verbal communication. With distributed teams becoming more common, the ability to clearly and accurately communicate without the luxury of all the bandwidth you have in personal settings becomes even more important.

Passion: I want to see some combination of jobs, project accomplishments, technologies, and familiarity with techniques that let me know you’re passionate for both delivering good software, and becoming better at the craft of software engineering. I like to see technologies like open-source libraries, frameworks, projects, and other tools that show you’ve investigated what’s out there in the course of your work. Practices like TDD, Agile, UCD, or others that show you’re continually looking to try, and adopt better ways of working are also a strong plus.

If those pieces are there, then I strongly believe the other fundamentals will follow, which makes it much more likely that someone will get an interview to see if things click in terms of team dynamics and the needs of a specific position.

Ira Fuchs from Mellon is talking about Community Source, and the larger dynamic within the community — successes, attitudes, opportunities, and risks.

zotero is interesting, both as an example of an open-source project that like Firefox has had viral adoption, with a strong community marketing and communications effort. I also wonder if there’s a convincing Sakaibrary integration possibility, perhaps a direct gateway into the Citations Manager tool that let you save or push bookmarks into the citations manager.

Vertox – a plug-in for a plug-in is interesting. Video tagging is a neat application, though in many respect I’ve always thought the combination of OCR and voice recognition to auto index text & words mentioned in a clip, and index them would be potentially more transformative than manual tagging & citing.

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.

Sitting on a flight, returning from the Sakai conference — still trying to take everything in. There’ll probably be more musing on the significance of specific items coming up, but things that struck me enough to want to brain dump were:

• There was wide consensus during the planning sessions that there’s a desire to focus on quality: reliability, testing, performance, and other traits, over new feature development.
• The community is moving from a development -> production mindset. The transition of many of the core schools from pilots or development efforts into full-blown production instances has certainly changed priorities and outlooks.
• Increased desire to pick up open-standards in preference to inventing our own. JSR-168 (Unicon demoed a cool Portlet-Tool for Elluminate integration), JSR-170 and the good work Ian is doing to integrate with repositories like Jackrabbit and Xythos, CAS Authentication (vis-a-vis Dan M.’s sweet CAS-embedding UserDirectoryProvider)
• There’s a lot of commercial activity around Sakai. RSmart, Unicon, Oracle, IBM, bit players like Mark Norton & Zack Thomas. I sat in a presentation about the work I did with FIDM for CampusEAI. I even talked with another developer who has already resigned (as of Jan 1) from his university to join his part-time venture (with others) full-time. Certainly a large, vibrant marketplace.
• Many sub-groups are organizing around Sakai. In addition to our very own NYC Regional group, there are groups in California, Australia, the Netherlands, and other places. They’re holding events, sponsoring training, and moving forward.
• It’s not just regions — there are an increasing number of functionally aligned teams. Developers, Designers, and Managers are the best organized and served. I also saw a lot of User Support people or academic technologists as well. This is the group I suspect may be the next to organize — a CAFE track focused on bringing user support people up to speed or sharing experiences/resources would probably be really valuable.
• Lots of parallel activities. Many examples of SIS integrations, library integrations, documentation & training, tool development. Unfortunately, communication barriers and other difficulties seem to be producing several duplicate/parallel efforts (e.g. Yale’s SignUp tool, EDIA’s signup tool, Stanford’s efforts around this space) though there is a desire to collaborate.
• Some stuff is still too hard: authentication integration, CourseManagement integration, libraries work, documentation, training are all pain points, especially for smaller teams/schools.
• Strong community. It’s easy to get lost in a group of smart, affable people moving towards a common purpose. Had an excellent time, and there’s a good sense of camaraderie weaving throughout the community. People are friendly and helpful.
• Twitter – yeah, it’s kind of narcissistic, but at an event or convention it can certainly be a lot of fun. Both to do self-organizing (e.g. dinner?) and to pull in people who are in the circle, but not present.

<

p>The Ed Techie: What Mailbox limits reveal:

<

p>

Grainne posted recently about the frustration of continually getting the ‘Your mailbox is over its size limit’ in our OU email accounts. I can’t tell you how annoying this – sometimes I am just trying to send a quick response to someone before I have to dash out of the door, but it won’t let me because I have to find and delete any attachment over 2K to free up space. Grrrr.

(Discovered this site through the Edublogs Awards.)

It’s interesting to see the comments on the gist of this article — in terms of how reasonable the restriction or attitude behind it are. IT usage restrictions always seem to generate two separate camps of apologists and critics. Apologists focus on the rational behind it, the need to balance services with resources, and limitations of the technology or workflow. Critics tend to express frustration over inconvenience, limitations, or restrictions that make their work harder, or prevent them from performing a specific action, or in a particular way.

While I can’t claim to have a solution to IT limits (regrettably, my superpowers don’t seem up to the task) I do notice that we seem to have an opportunity for dialog. IT Governance is an increasingly hot topic, particularly with institutions struggling to prioritize during lean budget years. We clearly have a pool of customers who are more than willing to tell us what they think is important.

I think the need to create dialog highlights one of the reasons a number of us found Collier’s MyUMBC feedback feature so compelling. By integrating feedback submission forms into every page, portal visitors are encouraged to communicate their reactions and thoughts (even about email quotas ) making the barrier to contribution very low. At the same time, while many of us have feedback forms that email teams, the MyUMBC example of integrating the admin panel & tools to ease followup/contact make it easy to go back, and mine through the data, or engage customers in dialog regarding their experiences with the product or service.

I’m happy to say that Jenn’s work on the feedback portlet stemming from the JA-SIG Unconference seems likely to move uPortal (and maybe someday Sakai or other portlet containers ) further in the direction of built in mechanisms to collect these user sentiments and provide information so we can work to better address our users concerns, experiences, and frustrations.

Using Sakai in multiple institutional research settings – AERS

Case Study: Adult Literacy – used resources for file storage and as a documentation store, and diary entries stored as discussion entries. Teams liked the ability to contribute entries/discussions asynchronously, and despite being in many separate locations. Site Stats showed that most visits were content reads (~75%) followed by other tasks.

“Communities of Enquiry” – teams used Sakai as a collaborative environment, after a review of literature to assess models and others. Sites focused on encouraging:

• dialogue
• participation
• perspectives
• structure
• climate
• purpose
• control

An interesting characteristic that was noted was that groups tended towards relatively flat permission hierarchies, and high usage of communication tools (discussions, chat, etc – as opposed to other).

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.

http://developers.facebook.com/index.php

Facebook has once again made it the coolest platform ever by opening their API further, and most importantly supporting sessions that don’t expire every 24 hours. There’s been a lot of talk on the web about this helping them to monetize Facebook’s user base through commerce partnerships. I think that’s true, but I also think it’ll have a profound affect on Facebook’s traditional market — college students.

The breadth and volume of Facebook’s usage on college campuses is hard to ignore. In a focus group I had with our career center, a number of students told me that Facebook was basically their primary method of communications. It’s how people share photos, find study partners, blog, and watch their friends all rolled up in one.

I think the key of the new platform initiative is that integrations like Duke University’s DukePass portal integration that drive Facebook into the heart of institutional IT initiatives. There’s just too many users, and it does stuff too well.

So not only is Facebook broadening their reach — they’re also tightening their ties to their core audience. And the possibility to actually partner with institutions, as opposed to having to grassroots everywhere. Bottom line — smooth move.

I finally get REST. Wow.

It’s depressing to think that SOAP started just about 10 years ago and that now that everything is said and done, we built RPC again. I know SOAP is really an XML messaging protocol, you can do oneway async stuff, etc, etc, but let’s face it. The tools make the technology and the tools (and the examples and the advice you get) point at RPC. And we know what the problems with RPC are. If you want to build something that is genuinely loosely-coupled, RPC is a pretty hard path to take.

This generally sums up what I’ve been thinking about the whole SOAP stack. Java, .Net, all seem to wrap SOAP in something that looks like RPC — and results in lots of brittle implementation where making minor changes to the services causes incompatibilities. Admittedly, this isn’t necessarily true, but it seems like to have really loosely-coupled services, you need to be explicitly thinking about passing messages around, and designing a good forwards-compatible message/document format.

Continue Reading »