michi bloggt!

JSON is a handy, comprehensive format to store/transmit data, especially when working with JavaScript. The syntax looks something like this:
var obj = {key1: value1, key2: [value2, value3]}
And the good thing in JavaScript is, that all you need to do in order to convert a string into an according object or array, is to call "eval(.)" on that string.
Well, well, this "good" thing is actually a very "bad" thing (especially on the server side, i.e. in helma), since it might encourage programmers to call eval on all kind of unsafe strings. Fortunately there is a free javascript-library available at http://www.crockford.com/JSON/js.html, which parse such strings in a safe way. This library can and should always be used instead of eval!

RubyOnRails (or Ruby in general?) heavily uses YAML as data format, and i must say that i really like that format. But go ahead, and judge for yourself:
-> http://www.yaml.org/start.html
On the website you will also find a Java- as well as a JavaScript-implementation for that format.

Thomas released his Java Language Guesser (which is basically a java port of libTextCat) under the LGPL:
-> http://textcat.sourceforge.net/

var de = "Hallo! Das ist ein deutscher Text.";
var en = "Hi! This is some english text.";
var fi = "Moi joulupukki!";

var guesser = new Packages.org.knallgrau.utils.textcat.TextCategorizer();
res.writeln("de: " + guesser.categorize(de));
res.writeln("en: " + guesser.categorize(en));
res.writeln("fi: " + guesser.categorize(fi));

I haven't read through the whole paper, but it seems that the idea of the algorithm is pretty simple, yet turns out to be quite powerful, i.e. accurate.
For each category (in our case here: for each language) a fingerprint is provided, that simply contains the frequencies of all n-grams. Then the n-grams-frequencies of the new document are compared to these fingerprints, and whatever category/language comes closest, will be the guess.
If you want to use textcat for sthg different than languages, then the library also provides a handy method to create such fingerprints (i.e. train the dataset).

I bet this would also work to determine whether a text is written by an austrian, by a swiss or by a german (which would be interesting to determine here at twoday.net). I would even go that far, that it would probably work to determine the gender of the author. And I am afraid that "fingerprint" isn't such a far-fetched analogy, and that such an algorithm will also, at some not-so-distant time in the future, work to determine the actual author of a text, which is a frightning thought.

