So today is my last day at Alfresco. I guess it’s natural to have mixed feelings at this point, but when I think of all the amazingly gifted people I have met, the things that we did and the fun we had along the way I feel blessed to have been able to have been part of the journey.

Since I joined in 2005 as the ‘website boy’ I’ve travelled around quite a bit (back when that was a thing), had the pleasure of presenting on technical subjects to many people, many of whom were smarter than me but who gave me their time, attention and encouragement, and worked with some hugely talented but humble engineers, both inside and outside the company.

This was the note I sent round on our internal email group the other day

Nearly 15 years ago (which I remember as it was the week before Christmas and the office was almost empty) I started at a small company called Alfresco, after landing a job re-writing the website. My friends told me I was crazy for taking a job with a company with only 14 employees, but there was something about the three people I’d met during the interview stage (4 if you include JN, who I spoke to on the phone a couple of times, though only because he usually picked it up) that convinced there was something in this open source ECM stuff.

It’s usual when writing these notes to give praise to the technical excellence of your colleagues, and of course that is as true now as it was at the start, but what I think marks Alfresco out more is the humbleness of those people and the time that they have for others, whether in their team, the wider company, our customers and partners or the wider community. I strongly believe that other people notice these things, and the success of the company is in no small part thanks to these qualities.

Although some of the faces have changed over the years, the spirit of the company that wanted to do things differently and disrupt things a little, has not. I am incredibly grateful to all the colleagues over that time who have taught me, given me their trust and encouragement or just shared a coffee or a beer, and from whom I have learnt so much. So thank you.

Alfresco is now part of the Hyland family and I’m sure those people who I will miss so much will do well there. For me some new challenges await next week, more on that some other time.

Following hot on the heels of the 4.2.a release from last week, it’s great to see 4.2.b going out this week with another bunch of improvements before DevCon. I’ve been able to help get a few more changes into the this release, which provide a new dashlet and several improvements for developers.

Notice Dashlet

This dashlet may already be familiar to some of you who have used the add-ons available from Share Extras.
The Notice Dashlet allows site managers to add a custom notice that will be displayed to all site members, and allows this to be done directly from the dashlet itself. Now you no longer need to create a wiki page just to display some basic text on the dashboard!

New Bubbling event for dashlet resize notifications

If you’ve developed any complex dashlets to render maps or other graphics, you’ll appreciate that it’s important to know the vertical height of the dashlet when you render your content. That is easy to get via the Dom or using YUI2’s YAHOO.util.Dom.getRegion() function, but what if the user resizes the dashlet?
Now the resizer module can notify your listeners via the new Bubbling event dashletResizeEnd. This is fired when the resizing has been completed and passes a number of parameters in the event arguments, including the new height of the dashlet, the dashlet element and component IDs and the Dom element representing the dashlet. To subscribe to the event, simply define a new custom function in your dashlet class prototype and bind it to the event in the dashlet class constructor, e.g.

YAHOO.Bubbling.on("dashletResizeEnd", this.onDashletResize, this);

In your custom function you can then take any further action which is necessary, e.g. informing a map instance that the element bounds have changed.

More options for Data List actions

The ability to add custom UI actions to Share’s Document Library is well documented and the add-ons site has a number of extensions which utilize this capability. But did you know the same thing can be done for data list items?
Until now the number of actions that can be displayed in the UI has been effectively capped at three. But now you can easily add new actions of your own there too. Thanks to the work done by Dave Draper these definitions can easily be inserted into the application by using an extensibility module to customize the datagrid.get and actions-common.get components.

As an example, the following code could be used to add the Sample Datalist Action provided by Share Extras to your datalist items, as part of an extensibility module.

if (model.widgets)
{
   for (var i = 0; i < model.widgets.length; i++)
   {
      var widget = model.widgets[i];
      if (widget.id == "DataGrid")
      {
         // These two lines only needed if you want to show the action in the 'actions' cell,
         // otherwise a 'More actions' menu will be created to display it.
         //widget.options.splitActionsAt = 4;
         //widget.options.actionsColumnWidth = 105; // splitActionsAt * 25 + 5
         // Add the action definition - this will be action-specific
         model.actionSet.push({
            id: "onActionSample", // Change to match your handler function name
            type: "action-link",
            permission: "",
            href: "",
            label: "actions.datalist.mycustom" // Change to match your custom label in datagrid.get.properties
         });
      }
   }
}

If you have attempted to customize the existing Edit and Create data list actions with your own custom form configuration, then you may also appreciate the ability to increase the width of the modal dialogs used here, which previously were fixed-width.

Better handling of missing custom previewers

