Richard Cyganiak’s Weblog

Aus unerfindlichem Grund kommt Mac OS X ohne eine Möglichkeit daher, die Geburtstage aus dem Adressbuch auch im Kalender anzuzeigen. Hier die Lösung als AppleScript. Update: Seit Tiger ist diese längst überfällige Funktion endlich von Haus aus in iCal vorhanden. Der Geburtstagskalender lässt sich in den iCal-Einstellungen aktivieren.

Installation

• Script herunterladen.
• in den Ordner ~/Library/Scripts/Address Book Scripts ablegen (Library heißt Bibliothek im deutschen MacOS). Falls der Ordner noch nicht existiert, anlegen.

Es passiert nicht mehr alle Tage, dass ich eine neue Programmiersprache lerne.

AppleScript ist so was wie VBA für Mac OS. Es ist eine recht einfach gehaltene Sprache, die selbst nicht viel kann, aber auf die Funktionen und Daten vieler Mac-Programme zurückgreifen kann.

Ein typisches Beispiel: Im Adressbuch von Mac OS X kann man Geburtstage eintragen, aber diese werden im Kalender von Mac OS X nicht angezeigt. Das ist eine Parade-Anwendung für AppleScript. Wahrscheinlich wurde die Funktion extra weg gelassen, damit die Leute einen Grund haben, AppleScript zu lernen. Mein erstes Programm löst genau dieses Problem und ist hier zu finden: Applescript: Kopiere Geburtstage vom Adressbuch nach iCal

Lernen war einfach. Ich habe mir Matt Neuburg’s AppleScript: The Definitive Guide gekauft, was wahrscheinlich Overkill ist. Ich habe die ersten 40 Seiten gelesen (sehr nützlich, sie geben einen groben Überblick zu Anwendungsmöglichkeiten, Tools, usw.), und 4-5 Mal zu bestimmten Themen nachgeschlagen. Mehr war nicht nötig, um den Einstieg zu schaffen. Bis das Script fertig war, vergingen etwa drei Stunden. Nicht schlecht.

(Zugegeben, zwei Dutzend Geburtstage von Hand zu kopieren, hätte zehn Minuten gedauert.)

AppleScript ist offensichtlich auf leichte Erlernbarkeit angelegt. Programmzeilen lesen sich halbwegs wie englische Sätze (was ja keine gute Idee sein muss, siehe COBOL). Beispiel: make new event at end of events of theCalendar with properties eventProps. Dabei sind theCalendar und eventProps Variablen, deren Wert ich vorher gesetzt habe. Mir gefällt das ganz gut. Ist zwar viel Tipperei und nervt wahrscheinlich auf Dauer, aber merkt sich extrem gut.

Was fiel mir bei der Lernerfahrung negativ auf?

• Kein automatisches Anzeigen von Fehlern während des Tippens, wie z.B. bei Eclipse.
• Schlechte Fehlermeldungen. NSScriptFooBarError, und die verursachende Zeile wird markiert. Ursache war dann vielleicht, dass ich auf ein nicht existierendes Array-Element zugreifen wollte.
• Es ist schwer nachzuvollziehen, was für Ergebnisse die einzelnen Befehle geben. Mein Wunsch: Nach der Ausführung des Scripts mit der Maus über den Code fahren und in Tooltips die letzten Werte aller Rückgaben sehen, inkl. Elemente eines Arrays, Eigenschaften eines Objekts usw.
• Als Ersatz diente mir die display dialog-Funktion. Sie akzeptiert aber nur Zeichenketten und keine komplexeren Strukturen wie Arrays.
• Der Rückgabewert des letzten Befehls wird in einem extra Bereich angezeigt, auch inklusive Array-Elementen und Objekteigenschaften. Manchmal steht da aber nur “event 12 of calendar 3 of iCal”, was überhaupt nicht hilfreich ist.
• Zum Lernen wären ein paar Beispielscripte hilfreich gewesen, an denen man sich die Grobstruktur eines Scripts und nützliche Idiome abschauen könnte.

Mit einer besseren IDE als dem doch recht bescheidenen Script Editor von Apple wäre es ein superleichter Start geworden. Das gibt mir Hoffnung, dass Programmieren mit der richtigen Sprache und den richtigen Werkzeugen doch eines Tages zu einer Grundfertigkeit wie Lesen, Schreiben und Rechnen werden kann.

TinyCC ist ein superkompakter, extrem schneller C-Compiler. TinyCC kann beispielsweise einen Linux-Kernel in 15 Sekunden kompilieren. Schnell genug, um das bei jedem Bootvorgang zu machen, wie Slashdot schreibt.

