michi bloggt!

-> http://www6.inode.at/inode.at/ueber-uns/geschichte/

2005 Launch der neuen allermiesesten Website seit Firmengründung

Mir tun nur die Leute von der Datenkraft leid, die davor stets eine hervorragende Website für die Inode auf die Beine gestellt haben. Vor paar Monaten nun haben sie den Etat an Nofrontiere abgeben müssen, und nun kommt so ein Kindergarten-MIST dabei raus.

Mich ärgert dass deshalb auch so, weil ich stets relativ viel auf inode.at herumgesurft bin.

In somewhat related news: der heutige Server-Ausfall des Knallgrau-Servers war durch nen Hardware-Defekt bei der Inode verschuldet worden. Inode, quo vadis? Die letzte Finanzierungsrunde hat dir wohl nicht gut getan.

Nachtrag I: "Wir sind die Schiachen!" Treffender kann mans gar nicht formulieren.

Nachtrag II: Noch ein paar Schmankerl aus der zugehörigen Mitteilung "Einfachheit hat Vorrang!" auf der Website:
Ihr innovatives Design ist auf das Wesentliche reduziert – was nicht nur gut aussieht, sondern auch die Übersichtlichkeit erhöht. ... schneller ... optimal geeignete Lösung ... mit maximaler Transparenz dargestellt ... möglichst intuitives Finden ... optimale Servicequalität ...
Ja um Gottes Willen, haben die die komplette Kommunikationsabteilung ausgetauscht? Bullshit Bingo lässt grüßen.

Nur mal zur Klarstellung: Ich bin noch immer sehr zufrieden mit der Inode, ich frag mich halt nur grad, was mit denen los ist. Die Inode Website war für mich definitiv ein USP, und der wurde nun von heute auf morgen gekillt. Wir (Knallgrau) zählten jedenfalls zu den ersten Kunden hier in Wien. Wir hatten damals meinen alten 486er Home-PC als Server umfunktioniert und in den "Inode-Server-Raum" (sprich Keller) in der Feldgasse stehen gehabt. Damals wie heute hatte ich stets äußerst kompetente Techniker als Ansprechpartner vorgefunden. Somit benötigt es mehr als eine "schiache Website" um mich zu einem Wechsel bewegen zu können.

-> IE Dev Bar

-> Jetty 6.0 Continuations - AJAX Ready!

beide Links vom (noch immer rss-losen?) herrn rinner geklaut.

Emails treiben einen noch in den Wahnsinn! Genauer gesagt das zugehörige Protokoll. Abgesehen davon dass unsere Mail-Schnittstelle (bzw die dazugehoerige mail.jar von sun), obwohl seit fast zwei Jahren im Einsatz, noch immer von eigenartigsten Email-Formaten geärgert wird, hab ich nun im Laufe der letzten Woche versucht zu entschlüsseln, was es mit diesen =?ISO..?= in attachten Dateinamen auf sich hat. Bzw wie man denn diese eben ausliest entschlüsselt.
commons-codec.jar liefert einem die passende Lösung, bzw genauer gesagt die Klassen BCodec und QCodec. Da man ja aber nicht im Vorhinein weiss, ob ein Filename wie codiert ist, muss man noch etwas mit regular expressions herum tricksen:

...
var str = part.getFileName(); // fetch the filename of the MessagePart
var codec = Packages.org.apache.commons.codec;
var reg = /(=\?[A-Z\-0-9]+\?B\?[^?]+\?=)/gi;
var match = str.match(reg);
for (var i in match) {
  str = str.replace(match[i], (new codec.net.BCodec()).decode(match[i]));
}
var reg = /(=\?[A-Z\-0-9]+\?Q\?[^?]+\?=)/gi;
var match = str.match(reg);
for (var i in match) {
  str = str.replace(match[i], (new codec.net.QCodec()).decode(match[i]));
}
...

...ist nun seit Neuestem eine Aktiengesellschaft.
-> http://www.thomas-krenn.de/

Und ich gratuliere! Seit einigen Jahren beziehen wir unsere Server ausschließlich von dort, und hatten noch kein einziges Problem mit der gelieferten Hardware (ui ui, so was sagt man ja nicht, ganz schnell auf Holz klopfen).

Ich kann nicht oft genug auf diese Seiten hier hinweisen:
-> http://www.mozilla.org/rhino/ScriptingJava.html
-> http://www.mozilla.org/js/liveconnect/lc3_method_overloading.html

Es macht das Leben eines Helma-Programmierers, der in die Java-Welt eintaucht, ungemein leichter wenn man diese Kniffe kennt.

95 Prozent aller Passwörter sind unsicher...Nur 5,1 Prozent der Passwörter entsprachen gängigen Sicherheitsanforderungen und bestanden aus Großbuchstaben, Kleinbuchstaben, Ziffern sowie Sonderzeichen...So stimmte in 30 Fällen (2,7 Prozent) das Passwort mit dem Usernamen überein.
-> http://derstandard.at/?id=2159693

Interessanterweise stimmt die Gleichung (username==passwort) auch hier auf twoday.net in 3,2% der Fälle.

Dass nur Passwörter sicher sind, welche Großbuchstaben, Kleinbuchstaben, Ziffern und Sonderzeichen enthalten, halte ich für unsinnig. Ein Passwort aus nur 6 Kleinbuchstaben ergibt schon 308.915.776 Kombinationsmöglichkeiten (von 'aaaaaa' bis 'zzzzzz'), und das scheint mir bereits ziemlich gut zu sein. Die Problematik ist viel mehr dass immer und immer wieder die gleichen Passwörter (sprich Namen/Dinge) verwendet werden. Auf twoday teilen sich 108 User (bzw 0,3%) das häufigste Passwort. Mit den häufigsten 10 Passwörten erwischt man 459 User, bzw 1,36%. Und mit den häufigsten 100 Passwörtern (welche jedem Hacker bekannt sind) erreicht man bereits 5,3% der User.

Die Situation ist also nicht ganz so dramatisch wie von der Studie dargestellt ("95 Prozent aller Passwörter sind unsicher"), dennoch aber übel. Man kann die User / Kollegen nicht oft genug daraufhin weisen bei ihren Passwörtern kreativer zu sein.

Verspätete Glückwünsche den Damen und Herren welche hinter dem herold.at-Relaunch stecken.

Die Suche in den Gelben Seiten ist super-flott, und die nachträgliche Einschränkung nach der Region ein Segen des Himmels :-) Und das sag ich alles so, obwohl wir (leider) gar nichts mit der Sache zu tun hatten. Wollte das nur mal los werden.

Der Routenplaner und die Stadtplansuche können natürlich nicht mit Google/MSN Maps mithalten, aber das ist auch zugegebenermassen gar nicht einfache Thematik.

An alternative approach to store hierarchical data in a relational database:
-> http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
[via MySQL newsletter]

Interesting approach, i've never actually seen it before, but smells a bit esoteric (but thats probably just *because* i've never actually seen it before).

But, what the heck, who needs to store hierarchicaly data nowadays anyways?

Folgende Frage galt es klären:
Wie definiert man dass bestimmte Files im CVS als executable Files unter Linux ausgecheckt werden sollen?

Die Antwort:
Man muss die Permissions der Dateien direkt im CVS-Repository mittels 'chmod +x' entsprechend setzen. Wenn nun ein CVS-Client unter Linux diese Dateien auscheckt, dann sind sie auch gleich executable.

Lösungsfindung:
Nachdem Googling versagte, führte 'Wild Blind Guessing' zum Ziel.

Weiss denn jemand ob dies in SVN eleganter gelöst wurde?