The Intellog Blog

I’ve attended a couple of webinar events put on by the folks at Lucid Imagination (LA), and have found them all to be very useful, and well worth the time spent attending them.  In particular, I recently took in Building Local/Geo-Search with Apache Lucene and Solr  and found it extremely interesting.  ‘Geo-search’ is getting a lot of press these days, and in an hour, it was possible to get an overall sense of Solr’s positioning in this regard.

There is another event coming up on 2009-12-02 which I thought I would bring to readers’ attention; An Introduction to Basic of Search and Relevancy with Apache Solr.  From the description, it sounds like a  good place to start if you’re contemplating a  Solr implementation in the future.  More detail about the presentation, and a registration link, can be found here.

Intellog uses Solr to implement search, and it’s an amazing product with incredible potential for Intellog and our customers.  If you’re interested in our approach to implementing Solr, by all means, post a comment below and we can get in touch.  Also, this is not a compensated endorsement, and I have no affiliation with LA other than having a lot of respect for the company and the people who work for it.

A professional colleague called recently to enquire as to whether I was available to build something for them to address their modest contact management requirements.  They are a small team of engineers, and the primary concern was keeping the team in synch; when one of their team members makes contact with somebody about something, the team wants its diarized, and have some way to make sure the other members of the team know what’s going on.   They have no internal IT resources, so a solution which requires a minimum of care and feeding is a high priority.  In the space of 15 minute conversation, he came back to the theme of ‘simple’ quite a few times, so that appears to be high on his priority list.

Of course, it was hard for me to believe that anything like that actually needed to be built, so I spent some time investigating the state of the nation is this problem domain.  I finally concluded that if they didn’t want to go with commercial product such as Highrise, the next best alternative may be to configure an Excel spreadsheet to do the job.  It’s not a patch on what dedicated contact management software can do, but if they’re interested in something in between nothing and something more sophisticated, it might just do the trick.  If you’re in the same position, and want a very simple contact manager based on Excel, here’s a cheat sheet in PDF format which should help.

By all means, let me know what you think by posting a comment below, and thanks for reading.

A long time ago, Intellog submitted a proposal to LinkedIn to integrate some of their features into an application currently in development*.  The new application is based on the co-ordination of work between a professional community which is well known to each other, and many of which have already have LinkedIn profiles.  Instead of having to laboriously re-enter information which was already in their LinkedIn profile, it was visualized the user could simply click a ‘use LinkedIn profile’ button or similar, and the necessary information could be brought across to the Intellog application.

The application involves user interaction with documents and other information which are owned by corporations.  Intellog users work for these corporations, and their right to interact with a particular document is dependent on their current employment status with that corporation.  For example, Document A belongs to Corporation B, which employs Employee C.  So long as Employee C remains an employee of Corporation B, that individual should be able to see and interact with Document A.  However, the instant Employee A resigns from Corporation B, and starts working for Corporation D, Document A and any other document owned by Corporation B will no longer be available to Employee C.  Conversely, any documents owned by Corporation D are now available to Employee C. 

Based on the premise that individuals will want to keep their LinkedIn profile up to date, systematic interaction with LinkedIn can provide valuable updates as to current employment status, which can subsequently be used to determine the current set of documents to which a given user should have access.  Access to other LinkedIn objects is seen as adding a lot of value to the new application development effort in other areas, as well.

This API is based on LinkedIn having adopted the OAuth protocol.  At first blush, this seemed to be taking LinkedIn in a different direction than OpenID, which has been described and discussed in previous posts to this blog.  However, some initial investigation into OAuth seems to position it as complementary to OpenID, rather than in competition with it.  The specifics of that relationship are still to be investigated, and will provide the basis for some additional posts in the near future.

But in the short term, LinkedIn opening up their API appears to be nothing but good news as it related to the work about to be undertaken. 

Code Shavings  Anybody wanting to start an investigation of OAuth would do well to visit their official site at oauth.net, or check out the series of articles on OAuth at hueniverse, or various presentations on YouTube.

*Alas, that proposal never received a response, but it would appear as though they took the spirit of what was proposed (along with proposals from many, many others no doubt) and incorporated it into their API offering.

I attended the November meeting of CAMUG last night to hear lean software development guru Mary Poppendieck speak on the subject of Results Are Not The Point.  A provocative title, to say the least – sounds almost like post-Agile Agile.  The Scrum-dialect of Agile with which I am familiar can be said to focus all of the attention on results – the so-called “potentially shippable product increment”.  As long as a product increment is achieved, it is less important how it is achieved, so long as good software engineering practices are employed.  When I read the title of Mary’s presentation, I feared there might be some unravelling of this fairly well established and — in my experience — successful strategy.