In einem Kommentar habe ich das gesehen:

#!/usr/local/bin/tcc -run

main()
{
    DoSomethingHere();
}

Mir ist schwindelig. C als Scriptsprache? Man kann sich auf gar nichts mehr verlassen dieser Tage.

Für das diesjährige Projekt Semantic Web an der Freien Universität Berlin hatte ich ein Wiki eingerichtet. Dieses wurde heute Opfer einer WikiSpam-Attacke. Auf vier Seiten wurden jeweils dutzende Links zu diversen asiatischen Seiten eingefügt. Sollte wohl die Google-Positionierung der Seiten verbessern.

Zum Glück habe ich die RecentChanges als RSS-Feed abonniert. Den Mist wegzumachen, dauerte ungefähr eine Minute. (Das drüber bloggen zwei. Ähem.)

Ich stelle mich schon mal auf dier ersten Comment-Spams hier im Blog ein.

Im Moment habe ich kein Problem damit, Wiki- und Comment-Spam gelegentlich von Hand zu entfernen. Wenn es schlimmer wird, muss aber eine andere Lösung her. Von technischen Lösungen halte ich nicht viel, da sie sich meist mit ein wenig Grips umgehen lassen und ich keine Lust auf ein ewiges Wettrüsten habe. Wie ich gerade sagte, muss dieses Problem letztendlich rechtlich oder gesellschaftlich (durch Ächtung solcher Methoden) gelöst werden.

Der Zustand des Internets ist deprimierend. Wohin man klickt, Viren, Würmer, Trojaner, 419-Scams, Phishing, Dialer, Spy- und Adware.

Gibt es einen Ausweg? Jakob Nielsen stellt treffend fest, dass der vielfache Ruf nach mehr Verantwortungsbewusstsein bei den Benutzern nicht die Antwort sein kann:

However, user education should not be the main approach to countering security problems for three reasons. First, and most importantly, it doesn’t work. Computer security is too complicated and the bad guys are too devious and inventive. … Second, user education puts the burden on the wrong shoulders. It’s like the old Wild West, where the answer to crime was that every man carried a gun. In civilized society, we’ve abandoned this approach in favor of a professional police force to deal with criminals. … Third, as long as we keep the burden on users rather than fix the technology, we’ll never realize the Internet’s full benefits. Instead, we’ll alarm users and make them ever more reluctant to use the technology to its full potential.

Was dann? Jakob schlägt sechs Maßnahmen vor:

1. alle Informationsübertragungen verschlüsseln,
2. alle Informationsübertragungen digital signieren,
3. alle Sicherheitseinstellungen standardmäßig aktivieren,
4. alle Updates automatisieren,
5. die Usability von sicherheitsrelevanten Funktionen verbessern,
6. die verantwortlichen Betrüger und Verbrecher aggressiver verfolgen.

Das trifft den Nagel auf den Kopf. Aber: Die ersten fünf dieser Punkte sind schon weitgehend erreicht oder können in absehbarer Zeit umgesetzt werden. Es hakt an Punkt sechs.

Heute kann jeder Glücksritter mit einem Minimum an Verstand ohne Angst vor Strafe seinen neuesten finsteren Plan an der nichtsahnenden Internet-Bevölkerung ausprobieren. So lange sich das nicht ändert, wird das Internet ein ungemütlicher Platz bleiben. Und da habe ich wenig Hoffnung. Das Problem kann nur international gelöst werden. Und nicht mit dieser Generation von Politikern und Richtern.

Bis dahin können wir an den Punkten eins bis fünf arbeiten. Und die wichtige Frage diskutieren, wieviel Anonymität wir im Internet wollen.

James Robertson hat einen kurzen Eintrag zu einer Idee von Sonia Carter: Using training during CMS selection.

Es geht um den Einkauf von Content Management Systemen. Diese sind komplex, der Markt ist unübersichtlich, die Evaluierung verschiedener Produkte ist sehr aufwändig. Die Idee ist nun, jeden Anbieter eine Schulung für Endbenutzer machen zu lassen. Dadurch wird ein Unterscheidungsmerkmal hervorgehoben, das für den erfolgreichen Einsatz komplexer Softwareprodukte absolut entscheidend ist: die Usability.

Die Idee schreit geradezu nach einer Anwendung auf andere Produkte. Ich sage nur Telefonanlagen.

Gestern aufgeschnappte Trivia: Die polnische Sprache hat zwei Formen des Plurals. Eine für Gruppen mit mindestens einer männlichen Person, und eine für alle anderen Gruppen. Eine Gruppe von einer Million Frauen wird grammatisch anders behandelt als eine Gruppe von einer Million Frauen und einem Mann. Lustig.

