Header graphic 6 of 8



Other stuff

Other sites

I wish this site were powered by Django

February 22nd, 2008

PHP sucks… now even more.

Filed under: General,Java,PHP,Python,Technology — jm @ 01:52

I finally made the time to update I'm sorry, but PHP sucks. This part of my site gets by far the most traffic and I found it important to update it to reflect all the changes that have occurred since I originally wrote it in 2006. I also created a new sub-section on programming languages where I'll write down trivia about Java and Python and other programming languages that I use daily, concentrating on weaknesses and bugs that are less-known, but can become highly volatile for a project.

Of course, I don't have nearly as much material on Java and Python like I had on PHP, but you never know, perhaps I'll even receive a few suggestions :-).

March 25th, 2007

Django, Java and framework functionality

Filed under: Django,Java,Python,Technology — jm @ 08:06

Update: This post addresses the differences between Django and Tapestry 4.1 and it’s a bit outdated. I wrote another, higher-level, post on that topic that you might want to read.

It seems that every web framework has the desperate need for displaying tabular data, but only few solve it as well as Tapestry does with contrib:Table. Even if you’re stuck with plain JSP there’s the excellent Displaytag library. Django has no such thing at the moment.

Not only that, the more I work with Django the more it reminds me of early Servlet-based development environments. urls.py resembles <url-pattern>s, Middleware can be compared to javax.servlet.Filters. Now, of course, Django is much more fun to develop with, because of its Admin-application, the newforms library, it’s pythonic and it supports rapid-turnaround development. So there’s no XML-juggling involved and you don’t repeat yourself and generally the design revolves around easy to guess interfaces. But really, I’m missing some of the features that are available in a Java software stack.

Currently, if I’m working with Java that means I have:

Feature Library
Component-oriented development Tapestry 4.1
Dependency Injection and module discovery Apache Hivemind and of course Spring
Full Ajax support Tapestry 4.1
Declarative, fine-grained security Acegi, combined with Tapestry-Acegi (modified for form-based authentication)
Database access JPA / Hibernate
RSS/Atom support Rome
Full PDF support iText
Real full-text search Lucene

Of all these, Python has only a few equivalents. Rome, for example, is modeled after Mark Pilgrim’s excellent Universal feed parser and Django’s ORM solution works for most cases (I happen to think that EJB3 did a few things right), but there’s no equivalent to iText in terms of functionality and feature support and Acegi/Spring-security is simply the most-advanced authentication/authorization-library there is.

So if Sun would finally stop diluting the standard library and instead get their act together on fast and painless class-reloading, it would be a blast to work with (feature-wise, not language-wise, which might be fixable by using JVM-based scripting languages like Groovy or JRuby). But as long as I have to wait 30 seconds per round-trip for Tomcat to restart, I’d rather shoot myself than attempt to develop a CRUD web-application with Java again. If only someone wrote something like Django’s Admin application for Tapestry and JPA…

For now, it might at least be possible to integrate some of the libraries mentioned above with Python, by using gcj along the lines of PyLucene.

So I guess if I find time, which I don’t have, it’s pretty clear what has to be done. Someone needs to develop an Admin-application for Tapestry based on contrib:Table, BeanForm, JPA and annotations and then someone needs to develop a contrib:Table-lookalike and a fine-grained authentication and authorization middleware for Django based on decorators for views, but with the possibility of an external configuration file (dare I say it: possibly XML-based).

August 08th, 2006

UTF8-encoded Unicode support

Filed under: Attitude,Cutting the crap,Django,Java,Python,Technology — jm @ 02:15

From this post at MySQL DBA:

The utf8 spec says that a utf8 character can take up to 4 bytes, mySQL currently only supports up to 3 bytes.

……holy crap. Let’s summarize how different languages and frameworks support Unicode at the moment:

