The Zope Component Architecture is often touted for letting you override so-called components which have already been registered elsewhere (by a library, out of your immediate control).
It's wrong (edit: to clarify, using the overriding facility of the ZCA is wrong, and by extension, to use the ZCA because you can override components, is wrong too; I do not mean to suggest that the use of ZCA is misguided in general).
Shrink-wrap software is a circumstance. If you must change it from outside (instead of branching, which is a fine approach in many cases), just go ahead and update the functions or classes in question using the reload approach (object identity changes should be avoided at all costs).
There's nothing wrong with ZCA; it's in my view a misunderstanding to employ it for web application development at large. Rather, it's applicable for deployments that require live software component introspection. I don't know that web applications need this in general. What happens is that frameworks like Zope Toolkit and Plone use these introspection features to map requests to code. That's a bit like using RDIF tags for consumption tracking (hint: require credit card payment or identity-based rebate instead).
Most software is misunderstood. How to use it, when to use it. Sometimes it's worth the while to retrace your steps to learn why you ended up using a particular software.
2009-11-06
2009-11-03
New in school
I've written an HTTP publisher!
The most common reaction is: why write a new framework? Well, it's not a framework. It's a little device that sits between the server and your code. It does more than bobo, less than bottle. What it does, it does better than both.
The name is Otto.
There aren't many moving parts, but the design is flexible enough to handle most use-cases. The syntax is agreeable, terse and very clear. Most importantly, it gets you going without any mental effort. There is no inversion of control. It is obvious at every step what happens, from request to response.
The design has evolved entirely through examples, setting the library requirements instead of the other way around. The documentation is tested continuously using the manuel package which keeps everything in sync and makes it possible to write out and test complete self-contained examples right in the documentation.
That said, there isn't a lot to it.
You can use the publisher directly as the basis of a web application, or integrate it into an existing framework. Suggestions or other feedback are welcome as comments are on the repository tracker.
The publisher will grow a few more features (e.g. support for virtual hosting, static file helper) before its first release, but an effort is made to keep scope narrow.
The most common reaction is: why write a new framework? Well, it's not a framework. It's a little device that sits between the server and your code. It does more than bobo, less than bottle. What it does, it does better than both.
The name is Otto.
There aren't many moving parts, but the design is flexible enough to handle most use-cases. The syntax is agreeable, terse and very clear. Most importantly, it gets you going without any mental effort. There is no inversion of control. It is obvious at every step what happens, from request to response.
The design has evolved entirely through examples, setting the library requirements instead of the other way around. The documentation is tested continuously using the manuel package which keeps everything in sync and makes it possible to write out and test complete self-contained examples right in the documentation.
That said, there isn't a lot to it.
You can use the publisher directly as the basis of a web application, or integrate it into an existing framework. Suggestions or other feedback are welcome as comments are on the repository tracker.
The publisher will grow a few more features (e.g. support for virtual hosting, static file helper) before its first release, but an effort is made to keep scope narrow.
2009-10-16
The cure
A couple of years ago I wrote a small package called z3c.jbot which made life as an integrator on Zope and Plone a lot easier. This is an advertisement for the latest version 0.5.
New features:
More information on the project page.
New features:
- No performance hit
- It works with Chameleon
- Replace images, stylesheets and javascripts too!
More information on the project page.
2009-10-03
Copying music left or right
I pirate music. Frequently. Most people do, too. It's not right in terms of copyright; so let's talk about copyleft.
When we talk about music piracy, we usually think of it as a free lunch. But we've been told many times over that there's no such thing. Money don't grow on trees; there are no free lunches. Won't the world stop turning if we give up copyright?
'Lo and behold free software.
I write free software, made available as is, under the BSD license. My only source of income is the hours I clock from clients. The clients are interested because I write free software.
The answer to music piracy is free music, as in copyleft. Everybody can hum, sing, dance and play along to music. To copyright music and sell it under a non-free license is artificial. It's no different than software, books or thoughts. Need a source of income? Work. Perform your music, or other people's music, sell it to advertisers (god forbid), sell merchandise to teenagers looking for an identity.
There's just one problem. Record labels aren't interested; they are afraid that free music will hurt their business model. The irony is that it probably won't. They can still issue compact discs and charge for them. We have recently seen that the LP has grown popular again. There is money to be made from selling free music goods. I think there is money to be made from printing and selling free books, too (in fact, many older books are free; they are still being printed and sold for a profit).
I think my music habits will stay illegal for the better part of this century. Things won't change. But when people complain "but how can you make yourself do it, knowing that the artists are starving from lack of income" my answer is:
I don't starve.
When we talk about music piracy, we usually think of it as a free lunch. But we've been told many times over that there's no such thing. Money don't grow on trees; there are no free lunches. Won't the world stop turning if we give up copyright?
'Lo and behold free software.
I write free software, made available as is, under the BSD license. My only source of income is the hours I clock from clients. The clients are interested because I write free software.
The answer to music piracy is free music, as in copyleft. Everybody can hum, sing, dance and play along to music. To copyright music and sell it under a non-free license is artificial. It's no different than software, books or thoughts. Need a source of income? Work. Perform your music, or other people's music, sell it to advertisers (god forbid), sell merchandise to teenagers looking for an identity.
There's just one problem. Record labels aren't interested; they are afraid that free music will hurt their business model. The irony is that it probably won't. They can still issue compact discs and charge for them. We have recently seen that the LP has grown popular again. There is money to be made from selling free music goods. I think there is money to be made from printing and selling free books, too (in fact, many older books are free; they are still being printed and sold for a profit).
I think my music habits will stay illegal for the better part of this century. Things won't change. But when people complain "but how can you make yourself do it, knowing that the artists are starving from lack of income" my answer is:
I don't starve.
2009-09-28
Picking the right nose
Like or dislike, doctests formatted as restructured text (e.g. the venerable README.txt that resides in many packages) are a convenient way to document your software and make sure the documentation stays in sync with the actual codebase.
It's surprisingly awkward to run these tests using nose. After some debugging of the unittest module, the following is the workaround I've resorted to employ.
It's surprisingly awkward to run these tests using nose. After some debugging of the unittest module, the following is the workaround I've resorted to employ.
import unittestThe documentation for nose suggests using the ``--doctest-extension`` command-line flag to use non-Python files as doctests, but it seems much more convenient to define them in the actual test module.
import doctest
class MyTestCase(unittest.TestCase):
def __new__(self, test):
return getattr(self, test)()
@classmethod
def test_readme(cls):
return doctest.DocFileSuite('README.txt')
2009-09-26
A new object database for Python
When Chris McDonough presents his BFG framework he uses the punchline "like Zope, but less". I'll take the liberty to reuse it about a new object database that I've written over the summer: "like ZODB, but less". It's called dobbin, which is a reuse from another project, incidentally also an object database.
Less code. About one twentieth. Of course, less features, too. And easier assumptions.
I'll be the first to admit that I felt caught in the act when I first read the so-called architect notes of the varnish proxy server. The author of that software claims most developers are still writing software like it was 1975. If you read that document and consider the memory management attempts of the ZODB, you might get the feeling that he's right.
Dobbin is the logical consequence of that document. It doesn't try to manage its own memory.
Less overhead. Persistent objects are read-only, until checked out. Their state is shared between threads. This significantly reduces memory usage; in fact, memory usage has always been the Achilles' heel of the object database. This reduction comes with an inconvenience: objects must always be explicitly checked out before they can be changed.
There's no inherent network support, but multiple processes can connect to the same database without configuration. There's no server process; the database is simply a file.
Less complexity. Dobbin is written all in Python.
The project page on PyPi has more information including a user's guide. It's not quite ready for serious usage yet. If you're interested in helping out, these are the next steps:
Less code. About one twentieth. Of course, less features, too. And easier assumptions.
I'll be the first to admit that I felt caught in the act when I first read the so-called architect notes of the varnish proxy server. The author of that software claims most developers are still writing software like it was 1975. If you read that document and consider the memory management attempts of the ZODB, you might get the feeling that he's right.
Dobbin is the logical consequence of that document. It doesn't try to manage its own memory.
Less overhead. Persistent objects are read-only, until checked out. Their state is shared between threads. This significantly reduces memory usage; in fact, memory usage has always been the Achilles' heel of the object database. This reduction comes with an inconvenience: objects must always be explicitly checked out before they can be changed.
There's no inherent network support, but multiple processes can connect to the same database without configuration. There's no server process; the database is simply a file.
Less complexity. Dobbin is written all in Python.
The project page on PyPi has more information including a user's guide. It's not quite ready for serious usage yet. If you're interested in helping out, these are the next steps:
- Packing (trimming away old versions from the transaction log)
- Indexing (field-indexing and querying)
- Persistent dictionaries and lists (buckets or similar)
2009-09-16
Where to eat in Porto
It's just around the corner; you sit where you like. The waiter (empregado) will quickly bring bread, olive oil and vinegar, a tray of olives, mixed salad and two charcoal-grilled sausages (chouriço), then insist on a bottle of vinho verde, green wine. He will then take the actual order. The people known as os tripeiros are hedonists; this is at midday.
I usually ask for the picanha, which is an exquisite red meat cut from the loins. It's prepared on the grill and always served rare. Served with rice, black beans and cabbage (usually kale, prepared like the East-African sukuma wiki, quite bitter), it's not exactly an incentive to get back to work. The wine doesn't help here.
After the meal the waiter will bring the sobremesa. It's impolite to refuse. Then coffee.
The restaurant goes by the name of central dos leões, which is only apt. You needn't actually try and find any other restaurant in Porto; it's the best there is and you'll find that they open before you even wake up and serve the last picanha long after it's bedtime for Frances.
I usually ask for the picanha, which is an exquisite red meat cut from the loins. It's prepared on the grill and always served rare. Served with rice, black beans and cabbage (usually kale, prepared like the East-African sukuma wiki, quite bitter), it's not exactly an incentive to get back to work. The wine doesn't help here.
After the meal the waiter will bring the sobremesa. It's impolite to refuse. Then coffee.
The restaurant goes by the name of central dos leões, which is only apt. You needn't actually try and find any other restaurant in Porto; it's the best there is and you'll find that they open before you even wake up and serve the last picanha long after it's bedtime for Frances.
Subscribe to:
Posts (Atom)
