Archive for the ‘java’ Category

Diving into the talent pools

Tuesday, July 21st, 2009

Even in this down economy, finding technical talent can be extremely difficult. Résumés are worthless. It comes down to this: programming is a craft but we don’t get to see the craftsmanship and creative process when we hire programmers. At least not before we narrow down the application pool of thousands to a short list of real candidates. After that, during the interview process we can do things like logic questions and programming exercises to see how the programmers solve problems.

The issue of finding talent is a very real concern not just for start-ups but also for established organizations that are selecting technology (like a CMS) that they must staff up to support. The natural tendency is to go by the numbers. Choose a technology with a “household name” like Java, .Net, or PHP where programmers are a dime a dozen. You are bound to find a needle in a haystack that big. Where this logic breaks down is that when a technology is so widely known and used, everyone seems to have it on their résumé. You can’t tell if the candidate just spewed out a few hundred lines of crappy code or if they have immersed themselves in the technology to the point where they understand the core principles and philosophy. You can’t tell if they are a talented craftsman and are able to learn new things. By selecting a household name (commodity) technology you have just made the haystack bigger without necessarily adding more needles. It is hard to find a Jamie Oliver by putting out a search for people who can make a hamburger.

When it comes right down to it, a language is just syntax that lets you do things like assign variables, create conditionals (if statements), and loop through lists. Learning what is available in libraries is the true learning curve when it comes to a technology and those libraries are constantly changing. So a good programmer is always learning. One of my favorite books about programming (The Pragmatic Programmer: From Journeyman to Master) recommends learning a new language every year to expose yourself to different approaches. The best programmers love the challenge of learning a new language or framework. They read books on different technologies and practices. If I was hiring a PHP developer, I may get an even better result if I found a great Java developer who is open to working in PHP. Of course, then I would have to find a great Java developer. If I was looking for a great Java developer, I could see myself looking for people who have worked in Python, Ruby, Groovy, or even Scala. That would show that they are committed to learning new things rather than churning out code the same old way.

When you look at it this way, the relative size of the “talent pool” should not drive you to a technology choice. You want to choose a technology that has proven itself to be more than a fad so that it will continue to evolve and mature. You want to work with a language that has good resources for learning (like articles, books, IRC, and mailing lists). But you don’t want a technology just because a majority of technologists claim to know it. Most importantly, you want a good programmer. If a technology is sound and effective, a good programmer will be able to learn it and be productive with it.

Making developer docs more accessible

Thursday, January 8th, 2009
Java EE - crxdeploy/build.xml - Eclipse SDK - /Users/sethgottlieb/Documents/projects/clients/time_interactive/development/crx-clean-ab
Uploaded with plasq’s Skitch!

What do developers hate more than writing documentation? Writing documentation that nobody will read. I think everyone has been in a meeting and heard someone complain about needing some information that they didn’t even bother to search the wiki or document repository for. But what if the documentation was already in the developers face?

New
Uploaded with plasq’s Skitch!

A few weeks ago, a client turned me onto “Cheat Sheets” in Eclipse. Those are the little instructions that appear on the right-most frame of the Eclipse IDE. You may have used one of these Cheat Sheets before (and not known what they were called) but you probably didn’t know how easy they are to create. Simply choose the “File | New | Other” menu option and then, under “User Assistance,” select Cheat Sheet. This will give you a simple editing tool to create step by step instructions. The underlying XML is very simple so you can also just use Eclipse XML editor if you want to.

Java EE - crxdeploy/testing.xml - Eclipse SDK - /Users/sethgottlieb/Documents/projects/clients/time_interactive/development/crx-clean-ab
Uploaded with plasq’s Skitch!

This form of documentation is best for things like development environment setup. It is not so great for API or architectural documentation. It assumes that the developer is using Eclipse and has been able to check the appropriate source tree out of the source code repository because the documentation is stored within the project. I would use this in conjunction with a README and INSTALL file. README would be used for information about the application (version, usage, recent changes, open issues). INSTALL would be for someone installing the compiled application. The Cheat Sheet(s) would be for developers that are getting their Eclipse environment together.

Is anyone else using this feature? If so, have you found it effective?

InfoGlue shows some life

Wednesday, October 8th, 2008

I was just catching up on some of the open source web content management platforms that I track and noticed the new InfoGlue site. Around a year and a half ago I had given up on InfoGlue because so little had happened. Then I saw Dang Huu Cu’s cmf2007 presentation on the United Nations Development Programme Vietnam’s use of InfoGlue. Still, very little was happening on the project at the time.

While, I wouldn’t say that InfoGlue is thriving, There appears to be some life in the project. They put up a new release (2.9.3) in this September and the site looks much better. They will be holding an online conference on Monday October 13th.

Duh – I Get it Now

Friday, July 25th, 2008

