Wer während der Entwicklung “gern viel sieht”, ist eventuell mit einem recht großen Monitor ausgestattet. Eventuell sogar ein Multiple-Monitor Setup. Dieser Umstand sollte sich jedoch keinen Falls auf Code-Formatierungen auswirken. Nur weil ich eventuell vor einem 24 Zoll Monitor sitze, heißt das nicht das ich diese volle Breite auf meinen Code beziehen sollte. Kommt nämlich nachher ein Kollege mit weniger Zoll oder einer anderen Auflösung ums Eck, hat dieser ein mächtiges Problem: der Code wird nahezu unlesbar. Gerade bei sowieso nicht-gut-lesbaren Sprachen kann das die Entwicklung von sehr einfachen Anliegen (z.B. Markup Änderungen in HTML) unnötig in die Länge ziehen.

Liebe git Freunde! Wer in seinem git Repository Dateien verändert die eingecheckt sind, aber die Änderung nicht commiten möchte, ärgert sich eventuell (wie ich) häufiger über den “modified Zustand” dieser Dateien im “git status”. Das tritt z.B. bei Datenbank-Konfigurations-Dateien auf, die meistens in verschiedenen Environements unterschiedlich aussehen. Da es in den meisten Fällen keinen Sinn macht diese Änderungen einzuchecken, kann man diese auch einfach ignorieren.

Bei einem Projekt kürzlich hatten wir die Aufgabe, eine einfache Datenbankanwendung (Liste von Büchern, durchsuchbar nach Autor) in einen webEdition-Dienst zu integrieren. Da auf der Pflegeseite die Anforderung relativ komplex war und ein komplexer Importer geschrieben werden musste, viel die Entscheidung für die Umsetzung quasi by default auf symfony, weil wir ja alle Anwendungen dieser Art in symfony umsetzen – dafür ist es ja da.

Von Zeit zu Zeit kommt es vor, dass eine Root- oder Boot-Partition (je nach Partitionierung) “voll läuft”. Meistens kriegt man das mit, wenn kleinere Helferlein wie z.B. apt-get ihre Arbeit nicht mehr voll richten können und nach mehr Festplattenspeicher schreien. Häufig liegt das daran, dass alte nicht mehr benötigte Dateien auf dem System gehalten werden, die eigentlich seit längerem nicht mehr benötigt werden. Sowohl auf privaten PCs, als auch auf Server-Setups macht das in den meisten Fällen keinen Sinn und zumindest unter Debian/Ubuntu-artigen Systemen werden diese Dateien nicht automatisch entfernt. Dabei handelt es sich z.B. um veraltete und nicht mehr verwendete Linux-Kernel.

Die kommende Drupal Version 8 wird zum Teil auf Symfony2 basieren. Explizit soll der Kernel von Drupal durch Symfony Klassen ersetzt werden. Damit verbünden sich wohl die zwei größten OpenSource Community’s hinsichtlich aktueller Web-Applikationen. Beide Systeme können dabei voneinander profitieren: während Drupal tausende Plugins bereithält, kann Symfony bereits seit frühen Versionen mit ausgezeichneter Performance auftrumpfen. Somit stehen die Chancen sehr gut, dass zukünftig Symfony2- und Drupal8-Plugins leichter miteinander austauschbar und kombinierbar werden. Der Release-Termin von Drupal 8 ist auf August 2013 gesetzt. Alle Interessenten können sich aber jetzt schon im Drupal Repository eine Development Version von Drupal 8 auschecken, um z.B. an der Entwicklung teilzunehmen oder Veränderungen live zu verfolgen. Wie in vergangenen Versionen von Drupal erhoffen wir uns für Drupal 8 eine ebenso reibungslose Möglichkeit, um bestehende Drupal 7 Systeme zu upgraden und Plugins zu portieren. Weitere Informationen gibts hier: Symfony2 meets Drupal8 Drupal8 Updates and how to help

Mit dem Release von Firefox 11 hat sich Mozilla etwas Besonderes für alle Webentwickler einfallen lassen.

Es gibt viele kontroverse Diskussionen rund um Adblocker und ob sie dem Web schaden oder nicht, aber darum soll es in diesem Artikel nicht gehen. Stattdessen beschäftigen wir uns mit einer anderen Nebenwirkung von Adblockern – einer die für Entwickler und auch Content-Erstellende (wie Blogger oder Redakteure)  relevant sein kann.

CSS3 und dessen neuen Funktionen sind Momentan in aller Munde. Im Rahmen eines Kundenprojektes haben wir uns ausführlich mit der Schrifteinbindung mittels @font-face beschäftigt und möchten Ihnen hilfreiche Hinweise, sowie ein paar Tipps und Tricks für einen reibungslosen Einsatz mit auf den Weg geben.

Jeder Entwickler kennt das: Man probiert sich längere Zeit an einer Problemstellung und kommt nicht so recht dahinter. Dann setzt man sich in einer ruhigen Minute doch nochmal hin und versucht die ganze Geschichte von Grund auf noch einmal durchzuprogrammieren. Et voilá – es funktioniert auf Anhieb.