Tag: Scripting

Alfresco Tech Talk Live: Leveraging Alfresco Share for Collaborative Enterprise Authoring

Posted by on June 04, 2009

Tomorrow (Friday June 5th, 2009) at 12pm EST I have the pleasure of presenting and leading a discussion for the bi-weekly Alfresco Tech Talk Live hosted by Dr. Yong Qu of Alfresco.

We’ll be exploring how Alfresco Share, with some basic modifications, can be leveraged to create a collaborative authoring and management environment for your enterprise content. Join us tomorrow for a demonstration and open discussion as we explore this interesting subject.

To attend, please visit http://alfresco.acrobat.com/live and enter the meeting room as a Guest.

Alfresco Community Meeting in NYC 2009

Posted by on May 11, 2009

Last week I attended the Alfresco community meetup in New York City. The turn out was impressive. Nancy Garrity (Alfresco Community Manager) told me that the event was completely “sold-out” and that there was not enough room for everyone that wanted to come. I was sorry to hear that we were not able have everyone there that wanted to be there but it’s really great that there is so much interest in Alfresco.

The session got underway with Ian Howells, Alfresco’s Chief Marketing Officer, who reviewed the trends in favor of open source ECM, not the least of which is the accelerating demand driven by the global recession.

Michael “Uzi” Uzquiano, Product Manager for Alfresco WCM and Alfresco Network, then laid out a roadmap for Alfresco WCM, Surf and Alfresco Network. Some key highlights were:

• Repository harmonization. Alfresco provides two distinct content stores: the Web Content Management (WCM) repository, and the Document Management (DM) repository. Alfresco is bringing these two stores together at the API level and then consolidating many of the core capabilities.

• Clustering for the WCM repository (not just DM) is under development.

• New Forms Service: Alfresco WCM has long had a capability for defining forms. A user can install an XSD in the Data Dictionary. The XSD is then translated in to a Web form that provides a friendly user interface for reading, modifying, and storing XML. The DM repo does not have such a feature. Instead, within DM property sheets map to the underlying content model. Many users have requested both capabilities be available uniformly for both DM and WCM. Alfresco is responding to these requests with the new service. The new Forms Service will have a much more powerful persistence capability. I asked to find out if customers who already have XSD form definitions in play would need to change to a different format. I was told that these customers should be safe.

• Spring Webflow integration with Surf: Spring Webflow is the project in the Spring Portfolio that focuses on providing the infrastructure for building and running rich, Java-based web applications.

Uzi laid out a timeline for future Alfresco releases:

1. v3.2 Labs targeted for June

2. v3.2 Enterprise targeted for September 2009

3. v3.3 in early 2010

4. v4.0 later in 2010

In addition to Uzi’s presentation, a number of other presentations and demos were also given. I particularly liked the customer case study given by the Warren country Correction Center. They process a large volume of inmates in and out of the facility. Each time an inmate is processed in or out of the correction center a large volume of paper work is generated which must be stored for long periods of time. Warren country is now well on their way to eliminating the need to store large volumes of content in physical file cabinets. They have implemented an Alfresco based solution for archival and retrieval of inmate data. Electronic storage of the inmate information allows the correction center to quickly search and retrieve important information on inmate background, health, behavior and other important documents for both operational and legal functions.

Other demonstrations included
• Scanning best practices and an Alfresco-integrated Kofax demonstration.
• A walkthrough of Alfresco Share
• Digital tampering protection through an integration with Surety’s Absolute Proof.
• IMAP demonstration that allows your email bin and folders directly with Alfresco.
• A demonstration of a Flex UI for Alfresco.

I gave a presentation entitled “Leveraging Alfresco Share for Enterprise Content”. At Rivet Logic, we get a lot of requests for solutions to help authors manage deep, inter-related content types that need to ultimately be published to numerous channels, including the Web. In addition to the publishing requirements, enterprise class assets usually benefit from an authoring environment that includes social and collaborative capabilities like those found in Alfresco Share. To address this, we demonstrated a number of best practices and design patterns for managing enterprise content with an authoring environment plugged in to Alfresco Share combined with an instant Web preview capability. Based on the feedback, the approach seemed well received. Like many of our customers, members of the Alfresco community are quite interested in collaborative authoring environments for enterprise class content.

It was great to meet with everyone who was able to attend. These types of events are vital for the community. It’s a perfect time to give Alfresco feedback and for the customers and community to meet one another.

Keep it ‘Lite’ (Part I) : Layer your platform for development agility, performance and lower development costs

Posted by on October 24, 2008

This is Part I of a series that I will be doing on factoring your software architecture for development agility, software performance, and total cost of ownership (TCO).

When object oriented programming first arrived on the scene (25 years ago!), it delivered important concepts: encapsulation, polymorphism, and inheritance. These concepts were designed to help the developer factor code. Proper factoring reduces complexity, redundancy and cohesion. One of the most powerful factoring techniques in programming is grouping for reuse.  Functions, Objects, and Aspects are all code groupings that organize an area of concern for reuse.

Code reuse and other factoring techniques tend toward greater simplicity and development agility. These characteristics have an important and positive impact on cost and revenue. There is no doubt that software development can be an expensive undertaking and at the end of the day it’s always about the economics.

