Administrator's Blog

Synergy ist interessant für jeden der 2 Monitore, 2 Rechner und nur 1 Set an HID`s besitzt.

Man könnte jetzt Maus und Tastatur über ein KVM Hardware Switch ständig zwischen beiden Rechnern hin-und-her wechseln. Jedoch besitzt nicht jeder ein solches Gerät, noch lohnt sich die Anschaffung des selbigen Aufgrund der doch sehr hohen Kosten von USB KVM Switches.

Eine mittlerweile sehr gute Softwarelösung ist Synergy, welches Maus und Tastatur über das Netzwerk mit beiden Rechnern verbindet. Dabei fungiert der Rechner mit angeschlossenen Geräten als Server und der Rechner, welche keine Maus und Tastatur angeschlossen hat als Client.

Dabei hat man die freie Wahl der Plattform, denn Synergy ist Plattformunabhängig. Ein weiterer Vorteil ist die synchronisierte Zwischenablage. Zuletzt sei erwähnt dass man durch die Software Lösung auch gerne schnell vergisst, dass man 2 verschiedene Rechner bedient, denn Synergy schaltet seamless zwischen beiden Systemen um, sobald man den Konfigurierten Randbereich mit der Maus überschreitet.

Konfiguration
Vorab: Ich empfehle euch unbedingt die Beta zu benutzen, da hier die Benutzerschittstelle um einiges ausgereifter ist.
Szenario: Rechner 1 ist ein Windows mit angeschlossenen Gerätschaften, Rechner 2 ist ein OSX Lion der diese Geräte nutzen möchte.

Zuerst installiert man auf beiden Systemen die Software. Dabei wählt man in der Installation für Rechner 1, Server aus und für Rechner 2 wählen wir Client. Die Frage nach dem Automatischen Start kann jeder so beantworten wie er es gerne mag, bei mir starten beide Rechner die Software im "Desktop" Level, bedeutet erst nachdem ich mich angemeldet habe.

Nun kann man auf Seite des Servers entsprechend "Configure Server..." wählen. Nun hat man eine Übersicht aller konfigurierten Rechner (im unkonfigurierten Fall entsprechend ein Monitor in der Mitte mit dem Netzwerknamen des eigenen Rechners).


Nun kann man von oben Rechts einen Monitor, via drag-and-drop an die Position ziehen, die der zweite physische Monitor hat, welcher an den 2. Rechner angeschlossen ist. Dadurch wird ein "Unnamed" Bildschirm erstellt.


Durch einen Doppelklick auf diesen gelangt man entsprechend in den Konfigurationsdialog. Dort gibt man diesem Bildschirm den Netzwerknamen/Hostname des 2. Rechners als "Screen name" an. In meinem Fall ist das "Christophs-MacBook-Pro.local". Jetzt kann man noch diverse "Key-Modifier" umsetzen, was bei OSX z.B. Praktisch ist, da sonst Super(Apfel) und Alt vertauscht sind. Daher mappe ich in meinem Fall "Alt auf Super" und "Super auf Alt". Damit ist auf Seiten des Servers alles fertig konfiguriert. Starten wir nun also den Server über die "Start" Schaltfläche und kümmern wir uns um den Client.

Beim Client muss man nun einfach nur den Namen des Servers eintragen. Dabei kann man den NetBios/DNS Namen oder aber die IP Adresse benutzen. Danach kann man auch hier auf "Start" drücken. Nun sollte bei beiden Rechnern in der Log von Synergy stehen, das eine Verbindung erfolgreich aufgebaut wurde.



Ab jetzt kann man den anderen Rechner von seinem Hauptsystem aus wie einen 2. Bildschirm verwenden. Einfach über den Randbereich hinweg gehen, je nachdem wie man den Monitor eingestellt hat links oder rechts, schon hat man Maus und Tastatur nutzbar auf dem 2. Rechner. Im selben Moment wird dann auch die Zwischenablage synchronisiert. Thats it.

Fazit
Der einzige Nachteil des ganzen ist, dass man den Monitor händisch an den 2. Rechner anschließen muss. Zudem werden auch Audiosignale nicht übertragen. Jedoch ist dies für den Office gebrauch nicht weiter tragisch. Für Audio könnte man die Software Airfoil nehmen, diese ist jedoch entsprechend kostenpflichtig und beim Monitor müsste man zwangsweise einen Hardware KVM Switch für Monitore besitzen.

Vorteil ist die ständige Weiterentwicklung dieses Projekts und dass es Open Source ist. Zudem sind, trotz Beta, während meiner Benutzung keinerlei Fehler aufgetreten. Einzig das Mapping von AltGr auf Command+Alt ist für OSX ziemlich nervig. Ein Patch scheint dafür schon in das Projekt eingeflossen zu sein, jedoch bietet die GUI noch keine Möglichkeit diese Einstellung vorzunehmen.

In aller Munde ist das Versionierungssystem Git, da es unter Anderem von großen Projekten zur Versionsverwaltung genutzt wird. Entwickelt wurde es von Linus Torvalds, da alle anderen Versionierungssystem nicht dynamisch genug für die Kernel Entwicklung waren, vor allem sobald es um das 'mergen' von einzelnen 'branches' ging.

Doch wie funktioniert Git nun eigentlich? Zuerst sei die Architektur von Git erwähnenswert, da diese nicht zentralisiert, sondern eher verteilt ist. Das bedeutet, dass Jeder, der mit einer Kopie eines Git-Clones arbeitet, im Endeffekt das gesamte Repository mit allen Änderungen auf seinem Rechner lokal vorliegen hat. Daraus resultiert auch ein gewaltiger Vorteil von Git z.B. gegenüber SVN oder CVS. Die Verwaltung sämtlicher Änderungen findet komplett Offline im 'working directory' statt. Ist man z.B. gerade im Zug unterwegs, muss man daher nicht auf eine Versionsverwaltung für sein aktuell bearbeitetes Projekt verzichten.

Die Basics sind dabei relativ einfach erlernbar und nach wenigen Nutzungen muss man auch nicht mehr groß darüber nachdenken Anbei eine kleine Einführung:

Zuerst müssen wir die Versionierung für ein Projekt oder genauer für das aktuelle Verzeichnis erstellen:

 git init 

Ab jetzt ist das Verzeichnis bereit, den Inhalt zu versionisieren. Welche Dateien oder Verzeichnisse man nun verwalten möchte, kann man über:

 git add <file|dir> 

festlegen, ziemlich analog zu SVN. Dennoch gibt es einen Unterschied, denn es werden nur die Änderungen zum 'Stage' hinzugefügt, welche bis zu diesem Zeitpunkt gemacht wurden. Bearbeitet man die Datei erneut, so müsste man diese Änderungen auch wieder mit einem 'add' erneut hinzufügen (auch wenn man in der Datei die bereits versionisierten Änderungen gelöscht hat, so muss man diese erneut hinzufügen, damit diese gelöschten Änderungen hinzugefügt werden).

Doch was ist denn eine 'Stage'? Der Stage ist ähnlich wie eine Kiste. In dieser liegen alle Änderungen, die wir über den 'add' Befehl hinzufügen oder über den 'reset' Befehl löschen. Zusätzlich gibt es auch noch eine temporäre Kiste in der man Änderungen zwischenspeichern kann um z.B. externe Patches auf einen Quelltext anzuwenden und dann die eigenen Änderungen wieder anwenden zu lassen. Letzteres geht jedoch für Beginner erstmal zu weit, es sei aber am Rande erwähnt.

Möchte man die 'staged' Änderungen verwerfen, kann man Dies erreichen, indem man folgendes eingibt:

 git reset <file|dir> 

Möchte man die Änderungen nun endgültig versionisieren, so kann man diese nun commiten:

 git commit 

Dabei werden sämtliche Änderungen in das lokale Git-Repository geschrieben.

Was jedoch machen, wenn man dennoch etwas vergessen hat dem aktuellen Commit hinzuzufügen oder aber man noch einen Fehler gefunden hat, der direkt auf den Commit bezogen ist? Git ermöglicht es dem letzten Commit weitere Änderungen anzuhängen. im Jargon nennt man dies entsprechen 'Amend'. Dabei kann auch die Commit-Message umgeschrieben werden.

Hat man also weiter Änderungen über add hinzugefügt, dann kann man diese dem letzten Commit hinzufügen:

 git commit --amend 

Damit hat man - grob - die Basics von Git umrissen.
Im nächstenTeil werde ich noch erklären, warum man immer auf einem Branch arbeiten sollte und die Änderungen entsprechend in den 'master' zurückfließen lassen sollte. In dem Zusammenhang werde ich auch noch erläutern, wie man sein lokales Repository auf github.com hochladen kann um eine 'globale' Version des Repositories zu haben.

Dependency Management ist auch in PHP ein wichtiger Teil der Entwicklung, da man sich vor allem beim Ausrollen der Anwendung sicher sein muss, dass alles auf den - meist stabilen - Versionen läuft, für welche die Anwendung entwickelt wurde.

Hilfreich kann hierbei Composer werden. Das Projekt entspringt zum Teil der Entwicklung von Symfony2, wodurch auch so ziemlich alle Symfony2 Pakete dort gefunden werden können, sofern der Maintainer des Pakets sein Repository entsprechend Composer kompatibel gestaltet. 

Zudem kann der Maintainer entsprechende Abhängigkeiten angeben, welche dann von Composer aufgelöst, heruntergeladen und installiert werden.

Die Nutzung von Composer wird sehr gut auf der Standard Repository Seite Packagist erklärt. Dort kann man dann auch entsprechend nach sämtlichen von Haus aus unterstützen, bzw. verwalteten Paketen suchen und sich deren Abhängigkeiten, etc. anschauen.

Geliefert wird die Composer im .phar Format, wodurch es ggf. nötig ist, die suhosin.ini für php-cli entsprechend anzupassen, falls Suhosin für PHP aktiviert ist (wie z.B. default unter Debian)

suhosin.executor.include.whitelist = phar

Hat man nun alle Einstellungen getätigt und sich seine composer.json erstellt, kann man sich nun die Abhängigkeiten bequem herunterladen via:

php composer.phar update

Dies erstellt zudem eine composer.lock Datei, welche die soeben heruntergeladenen Versionen dokumentiert. Rollt man die Anwendung nach der Entwicklung auf dem Produktivsystem aus, führt man einfach ein:

php composer.phar install

aus.

Dies installiert dann genau die Versionen, welche beim Aufruf von "update" festgesetzt wurden, selbst wenn in der Versionsverwaltung neuere Versionen existieren sollten.

Ein weiterer Vorteil ist die 'autoloader.php' im 'vendor' Verzeichnis, welches von Composer angelegt wird. Diese enthält das PSR-0 kompatible, automatische Laden von unbekannten PHP-Klassen anhand des Klassennamens und aktuellem Namespaces. Fügt man diese Datei in seinem Skript hinzu, kann man die Abhängigkeiten (bzw. deren Klassen) nutzen, ohne 100 Dateien inkludieren zu müssen.

Der initiale Konfigurationsaufwand scheint dabei groß zu sein, jedoch profitiert man umso mehr davon, je mehr Abhängigkeiten die Anwendung hat und je öfter man die Anwendung auf einem Produktivsystem ausrollen möchte.