Aber genau genommen ist es im Deutschen ähnlich. Unser Plural verwendet zwar den weiblichen Artikel, aber die männliche Form des Substantivs, außer wenn man sich ganz sicher ist, dass die Gruppe zu 100% aus weiblichen Individuen besteht (siehe „die Verkäufer“ und „die Verkäuferinnen“).

Das politisch korrekte „die VerkäuferInnen“ mag man gut finden oder auch nicht, aber zumindest gleicht es diese sprachliche Asymmetrie aus.

(Das hätte wohl „… mag man/frau gut finden oder auch nicht …“ heißen müssen.)

Matthew Porter schreibt über ein Problem mit Apples Dual-Prozessor-Systemen. Anwendungsprogramme unter großer Last können Kernel Panic auslösen, also das System vollständig zum Absturz bringen.

Apples Antwort: Einfach den zweiten Prozessor abschalten.

Matthew:

Attention Apple! This suggestion, while helpful, is nothing more than a bandaid. More importantly, Apple’s near instant refusal to investigate where the problem lies is just plain stupid and demonstrates that you fail to understand the needs of the enterprise (Unix) market.

Under no circumstances should a userspace application cause the kernel to panic. On Unix, this is just plain unacceptable and represents an issue with something in the kernel or core libraries.

Heftiges Kopfnicken meinerseits. Kernel Panic ist bei Hardwaredefekten und beim Einsatz schlampig programmierter Treiber verzeihlich, aber nicht bei Allerwelts-Anwendungen. Die Schuld einfach auf die Anwendung zu schieben, ist nicht akzeptabel. Schon gar nicht von einem Hersteller, der sich um den Enterprise-Markt bemüht.

Streicht den Rack voll mit XServes G5 von meinem Wunschzettel.

(via Andrew Newman)

Ich lese gerade bei Wikipedia, dass der Font im iPod-Display Chicago ist. Chicago war der Systemfont des originalen 1984er Macintosh.

Ich mag diesen Fakt. Der iPod, Design-Ikone des frühen dritten Jahrtausends, verwendet ein Gestaltungselement, das unter dem Zwang von technischen Beschränkungen entstand, über die wir heute nur schmunzeln können. Der 1984er Macintosh ist ein Fall fürs Museum, aber Teile seines Designs funktionieren eine Generation später in völlig anderem Kontext immer noch.

Der „iPod“-Schriftzug auf der Rückseite ist übrigens Myriad Pro Semibold, falls das irgendwen interessieren sollte.

David Weinberger linkt zu David Salesin’s Fotos aus Bhutan. Die Farben. Die Berge. Die Gesichter. Unglaublich schöne Bilder. Bhutan ist eines der ärmsten Länder der Welt. Nach was für einem Maßstab?

Wenn ich mir diese Fotos anschaue, fällt mir noch etwas auf. Das Genre der Fotografie ist in den letzten Jahren, hm, anders geworden. Eindrücklicher, lebendiger, unmittelbarer. Ich kann es nicht genauer beschreiben, aber ich schiebe es auf die Digitalkameras. Weil man 50 Fotos aus 5000 auswählen kann. Das verändert alles. Es wird ein anderes Medium.

Oder erhöhen alle Fotografen einfach in Photoshop die Sättigung?

(In der Slideshow kann man mit den Cursortasten navigieren.)

Alles, was ich zu diesem Stück Weisheit sagen kann, ist: „Amen. Amen. Amen.“

Auszüge:

You’ve forgotten what it’s like to be a beginner.

A computer is a means to an end. The person you’re helping probably cares mostly about the end. This is reasonable.

The best way to learn is through apprenticeship — that is, by doing some real task together with someone who has a different set of skills.

Your primary goal is not to solve their problem. Your primary goal is to help them become one notch more capable of solving their problem on their own.

Most user interfaces are terrible. When people make mistakes it’s usually the fault of the interface. You’ve forgotten how many ways you’ve learned to adapt to bad interfaces.

Don’t take the keyboard. Let them do all the typing, even if it’s slower that way, and even if you have to point them to every key they need to type. That’s the only way they’re going to learn from the interaction.

Explain your thinking. Don’t make it mysterious. If something is true, show them how they can see it’s true. When you don’t know, say “I don’t know”. When you’re guessing, say “let’s try … because …”. Resist the temptation to appear all-knowing. Help them learn to think the problem through.

