michi bloggt!

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?

altough i've been on that site before, i just realized recently the eye-pleasing and at the same time helpful page navigation that Jürg Lehni implemented for that site.
-> http://www.hektor.ch/

Apache 2.2 wurde vor Kurzem released (und auch bei diesem Versionssprung scheinen die Wellen nicht allzu hoch zu schlagen)
-> http://www.apache.org/dist/httpd/Announcement2.2.html

New Features:
-> http://httpd.apache.org/docs/2.2/new_features_2_2.html

Am interessantesten scheint der neue event-Module zu sein,
The event MPM uses a seperate thread to handle Keep Alive requests and accepting connections. Keep Alive requests have traditionally required httpd to dedicate a worker to handle it. This dedicated worker could not be used again until the Keep Alive timeout was reached.
bzw vom Namen her klingt mod_proxy_ajp verlockend.

Aber die Dokumentation beider Neuerungen lässt dann doch noch zu Wünschen übrig, bzw mich eben im Unklaren darüber wann diese denn einzusetzen wären.

[via dkg]

...und wahnsinnig viel ist mal wieder passiert. Man wird das Geühl nicht los, dass sich die Erde immer schneller und schneller dreht. Vor allem der internette Teil davon (bubble? hat hier jemand bubble gesagt?). Gottseidank gibts da noch den Rest.
Naja, u.a. haben Chris und Earl ihr exzellentes, und sehr lehrreiches (sorte 'eye-opener') Snips-And-Spaces paper veröffentlicht, unsere jungs haben einmal eine erste version von tagthe.net online gestellt, und das Sensationellste aller ground-breaking / earth-shaking news ist:

Jürg Lehni hat nicht eine, er hat gleich zwei neue Templating Engines für Helma zum Leben erweckt!!
-> www.scratchdisk.com/Random+Notes/November+2005/Helma+Templates/
-> http://jakarta.apache.org/velocity/
-> http://freemarker.org/

..und ich mach mich gleich mal dran, dies auch auszuprobieren.

Die ersten Berührungspunkte mit Helma (bzw generell mit einem Web Application Framwork) erfolgen meist eben mit der Templating Engine. Ganz abgesehen von den tausenden twoday/antville-Usern gibt es ja neben den reinen Developern in den Projekten immer eine Reihe von Template-Designern und HTML-Umsetzern. Insofern ist die Templating Engine von großer Bedeutung für die Aussenwahrnehmung von Helma, und hier künftig auf die eine oder andere weit verbreitete und gut dokumentierte Engine setzen zu können, ist ein enormer Mehr-Wert für Helma.

Nach so etwas hab ich schon immer gesucht, und bin nun soeben zufällig drüber gestolpert. Ein (OpenSource) DB-Modellierungsprogramm mit Reverse Engineering! Ein Click und die ganze Datenbank hat man als Modell dargestellt.
-> http://www.fabforce.net/dbdesigner4/

Und ich hab das doch tatsächlich mal mit Visio versucht. tsts.

-> http://jeffhowden.com/code/css/forms/

I must admit, that i tend to neglect looking at other systems/platforms/applications when it comes to programming. Not that i am totally blind and not aware of whats going on, but I am just not the type of guy who dives into some esoteric languages in his spare time, or who evaluates 3 different programming frameworks on a foggy november sunday. Well, but i guess, i SHOULD. Fortunately i am surrounded by smart people (in the blogosphere, as well as in the company) who actually do stuff like that, and also share their opinions openly.

Last week a highly interesting discussion was going on the helma-dev mailing list (helma-dev), last friday most of the company (incl myself) attended a presentation by mihi and ferrari on Ruby on Rails, and yesterday i finally took my time for catching up with some reading that i should have done earlier ([smi], [ferrari], [smi again], [Jürg Lehni on 'Helma vs Rails'], [wikipedia on 'Rapid Application Development'], [wikipedia on 'Agile Software Development']). Well, it seems about the right time for a (self-)reflective look at how programming can be improved, and for me to write down some thoughts and experiences.

Knallgrau's development team has seen a tremendous growth over the last year. But not just the number of projects were increasing, but also the size of projects tended to get bigger. Let's pretend that there is this big project 'XYZ' we are working on :-), having five/six people write code for that same project is just a whole different sport than we were used to. (Readers in charge of development-teams bigger than 10 or 100 are allowed to smirk on such tiny numbers.) 'Programming in the large' is the name of the game!

Lessons we learned from project XYZ (for Helma projects in general):

• Separation, separation, separation (also known as 'modularity'):
  The first thing we did, before starting with the project, was to make extensive use of Helma's (back then) new repository logic, which allowed to separate code into several repositories/directories. I would go that far and claim, that without this separation the project could have never been completed. We got helma-libraries, java-libraries, core logic, modules (modBloggerApi, modJCaptcha, and 18 others), custom logic and custom modules. Next time, we would probably go even further and also separate skins and logic into different repositories as it is done in gobi, and also (finally) start a knallgrau-library.
  Separation on the other hand will lead to dependencies of the components. Avoid them as much as you can!
  Seperation also includes separating actions (=web-accessible functions) and model logic. Helma allows you to put all your logic into actions, but keep them separated.
