Linux


VIM mit Syntastic for PHP  and Drupal development

Abbildung 1, Vim mit Editor Tab und location list.
Bei der Statischen Code Analyse1 (englisch linting), welche den den White-Box-Test-Verfahren zugeordnet ist wird der Quellcode einer Software auf seine Beschaffenheit überprüft.
Hierzu gehört z.B. neben dem eigentlichen Linting, in PHP mit z.B. php -l oder dem Tool phplint die Überprüfung von Coding-Standards2 oder das Erkennen von potenziellen Problemem bzw. suboptimalen Code wie z.B. ungenutzen Variablen, Properties oder Funktionen, zu hoher Komplexität (z.B. in Zusammenhang mit Wartbarkeit) und die Erkennung möglicher Fehler.

In der Programmiersprache PHP werden hierfür die Werkzeuge PHP_CodeSniffer3 (squizlabs/PHP_CodeSniffer4) und PHP Mess Detector5 genutzt, welche sich bequem in IDE's wie PHPStorm integrieren lassen6. Aber wie schaut es mit einem scheinbar betagtem und angestaubtem UNIX-Editor wie dem VIM aus?

Natürlich geht das auch im VIM! Wie zeigt dieser Post.

Neues Projekt, Repo und Credentials bekommen, aber es hapert schon beim initialen Checkout des Projekts auf der Kommandozeile, das Argument der Option --username wird ignoriert, stattdessen wird meine Login-Name, also florian verwendet. (natürlich funktioniert das kommunizierte Passwort in der Kombination nicht :D)

florian@x1:~$ svn co svn+ssh://example.com/opt/repos/project --username latzel
florian@example.com's password:

Um Geocaches von geocaching.com via Schaltfläche Aufs GPS-Gerät übertragen mit Garmin-Geräten nutzen zu können, ist das Garmin Communicator-Plug-In nötig,
welches von Garmin leider nur für Windows und Mac angeboten wird.

Dank Andreas Diesner gibt es das Plugin auch für Linux!

Nach dem Wochenende habe ich bemerkt, daß die Ubuntu-Updates, die ich am Freitag davor durchgeführt habe wohl etwas "verschlimmbessert" haben.

So begrüßt mich am darauffolgenden Montag, direkt eine Kernel-Panic.

Alles im Grunde nichts gravierendes, aber...

  1. Root-Partition ist verschlüsselt
  2. Home-Verzeichnis ebenfalls verschlüsselt

Nunja...

Nach einer Woche HOND am Laptop und ziemlich zeitintensiver Suche, hier der zusammengetragene, komplette Lösungsweg.

Befehl: git config

git config --global user.name "Florian Latzel"
git config --global user.email "floh@netzaffe.de"

Git-Konfigurationsdateien: /etc/gitconfig, ~/.gitconfig, .git/config

Auswertungsreihenfolge:

Nachdem sich bei einem Rechnerverbund mal wieder Updates angehäuft haben, stand bis jetzt normalerweise immer die folgende Prozedur an:

  • ssh server1
  • aptitude safe-upgrade
  • exit
  • ssh server2
  • aptitude safe-upgrade
  • exit
  • ...
  • ssh serverN
  • aptitude safe-upgrade
  • exit

Ich hatte noch einen Artikel aus dem Linux-Magazin im Kopf (Ausgabe 1/11, S. 85, Charly Künast: "Sponton simultan"),
indem der gute Charly einen möglichen Lösungsansatz für mich parat hält um N Schritte zu einem zusammen fassen zu können.

Die Lösung heißt Cluster SSH.

Damit der Webserver auch die Repositories in Gitweb anzeigen kann,
habe ich den Benutzer gitosis der Gruppe www-data hinzugefügt.

Als root:

usermod -g www-data gitosis

Auf birgit, die Datei /etc/apache2/sites-available/birgit.example.com mit dem folgendem Inhalt anlegen:

<VirtualHost *>
  ServerName birgit.example.com
  ServerAdmin webmaster@example.com
  DocumentRoot /srv/gitosis/repositories
  SetEnv GITWEB_CONFIG /etc/gitweb.conf
  Alias /gitweb.css /usr/share/gitweb/gitweb.css

Die Konfigurationsdatei für Gitweb,
hier angepasst $projectroot welche auf das Verzeichnis /srv/gitosis/repositories, in dem gitosis seine Repos ablegt zeigt.

# path to git projects (<project>.git)
# $projectroot = "/var/cache/git";
$projectroot = "/srv/gitosis/repositories";

# directory to use for temp files
$git_temp = "/tmp";