Whenever they start to blame themselves, respond by blaming the computer. Then keep on blaming the computer, no matter how many times it takes, in a calm, authoritative tone of voice. If you need to show off, show off your ability to criticize bad design. When they get nailed by a false assumption about the computer’s behavior, tell them their assumption was reasonable. Tell *yourself* that it was reasonable.

Never do something for someone that they are capable of doing for themselves.

Ich versuche inzwischen sehr bewusst, nach solchen Einsichten zu handeln. Einfach ist es nicht.

(via Tim Bray)

StatCVS ist ein CVS-Statistiktool, dessen Maintainer ich bin. Jetzt habe ich Version 0.2 veröffentlicht. Ich musste gleich noch 0.2.1 und 0.2.2 nachschieben, da sich Fehler in den Buildprozess eingeschlichen hatten, die ich erst nach dem Release bemerkt habe.

Es ist das erste Release seit eineinhalb Jahren. In der Zwischenzeit haben sich eine Vielzahl neuer Features und Bugfixes angesammelt, die jetzt endlich auch für Leute verfügbar sind, die sich ihre Software nicht aus dem CVS selbst kompilieren.

Hier ist ein StatCVS-erzeugter Beispiel-Report, der die Entwicklung von StatCVS selbst darstellt.

Guus Schreiber ist Co-Chair der Semantic Web Best Practices and Deployment Working Group beim W3C. Sehr interessante Präsentation über die Arbeit seiner Gruppe. Mehr in meinem englischen Blog.

Frank Wagner bloggt Tag Eins der Berliner XML-Tage.

Christian Fillies, Semtation GmbH. Semtation verkauft SemTalk, eine Microsoft Visio-Erweiterung zur Modellierung. Semantic Web für Office, sozusagen. Daher hat Fillies eine andere Perspektive als die meisten Leute auf der Konferenz.

„Gute Ontologien entstehen im Workshop oder Interview mit Domänenexperten; externe Ontologien bringen es meist nicht“

„Bei unseren Endanwendern ist es schon toll, wenn sie einen subClassOf-Pfeil in die richtige Richtung ziehen.“ Daher sind Reasoning usw. in der Praxis äußerst problematisch.

Er stellt ein Forschungsprojekt vor: Bei der Suche nach Dokumenten in einer Organisation sollen unterschiedliche Ergebnisse je nach Rolle, Kompetenz, Erfahrung des Suchenden zurückgegeben werden. Scheint mir nach dem Versuch einer technischen Lösung für ein soziales Problem.

Noch einmal Elena Paslaru. Wie bei ihrem gestrigen Vortrag betont sie, dass die Annahme ihres Vortrags nichts mit dem Fakt zu tun hat, dass ihr Chef Organisator der Konferenz ist. Hm.

Gemeinschaftsprojekt mit dem Institut für Pathologie der Charité Berlin. Alle histologischen Befunde (medizinische Bilddaten), die im täglichen Betrieb anfallen, sollen digital erfasst werden. Jährlich 75.000 Befundbilder. Übliche Lösungen gehen nicht gut: Image Retrieval allein reicht nicht, da auch Ausschnitte der Bilder annotiert werden sollen. Text Retrieval funktioniert für die Pathologieberichte, aber nicht für die Bilder.

Textfragmente der Berichte werden mit Bildausschnitten verknüpft. Inhalt der Texte wird mit medizinischen Ontologien annotiert, um die Suche zu verbessern. Eine Natural Language Processing-Komponente gibt es auch, die ist aber nicht Teil des Vortrags.

Komplexer Ontology Engineering Prozess.

Evaluierung diverser Editoren, Visualisierungstools, Reasoning Engines, Triple Stores. Gut: Protégé, Jena, RACER, FaCT, Sesame

Reasoning ist zur Zeit noch kaum praktikabel, Rules gar nicht.

Um Jena2 kommt man zur Zeit nicht herum.

Ontologien mit mehr als 100 Konzepten sind performancetechnisch unpraktikabel.

Karsten Tolle, Johann Wolfgang Goethe-Universität Frankfurt/Main

Dieser Vortrag ist interessant für mich, da das Thema recht nahe an Named Graphs ist, woran ich zur Zeit mit Chris Bizer arbeite.

Beim Umgang mit RDF-Informationen ist es wichtig, den Kontext der Informationen zu kennen. Er hilft unter Anderem bei der Beurteilung der Vertrauenswürdigkeit der Aussagen.

Karsten Tolle unterscheidet zwischen externem Kontext (Provenance, Namensräume etc.), internem Kontext (Umgebung im RDF-Graph) und zusätzlichem Kontext (Metainformationen über Tripel etc., leider im Vortrag weitgehend ausgespart).