As we have observed, programming languages have been evolving to help manage complexity and make software development more efficient and effective.  As computing power continues to improve, platforms are also evolving to improve development agility.  For example JAVA introduced the JVM and the concept of “write once run anywhere.”  It’s clear that the JAVA platform (as opposed to the JAVA language) provides clear agility over languages compiled to specific machine architectures because it removes the dependence on specific machine architectures by introducing an abstraction; the JVM. It has greatly simplified building, packaging and the distribution of software.

Today scripting languages are mainstream.  Scripting languages are generally loosely typed and are interpreted rather than compiled. There are debates between what might be termed the “systems level programming languages” and “scripting languages.”  Some in the traditional camp cite that scripting languages lack rigor, and claim that it won’t perform when compared to their compiled counterparts.  Those in the scripting community point to “extra work for little value” and complex deployment environments as the other side of the coin.  The communities around PHP, Ruby, Python, PERL, Groovy and others boast impressive development agility characteristics over JAVA, C++, etc.

It’s unlikely that there is anything inherent in the languages available today that drastically change the agility characteristics of development in those languages.  Most of the mainstream languages have similar concepts and differ in terms of syntax.  While some expressions may be quicker in one language over another, it’s unlikely that any of the mainstream language’s syntax will produce agility characteristics that are orders of magnitude above and beyond the others. That is to say, it is not the “PHP” in “PHP” or the “Ruby” in “Ruby on Rails” that makes them faster to develop in. It’s platform and architecture that accounts for the difference.  PHP, Ruby and many other examples are interpreted rather than compiled and this means that when a change must be made to a program there is no need for a recompile and no need for a restart.  Just change the code and (in the case of the web) hit refresh.  In the same way JAVA cleaved an entire effort out of the development process (building for individual architectures), scripting languages have cleaved a massive time sync off the hands of developers by making it easy to modify code “on-the-fly.”   I believe that scripting and compiled languages are not at odds but rather they are complimentary.

The strong typing, static analysis and offline assembly of byte code makes perfect sense for framework or systems oriented code.  This code is not likely to change much in the course of an implementation but is executed frequently. Framework code often defines the performance profiles of a system.  You always want to optimize when possible.  Where there is no absolute requirement for interpretation and no strong value proposition it should be avoided.  That is to say favor compilation over interpretation where interpretation does not deliver significant value.  Don’t make the machine do the same work twice when it can be avoided.

Application level code (as opposed to framework code) changes often.  Developers benefit from the ability to easily write and run code without having to restart servers and perform compilations and deployments.  Application code has a lifecycle and release cycle that is much different from infrastructural / framework code.  This becomes more and more apparent as the framework matures and changes less and less often.  They are two different types of code with two different lifecycles.  Businesses don’t want to spend more time on framework than is necessary.  The value is in the applications and this is where agility matters most.

The optimal approach doesn’t have to be one or the other (although in some cases it is.)  Each platform plays best to a different set of concerns.  In software, a common approach for tackling separation of concerns is called layering.  It is possible to layer a system by using a traditional, compiler based language and platform (such as JAVA) for infrastructure needs while leveraging scripting languages and template technologies (such as PHP, Ruby, Groovy and so on) for the application layer.  By doing so, you combine the success characteristics of both platforms: compensating for weaknesses while playing to strengths. To understand the power and success of this approach, one needs to look no further than Excel; a truly killer application.  Excel is a framework.  You bring the application to it when you build your spreadsheet.  Excel’s (a compiled, c++ based application) power is opened full bore with the VBA scripting environment.

We also see this approach taking hold in the web space with packages like Bean shell, groovy, JRuby, Quercus PHP and so on.  At a recent community conference Alfresco, an open source enterprise content management platform demonstrated SURF, a java based framework that enables developers to code applications in server side Javascript.  Alfresco used the SURF platform to create its new Share application (a Share Point alternative.)  They are moving away from developing in pure JAVA because it just doesn’t provide the agility they need to compete at “internet speed”. Instead, they will continue to build their core repository and framework in JAVA but applications will be built based on SURFs support for Javascript and templates.  It’s powerful and fast as a development platform.  The productivity Alfresco has demonstrated in the last year is truly impressive and a testament to layering the two types of development platforms.  Use the right tool for the job and it will get it done better and faster every time.

I’d like to point out one more important outcome of layering your development platform. In doing so you can greatly reduce the learning curve that one must overcome before one can develop for the system.  A relative few people know how to program in JAVA.  However a great many more people have at least some experience programming in Javascript and even more have experience with PHP.  Why?  That’s simple. Javascript is common on web pages. PHP is offered by almost every ISP on the planet and it has a huge online community from which one can find code examples.  When you layer your system you get all the technical benefits of JAVA on the back end with all the benefits of easy to develop code on the front end (the application) in a way that is open to a very wide range of developers; for example: The core framework written in JAVA and the application consuming that frame-work written in PHP (Quercus PHP is an Open Source, JAVA based implementation of PHP5).

PHP developers tend to be much more available and affordable than JAVA programmers. It’s simple economics.