But such was not the case, and it an be explained by the subtitle of the presentation; “manage by means, not by the numbers”  In other words, a system has an inherent, immutable capability.  Any attempt to increase the capability – that is, improve the results — not only won’t improve things, and could well result in making matters worse.  If not satisfied with the output of a particular system, then the system itself needs to change.  Or at least evolve.  Her assertion, based on some fairly compelling albeit anecdotal evidence, was that no amount of huffing, puffing, target setting or other gimmickry is going to make a given system produce more than that of which it is inherently capable.

This was my first time attending one of Mary’s presentations, and I found here style to be simple, without being simplistic, and compelling without being bombastic.  She punctuates her presentations with very interesting, very practical stories drawn from her experience.  I thought her recollections of Handelsbanken Svenska, Tandberg and the description of pilot training feeback systems at the Israeli Air Force were all very useful.

Mary’s presentation was peppered with references;  Outliers by Malcolm Gladwell and Chasing the Rabbit by Steven Spear to mention a couple.  She also made mention of the Toyota Kata, which turns out is the title of a book by Mike Rother, as well as Deming’s System of Profound Knowledge.  These are all worth of reading, or at least a little additional research.  If Mary is in your neck of the woods in the near future, you would do well to take the time to hear her speak.

Carrying on the work describe in the previous post, attention turned to the loading of the California county boundaries.  Part 7 of Lesson 7 of the Geog 585 course notes discussed the ‘installation of data’, but the steps were presented a little out of order, and/or they may have changed a little with the advent of GeoServer 2.0.   After a little experimentation, the steps below were determined to be those required to get from a base installation of GeoServer running on an AWS Linux image, to one which is ready to serve the California county information. 

The first step was to start a new instance was from ami-2e5fba47.  The EBS volume – called data001 – created during the previous session was re-mounted on the new instance.  However, some of the benefit of storing the JDK and GeoServer downloads on the persistent EBS volume was lost because GeoServer 2.0 had just gone to stable status since the initial installation.  The new version was downloaded and moved up to the EBS volume to replace 1.7.7.  Installation of the JDK and GeoServer were installed using precisely the same steps as last time ‘round.

The next thing was to create a data directory external to the GeoServer application directory hierarchy.  This was done to ensure upgrades to the GeoServer software can be accomplished without overwriting the data.   It was determined the best place for this data directory was also on the EBS volume noted above.  A further decision was made to create a directory within it called geoserver – that is, a GeoServer-oriented directory which is version agnostic.  The new data_dir was created by  copying the native version to data001/geoserver, making the path to the new data directory data001/geoserver/data_dir.  Telling GeoServer about the location of the new data directory was surprisingly simple; the variable  GEOSERVER_DATA_DIR  was set with the path to the new data directory, the variable exported, and then GeoServer was restarted.  Finally, the shapefiles which included the California counties, air basins and air districts were unzipped from ARB_basins_districts_counties.zip, and then moved to data001/geoserver/data_dir/data/shapefiles.

The first GeoServer configuration change (all of which were completed using the Web Administration Interface) was to create a new GeoServer Workspace.  Workspaces are described as “[a]nalogous to a namespace, a workspace is a container which is used to organize other items.”  It may have been possible to use an existing Workspace, but the decision was made create a new one, called intellog, which would be used contain all the layers created as part of this training exercise.  What’s less clear is the precise role of the URI supplied when creating the workspace, so Intellog’s home page was used for this purpose, at least for now.

The next step was to create a Store, which was associated with the workspace created above and given the name californiaCounties.  The Store connects the logical entity being stored – the county information, in this case – with its physical location on the server.

The final configuration step was to create a Layer, which as the GeoServer documentation says “represents each feature that needs to be shown on the map. All layers have a source of data, called a Store.”  When the Layer was created –  named arb_california_counties_aligned_03 in this case — there were a dizzying array of options, but these were simply left at their default values for the most part.  Virtually all of the options will require some additional research to fully understand.

To test the configuration, Layer Preview was selected, followed by the OpenLayers option.  Voilà!  The California map comes up, as shown at the top.  For good measure, the KML version was also tried out — see the second illustration, above.  There are many more details to be worked out, but this was the bare bones Hello World-type exercise to get a shapefile installed and working on a GeoServer instance.  As always, takes way longer to describe than to actually do. 

Thanks for reading, and feel free to provide comments and/or questions below.  Until then…”keep those cards and letters coming in folks!”

Code Shavings  There are three commands you are required to enter when utilizing an EBS volume.  You do not want to issue the first one if the EBS volume contains something you want to retain!  (Please don’t ask me how I figured that out.)  ♦  The most visible difference between the 1.7.X and 2.0 is the administration interface.  It’s quite a bit cleaner and more functional.  Apparently, it’s based on the Wicket framework, which seems to make the latter worthy of some investigation.