kann so einfach sein.

Man muss einfach nur ein Captcha einbauen, dass "zuverlässig" zwischen Mensch und Maschine unterscheidet.

Well, zuverlässig.

Ich jedenfalls fühle mich jetzt offiziell zur Maschine geadelt, denn bei diesem Captcha bin ich einfach nicht weitergekommen. (Man muss noch sein Alter bestätigen, damit man das Captcha sieht.)

Doh.

Endlich mal ein guter ausgeglichener Vergleich zwischen den drei großen verteilten Versionskontrollsystemen.

Lest solange er aktuell ist!

Yes you do!

Rofl!

Hab ich mal für Python gegoogelt.

Und bin erstaunlicherweise auf eine extrem coole idee gestoßen:

Einfach indem man dem Lernenden Rätsel aufgibt, die ihn stück für stück an neue Konzepte aus der Python Standardbibliothek heran bringen.

Definitiv die beste Idee für Übungsaufgaben die ich bisher gesehen habe - und wunderschön über eine Webseite machbar.

Hier gibts die Rätsel

By the way: Auf dieses Coole Programm zum Python lernen bin auch auch gestoßen Einfach ein Webbrowser mit einem Manual links, und rechts ein Terminal um das alles auszuprobieren.

Nice!

NodeBox ein tool mit dem man in Python die Mac OS X Graphik-Bibliotheken ansprechen kann.

Die Galerie ist besonders faszinierend.

Dokumentation.

Den vergleich zwischen Dokumentation und dem Austausch von Körperflüssigkeiten spare ich mir jetzt. Wahr ist er aber trotzdem.

Vergleicht man die Python und die Cocoa Dokumentation dann fällt bei Cocoa recht schnell auf das es keine klare Trennung gibt in High level Dokumentation und Klassenspezifische Dokumentation während das bei Python gemischt ist.

Dazu kommt das bei Python oft die high level Beispiele fehlen und es von der Referenz-Dokumentation keinen Link auf die komplette Listung der Methoden eines Objekts gibt.

Zwar kann man dann in Python oft auf den interpreter zurückgreifen und sich von dort aus noch mehr informationen über ein Objekt holen - das ist aber ganz schön aufwendig.

High Level Dokumentation: Cocoa++, Python--

Wenn es um die Klassenbasierte Doku geht hat Cocoa auch eindeutig die Nase vorne. Alle Methoden sind immer nach Topics geordnet. NSArray zum Beispiel startet mit einer Liste der Fakten über die Klasse (in welchem file definiert, ab welcher Version des Frameworks verfügbar, welche High-Level Guides gehören dazu) und fährt dann erst einmal mit einem Überblick über den Zweck der Klasse fort der auch gleichzeitig die wichtigsten Methoden der Klasse erklärt.

