December 23rd, 2007
Currently on pocoo.org is a semi static webpage with a completely unmaintained semi static blog and completely outdated information. While pocoo is not dead yet (just resting) it’s time to put something on the front page that represents the current state of the situation in a better way.
Let’s see if we can get that updated in the next two weeks. Oh, and TextPress is now up to date again, a bunch of bugs were fixed and we’re much nearer to a release than some weeks ago, but unfortunately we’re behind the roadmap once again :-)
Tagged as: textpress, pocoo, announcement |
One Comment »
Again we’re coming close to December the 24th, a day many people will spend with their families or friends to celebrate. I want to use this Christmas to say thank you to a couple of persons that helped me a lot the last years, either directly or indirectly due to their tremendous work in the Open Source community.
First of all I want to thank you Georg Brandl, who you thought me a lot about Python’s internals. You had an answer to pretty all of my questions and you were the first person I worked with on a real Open Source project. Even though we still don’t have Pocoo released it was great fun to work with you.
Thank you Benjamin Wiegand, Christoph Hack and Christopher Grebs for all your code contributions and your work on Pocoo and the Pocoo libraries.
A big thank you to the whole ubuntuusers team, also those of you who left the team in the past. We had many problems in the past but I looking back those three years I think most of the time we worked together in the past were plesant :-)
Thank you Marek Kubica for all those nice discussions we’ve had. And thanks for your work on the German Python community and your patches to the Pocoo libraries. I guess the python forum and wiki wouldn’t be the same without you.
Of course a big thank you to Alexander Schremmer who keeps the pocoo server running. Learned a lot from you :-)
Also a big thank you to Fritz Cizmarov who introduced me to ubuntu. Unfortunately he passed away two years ago but I’ll never forget him.
I also want to thank Mike Bayers for his work on SQLAlchemy which I use on a daily basis, all the guys over at edgewall for Genshi and Trac, the mercurial people for their ass-kicking DVCS, Martijn Faassen for lxml and all the people working on ubuntu.
Keep up the good work and Merry Christmas to you all!
December 22nd, 2007 | Tagged as: planetubuntu, thoughts |
Comments Off
December 17th, 2007
This wonderful feature request for the German Keyboard Layouts. Open since quite a while and easy to fix (if someone knows how to do it).
And if one finds some intuitive places for emdash, endash, ellipsis and some other often used typographical characters and gets that into the next LTS he/she gets a hug :-)
Tagged as: planetubuntu |
No Comments »
After the Werkzeug 0.1 release I got some feedback by Ian Bicking. Summarized it was about why Werkzeug pretty much does what webob does. Afterwards I thought about the issue and talked with some current Werkzeug users. And to sum it up: Werkzeug stays a standalone library without webob dependency and will stay with the current request/response object implementation.
While I agree that there are things webob does what Werkzeug (currently?) does not provide such as byteranges I still think it’s on the right path. We have now a solid feature set in Werkzeug itself such as form data parsing, file uploads, conditional requests, simple redirects, useful exceptions, a good routing system, a simple bridge to wsgiref for a development server, a small helper library for management scripts and much more and additionally an optional contrib package with dozens of small helpers such as client side sessions, utilities for application sessions, the iterio library, a stream limiter for Django applications etc.
Even more important than having everything you need to get started with WSGI in one library the implementation is easy to understand, fast and written in a way that you will never hit a border. If you find a piece of code in Werkzeug that only solves 90% of your problem but provides absolute no way without side effects to get the full 100% solution that’s a bug and should be fixed.
The minimal configuration you need to get a full featured web app running in a production environment with Werkzeug is currently something like Werkzeug + Genshi + SQLAlchemy + flup. Makes a total of four dependencies. It’s not like I think dependencies are problems but what I noticed so far is the more libraries a user has to install the higher the number of problems and the lower the number of happy users. This is one thing Django does right: install django and you’re done.
If you don’t like that philosophy there is pylons with a whole string of dependencies ;-)
December 15th, 2007 | Tagged as: werkzeug, thoughts |
2 Comments »
Since a few changesets Werkzeug provides a module for client side sessions. While it’s of course not yet perfect I think it’s an interesting approach and we’re currently replacing django’s sessions with Werkzeug’s secure cookie.
How does it work? Basically the data is stored as pickled data inside the cookie. The pickled data is hashed and added to the cookie too. Whenever the data is loaded from the cookie a new hash is created and the two hashes are compared. If they match the data is unserialized, otherwise a new SecureCookie object is created with empty data. As a matter of fact there is no “session key” so if you want to use it with django you have to fake the “session key” by inserting it into the data. We use the following session middleware as replacement for the django session middleware:
try:
from hashlib import md5
except ImportError:
from md5 import md5
from time import time
from random import random
from django.conf import settings
from django.utils.http import cookie_date
from werkzeug.contrib.securecookie import SecureCookie
class Session(SecureCookie):
@property
def session_key(self):
if not 'session_key' in self:
self['session_key'] = md5('%s%s%s' % (random(), time(),
settings.SECRET_KEY)).hexdigest()
return self['session_key']
class ClientSideSessionMiddleware(object):
def process_request(self, request):
data = request.COOKIES.get(settings.SESSION_COOKIE_NAME)
if data:
session = Session.unserialize(data, settings.SECRET_KEY)
else:
session = Session(secret_key=settings.SECRET_KEY)
request.session = session
def process_response(self, request, response):
try:
modified = request.session.modified
except AttributeError:
return response
if modified or settings.SESSION_SAVE_EVERY_REQUEST:
if request.session.get('is_permanent_session'):
max_age = settings.SESSION_COOKIE_AGE
expires_time = time() + settings.SESSION_COOKIE_AGE
expires = cookie_date(expires_time)
else:
max_age = expires = None
response.set_cookie(settings.SESSION_COOKIE_NAME,
request.session.serialize(),
max_age=max_age, expires=expires,
domain=settings.SESSION_COOKIE_DOMAIN,
secure=settings.SESSION_COOKIE_SECURE or None)
return response
Additionally to the normal django session middleware this middleware can handle both persistent sessions and browser-session bound sessions. Per default a session ends at the end of the browser session, if you want to make it persistent you have to set “is_permanent_session” in the session data to True.
Keep in mind that cookies have a size limit and that users will be able to look at that data (but not alter it). The example above requires the current werkzeug tip and not the 0.1 release version.
December 15th, 2007 | Tagged as: snippets, werkzeug, django |
2 Comments »
December 12th, 2007
I stumbled about this thread on django-developers which proposes calling the Django 1.0 release Django 2.0. One the one hand version numbers say nothing. Just take Wine or Trac as two examples that are already very stable but still below the magical 1.0 release. Open Source software often takes some time until a 1.0 is released and that’s perfectly fine. However skipping a version number is purely a marketing trick IMO. Just think of Java which currently names 1.6 Java 6 whereas 1.4 still was Java 2.
With django it looks like the plan is to keep up with Rails which went to 2.0 a few days ago. While I love to see that django kicks ass and it’s moving toward a stable release I have a bad feeling naming it 2.0. Because there is currently a huge gap between rails and django unfortunately. Rails has gained really good integrated migrations, REST webservices, a debugger and many other things django is still lacking.
Django makes an incredible good framework if you get your problem into the use case of django. But as soon as you break out of it and need something that goes beyond what’s possible in django you wish you have chosen something else. The django ORM is far from optimal, the admin rocks but as soon as the number of users exceeds 10.000 users it’s impossible to use it (chose yourself in a dropdown of 50.000 users …) or becomes utterly complex. Complex data models also look awkward in the admin or become too complicated to manage. And if you want to stick with the admin you cannot replace the user model. Now what do you do if you have a forum and want to count the posts? Use a UserProfile module? And how do you want to display a list of users sorted by their number of posts?
Yes there are ways to hack around it but the more complex the application becomes the more you of django’s strengths become obsolete. The application I’m working on right now now is only using two more contrib modules. The auth and the admin, and it looks like we have to drop them too, due to the limitations. All applications in that project hack around ORM limitations, we have an incredible number of recreated base middlewares, we have to monkey patch the request object to hack in subdomain support.
I was talking with David Cramer from curse gaming about some of the issues and he told me that they have forked django at a given point and patched the ORM. The django template engine was replaced by Jinja (our application does the same) and they are caching the hell out of the application to scale it. Bryan McLemore from the curse team told me some time ago that some pages have up to 30 queries on a page.
I don’t want to say that django fails in what it’s doing. But it’s far from 2.0.
Tagged as: planetubuntu, rant, django |
27 Comments »
December 11th, 2007
I now installed the Werkzeug example applications on pocoo.org. So you don’t have to pull all the code if you want to try them out :-)
Here is the Wiki and the Planet. Have fun testing.
Tagged as: werkzeug, python, announcement |
No Comments »
(Thanks monkey patching). Ugly but works: using the werkzeug debugger with django.
Now digg/reddit it ;-)
December 10th, 2007 | Tagged as: planetubuntu, snippets, django |
4 Comments »
…because we use prefixes:
<?php
class Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum_CaseInsensitive
extends Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum
Found in the Zend framework :-)
December 10th, 2007 | Tagged as: planetubuntu, php, stumbledupon |
4 Comments »
December 9th, 2007
Finally (sorry for the long delay) Werkzeug 0.1 is out. Here parts of the current featurelist:
- Provides Request and Response objects for WSGI
- Handles file uploads by using temporary files for incoming data.
- Provides a middleware for static data for development purposes
- Tiny wrapper around wsgiref for easier development (autoreload, optional
multithreaded enviornment)
- Unicode aware data processing. Just use unicode everywhere, werkzeug
handles that for you.
- Mini template engine. Sometimes string formattings just are not enough
and real template engines are too big for that tiny task.
- Context locals. Don’t pass request/user/database connections and
other objects around. Put them on a global context local object and
werkzeug makes sure that everyting is cleaned up end delivered well.
- Test utilities. Create fake WSGI environments and requests to test
your application.
- Interactive debugger. Application dies with an error? Hook the debugger
in and inspect every frame.
Here a screenshot of the debugger in action:
Small werkzeug example applications can be found in the trac. In the werkzeug.contrib package are also some pieces of code that can be useful for django developers. For example there is a stream wrapper that limits incoming form data to a given number of bytes. This is useful for django because django streams into the memory and not to the file system.
Have fun and report bugs / feature wishes in the trac :-) Get it while it’s hot from the Cheeseshop.
Tagged as: werkzeug, django, announcement |
13 Comments »