For some reasons, someone over at Sun decided that Java’s char-data type should have 2 bytes and be represented in modifed UTF8, so that certain characters that would normally require 4 bytes in normal UTF8, now require 6. This actually makes sense to keep compatibility with C programs (modified UTF8 has no “0-bytes” in strings), but makes it hard to support Unicode’s supplementary plane, where characters can have up to 4 bytes. The details can be found in JSR-204. Ever since then… string operations in Java cannot reliably calculate string length, because these methods do actually count valid UTF-16 characters.

PHP… don’t even get me started. PHP just sucks.

Ruby apparently also has problems with moving to Unicode (and this language was designed in Japan)?

So while I’m very glad that I decided to focus on Django and Python, which have has excellent Unicode support, I really feel, more than ever, the need to get the word out that text processing is incredibly hard and that there is no excuse for so many developers and teachers not caring about it.

Update (08/31/2006)

Django’s unicode support apparently also sucks. They try to do the right thing in their MySQL driver (using SET NAMES 'utf8'), but fail to set the connection character set properly, so even if the model is in UTF8, MySQL will treat every incoming string as latin1. This leads to ugly reencoding errors. It seems to work better with PostgreSQL, but it’s still a huge fucking bug. The developers try to get their act together, though and the “unicodification” will probably be done before they hit 1.0. #1356, #1355 and #952 read very badly. At least I have now pointers on what to fix (follow the links), but out-of-the-box you’re fucked if you want to connect your legacy Windows-1252 database to the web using UTF8 with django.

This reminds me a bit of the sad situation with Typo3. At least, with django, it’s not the programming language that’s the core problem.

Update (02/15/2008)

Unlike Java and PHP, Django has come a long way since this post was written. I wrote an update on Django’s Unicode capabilities that can be found here.

October 01st, 2004

Java 1.5 5 is out

Filed under: Java — jm @ 02:40

Available for download now. Generics, attrib annotations, auto-boxing, enums, foreac enhanced 'for' syntax, varargs and so much more. Also finally real queue-support in the out-of-the-box collections. It's about time that Sun starts competing with .Net.

September 16th, 2004

mod_jk2 / Scarab / JVM crash

Filed under: Java — jm @ 14:01
Well, the crash reoccured a few times over the last few days. To be exact:
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002EF
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
# Java VM: Java HotSpot(TM) Server VM (1.4.2_05-b04 mixed mode)
This seems to be a known problem. There are numerous bug reports in Sun's bug parade. However, they fixed at least one instance of this bug. It seems to be a threading / synchronization / classloader issue. For the moment I fixed it by installing IBM's JVM that's at least just-as-good. Unfortunately, IBM's JVM for Windows is not publicly available anymore. You can still get it by downloading trial packages of Java-based IBM-Software, but I dislike the fact that I can't have a consistent development environment on Windows and Linux. Let's hope that Sun fixes this bug in time for Java 5.

September 13th, 2004


Filed under: Java — jm @ 21:23
I'm sorry, but they should have added a leading zero to mod_jk2's version before they released v "". I spent hours today trying to compile this thing on a Debian Linux v3 machine. That machine (the very machine this weblog is running on) uses a couple of backports.org's packages (apache2 and mysql, for example). For some reason mod_jk2 didn't want to compile at all. There are issues with libtool, backport.org's APR package, a missing apr-util library and more. The release isn't polished at all. In fact, In the end I settled on compiling the last release without APR "". This one at least compiled with just a little bit of hassle. Just like the newer release it has a hard-coded path to libtool, for example.

Still, the documentation is in a very sad state, so then I had to fiddle a few hours with the configuration. Interestingly , the previously supported "JkMount" directive is now commented out in the code. VirtualHost-support is now provided in <Location>s via the JkUriSet-directive. Unfortunately, this also isn't documented.

Well, it runs now, but halfway through installing Scarab, the JVM (1.4.2_05) crashed. I don't know why... installing Scarab also is a pain. If you ever wonder why the documented "ant create-db" doesn't create any tables, well, it seems like that's because you need a MySQL Connector/J version >= 3.0 if you're using MySQL > 4.0

The JK2-connector really needs a lot of work, badly. Scarab b19, at least, is in a half-way usable state now, since I last tested it (b17). We'll use it for a few weeks, then I'll write more.