Danach kommt immer der Guide was man beachten muss wenn man eine Subklasse davon anlegen will. (Was erfordern kann dass man ein bestimmtes set von Methoden immer gleichzeitig überschreiben muss, da in Cococa gerne Class Clusters eingesetzt werden - ein Konzept das ich in Python leider noch gar nicht gefunden habe.

Dann kommt der für die tägliche Arbeit für mich wichtigste Teil der Dokumentation: Tasks. Hier sind alle Methoden des Objekts nach den Aufgaben sortiert die man mit ihnen erledigt.

Creating an Array, Initializing an Array, Querying an Array, Comparing, Sorting, ...

So findet man schnellstens heraus was das Objekt anbietet für das was man tun möchte.

Ergo: Dokumentation in Python ist ganz schön mies - in Trac fehlt sie sogar ganz :/

Und wieder mal heißt es: Python/Trac oder Cocoa? Wer wird gewinnen?

Erkundbarkeit der Frameworks ist mein nächstes Thema: Die Klassen die bestimmte Aufgaben haben sollen leicht zu finden sein.

Das funktioniert bei Trac in der Regel sehr gut, da man in Python sehr schön über Packages hierarchische Namensräume definieren kann - ähnlich wie bei Java eben auch.

Nur dass es dort etwas Taktvoller eingesetzt wurde.

Das heißt es gibt trac.wiki trac.tickets trac.timeline etc. Wenn man den Code zu einem Feature sucht, kann man ihn auch schnell finden.

Ganz im Gegensatz zur Standard Library von Python - da ist alles Kraut und Rüben - wenn man mal eben versucht alle Klassen die was mit String-Verarbeitung oder mit ein und Ausgabe zu tun haben, dann kann man ganz schön suchen - es gibt nicht einen Namensraum der überschaubar wäre und alles enthält.

Cocoa ist da auch nicht vorbildlich - da gibt es gar keine Namensräume. Nur eine grobe unterteilung in Foundation für alles was keine GUI braucht und AppKit für alles was mit einer GUI zusammenhängt.

Na immerhin etwas. Dazu kommt dass Apple fast alle neuen größeren Features als Framework verpackt die einen Aufgabenbereich verkapseln. CoreAudio für alles was mit Audio zu tun hat. CoreImage für ... Bilder, CoreVideo.... etc. Immerhin. Aber. Da alle Klassen zur Laufzeit dann doch in einem einzelnen Namensraum liegen, heißt dass das dann doch wieder jede Klasse einen Präfix bekommt, damit sie nicht mit Klassen von irgend jemand anderem zusammenstößt. Bäh. Man hat also NSArray statt Array und NSApplication statt Application und NMDeviceDatabaseEntry (NM für NovaMedia). Also: Namensräume rocken - und Cocoa kann da deutlich weniger als Python.

Hierarchische Namensräume sind gut, weil sie Übersicht schaffen - wenn man sie nicht nur zum Spaß einsetzt sondern tatsächlich verschiedene Bereiche getrennt bekommt.

Da hab ich doch endlich eine schöne fundierte Einführung wie mann am besten mit Distributed Revision-Controll-Systemen arbeitet.

Ok, sie ist komplett auf GIT zugeschnitten, aber trotzdem sehr ordentlich. Vor allem erklärt er auch anschaulich wofür man die advanced features wie rebasing sinnvollerweise verwenden kann.

Also alles in allem eine Empfehlung. :)

Tja, nach anfänglichem [wiki:2008/07/12/22.30 Erfolg mit meinem NAS] muss ich leider doch geschlagen geben.

Auch wenn alles zum Funktionieren zu bringen war, bricht jeder Backup auf den NAS so nach etwa 1-6 Gigabyte ab und ist nach dem zweiten Restart gar nicht mehr zum starten zu überreden (angeblich weil die Backup-Festplatte Schreibgeschützt ist.

:-(

Ich probier es jetzt mal mit einem anderen Hersteller.

Dachte ich mir zum letzten mal.

Denn das kann XCode ja schließlich auch automatisieren, wenn man ein wenig in die Makros von Xcode reingreift.

Schritt eins, /Developer/Applications/Xcode.app/Contents/PlugIns/TextMacros.xctxtmacro/Contents/Resources/ObjectiveC.xctxtmacro im Texteditor der Wahl öffnen und das Macro finden das Apple als Hilfe für solche Fälle vorgesehen hat. (Bei mir ist das auf Zeile 68)

{
            Identifier = objc.bracket;
            BasedOn = objc;
            IsMenuItem = YES;
            Name = "Bracket Expression";
            TextString = "[<#!expression!#> ]";
        },

Das habe ich mir dann durch zwei Macro-Definitionen ersetzt die für mich wesentlich nützlicher sind:

{
            Identifier = objc.bracket;
            BasedOn = objc;
            IsMenuItem = YES;
            Name = "Bracket Expression";
            TextString = "[<#!expression!#>]";
        },

        {
            Identifier = objc.bracket.withSemicolon;
            BasedOn = objc;
            IsMenuItem = YES;
            Name = "Bracket Expression with Semicolon";
            TextString = "[<#!expression!#>];";
        },

Das war Schritt eins, um dass jetzt noch richtig Nützlich zu machen, habe ich mir diese Befehle (die jetzt beide im Menü auftauchen) noch mit einem Shortcut belegt - also Menü->Xcode->Preferences->Key Bindings, dort eine eigene Konfiguration anlegen und bei den "Menu Key Bindings" die Menü-Eintrag unter Edit->Insert Text Macro->Objective C finden.

Ich hab mir den ersten (ohne Semicolon) auf Command-1 und den zweiten (mit Semicolon) auf Command-2 gelegt.

Nie wieder Semicolons Tippen. Einfach Text-Auswählen und Command-1, dann hab ich eckige Klammern drumherum.

Ahhh....

Lediglich eines hätte ich noch gerne, dass der Cursor danach vor der schließenden eckigen Klammer ist.. aber das finde ich auch noch raus.