Co·sent: shared perception; joint knowledge; collective intelligence.
Free e-book about knowledge work at the intersection of social and knowledge technologies
A new Cosent publication shows, how knowledge technologies can be combined with social technologies and legacy applications to optimize knowledge flows, accelerate innovation, improve process efficiencies and engage stakeholders.
Read more about Systems of Intent - Digital Workplace Technologyy Roadmap
An overview of the status of PloneSocial and where we're heading. Also introduces a preview of the Digital Workplace Technology Roadmap that will be published soon. Update: talk video now available.
Update: the video registration of this talk is now available at Youtube.
Below the slides used in the talk:
The video below gives an overview of the current PloneSocial feature set. It's part of the presentation above at the "demo" slide. No audio available.
How to create a Plone deployment that performs like crazy and survives not only a datacenter failure, but even keeps on running when all Plone heads are down. Update: video now available.
The video of this presentation at PloneConf 2013 Brazil is now available on Youtube:
The slides are not readable in the video, but you can see them on Slideshare:
Run-time software modification can save your day, and kill your project.
This is a highly technical article, intended for a technical audience. You should probably skip it if you're not a software developer.
I just had a bad news conversation with a client:
"Your website is doomed. It cannot be upgraded. It cannot be maintained.
All your content is fatally compromised, as if a computer virus had attacked your site.
The only remedy is to make a fresh copy of the software and start from scratch with a clean database. The hundreds of pages in your site will have to be re-entered manually."
He was not pleased. I was surprised he didn't cancel my contract, right there and then. Luckily for me, I am not the author of the original website: this disastrous outcome was not my doing.
The whole affair did lead me to reflect on the question, whether this could have happened to me, in one of my own projects? How resilient are my own coding practices against the kind of extreme outcomes I just witnessed? Hence, this article.
As you will have guessed from the title of this article, we're talking about monkey patching: the practice of modifying a system's behavior by changing its code base run-time.
The Good is, that as an integrator working with a software framework like Plone, you do this all the time without even thinking of it as monkey patching. Registering an adapter with the Component Architecture is the canonical way of customizing the system's behavior, and involves getting your code called instead of the code that normally would be called at that interface point. Customizing a view template is just a light-weight variant of the adapter pattern. It's perfectly normal and accepted. This is what ZCML is for. It's expected.
To paraphrase Cruijff: "every upside has its downside".
The Bad is, that there's a thin line between customizing a framework as intended, and messing around with collateral damage, i.e. monkeying around.
What if the behavior you want to customize is not componentized in a way that makes it easy to overlay your custom code over its implementation? Monkey patch to the rescue:
import some.framework.goodie def my_monkeypatched_search(context, query): # do something smart return original_search = some.framework.goodie.search some.framework.goodie.search = my_monkeypatched_search
And hey presto! Every call to some.framework.goodie.search now gets dispatched via my_monkeypatched_search instead.
There's a price to pay for this, though:
- It becomes very difficult to debug the call flow. You just performed a man-in-the-middle attack against all other consumers of the framework function you monkeyed.
- You introduce a tight coupling between the framework implementation and your monkey patch. Meaning that when the framework changes, your monkey patch has to be upgraded in sync. That's a nicely hidden, undocumented maintenance problem you just created.
- Other modules may be trying to override the same original framework function. Which means you have a race condition with two (or more) parties warring to get their monkey patch in place.
The last issue is the source of the term monkey patch: you have guerrilla patches fighting it out. Guerilla, gorilla, get it? Monkey patches.
To illustrate how thin the line is: the tight coupling maintenance problem also occurs if you do a simple template override via z3c.jbot. Unless you plan ahead and check the unchanged upstream template into your customization package first, with a commit message specifying the upstream location, you'll find it very hard in two years time to port your 5-line template change, which you didn't document and don't remember, into a 100-line template file with substantial upstream changes.
To further convolute matters we have collective.monkeypatcher:
<monkey:patch description="This works around issue #xyz" class="Products.CMFPlone.CatalogTool.CatalogTool" original="searchResults" replacement=".catalog.patchedSearchResults" />
This mitigates the problem somewhat by resolving some sequencing issues when activating the patch. And it dresses up in a greppable, nice ZCML suit with a tie, blurring the line between legitimate businesses and the mob.
I'm not saying you shouldn't do this: I do it myself. Occasionally. But you should be aware of the dangers. Which brings us to the last part, and the reason I'm writing this piece.
There's a thin line between customization and monkey patching. And then there's a slippery slope between monkey patching and hacker hell, greased with good intentions and hacker hero hubris.
The disaster I described in the introduction was the result of an add-on developer realizing that not only the code base can be monkey patched. You can monkey patch actual stored objects in the database, too! Yeah!
Please check your medication, if you think that's a neat idea.
These guys not only overrode every field in every content type in the code base. With a coding style that pokes out your eye with pep8 violations. They also changed the storage model for every field. On every content object in the database. With a one-way migration from mainstream sanity to multiple f***edup disorder.
In my client's case, the add-on is poorly maintained and blocks a Plone upgrade. Removing the add-on results in empty fields on all objects, and gibberish in the catalog. Trying to reverse-engineer and revert the database hacks makes your head explode.
Code base monkey patches you can escape from: by removing the offending code from your system. Just refactor away all dependencies and remove the stuff from your buildout.
However, anything that changes your database in a meaningful way, without a corresponding uninstall, risks turning a nice project into a full-fledged nightmare. After you've launched, and a change request opens up the can of worms.
Which raises some interesting questions, for me and for you:
- How often do I/you write add-ons without providing and testing an uninstall profile?
- How often do I/you install add-ons without auditing for irreversible installer changes?
- How many of my/your projects depend on add-ons we don't fully understand? Whose lead developer has, two years later, apparently moved on to greener pastures?
On all these counts, I plead guilty as charged. I have sinned and will better my ways.
How about you?
A classic right-brainers versus left-brainers drama playing out.
A big attraction at the Enterprise Design Retreat in Barcelona recently, was the spectacle of two worlds colliding: design thinking, and enterprise architecture.
The difficulties in reconciling these differing paradigms present a real problem. Established enterprises are stuck in a failing paradigm as they're facing failing control and failing systems. However, trying to introduce new approaches like design thinking triggers the corporate immune system. Design thinking is great at solving problems traditional approaches are unable to get a handle on. But it doesn't give you much of a handle on keeping 40-year old Cobol banking systems running.
This leaves incumbents in a dangerous situation: change is needed but very difficult to achieve. Innovation meanwhile is concentrated in "hip" startups. But for society to benefit from these innovations, those startups need to go mainstream by either wiping out the incumbents, or else through mergers and acquisitions. Which just postpones the paradigm shift challenge to the consolidation and/or M&A stages.
- Stay Sharp
Receive updates on innovation, knowledge management and social technology every two months.
- Tag Cloud
- agile complexity crowdsourcing design design research enterprise 2.0 foresight innovation internet of things intranet knowledge knowledge flow knowledge management management open source organizational learning plone plonesocial roadmap semantic web social business social network analysis social networking sustainability technology