Der ständige Wechsel zwischen der Metro Oberfläche und dem Desktop ist noch etwas nervig. Andererseits ist es natürlich gut, dass nach wie vor noch Desktopanwendungen installiert und verwendet werden können und wir unsere Rechner nicht völlig vom App Store abhängig machen müssen. Die Desktopanwendungen erscheinen dann auch auf der Metrooberfläche, die das Startmenü ersetzen.

Das größte Manko ist in meinen Augen aber die Tatsache, dass Metro absolut unintuitiv ist. Ich weiß nicht, wie sich das auf nem Tablet anfühlt aber auf nem Laptop ist das ziemlich unbrauchbar. Menüs sind alle versteckt und tauchen aus dem Nichts auf,  wenn man mit der Maus irgendwohin kommt. Nur weiß das ja niemand. Woher auch.

Am eindrucksvollsten merkt man das, wenn man zum ersten mal vom Desktop zurück zu Metro kommen möchte. Ich verrate Euch den Trick: Links unten im Eck ist der Button, der da hinführt – aber der kommt natürlich nur, wenn Ihr da mit der Maus hinfahrt. Oder Ihr nehmt die Windowstaste.

Wer das nicht weiß, dem geht es so:

Ich habe keine Lust, diese Anrufe meiner Eltern zu beantworten. Bevor die sich Windows 8 holen schwatz ich ihnen lieber Ubuntu auf.

Für diejenigen unter Euch, die es auch versuchen möchten: Nach der Installation von Windows 8 ist es wichtig, dass Ihr zuerst die Windows Updates installiert und dann die VirtualBox Guest Additions, ansonsten werdet Ihr einen schwarzen Bildschirm kriegen, der nie wieder weg geht (so wars bei mir jedenfalls).

Falls und wenn ich Zeit habe, Windows 8 ausgiebig zu testen, werde ich selbstverständlich hier berichten.

Speicher

Ich glaube dieses Problem ist mittlerweile behoben. Aber als ich noch regelmäßiger FF Nutzer war und über relativ wenig RAM verfügte, lief regelmäßig Firefox im Arbeitsspeicher Amok und je länger er lief, desto absurder wurde sein Speicherverbrauch. Das war der Grund, der mich seinerzeit von Firefox abgebracht hat, auch wenn er mittlerweile nicht mehr relevant zu sein scheint.

Fehlertoleranz

Bei weitem das nervigste Feature von Firefox! Fehlerhafter (X)HTML Code wird von FF (sofern er weiß wie) bei der Anzeige einfach korrigiert. Für den Anwender ist das natürlich erstmal super, keine Frage. Zwei entscheidende Macken hat dieses Feature dann aber doch. Zum Einen die Tatsache, dass es immer nur den korrigierten Code anzeigt, auch wenn man sich z.B. den Seitenquellcode anzeigen lässt und zum Anderen die Tatsache, dass dieses Feature nicht abschaltbar ist! Wie oft denkt man sich doch als Entwickler “Der Scheiß IE zeigt meinen Code nicht richtig an”, weil es im FF funktioniert. Erst wenn man dann z.B. Opera öffnet und den gleichen Fehler vor sich sieht merkt man, dass man mal wieder von Firefox an der Nase herumgeführt wurde. Selbst in Entwicklertools wie z.B. Firebug wird nur der korrigierte Code angezeigt.

 Eigenwillige Berechnungen

Auch wenn Firefox zu seiner Entstehungszeit als Retter des HTML-Standards gefeiert wurde, da es nicht so viele verrückten Eigeninterpretationen bot wie der Internet Explorer, nimmt es Firefox auch an manchen Stellen mit den Standards nicht so genau. Ein Beispiel mit dem ich jüngst selbst konfrontiert wurde, ist eine sehr seltsame Interpretation von Werten für letter-spacing. Die Spezifikation für CSS 2.1 sagt