Addendum: Actually, after reading the paper, i must withdraw my statement that it should be possible to detect different writing styles between different people. At least not with the distance measure which they proposed. Using a distance measure, which also effectively considers the "long tail" of the Zipf distribution (i.e. one that doesn't just "cut it off") by applying different weightings to the rank-differences (i.e. rank-differences for top-ranked n-grams should have more weight) would probably help.

grep '2005:17:' access.log |  \
  awk '{ print $5 }' |  \
  sort |  \
  uniq -c |  \
  sort -nr |  \
  head

    143 [14/Dec/2005:17:15:43
    138 [14/Dec/2005:17:40:13
    134 [14/Dec/2005:17:39:15
    127 [14/Dec/2005:17:35:17
    127 [14/Dec/2005:17:27:48
    127 [14/Dec/2005:17:07:21
    123 [14/Dec/2005:17:01:36
    118 [14/Dec/2005:17:24:37
    117 [14/Dec/2005:17:20:48
    116 [14/Dec/2005:17:13:09

Sprich bis zu 143 Requests pro Sekunde. Vielleicht wirds doch mal Zeit für den viel gepriesenen lighttpd? Schon jemand Erfahrungen damit gesammelt?

Nachtrag: Ebenso interessant, sind aber auch die Spitzenlasten bei der Bandbreite

grep '2005:17:' access.log |  \
  awk '{ print $5 " " $11 }' | 
  awk '{a[$1]+=$2} END {for (j in a) print a[j] " " j}' |  \
  sort -nr |  \
  head

1365589 [14/Dec/2005:17:40:57
1245322 [14/Dec/2005:17:40:12
1129162 [14/Dec/2005:17:41:04
1080311 [14/Dec/2005:17:41:35
1075507 [14/Dec/2005:17:43:31
991233 [14/Dec/2005:17:41:55
980098 [14/Dec/2005:17:41:12
967750 [14/Dec/2005:17:40:10
936295 [14/Dec/2005:17:41:50
929714 [14/Dec/2005:17:41:52

Bzw wenn man anstatt print $5 " " $11, einfach print $2 " " $11 schreibt, dann bekommt man sehr leicht denn großen Bandbreitenfresser (=IP-Adresse) heraus. Mit print $8 " " $11 erhält man die entsprechende Datei.

Wow, soeben entdeckt dass R auf onlamp.com mit einem fetten Artikel gefeatured wird:
-> http://www.onlamp.com/pub/a/onlamp/2005/11/17/r_for_statistics.html

Ich will ja nicht gross protzen, aber ich hab bereits 1998 oder so mit R zu tun gehabt :-)

Und dass aber nicht aus einer frühen Weitsicht heraus, sondern bloss weil ich zufälligerweise etliche Lehrveranstaltung bei Prof Leisc h besucht hab. Mittlerweile schreib ich (in unregelmäßig aber doch bemerkbaren Schritten) ja beim "Treasurer" persönlich die Diplomarbeit. Bzw genauer gesagt, arbeite ich die meiste Zeit hierfür mit R.

Dem R-Neuling sei folgende Referenz-Karte ans Herz gelegt:
-> http://cran.r-project.org/doc/contrib/Short-refcard.pdf

Und dem dann-noch-immer-an-R-Interessierten dieses Buch:
-> http://www.amazon.de/...9E5BVH%26camp=2025%26link_code=xm2

vor allem für Helma-Entwickler [via matthias]

Douglas Crockforg series of articles on JavaScript:
* A Survey of the JavaScript Programming Language (!)
* The World's Most Misunderstood Programming Language
* Private Members in JavaScript
* Classical Inheritance in JavaScript
* Recommendations for Modifications to the ECMAScript Language Specification

Allesamt lesenswert.

Bzgl der künftigen Entwicklung von JavaScript kann ich Herrn Henso nur vollsten beipflichten, dass einem vor allem die named function parameters abgehen, und leider siehts diesbzgl nicht allzu gut aus in naher Zukunft. Interessanterweise bemängelt dies Mr Crockforg nicht!? Das Fehlen dieser Funktionalität führt aber über kurz oder lang zu unzähligen Methoden, welche alle wichtigen Parameter gekapselt in einem Objekt übergeben bekommen.
function handleThisAndThat(param, usr)
anstatt
function handleThisAndThat(name, title, email, wantsNewsletter, isSunny, friends, usr)
Man könnte nun natürlich generell als design pattern festlegen, immer ein Objekt übergeben zu müssen, aber schön anzusehen ist dass dann auch nicht, bei jedem Funktionsaufruf, die Parameter als Objekt kapseln zu müssen.

Nachtrag:
Erkenntnis des Tages, ist dass der &&-operator ebenso wie der ||-operator als Shortcut des ternären ?:-Konstrukts verwendet werden kann.
var value = p && p.name;
var value = p ? p.name : p;

var value = p || x;
var value = p ? p : x;

TODO: das frei erhältliche JavaScript-Plugin für Eclipse begutachten
-> http://www.interaktonline.com/Products/Eclipse/JSEclipse/Overview/

-> Trails: a Java-clone
-> TrimJunction: a JavaScript-clone

Liquid:
-> http://home.leetsoft.com/liquid
-> http://home.leetsoft.com/liquid/wiki/DesignerHowTo
-> http://home.leetsoft.com/liquid/wiki/HowTo

http://dev.helma.org/Wiki/Helma+2+Templates+-+liquid+sample/

my proposal for a new helma 2.0 template mechanism can be found here:
-> http://dev.helma.org/Wiki/Helma+2+Templates+-+michi

also see:
-> http://dev.helma.org/Wiki/Helma+2+Templates

Hab mich vor kurzem rechtfertigen müssen, wieso ich etwas 'step01', 'step02',.. genannt hab, und nicht bloss step1, step2. Und dann erst bemerkte ich, dass dies ausschließlich deshalb erfolgt ist, weil ich 'Courier New' in meinem Text-Editor als Schriftart verwende, und diese nicht zwischen der 1 und einem kleinen l unterscheidet:
step01listItem

Peinlich, peinlich. Deshalb höchste Zeit eine vernünftige Schriftart für den Text-Editor:
-> Andale Mono (andale32.exe)

[merci an klemens für den tipp]