Der erste Teil hat ihn zu einer Internet-Legende gemacht.
Der Zweite teil ist noch besser.
Unbedingt anschauen. :)
Der erste Teil hat ihn zu einer Internet-Legende gemacht.
Der Zweite teil ist noch besser.
Unbedingt anschauen. :)
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.
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.
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.
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.
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.