Und zwar mit grandiosen schauspielerischen Leistungen. :)

Auf der Ruby-Conference 2008.

The Ruby Code Review. A Play in Three Acts

Überhaupt finde ich Confreaks sehr cool. :)

Und noch mal von den Confreaks.

Ausgezeichneter Vortrag von Yehuda Katz darüber was er für gute Tests hält und was nicht. Sein Argument: Am Ende will man Regression-Tests haben, da nur die wirklich nützlich sind beim Refactorieren. Nur die sind nützlich, weil dass die Tests sind die man behalten kann während man den Code neu faktoriert.

Damit das geht muss der Code aber schon eine gute Faktorierung haben die man (ausschließlich?) über öffentliche Interfaces testen kann.

Wohlgemerkt in dem Talk geht es nicht darum ob TDD gut oder schlecht ist - der Zweck ist einfach ein anderer. Ihm geht es um API-Stabilität und die Frage wie man Interfaces (nicht Implementierungen) über eine lange Entwicklung stabil hält.

Spannend. Mir ist dabei eingefallen dass ich damals im ersten Buch über Test Driven Development einen Absatz gelesen habe in dem Stand dass man zuerst seine Tests schreiben soll um dann an diesen seinen Code zu schreiben und zu refaktorisieren. Und dass man danach den Code als Tests für die Tests verwenden kann um wiederum diese zu refaktorisieren.

Gaudio. Ob das schon das ist was Yehuda meint? Ich vermute noch nicht ganz - aber es hört sich für mich nach etwas an was ich direkt tun kann - ich kann meine Tests betrachten und mir anschauen ob sie tatsächlich das testen was mich interessiert (das interface) und wenn dem nicht so ist, dann kann ich mir das Interface betrachten und die Tests tatsächlich refaktorieren.

Yay, mehr Arbeit. :)

I just started playing around with Mars which is a bridge from Squeak to Cocoa, which allows Squeak Programms to have a Cocoa GUI.

Pretty nice - however not quite as easy to get installed if you are a SmallTalk newbie like me.

There are installation instructions on the Mars homepage however I couldn't quite follow them, so I enhanced them a little and give you the rundown here:

Instructions

• I downloaded the basic Image from http://ftp.squeak.org/3.10/Squeak3.10.2-7179-basic.zip
• Got the Virtual Machine from ftp://ftp.smalltalkconsulting.com/experimental//Squeak%203.8.21beta1U.app.zip
• Installed basic developer tools by executing <HTTPSocket httpFileIn: 'installer.pbwiki.com/f/LPF.st'.> in a workspace window (select it and hit command-d)
• Then I ran

  Installer universe 
   addPackage: 'OmniBrowser';
   addPackage: 'OmniBrowser-Morphic';
   addPackage: 'OmniBrowser-Standard';
       addPackage: 'OmniBrowser-Refactory';
   install.
  

  to get the basics and
• installed Mars by executing ``` Installer wiresong project: 'ob'; install: 'OB-Monticello'. Installer lukas project: 'omnibrowser'; install: 'OB-Tools'.

Installer ss project: 'Mars'; install: 'Mars'; install: 'OB-Mars'.

After that `OBMarsWorld execute.` replaces the menubar of Squeak with the Cocoa stuff.

:) Have fun!

Oh, and by the way, I just tried this with the dev image available from Damien Cassou at http://damiencassou.seasidehosting.st/Smalltalk/squeak-dev

This image already has most stuff preloaded, so you can just run

Installer wiresong project: 'ob'; install: 'OB-Monticello'. Installer lukas project: 'omnibrowser'; install: 'OB-Tools'.

Installer ss project: 'Mars'; install: 'Mars'; install: 'OB-Mars'. ```

to get Mars installed and then start it by running: OBMarsWorld execute.

Ich habe immer wieder das Problem, dass ich in Shell-Scripten den absoluten Pfad zum eigenen Script, oder zumindest den Ordner in dem das Script liegt benötige.

Dieses Problem hat viele Lösungen - die allermeisten kommen aber entweder nicht mit Leerzeichen in diesem Pfad klar, oder versagen wenn man das Script über verschiedene Kombinationen von absoluten und relativen Pfaden aufruft.

Meine gegenwärtige Lösung ist das hier:

SCRIPTDIR="$(cd "$(dirname "$0")" && pwd)"
echo $SCRIPTDIR

Damit bin ich zwar auch überhaupt nicht glücklich, aber immerhin scheint es zu funktionieren. :/

Insbesondere ist das Quoting extra funky. Unter MacOS X scheint es aber zu gehen (d.h. die Bash frisst das korrekt)

Hat da vielleicht jemand eine bessere Idee?