I can’t remember if I knew this before but someone recently mentioned that the Eclipse project was named as a dig on Sun Microsystems. Get it? Sun, Eclipse? I always questioned Sun’s lack of involvement in Eclipse. I don’t know if it was only the Eclipse project itself but I would say that the Eclipse supporting companies (like IBM, Oracle, and Borland) are eclipsing Sun in their Java-oriented businesses. Hostility aside, this is a good example of using an open source project as an opportunity for companies to collaborate and cooperatively force market change. Other examples include the many open source projects that were established as reference implementations to push forward a standard.

Other hostile open source project names:

  • Fuzed is for F-U Zed. Zed is the guy who wrote Mongrel
  • GNU stands for GNU’s Not Unix.

Any others?

Give Your Repository a REST

Tuesday, July 22nd, 2008

Through my research and my client work I have been running across this recurring pattern of exposing a content repository through a REST interface. In the past, I have written about the JCR and Sling and Alfresco’s Web Scripts architecture. I really like both of those implementations. More recently, I have been working with a client who has built their own REST interface on top of Day’s CRX. They started their project before Sling was a glimmer in Apache’s eye and they took a slightly different approach. Instead of using Sling’s repository-oriented request handling, or Alfresco’s model of registering a Web Script (written in Javascript) to a particular path, my client has built out a full URL based query syntax through a servlet. Right now, the syntax focuses on searching retrieving content and is very powerful.

The strategy of using a REST API for your repository solves a central problem with the JCR and other Java base repositories: remote connectivity. Without a remote connectivity infrastructure like JDBC or ODBC, technologies wishing to talk to a Java repository must resort to connectivity like RMI (Remote Method Invocation) that are inefficient and do not necessarily play nicely with firewalls. While not particularly efficient (lots of protocol layers and text processing), REST offers a nice foundation for enabling remote connectivity at the appropriate layer of abstraction (that is, how content is logically stored – not how it is physically persisted). There are many reasons why REST is a good strategy but I think that the most important ones are:

  1. There is great infrastructure available for optimizing and controlling HTTP traffic. For example, reverse proxy technologies like Squid can stand in front of the REST interface and serve repeated requests out of cache. Firewalls can be used to filter traffic with rules that evaluate the requested path and requester origin (beware IP Address spoofing).
  2. REST is entirely technology neutral. Everything talks HTTP and XML. You can replace the implementation of either the server or the client with little risk to the overall architecture.

I think the only downside is that developing your own API is tricky business. While you are free to change your underlying data structures, once you publish your API and start writing applications on it, you lock yourself in. Where possible, it is best to support standardized query syntax like XQuery or the JCR query language in addition to your domain-specific methods.

I expect to see this pattern of REST-based repository access to be pretty much the standard as we get into Web 2.0 architectures that support mash-up applications. If they can address the overhead of all the text handling, more and more systems will use REST API’s to de-couple the various components in the application stack. Something to consider the next time you design a content-centric application.

Nuxeo Web Engine

Friday, July 11th, 2008

Nuxeo just announced the first official release of their WebEngine. I have been hearing updates about this project for a while and have been meaning to check it out. From glancing through the slides, WebEngine seems very similar to Apache Sling and has many of the things that I like about Sling: a RESTful interface and a lightweight, content-centric programming model. In WebEngine templates are written in FreeMarker and you can script in your choice of Groovy, Python, Ruby, Javascript and other languages (thanks to JSR 223) which provides a scripting interface for Java applications). I am looking forward to playing around with WebEngine. In my past experiences with Nuxeo applications, I found them to be well engineered.

If you are new to Nuxeo, they have a legitimate claim to being the first open source ECM company. Their primary geographic focus is in France and they are less well known in the US. Nuxeo’s original ECM product (which combined Document Management, Collaboration, and Web Content Management) was written on the Zope platform. In 2006, they ported their product (then called CPS for Collaborative Portal Server) to a Java stack (using JBoss Seam). Long time readers of this blog may remember me being skeptical of whether they could pull it off. It turns out that they did a great job with the migration and have been aggressively pushing the platform forward.

Like, Alfresco, Nuxeo’s experience and customer base leans towards the document management side of ECM. Web content management is a newer focus that is (I think) well timed as more companies are looking for ways to rapidly build internally and externally facing content centric web applications.

First Official Release of Sling

Monday, June 30th, 2008

The Apache Sling team recently announced the first official release of Sling. Now you can download some nicely packaged Sling bundles to play around with.

I have been experimenting with the Sling/CRX bundle that came with Day Software’s JCR Cup 2008 competition (entries due midnight September, 30) and was really impressed by what I saw.

Sling allows you to write applications on top of the JCR using either server side or client side Javascript. On the server side, you can create Java Script Templates (ESP files) that give you access to the full JCR API. Templates are stored in the repository and called using an elegant MVC request processing framework. Templates can be called directly, or can be associated with content types and executed when an asset of that time is requested. As you might expect from Roy Fielding’s employer, it is all very REST. For client-side scripting, you just import a Javascript file called sling.js and you get methods like “Sling.getContent” (which gives you an array of Javascript objects).

