Libcoffee.net's source code is now released at http://github.com/zanglang/libcoffee under the Creative Commons Attribution-Share Alike license, with which the end result is what you are reading right now. ;) The codebase is by no means complete, and by extension of that I'm pretty darn sure it's neither bugless, stable, nor razor efficient yet. However, it's being continuously updated so if by any chance you spot an error feel free to send a shout. So, to summarize:
- Basic blog authoring and publishing with plain URLs e.g. 'blog/2009/12/31/slug'
- Comments with Google, OpenID and Facebook identities
- Content markup with reStructuredText, Markdown and Textile
- XMPP and email notifications for new comments
- Clean default template with Blueprint CSS framework, hAtom and hCard microformats
- Code block syntax highlighting
- Trackbacks and pingbacks
- Automated datastore backup via email
- And of course, other miscellaneous benefits brought by running on Google's distributed computing platform.
There's a fair bunch of library dependencies used, so refer to READEME.rst for a list, as well as installation instructions. (So, uh, why yet another Django blog engine ? Answer: because it's not cool if you don't write one while learning Django. Amirite? ^^) All in all, fun experience. Lessons learned from this mini project:
- Resource management on a distributed computing environment is very textbook. Disk space and CPU is cheap. Cloud computing, a buzzword it may be, could very well be the future of software. Memory is a lot cheaper than disk read/writes too, so it pays to cache the hell out of everything.
- I have mixed feelings about running Django on App Engine, via app-engine-patch. Django itself is great, but BigTable imposes so many restrictions that half of Django doesn't work the same anymore, not to mention there's a massive requent-response latency when the app has to cold start , and then load the 3mb Django zip file, then crawl along as compiled Python bytecode is not allowed. In the first week, I was seeing ridiculously high response times averaging at 25 seconds each, but that seems to be have improved by now.
- I clearly have not reached the point where I require the benefits of BigTable yet, so I frequently suspect if it would have been much less trouble if I just coughed up the money for a Python web hosting account... :P
And stuff on the to-do list:
- Rewrite the comments/feedback modules. They were originally ported from Django apps, but a lot of unused cruft is still left over. I still don't know if trackback/pingbacks work properly, for instance.
- Content caching is still very inconsistent. As it is, memcache keys are pretty much generated adhoc without a proper consistent namespace policy, and purged en masse every time a post is created so it's pretty wasteful. Need to get ideas from Nick Johnson recent posts on implementing a static content generator.
- Use more of those leftover App Engine quota. I guess that requires me to blog more. :)
- I really need to look at how to further cut down response times too. Perhaps it'll be yet another fun project - replace bits and pieces with newer and more interesting bits and pieces.
- Libcoffee.net project page: http://github.com/zanglang/libcoffee
- Django: http://www.djangoproject.com/
- Google App Engine: http://code.google.com/appengine/
- app-engine-patch: http://code.google.com/p/app-engine-patch/
|||I've originally wanted to call it Nii, as it's a *typo* of Ni, which was an utterance of the Knights from Monty Python, which inspired Python, which I would be using to write it with - uh, it was all supposed to be all connected and funny, okay?|
|||In fact, there's probably already a whole rainbow spectrum of blogs named Yet another Django blog in a dozen alphabetical variants, too.|
|||A proper analogy would be: after a period of inactivity an App Engine app goes cold (deactivated?), until the next request is received, where Google picks a new CPU slice for us to run on again. A popular app will propably stay warm quite well.|