Archive for category Uncategorized

Open Repositories 2012: Review

Offered for the benefit of present and future OR conference organizers.  Rated on the A-B-C-D-F scale.

Edinburgh: Wonderful city!  I hope to go back some day!

Pollock Halls: More or less what I expected from a dorm.  Good breakfast.

Pre-conference: Good offerings.

Opening session:  Thought-provoking and context-setting keynote.

Lunches: Not enough food (or water!).  Friday’s entree served cold.  Inexplicable.

Breaks: Suggestion: early morning beverages (at least self-service).

Presentations: Good variety and depth.

Dinner and Ceilidh: What a treat!  So much fun that I’ll forgive the service staff for constantly removing our water glasses during the ceilidh.

Overall: Great job!


Leave a comment

WSGI daemon mode solves python-ldap connection issues

I was porting a Django/python-ldap application to another server and getting sporadic ldap.SERVER_DOWN errors.  Some basic troubleshooting showed that the problem was occurring specifically when requests routed through mod_wsgi.  If I just ran the Python code — no problem; just the Django app via the dev server — fine; Apache straight to Django (proxying to dev server) — OK.  Now, while I had been planning to investigate mod_wsgi’s “daemon mode” for some time, I was still running all my apps in “embedded mode”.  But with this python-ldap problem, I had to dig deeper into the docs.  The mod_wsgi ApplicationIssues page discusses a number of problems related to C extension modules, and while not specifically mentioning python-ldap, it does make this generalization:

Because of the possibilty that extension module writers have not written their code to take into consideration it being used from multiple sub interpreters, the safest approach is to force all WSGI applications to run within the same application group, with that preferably being the first interpreter instance created by Python.

To force a specific WSGI application to be run within the very first Python sub interpreter created when Python is initialised, the WSGIApplicationGroup directive should be used and the group set to ‘%{GLOBAL}’.

WSGIApplicationGroup %{GLOBAL}

If it is not feasible to force all WSGI applications to run in the same interpreter, then daemon mode of mod_wsgi should be used to assign different WSGI applications to their own daemon processes. Each would then be made to run in the first Python sub interpreter instance within their respective processes.

I did try WSGIApplicationGroup %{GLOBAL} first, but (assuming I implemented it correctly), the problem remained. So I tried WSGI daemon mode and the process has proved stable.

, ,

Leave a comment

Emacs + SVN 1.7 = Ouch

It’s only partly in jest when I say that working in IT means being annoyed most of the time.   Sometimes it feels that way.  The latest annoyance came last week: updating my Cygwin install brought SVN 1.7.  I knew about the required updating of working copies to the new format.  What I didn’t know was that my beloved Emacs version control integration would break so horribly.  I suppose this is another reason for Emacs-haters to chuckle, and I’m rarely inclined to tinker with the config or try alternative Emacs modes, so I’m basically stuck with the brokenness until a fix comes down stream.  All in a day’s work.


Use the framework

I don’t know how many times I’ve developed or implemented some clever enhancement of an application or framework (e.g., Plone, Django, others) only to regret it later.  Of course it always seems like a reasonable idea at the time, but the more repetitions of this pattern I experience, the more skeptical I am of fancy solutions (included many of my own published on this site) and add-ons that promise short-term feature additions but too often incur long-term maintenance costs that simply aren’t worth the benefits.  Here’s how I’m thinking about it now:

  • Don’t reverse engineer the system.  By all means, read the code, just don’t try to outsmart it.
  • If you can help it, don’t use methods or attributes marked as private (yes, I have a beef with Django’s Model._meta).
  • Don’t use a third-party product for something you can do relatively easily without it.  Stop and ask yourself if the coding you may save is worth the headache of maintaining the product through framework upgrades, etc.
  • Keep an eye on framework developments.  Watch the roadmap.  Read the release notes!  I’ve been pleasantly surprised a number of times to find out about new (or existing) features by re-reading documentation.
  • Participate in the core community.  Everybody benefits from improvements to the core framework.  This is not to say that every good product should ultimately aim for inclusion in the framework, but with a strong group of core developers new features are subjected to critical analysis, rigorous testing and benefit from wide usage and long term support.


Leave a comment

A tale of two villages

Once upon a time there was a village.  And the people of the village all worked very hard creating “content”.  And the content was good and useful.

In the course of commerce the people saw that other villages also produced content which was good and useful.   So one day elders from all the surrounding villages held a meeting to see about how they could work together and “share” their content more freely and easily.  After talking briefly the elders agreed that this would be a good thing, and they gave it a name: “content management”.   And the elders returned to their villages to tell the people how wonderful it was going to be that all the content which they created in their separate villages would be available to everyone in all the villages.  And the people rejoiced.

When the village elders reconvened to start working toward achieving this dream they immediately saw that it wasn’t going to be so easy.  It seemed that folks had many different ideas about how the content sharing should work. Some people said, “I just want to share content with the people in my neighborhood.  That’s all I care about.” Others said, “I want to be able to pick and choose what gets shared with other villages.”   And on and on.   The elders tried their best to come up with a way that all the needs and desires of their constituents could be met, but alas they did not succeed.   Eventually, they realized that content sharing could happen in many different ways without having “one system” that governed all.   The villagers indeed over time worked out many ways to share their content, which, while far from being the promised land of “content management”, served their needs pretty well.    And they were reasonably happy.

Now there was another village in another land.   And the people of this village worked very hard creating and organizing “resources”.  And these resources were highly sought after by people from all over the land, well beyond the boundaries of the village itself.   And the people of the village stored their resources in giant silos in different places throughout the village.   And each silo was accessible by different means: one by train, another by boat, another by cart and horse.  And they thought to themselves, “Wouldn’t it be wonderful if the resources from all these silos were accessible by the same means, whether by train, or boat, or horse-cart?   Then people could come to one place for all the resources they desire.”   And so the village elders met to discuss this, and agreeing it was a good thing, they gave it a name: “resource discovery”.  And the elders told the people how wonderful it was going to be …

Leave a comment

Learning to love tags

I woke up this morning thinking about tags … and buckets.

Probably because I had reorganized my Picasa albums last night.  Actually I collapsed all my public photo albums into one and applied more tags to individual photos.  For some reason — most likely habit — I had originally created several albums for different subject categories: Bugs, Animals & Birds, Buildings & Places, etc.  It worked fine, since I could easily pick one “bucket” in which to put each photo.  And then I could apply tags, too.  I guess I thought of tagging as a secondary means of organization, an optional sort of extra goodness.  But I encountered a situation where I wanted access to all my public photos using a mechanism that dealt only with individual albums.  I was stuck.  Then I realized that by using tags instead of separate albums to create subject categories I would have a more flexible structure, and not just for this one application.

Since I work in a library (although I am not a librarian by trade or training) I frequently deal with systems for organizing objects (principally books and other written materials) and metadata.  Of course, prior to the existence of computer networks, the library was the premier information storage and retrieval system.  And the techniques libraries use for managing metadata for effective and efficient retrieval of objects were largely developed to meet the needs of a physical collection.  Without automated indexing and searching, information tends to be organized hierarchically.  Having used this strategy with physical objects, it was natural to do the same with “virtual” or electronic objects.  Hence we organized our email and documents by creating folders.  The problem, of course, is always, “What folder did I put that thing in?”  When I switched to Gmail I felt a bit insecure at first because there were no folders, just “labels”.  I wasn’t accustomed to the paradigm, but I went with it.  Gradually it has dawned on me that the impulse “to put each thing in its place” isn’t always necessary in the digital world, and it’s sometimes not the best organizational strategy.