Trotz der Krise

Lange war es ruhig seit dem letzten Post zu diesem Thema, doch hoffe ich, ihr konntet die Zeit gut nutzen, um euch etwas in git einzuarbeiten.

In diesem letzten Teil der Serie “Website Management mit Git” komme ich zum eigentlichen Kernpunkt: wie kann man die eigene Website mit git administrieren. Wenn ihr bis jetzt meinen Ausführungen gefolgt sein, sollte dieser letzte Schritt nur noch ein Klacks sein und ich denke, der Beitrag wird auch eher kurz. Also, starten wir.

Grundlegender Ablauf und Idee

Als Webentwickler hat man meist eine lokale Version der Webseite, an welcher man arbeitet. Sobald die Seite ausgehend getestet ist, werden dann die Änderungen (meist per FTP) auf den Server geladen. Mit git gestaltet sich dieser ganze Prozess noch viel schneller und einfacher. Sobald die Webseite in Ordnung ist, reicht es 1 Befehl einzutippen und alle Änderungen werden auf den Server übertragen. Da git die Dateien komprimiert und auch nur die Änderungen hochlädt, ist die Aktualisierung auch um einiges schneller. Dies sind die Schritte im Überblick:

1. Webseite für die Arbeit mit git lokal vorbereiten

2. Webserver vorbereiten

3. Lokale Webseite mit dem Webserver verbinden

Weiter lesen

Als auf deutschen Blogs bekannt wurde, dass iTunes Match in Deutschland gestartet ist, musste ich natürlich überprüfen, ob dies auch für die Schweiz gilt. Und siehe da: ja, iTunes Match ist per sofort auch in der Schweiz aktiv. Mit einem jährlichen Beitrag von 35 CHF, kann man die gesamte Musikbibliothek mit der iCloud synchronisieren. Das tolle dabei: man bekommt automatisch auch Titel mit, die man von anderswo geladen hat und einige Stücke dürften auch mit 256kBit AAC an Qualität gewinnen.

Der Start von iTunes Match war wahrscheinlich auch der Grund, warum ich gestern die neuen AGBs im iTunes Store akzeptieren musste.

Gerne würde ich den Service nun abonnieren, doch leider funktioniert meine Apple-ID nicht. Ich vermute, dass momentan einfach die Server mit Anfragen überlastet sind, da mein Account bei icloud.com perfekt funktioniert.

Und warum möchte ich mich bei iTunes Match eigentlich anmelden? Die Verfügbarmachung auf sämtlichen Devices ist es nicht. Hier hätte ich eine Streaming Lösung besser gefunden anstelle von Downloads, da mein iPad ein 8GB Modell ist und ich da einfach keinen Platz für mehr Musik habe. Aber Apple’s Devise lautete immer: die Benutzer möchten Musik besitzen und nicht abonnieren. Dem kann ich prinzipiell zustimmen, doch gerade für Geräte mit knappem Speicherplatz, wäre eine Streaming Lösung in meinen Augen sinnvoll gewesen.

Mein eigentlicher Grund für iTunes Match liegt darin, dass ich tausende Musikdateien besitze, wovon viele in mässiger Qualität vorliegen. Mit iTunes Match erhalte ich gute Qualität zu kleinem Preis. Ein weiterer Vorteil für einige kann sein, dass man durch iTunes Match rechtlich in den Besitz von Musikdateien kommt, welche vorher von irgendwo her stammten.

So, hoffen wir, dass die Apple Server bald wieder ansprechbar sind, insbesondere weil es mir momentan auch nicht möglich ist, auch andere Dinge wie Apps im Store zu kaufen.

Nach einiger Zeit der Pause, nehme ich doch den zweiten Teil meiner Anleitung in Angriff. Im ersten Teil ging es darum, wie man git bei einem webhoster installieren kann. Nun geht es ans Eingemachte und wir werden die grundlegenden Arbeitsweisen von git kennenlernen. Auch wenn git ziemlich umfangreiche Funktionen bietet, braucht man im Alltag nicht viel zu wissen. Erst wenn man direkt in das Repository (das heisst den Snapshot der gespeicherten Dateien) eingreifen will, muss man teils recht knifflige Befehle eingeben. Da aber git prinzipiell “out-of-the-box” funktioniert, kann man mit einfachen Funktionen beginnen und später, wenn man dann unbedingt etwas bestimmtes bewerkstelligt haben will, das Netz nach Antworten durchforsten.

