Kann mir mal jemand erklären, warum Apple die AirTunes-Geschichte so implementiert hat, das scheinbar nur iTunes damit arbeiten kann? Das ist doch hochgradig dämlich. Wenn ich schon eine Möglichkeit habe, meine Stereoanlage an meinen Mac zu hängen, dann will ich das doch nicht nur für iTunes machen - mindestens der DVD Player sollte doch wohl bitte schön den gleichen Komfort bekommen. Noch besser wäre natürlich eine allgemeine Lösung - wobei ich verstehen würde, wenn sie das nicht täten. Immerhin muss für AirTunes ja digitale Musik gestreamed werden- und zwar in einem passenden Streaming-Format. Aber DVDs produzieren das doch schon von Hause aus, also wieso kann ich da kein AirTunes-Device auswählen? Selten dämlich.
FireWire not dead, but it's on life support - der Life-Support ist aber ziemlich mies. Gerade nochmal nachgeguckt: die neuen iPods (Nano und Video) haben kein Firewire mehr. Was ziemlich banane ist, denn mein Mac Mini hat kein USB 2 - und mit USB 1 will ich meine Musiksammlung wirklich nicht kopieren. Was denkt sich Apple bei so einer dämlichen Sache? Firewire kann nun wirklich nicht mit diesem armseligen USB 2 ersetzt werden. Auch neue Rechner werden wohl nur noch notgedrungen dann einen Firewire-Port mitbringen, wenn die Maschinen von Apple für Videocontent geeignet angesehen werden. Ausgesprochen schade, denn Firewire ist eine wirklich sinnvolle Anschlusstechnik, die auch gute Leistungsreserven für kommende Geräte bietet - und im Gegensatz zu USB 2 nicht die CPU mit Datenschaufeln überbeschäftigt.
appscript - Python als Alternative zu AppleScript. Also Applikations-Steuerung über die AppleScript Schnittstellen direkt aus Python Programmen heraus.
PEAK bietet ja seit geraumer Zeit generische Funktionen ala CLOS für Python an. Ich wollte immer mal damit rumspielen, aber lange Zeit war es ja einfach nur Bestandteil von PyProtocols, und die Installation etwas haarig. Seit September diesen Jahres ist es aber ausgekoppelt und sehr viel einfacher zu installieren. Also hab ich mich mal draufgestürzt.
Und ich muss sagen: wow. Was Phillip J. Eby da geleistet hat ist wirklich fantastisch. Die Integration in Python (funktioniert ab Python 2.3 - er hat einfach eine eigene Implementierung von Dekoratoren für Python 2.3 erfunden) ist super, auch wenn natürlich das eine oder andere etwas gewöhnungsbedürftig ist.
Ein kleines Beispiel:
import dispatch
[dispatch.generic()]
def anton(a,b):
"handle two objects"
[anton.when('isinstance(a,int) and isinstance(b,int)')]
def anton(a,b):
return a+b
[anton.when('isinstance(a,str) and isinstance(b,str)')]
def anton(a,b):
return a+b
[anton.when('isinstance(a,str) and isinstance(b,int)')]
def anton(a,b):
return a*b
[anton.when('isinstance(a,int) and isinstance(b,str)')]
def anton(a,b):
return b*a
[anton.before('True')]
def anton(a,b):
print type(a), type(b)
Dieses kleine Beispiel liefert einfach eine Funktion namens 'anton', welche auf Basis der Parametertypen unterschiedlichen Code ausführt. Das Beispiel ist natürlich völlig sinnfrei, zeigt aber einige wichtige Eigenschaften von generischen Funktionen:
- generische Funktionen sind - anders als klassische Objekt/Klassenmethoden - nicht an irgendwelche Klassen oder Objekte fest gebunden. Statt dessen werden sie über ihre Parametertypen ausgewählt.
- Parametertypen müssen demnach definiert werden - im Regelfall passiert das über eine Minisprache, mit der die Bedingungen der Auswahl formuliert werden. Das ist auch der einzige syntaktische Teil der mir nicht so gut gefällt: die Bedingungen werden als String abgelegt. Allerdings ist die Integration sehr gut, man erhält saubere Syntaxfehler schon beim Laden.
- eine generische Funktion kann mit beliebigen Bedingungen überladen werden - nicht nur der erste Parameter ist entscheidend. Bedingungen können übrigens auch auf Basis von Werten entscheidungen treffen - jeder beliebige Python-Ausdruck kann dort verwendet werden.
- mit Methodenkombinationen (Methoden sind hier die konkreten Ausprägungen einer generischen Funktion) kann man eine Methode vor oder nach ihrem Aufruf modifizieren, ohne an den Code selber ranzukommen. Das Beispiel benutzt eine before-Methode die immer (deshalb das 'True') herangezogen wird, um Debugging-Output zu erzeugen. Natürlich kann man bei before/after Methoden jederzeit auch Bedingungen benutzen, um sich auf spezifische Ausprägungen des Aufrufs der generischen Funktion zu hängen - womit generische Funktionen ein vollwertiges Event-System sind.
Ein recht guter Artikel über RuleDispatch (das generische Funktionen Paket) gibt es bei Developerworks.
Das Beispiel zeigt übrigens die Python 2.3 Syntax für Dekoratoren. Mit Python 2.4 kann natürlich auch die @-Syntax benutzt werden. Ein Nachteil soll nicht verschwiegen werden: die Definition von generischen Funktionen und ihren Methoden ist nicht interaktiv möglich - jedenfalls nicht mit der Python 2.3 Syntax. Leider muss man da generell mit externen Definitionen in Dateien arbeiten.
RuleDispatch wird definitiv einen Platz in meinem Werkzeugkasten finden - die Syntax ist einfach genug, die Möglichkeiten hingegen sind gigantisch. Als Eventsystem schlägt es an Flexibilität jedes andere System und als generelle Möglichkeit der Strukturierung des Codes kommt es sehr nah an CLOS heran. Schade, das Django sich vermutlich auf PyDispatch ausrichten wird - RuleDispatch würde meiner Meinung nach wesentlich besser passen (da viele Aspekte in Django als Dispatch auf mehrere Parametertypen geschrieben werden könnten).
LTK - The Lisp Toolkit - wenns mal nur einfach ein bischen GUI sein soll, aber nicht unbedingt die grosse Keule nötig ist - LTK bietet einfache Bindings für TK in Common Lisp. Arbeitet auch hervorragend mit OpenMCL zusammen, sogar CLISP mag damit.
Sams Teach Yourself Shell Programming in 24 Hours - Ein ganzes Buch über Shell-Programmierung. Und damit natürlich auch eine recht gute Einführung in die diversen Tools, die Unix-Systeme zur Verfügung stellen. Sicherlich jedem zu empfehlen, der sich z.B. einen Root-Server zugelegt hat und da jetzt mehr mit machen will - aber eben sonst Linux eher vom GUI her kennt.
Diebe mit Kunstgeschmack?
Mit Hilfe eines Krans haben in Großbritannien drei Diebe eine zwei Tonnen schwere Bronzeskulptur des weltbekannten Künstlers Henry Moore gestohlen. [...] Die Polizei äußerte die Vermutung, das Diebes-Trio habe es ausschließlich auf den Materialwert abgesehen und wolle die Figur einschmelzen.
Einschmelzen? Definitiv Kunstgeschmack!