Update: Florian hatte die großartige Idee doch einfach mal in gut benutzte Shell-Programme wie den Wrapper für OpenOffice zu schauen. Und siehe da:

# cat /usr/lib64/openoffice/program/swriter
#!/bin/sh

cmd=`dirname "$0"`/soffice
exec "$cmd" -writer "$@"

funktioniert großartig. Man kriegt zwar nur den relativen Pfad - aber das reicht ja in aller Regel.

Unfactoring is nicht einfach. Man muss es immer wieder üben.

Hier ein Schulungsvideo von der RubyConf08.

Highly advised! ;)

Das wollte ich tun, aber die bestehenden Lösungen fand ich alle nicht so toll.

Well, also noch mal.

Immerhin bietet Python ja eine menge mit seinen Batteries Included. Das heißt ich muss nicht aufwendig mit RegExen die plist dateien auseinander nehmen. Schließlich gibt es die plistlib.

Hier das Resultat:

#!/usr/bin/env python

# Usage:
# Either copy into a shell script build phase 
# (don't forget to change the interpreter to "/usr/bin/env python")
# Or just put it into a shell script and call it form there.
#
# Discussion:
# There are really two info plist keys that could be used for the source revision:
# The CFBundleShortVersionString and CFBundleVersion
# Apple recommends to use CFBundleVersion, because it is not shown in the finders info dialog,
# but is shown in the standard about dialog of a cocoa application where the CFBundleVersion
# is shown in parantheses behind the CFBundleShortVersionString.
#
# Inspired by Daniel Jalkut at http://www.red-sweater.com/blog/23/automatic-build-sub-versioning-in-xcode
# License: Creative-Commons Public Domain http://creativecommons.org/licenses/publicdomain/

import os, re, plistlib

# Test if run from xcode
is_run_from_xcode = os.environ.has_key("BUILT_PRODUCTS_DIR")
if not is_run_from_xcode:
    exit("Needs to be run from a Xcode shell scribt build phase")

# We take the one from the built products dir to keep revision numbers out of the repository
info_plist_path = os.path.join(os.environ["BUILT_PRODUCTS_DIR"], \
                               os.environ["INFOPLIST_PATH"])

# get latest svn revision
def output_of_command(*command_and_arguments):
    import subprocess
    return subprocess.Popen(command_and_arguments, stdout=subprocess.PIPE).communicate()[0]

os.chdir(os.environ["PROJECT_DIR"])
version_range = output_of_command("svnversion", "-nc")
latest_commited_version = re.search(r"\d*\w*$", version_range).group(0)

# enter into Info.plist
info = plistlib.readPlist(info_plist_path)
info["CFBundleVersion"] = latest_commited_version
plistlib.writePlist(info, info_plist_path)

Pretty neat. :)

Die aktuelle Version des Scripts liegt wie immer [source:open-source/utilities/xcode-add-subversion-version-to-built-Info.plist.py im Repository].

... im Schlüsselbund, dann möglicherweise deswegen weil man gerade Services Scrubber verwendet hat um sein Services-Menü aufzäumen.

Und das funktioniert indem es die Info.plist eines Programms manipuliert.

Doh. Wenn das nämlich eine signierte Applikation ist (wie alle Apple-Programme) dann stimmt danach natürlich die Signatur nicht mehr. Und das bedeutet dass sie nicht mehr auf den Schlüsselbund zugreifen können.

Natürlich ohne sich irgendwo in logfiles zu beschweren.

:-/

Mit einer sehr schönen Analogie (youtube)

Sehr sehenswert.

Heute war ich Brunchen mit Bekannten - insbesondere war da auch ein Blinder dabei, der Linux benutzt und versucht von Windows wegzukommen.

Das war spannend. Zuerst einmal, dass Computerbenutzung für Blinde ein riesen Problem ist. Die bekommen von irgendwelchen Firmen für irrsinnig viel Geld Windows-Computer verkauft, die dann vielleicht auch funktionieren - für die sie aber 5000 € jährlich bezahlen müssen. (Ob die Zahl jetzt stimmt sei mal dahingestellt - Fakt ist, es ist teuer).

Und die Krankenkassen sind da nicht so geberfreundlich - denn wer braucht denn schon das Internet? Selbst braille-Zeilen sind wohl ein echter Kampf bis man sie kriegt. (UNGLAUBLICH wenn man sich das überlegt!)

Dabei geht es ja auch anders: Linux hat die Kommandozeile, die für Blinde schon mal ein großer Vorteil ist - und sie können freie Software selber Hacken bis Sie tut was sie brauchen.

Was wohl z.B. bei dem Gnome Screenreader Orca auch einige tun. (Yay! More power to you!)

