michi bloggt!

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;

Tagging revisited
-> http://smi.twoday.net/stories/1254702/

Die meisten Tags, in der Reihenfolge der Häufigkeit, haben laut Studie folgenden Sinn:
* Zu identifizieren welchen Inhalt (thematisch oder personell) ein Objekt hat
* festzuhalten woher ein Objekt stammt oder welcher Art es ist
* dem Objekt einen Ursprung (einen "Besitzer") zu geben
* die bereits gewählten Tags weiter zu verfeinern und verdichten
* Referenzen auf eigene Kategorien (mystuff, work, etc.)
* Aufgabenorientierte Tags, wie toread, toblog, etc.


Meinereiner muss ebenfalls erst lernen mit Tagging umzugehen (wie andere eben auch). Bei meinem del.icio.us-Account hab ich jedenfalls vor paar Monaten viel zu granular angefangen, und hab nun ständig das Gefühl das ich mal "aufräumen" sollte. Aber genau dies sollte doch verhindert werden, oder? Und mittlerweile verteile ich so zwischen 0 bis 2 Tags pro Bookmark, und das meiste landet dann doch bei "web" und "programming". tja, ganz hab ich den dreh noch nicht heraus.

Die für mich wichtigste soziale Komponente von del.icio.us ist übrigens, dass (nachträgliche) Nachsehen, wie viele und wer das gleiche gebookmarkt hat wie ich. Und natürlich was diese, bzw andere Bekannte noch so lesen. Kommt also ganz ohne Tagging aus.

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

Nachtrag: Das Foto hier hätte eigentlich bei dem Posting mitkommen sollen. Naja, hier wirds also nachgereicht.

-> 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]

Internationalization in
-> Django (a python web framework)
-> Ruby-On-Rails
-> Struts

Django and RoR have very similar solutions to internationalization. Both rely on the GNU gettext tool, which serves messages from the according localised .mo-files. While a developer write his code, all he has to do to enable the localization of the application is to use the gettext-method (resp their python or ruby-equivalent).

str = gettext("My name is %s")

resp. as a shortcut

str = _("My name is %s")

can be written. When the page is rendered, the application substitutes that string with the according translation. In addition to gettext the developer is provided with the following tools:
* A script/command to extract all messages from the source-files. This will create a .pot-file, that is plain-text, and can be updated with a text-editor. This is for example necessary when dynamically built strings are passed along to gettext(). That script has to be smart enough to detect such manual changes, so that these changes dont get lost, when the script is run again.
* A tool/gui (preferably poEdit) to translate these message-files, which will create single .po-files for each localization. poEdit also allows the translator to add comments to certain messages, and to store how certain/firm she is about the translation.
* And finally a script that converts the .po-files into binary .mo-files, that are optimized for fast access.

Struts follows a different approach, which is somewhat similar to how it is solved in twoday:
Each string has to be referenced by a unique identifier

<bean:message key="app.hello" />

through which the application will look up the localized string. Localizations then need to be defined in .properties-files. Note: The developer should make up 'self-speaking' message-ids, which will ease the work with such ids. One of these .properties-files will usually function as a fallback, which is used when that particular string has not been localized yet.

Now, the problem with the second approach should be apparent: In Django and Struts the work-flow of the developer is not interrupted by subsequent opening/scrolling/thinkingAboutSmartMessageKeys/editing of big properties-files while he is working on the code (resp. view). He just types along, and wraps each string within simple _(.)-calls. The translation task itself is furthermore made straight forward thanks to the availability of open-source translator-GUIs, that can be used by non-tech-savvy people.

mmh... On the other hand developers are often very insecure on the wording, and forcing them to define a default wording, that will be used as a future key-identifier is problematic as well. Or, did i miss the point? How do these tools keep updates to these default wordings, when the application has already been internationalized?