An dieser Stelle möchte ich allen wärmstens das kostenlose ebook “Pro Git” empfehlen:

http://progit.org/book/de/

Bevor wir loslegen können, müssen wir git natürlich erst einmal lokal installieren. Dazu gibt es verschiedene Möglichkeiten:

Weiter lesen

Nach der x-ten Neuinstallation von Lion auf meinem Mac, habe ich mich heute daran gemacht, auf allen Geräten die Accounts von MobileMe auf iCloud zu übertragen. Da ich nicht vorhatte, weiterhin auf Lion Server zu setzen (ich berichtete über viele Probleme in früheren Posts), wollte ich eine saubere Lösung für gemeinsame Kontakte und Kalender. Mit iCloud ist es möglich, Kalender zu sharen und auch auf gemeinsame Kontakte zuzugreifen. Sofern alle Geräte Lion bzw. iOS5 benutzen können, läuft alles wie geschmiert. Doch leider hat meine Frau immer noch ein iPhone 3G und da kann man iOS 5 nicht installieren. Somit musste ich also eine Lösung finden, wie ich unter iOS 4 iCloud benutzen kann.

Wir hatten einen Familien-Account bei MobileMe und benutzten gemeinsame Adressen und Kalender. Das sollte auch iCloud bieten. Um Kontakte gemeinsam zu nutzen, gibt es momentan keine andere Möglichkeit als einen gemeinsamen iCloud Account aufzusetzen. Somit haben wir insgesamt 3 Accounts: je einen Privaten und einen gemeinsamen. Es ist problemlos möglich, mehr als 1 Account zu benutzen.

Alle Funktionen ausser dem Adressbuch sind bei diesem gemeinsamen Account dekativiert.

Die Migration vorzunehmen war relativ einfach: einfach die angegebene MobileMe Seite aufrufen für jeden Account und die Migration von MobileMe vornehmen. Anschliessend wurde auf einem Mac ein neuer iCloud Account aufgesetzt, welcher gemeinsam benutzt werden soll. Die entsprechenden Accounts wurden dann auf den jeweiligen Geräten aufgesetzt (über iCloud bzw. Mail, Kontakte, Kalender). Dazu muss nicht viel gesagt werden und alles lief hervorragend.

Das eigentliche Problem war aber, die Kalender, Kontaktdaten und Mails auf dem iPhone 3G unter iOS 4 zu konfigurieren. Denn laut Apple ist iCloud nur unter iOS 5 zu benutzen. Das stimmt so nicht, wie auf vielen Anleitungsseiten nachgelesen werden kann. iCloud benutzt Standard-Protokolle wie CalDav und CardDav. So ist es problemlos möglich, die entsprechenden Accounts einfach unter dem Punkt “Andere” auf dem iPhone einzurichten. Eine sehr einfache und ausführliche Anleitung dazu gibt es hier:

http://3th.be/2011/10/14/icloud-am-iphone-3g-einrichten/

Bei mir war es jedoch noch einfacher, da es nicht notwendig war, die ganze konkrete Serveradressen einzugeben. Anstatt von z.Bsp:

p01-imap.mail.me.com

zu benutzen, reichte es vollkommen einfach:

imap.mail.me.com

einzugeben.

Analog bei Kontakten und Kalender. Also so wie hier beschrieben:

https://discussions.apple.com/message/16400451#16400451

Auch musste ich nicht die Serveradresse wie in diesem Post angegeben, kopieren und einsetzen.

Aber trotzdem dauerte es etwa 1 Stunde, bis das Synchronisieren geklappt hat! Was genau der Ausschlag für die erfolgreiche Synchronisation war, kann ich nicht sagen. Ein Deaktivieren des Accounts und Deaktivieren von SSL unter den erweiterten Einstellungen (und dies mehrmals) scheint dabei wichtig gewesen zu sein (und den Account auch so jeweils zu sichern).

Daher: auch wenn es auf Anhieb nicht klappt: nicht verzagen. Spielt einfach mit diesen Einstellungen von Aktivieren, SSL an/ab, Speichern etc. etwas herum. Irgendwann scheint es zu klappen. Kalender, Kontakte und Mail kann sehr wohl unter iOS4 benutzt werden, aber natürlich möchte uns Apple gerne ein neues iPhone 4S andrehen