Prinzipiell haben Blinde mit freier Software überhaupt eine Chance, denn der Markt gibt viele Hilfen die sie bräuchten einfach nicht her. Spezielle Routenführer für Blinde? Gibt es, aber dort stehen für Berlin nicht mal die U-Bahnen mit drinn. Geschweige denn wo genau der Eingang dazu ist und ob sie aus dem Zug jetzt vorne oder hinten aussteigen sollen, damit sie gleich noch eine Unterführung unter der Straße nutzen können.

Das fand ich überhaupt das Spannendste, wo denn die Probleme liegen. Also zum Beispiel:

• Open Office funktioniert wohl ganz gut - aber sobald man eine Präsentation im Full-Screen Modus anschaut, rendert OpenOffice offenbar die Folien als Bild - tada, die Screenreader Information fehlt und alles ist still.
• Scannen ist ein riesen Problem. Es gibt einfach keine Software mit vernünftiger Layout- und Tabellen-Erkennung die eine genügend hohe Erkennungsrate hat. Bis vor kurzem war noch nicht mal drinn dass die Orientierung des Textes erkannt wurde...
• PDFs lesen geht nicht. Acrobt Reader soll es wohl können - aber die freie Software noch nicht.
• Browsen mit Firefox funktioniert gut - aber wenn man eine lange Seite schnell ein paar mal scrollt (space oder pagedown) dann dauert es manchmal bis zu einer Minute bis der Screenreader auch so weit gekommen ist.

Spannend. Das sind nicht ganz die Probleme mit denen ich gerechnet hätte. Vor allem dass GUI-Anwendungen so wichtig sind. An Firefox und OpenOffice kommt kein Blinder vorbei.

Noch ein eher abschreckendes Beispiel: Er hat an der exzellenten Freien Universität Informatik Studiert. Dabei ist er aber gescheitert, weil z.B. die Aufgabenblätter zwar als PDF kamen - aber darin nur gescannte Aufgabenblätter waren...

Peinlich.

Ein langer Traum ist in Erfüllung gegangen - alle Versionskontrollsysteme (hg, bzr, git und natürlich svn) unterstützen endlich das Reden mit einem Subversion-Server.

Das bedeutet, man kann jetzt SVN als Lingua Franca mit allen verteilten Versionskontrollsystemen einsetzen um einen gemeinsamen Server zu haben von dem alle pullen und pushen können. Oder kurz gesagt: Wenn man SVN als Server hat, kann jeder benutzen was ihm persönlich am meisten liegt.

Das funktioniert natürlich noch alles nicht perfekt - aber es fängt an.

Und daher hab ich mal aus Spaß ein Projekt mit jedem der VCS ausgecheckt und bin etwas überrascht von den Ergebnissen:

• bzr git und svn haben den root des Projekts einfach als große Ordner-Hierarchie ausgecheckt, so wie das in svn eben abgebildet ist.
• hg hat als einziges ohne Zusatz-Optionen erkannt das es trunk, branches und tags gibt und das auf die entsprechenden nativen Konzepte (branches) abgebildet. (Das müsste mit mehr Aufwand aber mit bzr und git auch gehen).
• Der Import hat schon mal recht unterschiedlich lange gedauert:
  • bzr: 20 min
  • git: 14 min
  • svn: 7 min
  • hg: 7 min (sogar drei Sekunden schneller als svn! :)
• Logischerweise sind damit die Repositories auch völlig unterschiedlich groß:
  • bzr: 83 MB
  • git: 93 MB
  • svn: 162 MB (Zweimal die Größe des ganze Source-Codes aller tags und branches, also wie erwartet)
  • hg: 5.2 MB (überraschend - angeblich steckt da die ganze History drin - so richtig glauben kann ich das aber noch nicht. Vom Platz her ist das etwa das doppelte den alleine der trunk als checkout braucht)

Hier die Kommandos die ich abgeschickt habe (mit den Laufzeit Ergebnissen)

bzr clone http://python-nose.googlecode.com/svn nose-bzr:: 177,62s user 27,00s system 16% cpu 20:17,34 total git svn clone http://python-nose.googlecode.com/svn nose-git:: 57,63s user 130,80s system 22% cpu 14:02,33 total svn co http://python-nose.googlecode.com/svn nose:: 9,13s user 19,77s system 6% cpu 6:58,31 total hg svnclone http://python-nose.googlecode.com/svn nose-hg:: 27,15s user 12,25s system 9% cpu 6:57,76 total

So viel kann man daraus natürlich nicht schließen - aber mir gefällt dass man jetzt mit allen VCS an Subversion herankommt und der Weg auf dem hgsubversion ist scheint mir schon mal sehr gut zu sein. :)