• Readable code (also known as 'maintainability'):
  
  • Stick to the coding conventions (resp. write down coding conventions before you even start :-) [see here for a good start for JavaScript])!
  • Define a coding framework
    After having taught Helma to about ten people this year, the biggest struggle for Newbies is imo the freedom of choice of how to do things. Especially when it comes to writing a new application from scratch. Conventions over Configuration is a good claim, but you don't necessarily need Ruby On Rails to accomplish this. Just write them down.
  • Use self-explaining names for everything (methods, properties,..)! Don't be afraid of being verbose.
  • Write JavaDocs and inline comments!
  • Break up your logic into small pieces, 'cause methods with more than 50 lines are just not readable anymore.
  • Also the importance of "Don't repeat yourself" and of "lean coding" can't be stressed enough. The less code it takes you to perform a certain task the better it is (sthg that should not be taken too literally).
• Use the power of inheritance
  In project XYZ we ended up with 82 (!) defined prototypes. But 68 of these are simply thin extension of the main 14 prototypes. Using inheritance seems to contradict readability, but cuts down the number of code lines. And if you understand the main prototypes and their purpose, you already grasp the whole application. The other downside of this is, that your Helma application will get cluttered with directory folders.

Mmh, i am not too content with my structuring of the above list. It turned out a bit random, and a lot of the things mentioned are correlated to each other, and some of them also contradict each other. But i hope you get some ideas out of it. Others already have put by far more thought into these problems, and i will just bluntly point to the core elements of Rapid Application Development, and state that 'this is the way, it should be'. Dooh! (Time-to-market and iterative development are imo still getting more and more important.)

Discussions on the future of Helma development are right now going on, and it's very interesting following these discussions. The incredibly fast rise of Ruby on Rails certainly leads to the question for 'what is in for me (resp. Helma)?'.

My wish list is sthg like the following:

1. Try to be even more JS standard compatible then before. Use common JavaScript syntax for defining prototypes, and their type-mappings.
2. Smarter JavaDoc generation of applications, that can be triggered as ant-task.
3. Automated (my)sql-script generation (including indexes).
4. Move all configurations away from apps.properties
5. Allow a pluggable templating engine (in order to allow for example Velocity to be used)
6. Establish 3 environments (development/testing/production) similar to RoR
7. Establish testing as an integral part of development
8. Finish and maintain documentation! (oops, thats actually my task anyways)
9. ...i definitely forgot sthg here...

Common Framework for how Helma apps should be written? It would be great if the Helma community could decide on one, but i am not too optimistic that this will happen anytime soon. Hopefully i will be proven wrong.

An IDE for Helma? This is sthg that has been asked for over and over again. But imo we might get this for free at some point, if we become more 'JavaScript compliant'. JavaScript is getting more and more attention, and code written in JavaScript becomes more complex. Tools will appear to handle this complexity, and hopefully these are then easily adaptable for Helma.

So, thats about five times longer then the longest blog entry i have ever written before. And i better hit the 'save'-button now, before i change my mind again. Time to market! Also for blog-entries :-)

Naively i assumed that connecting to a cvs server over ssh over a different port, is just a matter of

cvs -d :ext:michi@cvs.some.server.com:12345/opt/cvs co MyProject

But this results in the following error:

CVSROOT port specification is only valid for gserver, kserver, and pserver connection methods.

According to this posting
-> http://lists.gnu.org/archive/html/info-cvs/2004-10/msg00291.html
it seems, that it is necessary to define an ssh-Alias by adding the following lines to ~/.ssh/config:

Host SomeCvsServer
  HostKeyAlias cvs.some.server.com
  Hostname cvs.some.server.com
  Port 12345

Then the following command will be rewarded with success:

cvs -d :ext:michi@SomeCvsServer:/opt/cvs co MyProject

(I am posting boring stuff like this for the sole purpose of some poor anonymous fellow in the future, who will struggle with the same problem, and googles his way to my blog. Sorry for all the others, who just dont give a damn about the above.)

TASK:
Given: An (unsorted) array of objects. Each of these objects can have a parent object defined, that is also contained in that array.
Problem: Determine an order for this array, that guarantees that for each object its parent object is positioned further to the beginning of the array.
Background: I am parsing an unsorted array of files, creating a database object for each of these files. Since i also need to store the parent reference for these objects, i had to pre-sort that array, so that when i loop through it, i can be certain that the parent object already exists (and that i know its unique id for the foregin reference)

SAMPLE:

• tick with parent donald
• dagobert with no parent defined
• trick with parent donald
• donald with parent dagobert

-> correct order: dagobert, donald, tick, trick

SOLUTION:

unsortedArray; // the unsorted array of objects
var sortedArray = new Array();
for (var i=0; i<unsortedArray.length; i++) {
  var obj = unsortedArray[i];
  if (obj.parent == null) {
    // position objects without parent at the beginning
    sortedArray.unshift(obj); 
  } else if (Array.contains(sortedArray, obj.parent)) {
    // position objects, with a parent that 
    // is already contained, at the end
    sortedArray.push(obj);  
  } else {
    // if parent is not contained yet, then we append 
    // it to the end of the original array
    unsortedArray.push(obj);
  }
}

Problem: A circular reference (dagobert is parent of donald, and donald is parent of dagobert) must be caught by breaking out of the loop at some point.

Nachtrag: Und kommentieren kann man mit der auch.