Seit einer Woche arbeite ich nun mit git. Was ist git und warum bin ich so angetan davon?

git ist ein Versions-Kontroll-System, das heisst, wann immer man eine Datei speichert, kann davon ein Backup gemacht werden – einfach gesagt. Wir alle kennen Backup-Systeme, oder sollten zumindest eines kennen. Zu schnell sind wichtige Daten gelöscht oder nicht mehr auffindbar. git kann aber noch viel mehr, als bloss ein Backup erstellen. Es erstellt quasi einen “Snapshot” aller Dateien und Ordner zu einem gewissen Zeitpunkt. Man kann also immer wieder zu einem Zustand in der Vergangenheit zurück kehren. Das kennen wir Mac Benutzer seit TimeMachine auch schon, doch kann git gezielt eingesetzt werden, um verschiedene Versionen zu managen.

Insbesondere kann man genau sagen, was passieren soll, wenn ich etwas mache. Also zum Beispiel, lade alle neue Dateien auf den Webserver hoch, sobald ich mit einem Zustand zufrieden bin. Da git nun nur die Änderungen kopiert und diese noch verpackt, ist dies in kürzester Zeit gemacht. Es gibt kein manuelles Hochladen per FTP mehr. Auch kann man zuerst alle Dateien genauestens lokal überprüfen. Ein Klick und alle Dateien sind auf dem Server gespiegelt.

Und wenn irgend etwas schief geht, dann geht man einfach zu einem Zustand vorher zurück. Natürlich funktioniert dies auch in sehr kurzer Zeit.

Dies ist bloss eine der vielen Anwendungen von git. In der Regel ist git dazu gedacht, in einem Team an gemeinsamen Projekten zu arbeiten. Dies ist jedoch schon sehr ausführlich dokumentiert und ich möchte in diesem Post (wird wohl in diverse Serien unterteilt werden) auf meinen Workflow für das Administrieren von Webseiten eingehen.

Weiter lesen

Man ist sich als Webdesigner schon einiges vom InternetExplorer gewöhnt, doch das Problem, mit welchem ich letzthin zu Kämpfen hatte, war mir neu. Ich entwickelte für RapidWeaver eine Erweiterung, welche die Google Suche in eine Webseite einbaut. Bei meinen Tests funktionierte dies in allen Browsern problemlos. Die einzige Ausnahme war der InternetExplorer 8 (frühere Versionen habe ich gar nicht getestet). Ich durchsuchte mein Script auf alle mögliche Fehler, bis ich durch den Debugger der Developer Toolbar des IE8 auf etwas gestossen bin:

In meinem Skript verwendete ich eine Variable “wrapper”. IE8 meldete mir stets, dass dieses Objekt keine Zuweisung eines DOM-Elements gestattet. Kurzerhand habe ich die Variable in “theWrapper” umgetauft und siehe da: jetzt funktioniert das Script auch problemlos im IE8. Es scheint so, als benutzt der Explorer die Variable “wrapper” intern für irgendwas.

Was ich dabei gelernt habe: ich werde ab jetzt meine Variablen immer mit “the” beginnen, also z.B. “theContainer” oder “theElement”.

Überraschungen gibt’s. Insbesondere auf dem neuen Betriebsystem von Apple: Lion. Aber wahrscheinlich war dies auch schon in früheren Systemversionen vorhanden. Als ich mich heute etwas eingehender mit dem in OS X auseinandergesetzt habe, fand ich eine “versteckte” Systemeinstellung dazu. Warum Apple diese nicht automatisch den Systemeinstellungen hinzufügt, weiss ich nicht.

Die “PrefsPane” befindet sich in folgendem Verzeichnis:

/System/Library/CoreServices/Archive Utility.app/Contents/Resources/Archives.prefPane

Ein Doppelklick darauf startet die Systemeinstellungen und man wird gefragt, ob man diese Einstellung installieren möchte. Bejaht man das, erhält man weitere Einstellungsmöglichkeiten, wie Archive auf dem Mac behandelt werden sollen. Zum Beispiel, was nach dem Entpacken bzw. dem Archivieren mit dem Original geschehen soll.

So wahnsinnig nützlich ist es für mich nicht, da ich sowieso das Tool “BetterZIP” benutze, aber vielleicht kann dies jemand von euch brauchen.