This property specifies spacing behavior between text characters. Values have the following meanings:
[...]
<length>
This value indicates inter-character space in addition to the default space between characters. Values may be negative, but there may be implementation-specific limits. User agents may not further increase or decrease the inter-character space in order to justify text.

Es geht also um den Abstand zwischen zwei Zeichen. Wie wir alle wissen, arbeitet die Anzeige des Webbrowsers mit Pixeln, wie alles was mit dem Computerbildschirm zu tun hat. Nun gehen wir vielleicht mal hin und sagen unserem CSS-Code folgendes:

p.spacing {
  font-size:21px;
  letter-spacing:-0.02em;
}
p.normal {
  font-size:21px;
}

Wie Ihr seht, haben wir einen negativen Wert für letter-spacing. Das heißt der Abstand zwischen den Zeichen soll um 0,02em verringert werden (gegenüber dem normalen Abstand). em ist eine Einheit, die relativ zur Schriftgröße ist, 1em entspricht also 100% der Schriftgröße. In der Zeile darüber haben wir die Schriftgröße auf 21px gesetzt. Hier nun das Problem:
Bei einer Schriftgröße von 21px entsprechen 0,02em exakt 0,42 Pixeln! Der Abstand zwischen zwei Zeichen kann aber schlecht um 0,42 Pixel verringert werden, denn das lässt sich auf dem Bildschirm reichlich schlecht feststellen. Schreibt man nun die Zeichenkette “TestTestTestTestTestTestTestTestTestTest” in je einen Absatz der Klasse produzieren Browser wie Opera und Safari folgenden Output (Oben normal, unten spacing):

Ausgabe Safari

Ausgabe Opera

Ist ja auch logisch. Der Abstand kann nicht um weniger als einen Pixel reduziert werden, also macht man es nicht. Außer man ist Firefox:

Ausgabe Firefox

srsly??? What the ?? Ich weiß nicht genau wie – aber Firefox verringert tatsächlich irgendwie (und ziemlich unberechenbar) den Abstand zwischen den Zeichen. Ich vermute  mal (mir war nicht wirklich langweilig genug um das zu untersuchen), dass er einfach den Abstand jedes x. Zeichen reduziert, sobald er über die 1px-Grenze rauskommt beim addieren der Abstände. Das ist aber fatal und sorgt für ein uneinheitliches Schriftbild. Vom Problem für den Code mal ganz abgesehen.

Wer es mir nicht glaubt, kann sich die Testseite selbst anschauen. Übrigens macht IE9 den gleichen Mist.

Solche Berechnungen sind kein Einzelfall in Firefox und wenn ich mal wieder über eine stolpere, werde ich mich hier sicher genüsslich drüber amüsieren. May the browser flamewar begin.

Roman Zenner gibt bei t3n einen kurzen Überblick, über verschiedene Vorgehensweisen. Ein guter Artikel, den ich fast uneingeschränkt so stehen lassen kann (auch weil er eigentlich nur wenig sagt), mit folgender Ausnahme:

Wer anspruchsvoller ist, das Magento-Templating selbst erkunden und ein eigenes Theme erstellen will, hat im besten Fall einen Grafiker bzw. eine Grafik-Agentur engagiert, die neben optisch reizvollen Designs auch technisch einwandfreien und „schönen“ HTML/CSS-Code umsetzen kann.

Davon kann ich nur abraten. Die Anzahl der Grafiker, die tatsächlich wirklich gut HTML und CSS können ist sehr beschränkt. Ob es überhaupt welche gibt, die mit Magento Templates umgehen können, halte ich für fraglich (wenn doch, möge der betreffende sich hier melden). In der Regel wird es besser sein, wenn Grafik und Programmierung separat sind. Natürlich gibt es Agenturen, die auch das bieten – sei inhouse (was dann aber eine große und teure Agentur sein dürfte), oder über externe Programmierer (damit verdiene ich unter anderem mein Geld ). Wie dem auch sei: Grafiker sollten nicht Coden. Das war schon immer meine Devise. Umgekehrt: Programmierer sollten nicht designen. Außer sie sind gut. Und da gilt die gleiche Faustregel wie andersrum: Das ist sehr selten!