This will mainly be of interest to developers and administrators working with custom viewers in the web preview component, such as the pdf.js viewer in Share Extras’s Media Viewers add-on, and is a topic which I’ll be talking about in San Jose next month.
Previously, if the files implementing the viewer were unavailable for some reason then an error would be thrown in the client-side component. With this change the component now logs that the viewer class could not be found, and this will also be printed on the screen if no other viewers can be found.

Since I migrated away from Windows on my development machine a couple of months back, I’ve not looked back. One of the main benefits I’ve found is being able to build software packages locally, and Homebrew makes that easy. Now I can easily grab the latest version of various dependencies such as MySQL and ImageMagick and install them in seconds, just as if I was using yum or apt-get.
However, one problem has plagued me since I started using the Homebrew-installed version of ImageMagick in conjunction with my local Alfresco installs, with errors such as this in the logs

 2012-08-02 10:20:10,547  DEBUG [transform.magick.AbstractImageMagickContentTransformerWorker] [main] org.alfresco.service.cmr.repository.ContentIOException: 07020000 Failed to perform ImageMagick transformation:
Execution result:
   os:         Mac OS X
   command:    [/usr/local/bin/convert, /Users/wabson/Development/projects/share-extras-2/software/tomcat/temp/Alfresco/ImageMagickContentTransformerWorker_init_source_4067880520213204197.gif[0], /Users/wabson/Development/projects/share-extras-2/software/tomcat/temp/Alfresco/ImageMagickContentTransformerWorker_init_target_7684811633126657147.png]
   succeeded:  true
   exit code:  133
   out:        
   err:        dyld: Symbol not found: __cg_jpeg_resync_to_restart
  Referenced from: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
  Expected in: /usr/local/lib/libjpeg.8.dylib
 in /System/Libra

This frustrated me for a while. It happened every time Alfresco tried to call convert in order to effect an image transform – for instance generating doclib thumbnails – but running the exact same command at a bash prompt worked fine.
Various internet posts all pointed to the environment in which ImageMagick is run as being the cause for such problems. It seemed the environment variable DYLD_LIBRARY_PATH in particular was known to cause problems on OS X, but checking /etc/profile, /etc/bashrc and the custom alfresco.sh script I use to start up Alfresco (included in my Tomcat packages) did not yield any trace of such a variable.
Finally I found a comment in ALF-13452, which led me to check the Spring config within the thirdparty subsystem, responsible for starting up ImageMagick.

   <bean id="transformer.worker.ImageMagick">
      <property name="mimetypeService">
         <ref bean="mimetypeService" />
      </property>
      <property name="executer">
         <bean name="transformer.ImageMagick.Command">
            <property name="commandsAndArguments">
               <map>
                  <entry key=".*">
                     <list>
                        <value>${img.exe}</value>
                        <value>${source}</value>
                        <value>SPLIT:${options}</value>
                        <value>${target}</value>
                     </list>
                  </entry>
               </map>
            </property>
            <property name="processProperties">
               <map>
                  <entry key="MAGICK_HOME">
                     <value>${img.root}</value>
                  </entry>
                  <entry key="DYLD_LIBRARY_PATH">
                     <value>${img.dyn}</value>
                  </entry>
                  <entry key="LD_LIBRARY_PATH">
                     <value>${img.dyn}</value>
                  </entry>
               </map>
            </property>
            <property name="defaultProperties">
               <props>
                  <prop key="options"></prop>
               </props>
            </property>
         </bean>
      </property>
     ...

There it was. The subsystem itself was setting up a few environment variables before firing up the external process, and these were defined in processProperties. One was the DYLD_LIBRARY_PATH variable.
The solution was trivial. I copied the Spring config in tomcat/webapps/alfresco/WEB-INF/classes/alfresco/subsystems/thirdparty/default/imagemagick-transform-context.xml into tomcat/shared/classes/alfresco/extension/subsystems/thirdparty/default/default/imagemagick-transform-context.xml as per the subsystems docs on overriding beans, and commented out the offending <entry> element.

mkdir -p tomcat/shared/classes/alfresco/extension/subsystems/thirdparty/default/default/
cp tomcat/webapps/alfresco/WEB-INF/classes/alfresco/subsystems/thirdparty/default/imagemagick-transform-context.xml tomcat/shared/classes/alfresco/extension/subsystems/thirdparty/default/default/
vim tomcat/shared/classes/alfresco/extension/subsystems/thirdparty/default/default/imagemagick-transform-context.xml

The result – image conversions now work perfectly in my local dev environment using the Homebrew-installed version of ImageMagick.