Die heutigen RDF-Standards bieten keine ausreichende Möglichkeit, um solche Kontextinformationen explizit zu erfassen. Es gibt zwei Ansätze: Quads erweitern die üblichen RDF-Tripel aus Subjekt, Objekt und Prädikat um ein viertes Element, das Quelle oder Kontext bezeichnet. Sehr mächtig, aber nicht besonders kompatibel mit der RDF-Semantik. Die Alternative sind Tripel mit Kontext. Karsten Tolle findet sie besser, da man durch einfaches Weglassen des Kontexts abwärtskompatible RDF-Tripel bekommt.

eRQL (easy RQL) ist eine supereinfache, Google-style RDF-Anfragesprache. Sie soll großmutterkompatibel sein. Beispiele:

bridge sucht das Wort in allen Literalen oder URIs, case insensitive
<bridge;1,2,3> sucht aus Quellen 1,2 und 3
<~~~bridge> sucht mit Graph-Umgebung der Größe 3 (nett!)

Es gibt eine Implementierung.

Mir stellt sich die Frage, ob eine großmuttertaugliche RDF-Abfragesprache nützlich ist. Die Ergebnismenge wäre ein RDF-Schnipsel, der wahrscheinlich voll von URIs und RDF-Datatypes ist. Wie man so etwas für Großmütter aufbereitet, bleibt eine offene Frage.

Mich interessiert das Feld zwischen beiden Extremen. Ein halbwegs intuitives und kompaktes XPath für RDF wäre nett.

Universität Stuttgart & IBM Software Group

Frank Leymann beschreibt IBM’s Vision von Web Services und Grid Computing. Ziel ist die Virtualisierung von Geschäftsressourcen und von Hardware. Es soll möglich werden, Geschäftsanwendungen auf einer sehr hohen Abstraktionsebene zu bauen. Durch Zusammenstecken (Choreography, Flow) von Web Services.

70% aller Softwareausgaben in großen Unternehmen liegen im EAI-Bereich.

“Web Services haben in Wirklichkeit kaum etwas mit Web zu tun; Web Services sind Hardcore-EAI-Technologie”

Frank Leymann gibt eine Tour durch einige der WS-Standards. Es gibt viele, aber sie sind nötig, und modular. Schon die Kombination weniger Standards löst echte Probleme. WS-* kann scheibchenweise implementiert/eingeführt werden.

WS-* sieht aus wie CORBA, warum sollte es diesmal klappen? „Keine Ahnung …“ Aber es gibt breite Unterstützung für WS-* quer durch die Industrie.

Ich sehe WS-* mit Skepsis. Ja, damit soll ein echtes Problem gelöst werden. Die Ziele sind valide. Die Architektur scheint gut durchdacht zu sein. Es wäre toll, wenn wir so arbeiten könnten.

Es ist aber sehr weit entfernt von der heutigen Realität. Ich glaube nicht, dass man ein derart komplexes System top-down bauen kann. Ich glaube, hier gilt Gall’s Law:

A complex system that works is invariably found to have evolved from a simple system that worked.

Niemand will mehr 17″-Laptops kaufen, schreibt der Inquirer. 15″- und 12″-Modelle hingegen erfreuen sich weiterhin steigender Beliebtheit.

Wen überrascht’s? Mich nicht. Seit Jahren verwunderen mich Leute, die freiwillig solche Dinger kaufen und mit sich rumschleppen (oder dann eben zu Hause stehen lassen). Ein Laptop muss klein und leicht sein. Wenn ich ihn nicht komfortabel überall hin mitnehmen kann, dann ist die Investition relativ sinnlos. Selbst mein 12″-Laptop ist noch zu sperrig. Ein noch kleinerer Formfaktor würde leider zu Lasten der Tastatur gehen.

(via Engadget)

Der Vortrag ist Teil des Doktorandenworkshops der Berliner XML-Tage 2004.

Alexandru Berlea, TU München. Er zeigt, dass XML-Schemasprachen zu EBNF-artigen Grammatiken äquivalent sind, und dass Produktionen solcher Grammatiken als Abfragen auf XML-Bäumen dienen können. Er hat Abwandlungen von XPath und XSLT implementiert (Fxgrep und Fxt), die sehr effizient arbeiten und einige neue mächtige Abfragekonstrukte bereitstellen. Fxgrep riecht nach regulären Ausdrücken. Ich kenne leider XPath kaum, und der recht theoretische Vortrag war der letzte des Tages, so dass ich teilweise nicht mehr ganz folgen konnte.