Nochmal für alle, die es vergessen haben: TDD lässt sich kurz beschreiben: Statt (wie es klassisch üblich ist) erst den Quellcode zu schreiben und diesen dann zu testen, wird beim TDD zuerst der Testfall geschrieben. Der schlägt natürlich fehl. Dann wird erst die Implementierung geschrieben und zwar so lange, bis der Testfall nicht mehr fehlschlägt. Die Intention dahinter ist natürlich, dass sichergestellt wird, dass das getestete Objekt nachher auch nur das tut, was sie soll und dass es vollständig getestet wird.

Besonders bei Komponententests wird ja gerne ein White-Box-Verfahren angewandt. Auch wenn natürlich gerade JUnit als berühmtester Vertreter der Frameworks für Modul- und Integrationstests ursprünglich für TDD geschrieben wurde, bevorzugen viele Entwickler für diese Teststufe den implementierten Code zu testen und eben nicht TDD anzuwenden. Der vermeintliche Vorteil: Man weiß, welche Fehlerbehandlung getestet werden muss, weil diese ja bereits implementiert wurde (offensichtlich). Das ist allerdings ein Trugschluss, denn wenn die getestete Funktion von vorne herein gut designed wurde, sollte ja wohl schon vorher klar sein, welche Fehler behandelt werden sollten.

Wenn es richtig angewendet wird, zwingt TDD den Entwickler ja förmlich dazu, sich vorher Gedanken über das zu machen, was er entwickeln will und besonders darüber, wie es funktionieren muss.

Übrigens lässt sich das auch wunderbar mit requirementbasiertem  Testen vereinbaren, wie es z.B. der in der Luftfahrt geforderte DO-178B Standard vorsieht, vereinbaren. In diesem Fall müsste natürlich das Low-Level-Requirement noch vor dem Test geschrieben werden. Aber dann kann man den Test nach dem Requirement modeln und schließlich das Requirement implementieren.

Provokativ gesagt: Eigentlich funktioniert TDD überall da, wo die Entwickler nicht zu faul sind, sich vorher Gedanken zu machen.

herzlich Wilkommen auf Dead Bytes.

Dead Bytes – das ist mein persönliches Blog zu allen Themen, die mit meinem Studium oder meiner Arbeit zusammenhängen. Hauptsächlich wird es also in die Bereiche Softwareentwicklung, Softwarequalitätssicherung, Webentwicklung und Software Engineering gehen. Aber auch sonst werde ich wohl, wenn ich über ein IT Thema stolpere, gerne hier posten.

Politische IT-Themen (Netzsperren and whatnot) werde ich aber weiterhin auf dem Hömmel kommentieren. Für diejenigen, die das noch nicht kennen: Das Hömmel ist das ultimative Blog, in dem Jesus und die Linke&rechte Hand des Teufels einfach quasi über alles reden.

Übrigens, alle die Global Destruction suchen und verwirrt sind: Kai hat mir diese Domain, die er ja eh schon lang los werden wollte, dankbarerweise recht günstig überlassen. Das hat uns beiden was gebracht: Er ist die Domain los und ich muss nicht so viel nachdenken, wie ich meinen Blog nenne. GD ist also nicht mehr über diese Adresse erreichbar, aber natürlich wie immer noch unter http://www.global-destruction.de.

Aber zurück zu Dead Bytes:

Politische Meinungen und hitzige Sozialdebatten werde ich hier keine führen. Hier ist Raum für IT.

Ich könnte mir auch vorstellen, den ein oder anderen Gastbeitrag hier zu veröffentlichen, wenn jemand keine Lust hat, sein eigenes IT-Blog zu starten

Das ist so grob zusammengefasst mein Konzept für Dead Bytes. Wir sind gespannt, obs was wird.

Nachtrag: Es sei noch erwähnt, dass GD leider nur noch bis Ende Januar unter der genannten Adresse zu finden sein wird und dann vom Netz geht,