amüsanter fund aus der süddeutschen zeitung bei camp catatonia: fast alles über "bufonaria borisbeckeri", "masiakasaurus knopfleri" und natürlich "das führerinsekt".
i'm so tired from the week-end... and to those who i did not talk for a while i apologize. it's quite a busy time. super-busy, to be precise.
the antville.org update is getting closer and closer... i already can smell it!
"zwischen dem entdecker und seinem forschungsergebnis war schon immer mittler. weltkarten waren schon immer eine frage des wissens- und wahrnehmungsmanagements". – berliner gazette, 7. august 2002.
ein verkorkster und ein dummer satz. da mag ich doch gar nicht mehr weiterlesen. es wird mir bestimmt noch leid tun, aber so ist das nunmal.
bitzi has mp3s ready for download (via rinner.st).
once upon a time in a small, remote apophysis of our beloved audiogalaxy...
it's more fun to compute.
i am always and ever amazed how my coding skills are so incompatible to the act of coding itself. it's not only that i make shitty software, that bugs get in the way. it's moreover about how i gawkily dance around trying to fix them.
example: after almost two lightyears i once again started to write a helma app working with the internal database. you've got to know that helma's internal database has undergone drastic changes: it's now completely xml-based which sounds really cool and that is what it really is like.
i quickly scribbled the first files to enable my application setting up a simple website providing a document-based infrastructure similar to the old helma.org. ie., i was able to create, edit and display documents mounted to a custom url.
everything went fine so far until i restarted the application for the first time: duh! all data was gone.
this was the initial situation i started to find a bug in my code. i reduced everything down to one script creating a dummy document and kept myself watching the output in the xml database. still the data loss was 100%.
no bug in my code, i thought. so could it be that helma...? maybe the internal database does not work the way i was used to (lightyears, y'know)...
so i started to doubt: the accessname property of the document collection – throw it out! the use of the internal _children property – throw it out!. using type.properties: throw it out!
all without success.
my little dance already had become an eurythmic exercise, a seriously ridicilous and desperate effort to catch an invisible needle in a just as invisible haystack.
but then suddenly it dawned on me and i renamed the prototype called "document" (which is one of the reserved javascript keywords, even on the server side) to "doc".
from then on, everything went fine again. well, except that i was not able to create a persistent subcollection in root called "people", yet. could it be that helma perhaps this time...?
only for a limited time: try out the future antville colorp3kker (just right next to the "touch" link at the top of this page).
adult panties with a christian message: "since prayer was banned from public schools in 1972, our nation has been going straight to hell. but you can reverse this godless descent by investing in this most christian of undergarments".
thank you fatscape/boozilla developers: due to your urges for new features nobody needs and moreover everybody will hate, i have to use a kilo of code just to convert bloody rgb triples into hex strings. **** you, too!
grrrr...
to understand the problem click on the coloured box: 
while most browsers return "#ffcc00" at least netscape 6.2, mozilla 0.9 and even chimera 0.4 return "rgb(255,204,0)" – which actually is the same color but not the same value and least of all the color that was set in the code!