Despite the fact that Sling is still an incubation project, it is fairly mature and robust. Day’s upcoming release of Communiqué (version 5) uses Sling extensively. I envision Sling being used in a presentation tier where pages are statically rendered (baked) from content in the JCR and Sling is used to power dynamic AJAX overlays using content from replicated JCR workspaces.

I really like the fact that logic is written in an interpreted language like Javascript. Development and deployment is faster when you take out the compilation step. Furthermore, Sling is built as OSGi (using Apache Felix) bundles so it is more modular and flexible than a typical monolithic Java web application.

The CRX (or the free Apache JackRabbit implementation of the JCR) and Sling should be considered along side Alfresco with its elegant Web Scripts (which also uses Javascript as a scripting language). Alfresco has some nice virtualization features but there may be a higher level of lock-in to the Alfresco API’s. Alfresco has a user-oriented user interface while the CRX only has a JCR browser which is really only intended for administrators. However, in both cases, you will probably want to develop your own user interfaces because Alfresco’s current WCM UI is not optimized for managing web content (improvements are scheduled for mid 2009 – interestingly, the Alfresco team is calling these enhancements “project Slingshot).

Book Review: OpenCms 7 Development

Thursday, June 19th, 2008

I just got through reading Dan Liliedahl’s book OpenCms 7 Development (Packt Publishing). I met Dan when I was at the OpenCms Days developer conference and was impressed with his presentation. Dan knows his stuff (not just about OpenCms – he worked for FutureTense in the early days).

The book was first introduced at the conference. I was surprised that Dan was able to get it out so quickly after Version 7 was released. It seemed like Version 6 was out a long time before a book on it came out. Dan did mention that writing about the product as it was being developed was a challenge.

When I started reading the book, I was pleasantly surprised to not have to go through any content management theory. The book stays true to its title. Not that theory isn’t important but I think it is reasonable to assume that someone developing on a CMS knows the about the basic concepts. If you don’t, some background reading (and also some requirements analysis too) is in order.

One short-coming about diving right into the OpenCms architecture is that the beginning is a little choppy as the author tries to orient the reader to the platform (OpenCms is a very mature and elaborate application). Although it is choppy, there are some very good explanations of things like OpenCms’s request processing chain and how the code is organized. There are also excellent tips on configuration management and how to configure your IDE. Still a reader may want to supplement the book by reading some additional OpenCms doc to help introduce him to some of the bigger OpenCms concepts.

The book hits its stride as it gets into the examples, which revolve around building a blogging site. There is good coverage on everything from creating content types and display templates to building extensions. By over-engineering some of the design, Dan is able to go into depth in modularizing code and managing logic in Java classes. Dan’s experience in building big sites shows in how he designs for manageability and reuse. All the code is put into modules that can be exported and deployed to different OpenCms instances. The book also covers some of the new features like WebDAV, the new security model (with organizational units) and the relationship engine.

The one area that I think could use a little more coverage is on the TemplateOne and TemplateTwo frameworks. Dan builds everything from scratch to show how OpenCms works but these frameworks allow you to get up an running with less development. Unfortunately, neither of these are particularly well covered in the OpenCms documentation. Perhaps a whole book on TemplateOne and TemplateTwo is in order.

Overall, OpenCms 7 Development is a must read for anyone who wants to implement robust sites on the OpenCms platform.

OpenCms is covered in the Open Source Web Content Management in Java report. The standalone evaluation of OpenCms is also available.

Fireside conversation

Tuesday, May 13th, 2008

Entrance, originally uploaded by stevenn.

[Update: Steven posted slides from the facilitated discussions on slideshare]

Thank you Outerthought for all the kind hospitality and for hosting the first fireside conversation. The event was a great success (pictures) with a fantastic audience and thoughtful participation during the facilitated discussions. I have a feeling that there will be more events like these so be sure to register for the next one!

Alfresco releases Enterprise Edition 2.2

Thursday, April 24th, 2008

They are a bit behind schedule and there was very little publicity about it but Alfresco Software has released version 2.2 of Alfresco Enterprise Edition. While this is just a point release, 2.2 introduces a couple of big improvements over 2.2. Probably the most welcome enhancement from a user perspective is the introduction of search within web projects. While web projects were always indexed for search and the API supported it, users can now search for web content from within the user interface. Developers will appreciate that the deployment mechanism that came with 2.1 now has a GUI that allows developers to define deployments to push code or content to different environments.

While it still suffers from some core usability issues, with version 2.2, Alfresco has reached a point where it is a useful tool for web content management. Many systems integrators work around Alfresco’s usability limitations by using Web Scripts to rapidly develop custom user interfaces. Expect bigger UI improvements in Enterprise 3.0.

For more information on Alfresco 2.2, you can buy the 19 page Alfresco evaluation from Open Source Web Content Management in Java or buy the whole 160 page report to see how Alfresco stacks up against other options.