Apple in dem Fall mit Apple Mail.

Die Backtrace library will ich auch haben. :)

Tja, was soll ich sagen. Squeak mit Mars ist spannend.

Der Smalltalk Source Code für die Menü-Definitionen gefällt mir zum Beispiel wirklich gut.

menuFile
    ^ (MarsMenuItem label: 'File')
        add: (MarsMenuItem label: 'File Out...' keyStroke: $o command: #fileOut);
        addSeparator;
        add: (MarsMenuItem label: 'Save' keyStroke: $S command: #saveImage);
        add: (MarsMenuItem label: 'Save As...' command: #saveImageAs);
        addSeparator;
        add: (MarsMenuItem label: 'Quit (Development)' keyStroke: $Q command: #developmentQuit);
        add: (MarsMenuItem label: 'Quit' keyStroke:$q command: #quit);
        yourself

Das ist knackig.

Auf der anderen Seite... Das Versionskontrollsystem hat mal eben so vergessen das Changeset mit auf den Server zu schieben auf dem das was ich hochgeladen / comitted habe beruhte.

Äh, wiebidde? Das ließ sich dann zwar durch vereinte Anstrengungen von 3 Squeakern irgendwann fixen. Aber...

Und überhaupt, die GUI von Squeak ist... gewöhnungsbedürftig. Der größte Teil der Funktionalität liegt in Kontextmenüs versteckt - die man einfach nicht findet wenn man nicht weiß dass es sie gibt. Oder die nur kommen wenn man etwas bestimmtes nicht ausgewählt hat.

Grusel

Naja, mixed feelings.

Hrm, das ist mir doch ganz entgangen bisher.

Aber: here it is!

Was es tut: Beliebige Textbausteine in Xcode schnell einsetzen. Das geht zwar auch ohne ODCompletionDictionary, aber, mit kann man es auch in Xcode live bearbeiten. Und das macht das Feature eigentlich erst richtig nützlich.

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.

:-/