One of the only things I have been missing on the Mac has been a good Subversion client. Yes, there is the Subclipse plug-in for Eclipse but unless I am doing prolonged Java coding, I don't want to wait for Eclipse to start up. There is also the command line client but I like a GUI to easily visualize what has changed (yes, I know you can do that on the command line if you can remember the commands). I was looking for something like TortoiseSVN - actually better than Tortoise because Tortoise has the annoying tendency of slowing down Windows Explorer.
For a while I was using the Syncro SVN client. It came with Oxygen and was fine. A couple of days ago my friend Brian told me about Versions and Cornerstone. I have been playing around with both of them and am really impressed. Both are really new (Versions is still in Beta) and they feel like native Mac apps. Versions looks a little like another favorite program of mine: Things. Cornerstone costs $59 for a single user license. Versions hasn't announced prices yet.
Both Versions and Cornerstone are more powerful than their thin documentation would have you believe. For example, neither have instructions on how to branch a folder and neither have menu or contextual menu items to execute this action. However, by holding down the alt key and dragging a folder you can effectively branch.
After going back and forth between Cornerstone and Versions, I am finding Cornerstone a little more intuitive. In particular, I like how Cornerstone shows how many files you changed in Mail.app kind of style. Also, I found the notion of "repository" and "working copy" bookmarks a little confusing although I am sure it wouldn't take long to get used to it.
This summer I have had a crazy travel schedule so I was not able to attend the OSCON conference in Portland. I really need to get out there one of these days. Fortunately, the O'Reilly bloggers and Matt Raible have great notes from the conference. The speaker presentations are posted on the OSCON site and the keynotes are supposed to be available on BlipTV but I just checked and they don't seem to be there yet. While "virtually" attending a conference doesn't provide all the social and interactive benefits of physically being there, it is better than nothing.
The Google
blog posted that they passed the 1 Trillion pages milestone. They go on to say that the web is actually infinite thanks to websites like online calendars with "next" buttons that go into the future indefinitely. It makes my little corner of the web feel even smaller than usual. Even "billions and billions" seems small.
I remember hearing somewhere that Google is better positioned than anyone to handle large volumes of pages because their indices use a unique proprietary database and storage technology that can scale far beyond traditional relational databases. It looks like they are going to need it.
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
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:
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).
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.
The Django community recently announced the first official Django conference. DjangoCon 2008 will be held at Google's Mountain View headquarters on September 6th and 7th to coincide with release 1.0 of the platform. Admission is free (as in beer) but they are capping the attendance at 200.
If you are new to Django, Django is am open source web application development framework written in the Python programming Language. Despite its sub-1.0 status, Django is quite mature. It was first developed by the folks over at Lawrence Journal-World for sites like ljworld.com, lawrence.com, and KUSports.com. Later, Rob Curley assembled a team over at the Washington Post to build a bunch of local sites. Now Django is bundled and actively used in Google App Engine. There area also a number of books on Django. I am currently reading the Definitive Guide to Django by Adrian Holovaty and Jacob Kaplan-Moss. So far, so good. I see a lot in common with Rails and the two definitely seem to get along at least at a philosophical level.
I will be covering Django in an upcoming report about web content management in media and publishing because of Django's widespread use in that industry. There is a small commercial CMS called Ellington that is specifically designed for the newsroom. Do you have any experience with Django or Ellington? I would love to talk to you about it.
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.
In the old days, corporate websites and externally facing web applications used to be managed by the only group that knew anything about technology: corporate (or enterprise) IT - along with email, phones, and printers. However, as companies are incorporating websites and web applications as part of their product strategy, externally facing applications are starting to run into limitations from being managed by enterprise IT. They need more product oriented ownership. You could argue that if a piece of technology is externally facing (be it a customer extranet that supports customers use of the product, a marketing campaign website that brings brand value, or a service that a product plugs into), the technology is part of the product.
Product and enterprise technology are like yin and yang. Product technology requires constant innovation like the product it supports. Product technology is in a state of constant motion as it reaches for new opportunities to differentiate from competitors and serve customers better. Enterprise technology, most of the time, is the opposite. Enterprise technology needs to be as fixed as possible so that it can serve as a solid foundation to support various business processes. It is a cost center and money saved goes directly to the bottom line. A good enterprise technology manager looks at requests for change with skepticism. "Why is the change necessary?" "What are the risks if we do it?" "What are the risks if we don't do it?" "What is the ROI?" If enterprise IT didn't think this way, they would be rolling out a new phone system every week and that would be bad.
A best practice is having technology groups that report to the business unit that their technology serves - not to the centralized CIO who is responsible for everything from buying desktops and printers to email servers. The companies that are structured this way can be more agile and there is less tension in getting things done. The trend is definitely moving in this direction. By comparison, companies that lump all computer oriented technology together remind me of people who think that, because I work in "something related to computers," I must know why there's is broken.
The big problem with this decentralized technology strategy is that it can be highly inefficient. There will be redundancies in software, development, and people if every department has its own IT group. The role of the CTO (or the CIO if there is no CTO) should be balance efficiency and opportunity by setting parameters on the freedoms of technology choices of the different technology groups and establishing mechanisms for deploying and running these systems efficiently. The model may be similar to the manufacturing industries where the product designer has freedom within parameters set by engineering and manufacturing. In software, the business unit would build applications in a sanctioned (and supportable) set of tools. At Google, that is C++, Java, Python, and JavaScript. There may be a server platform and database that enterprise IT is good at managing. The business unit's product-oriented IT organization builds the application, tests it, and then hosts it on enterprise-managed infrastructure (or, better yet, a 3rd party data center). The business unit is responsible for fixing and enhancing the application. Enterprise IT keeps the servers running.
In practice, many companies work this way by having business units and departments hire outside systems integrators to be their own product oriented IT. That usually works well except for two problem areas: enterprise IT staff feel like they were circumvented on a project they should own and, when the consultants leave, no one knows how to maintain the application. The latter problem is worse if former is not solved - enterprise IT will be even less likely to step up and fix problems in an application that they resent. I think to be successful in the outsourcing model, the department that owns the product needs to have technical people to maintain and extend the application. Or, at least, work with a systems integrator that they can keep on retainer for maintenance.
This has big implications for the business units and departments. They will have more autonomy but they will also have more responsibility. They will need to know how to hire technical people, execute projects, and own technology. This is new ground for many and it will be hard work to get up to speed. But, as business models become more digital, these skills will become harder for business owners to live without.
I have been playing around with services that help me keep track of where I am going and where I have been. So far, the standout application for me has been Tripit. You mainly use Tripit by forwarding the email confirmations that you get from various travel booking services that you use. Tripit parses through the confirmation email and identifies where you are going and when. It also is smart enough to put together several reservations as part of the same trip. For example, if I book a hotel for the January 10th and 11th and a train ticket that leaves on the 10th and returns on the 12th, Tripit knows that it is part of the same trip. I found the email parsing capabilities to be surprisingly accurate. I occasionally try to stump Tripit by forwarding emails from international travel or very small hotels. It almost always got it right. Recently, when using a client's corporate travel service, I noticed an option to add my itineraries directly to Tripit (see screenshot). I wouldn't be surprised if other travel services started to giving their customers this option.
Tripit provides a lot of upside for the minimal effort it takes to forward an email. For one, I get a nice little itinerary that I can print out. The itinerary has the address, confirmation codes, and telephone numbers of all the places that I need to be. It even has maps. I can also subscribe to an iCal calendar of my trips so everything is put right into my local calendar (I use iCal) along with my meetings. This helps prevent me from scheduling meetings when I am en route. My wife also subscribes to my calendar so she has all the details in her personal calendar as well.
The other service that I think I will start to use is brightkite. I will use this to post when I am at a particular place and I want to meet up with a friend. I like the features of brightkite. You can easily "check in" to a location either by address or by using a saved place (called a "marker"). Brightkite suppors a simple syntax that you can use over SMS. Plus you can Ping.fm to email in your location.
I have also tried Dopplr and Fire Eagle. Dopplr didn't do it for me at all. You have to manually enter your trips. I tried to have Dopplr listen to my Tripit calendar but it was horrendously inaccurate. Dopplr had me taking all these crazy trips to various parts of the world and treated lay-overs at different airports as discrete trips. It wouldn't be so bad if Dopplr was not counting my carbon emissions. I hated feeling defensive about all those trips I was not event taking. I closed my Dopplr account.
I am on the fence about Fire Eagle. I should feel very lucky that I have an account there. I hear that invites are very hard to get. But I don't feel like I get much value from the service. Fire Eagle can listen to other services to find out where I am. I have it listening to brightkite. There are a number of other applications which I don't use (like Dopplr, Plazes, and Navizon) that also talk to Fire Eagle. The only benefit that I see is that it gives Yahoo more information to serve me up better ads (which really isn't a benefit for me) and search results (but I use Google search).
So, for now, I am sticking with Tripit and brightkite.
