April 15, 2008
5:52 PM
I'm going on vacation for three weeks starting in a couple hours, and I'll have little to no access to the net. So I'll be even less responsive to email and all that than I am anyway.
I would've really liked to make a Genshi 0.5 release before leaving, but unfortunately that didn't work out. Just as we were closing in on the last couple of tickets, Google came out with App Engine, which Genshi currently does not work with due to various restrictions in the hosting environment. And I'd really like the 0.5 release to be usable with App Engine (some progress has been made on a branch), so the release will have to wait until I'm back.
March 28, 2008
8:38 AM
It's old news by now that CouchDB is moving to the Apache Software Foundation. So what's the family here in the Incubator like, in terms of the other incubating projects?
Currently Incubating Projects By Primary Language
|C%20(1)|C%23%20(1)|Erlang%20(1)|Javascript%20(1)|PHP%20(1)|Ruby%20(1))
That sure is a lot of Java!
A couple of the non-Java projects look like they haven't been all that active lately (TripleSoup and XAP). Two others are just ports of existing Apache Java projects to other languages (Lucene.NET and Log4php, the first of which is apparently orphaned.) Which leaves just Buildr and CouchDB. And while Buildr is written in Ruby, it is a build system for Java applications
.
Just an observation.
March 25, 2008
1:50 PM
I've run into a tricky performance problem with my CouchDB client for Python.
I recently started getting some reports about really bad performance of the client on Linux, where you apparently couldn't get more than about 25 requests per second in throughput (that number may sound familiar.) I develop on Mac OS X, and could not reproduce the problem. In fact, on OS X couchdb-python was often faster than the other methods. But when I went on to run the performance tests on this server (a Debian 4 install with Python 2.4.4, running on a Xen-powered Linode), I was seeing the very same problem.
So I've been trying to figure out where the code is going wrong. And right now I'm just puzzled. I'd be grateful if anyone could point me in the right direction.
read on …
March 20, 2008
12:07 PM
The TurboGears project has been accepted as a mentoring organization for the Google Summer of Code program this year. The project ideas include two around Genshi: generally improved performance, and compatibility with Jython. Both tricky. I volunteered to act as mentor for the performance improvements project.
If you're a student with solid knowledge of both Python and XML/HTML, and you're looking for a GSoC project that's both interesting and challenging, start by reading my own ideas for performance work. The Genshi code makes intensive use of Python language features such as closures and generators, and then there's also AST transformation and bytecode generation going on. The thing is that much of the low-hanging fruit for optimization has already been picked. In trunk we even have a _speedups extension written in C. So making major advancements in performance will require some thinking outside the box.
If you have any questions, ask on the the Genshi mailing list, and/or come visit us on our IRC channel. See also the announcement on the TurboGears mailing list and the GSoC FAQs for more information.
March 4, 2008
6:09 PM
Not that long ago, CouchDB moved from XML document representations and a custom query language (dubbed “Fabric”) to JSON for documents and Javascript for views. Apparently, that move attracted a lot of new people to the project, myself included.
Not long after the switch, some think about defining JSON encodings of common XML formats. Others ask about using XML in CouchDB. Simply add back the XML backend and let people choose what they prefer? Hell, no.
Turns out there’s a much better way to support XML data in CouchDB: ECMA-357, also known as “ECMAScript for XML”, also known as E4X. And Mozilla’s SpiderMonkey Javascript engine, which CouchDB uses as the default view server, conveniently implements E4X. So it’s just a matter of enabling that support. Which means that, all of the sudden, and without any changes to the core, CouchDB is pretty well positioned for storing and querying XML data in addition to JSON.
For example:
by_lang: function(doc) {
var html = new XML(doc.content);
map(html.@lang, {title: html.head.title.text(), …});
}
To be fair, this is already possible if you use other view servers (such as the Ruby or Python ones), where you have access to the XML support provided by the respective standard libraries. Given CouchDB’s incremental view update model, you usually don’t care so much about the performance of view functions as you care about the data they produce. So if your view function can somehow parse the XML and put some data into the view index, that's usually all you need. Actually querying the view is going to be really fast.
But E4X is an exceptionally convenient API for XML. I think using E4X is going to be a pretty good approach for those who want to use CouchDB to store and query XML content.
January 31, 2008
12:24 PM
-
At least on the Mac, there don't seem to be any good Atom-enabled publishing clients at this point. On Windows you have Microsoft's Windows Live Writer, which comes with good AtomPub support, and actually seems to be pretty nice.
I really hope MarsEdit will catch up in this space soon. The 2.1 version released today doesn't include generic AtomPub support, but hopefully an upcoming version will. In the meantime, I'm using Joe Gregorio's apexer command-line tool to post here, as I don't feel like adding either an HTML interface or an implementation of the MetaWeblog API.
-
Is XML-RPC really the most solid option to support some kind of linkback these days? Hey, 1999 called and wants its technology back. Can't we just use a plain HTTP POST, something like:
POST /ping/ HTTP/1.1
Host: example.com
Referer: http://mysite.com/source-uri/
Content-Type: text/plain;charset=utf-8
Content-Length: 30
http://example.com/target-uri/
That is, the body of the request contains the URI of the resource that's being pinged, and the Referer header contains the URI of the resource that's, well, referring to it. Respond with 202 Accepted if the target URI exists and allows pingbacks, otherwise response with 404 Not Found or 403 Forbidden, respectively. Or 409 Conflict if that referrer has already been registered. Or something along those lines.
Being tracked by a couple of planets really makes you watch your steps when changing things around.
January 22, 2008
8:06 PM
There's been quite a number of negative reactions to the recent announcement that the upcoming version of Microsoft's Internet Explorer will introduce a new way to switch between rendering modes. I personally think the proposal makes sense and is technically okay.
I always wondered how DOCTYPE switching was supposed to be a long-term solution to the challenge of evolving browsers and standards. It only has two modes: quirks mode and standards mode (plus “almost standards” mode in some browsers). What this means is that rendering bugs in standards mode would need to be fixed without being able to provide compatibility with existing sites relying on the incorrect behavior, or otherwise would need to be left unfixed forever. Talk about a rock and a hard place.
The proposed version targeting, on the other hand, allows a web site to declare specific versions of browsers that it is compatible with. It's not just quirks versus standards, it's (for example) IE7 versus IE8. That's a lot more flexible, plus it's much easier for the average web designer to grasp. And it's a completely different beast than the browser sniffing that we used in the dark ages of the web: Just like with DOCTYPE switching, it's the browser doing the sniffing on your web pages instead of the other way around, so there'll be no “your browser is not supported” crap going on. And of course a browser can simply ignore the hint and render the site as close to the specification as it is able to.
This might make evolution in at least some web browsers a whole lot easier. As Eric Meyer puts it:
Version targeting allows browsers to much more easily develop new features and fix bugs and shortcomings in existing features, which has the potential to speed up the evolution of web design and development. That alone is reason enough to give it a chance.
read on …
January 18, 2008
6:46 PM
After a couple of years of hosting on TypePad, I've finally managed to move this site onto my own server (a Linode virtual host), running on top of my currently favored set of tools.
The blog software has been written from scratch. It uses CouchDB (via the CouchDB Python library) for storage, Genshi for templating, and Babel for, well, basically just date/time formatting. It's based on a custom WSGI-enabled Python web framework that I've been hacking on from time to time, basically as a playground for me to test various ideas. You can get a very basic impression of that framework here. Look Mom, No Classes! Oh, and that scratchpad site I just linked to is based on the same stack as this blog (plus Pygments for the fancy colors.) The code isn't publicly available at this point, although I do intend to release it when I feel it's ready. Just in case anyone needs another Python web framework to choose from.
The trackback functionality provided by TypePad has been removed, but I'll look into adding solid support for comments and pingback/trackback soon-ish.
November 6, 2007
8:25 PM
That's Santiago Noah Lenz Naranjo, born on Halloween 2007 (3 weeks earlier than estimated, but everything's fine).
Which makes me a happy dad. And explains why activity on all other fronts has dropped to zero. I'll be back in a few weeks. In the meantime, I'll be enjoying the time with my wife and my son, as we all learn what it takes to be a small family.
October 31, 2007
12:33 AM
As I haven't seen anyone writing much about the state of Python development on Mac OS X Leopard, here's a quick rundown. Leopard comes with Python 2.5.1 installed (OS X previously came with Python 2.3). And the interactive interpreter is now quite usable out of the box, as it includes the readline stuff you previously had to install by hand.
The setuptools/eggs infrastructure is also available by default, meaning that tons of third-party packages are just an easy_install incantation away. Quite a number of other packages come preinstalled (at least with the developer tools), such as numpy, wxPython, zope.interface and at least some parts of Twisted.
And then there's the whole PyObjC and BridgeSupport story, which should be great news for anyone interested in doing Mac OS X development with Python. Personally, I know nothing about this stuff, but being able to import WebKit gives me warm fuzzies (yeah, I'm weird).
For (potential) Trac users and developers, you should be delighted to learn that Leopard comes with SQLite 3.4, Subversion 1.4.4, and Apache HTTPD 2.2.6 (including mod_dav_svn) installed. The Python bindings for SQLite are part of Python 2.5, so there's nothing you need to do to use SQLite from Python. But also, Leopard includes the Python bindings for Subversion, so there's nothing needed in that area either.
When Trac 0.11 finally gets released (another story for another post), it'll be a simple matter of:
easy_install Trac
to get Trac up and running, including the default SQLite database backend and Subversion integration. That command will automatically download and install Genshi for templating. About as easy as it gets. On the flip side, neither mod_wsgi nor mod_python are installed by default, but hey, you got to draw the line somewhere, I guess.
There's tons of other really nice things for developers, of course. A much better Terminal.app, Instruments, and updated versions of many (if not all) of those tools we depend upon every day, such as make and autoconf. Ruby got similar love as Python. Java, not so much, at least for now.
