Meine ersten Befehle habe ich auf einem C64 getippt und zumindest in meiner Erinnerung ($zeit == ‘Grundschule’) hat das riesig Spaß gemacht, aber mit programmieren hatte das noch nicht viel zu tun. In der Schule wurde dann irgendwann “Programmieren” unterrichtet, aber auch dies hatte mit richtiger Programmierung nicht so viel gemeinsam. Nach der Schule habe ich eine Ausbildung bei der Global Village GmbH als “Fachinformatiker Systemintegration” gemacht und mich mit Netzwerken, Monitoring, Linux-Servern, MySQL-Server u.s.w. beschäftigt. Anschließend angefangen Informatik zu Studieren, habe jedoch abgebrochen und eine zweite Ausbildung als “Fachinformatiker Anwendungsentwicklung” bei der menadwork GmbH abgeschlossen.
meine Programmiersprachen in zeitlicher Reihenfolge: VBA -> Shell -> PHP -> C -> Java -> PHP (OOP) -> JavaScript (+jQuery)
PS: Go wird wohl als nächstes folgen :)
Zurück zur eigentlichen Fragestellung und eine schon oft diskutierte Frage. Welche Programmiersprache sollte man lernen bzw. lehren. Bis vor einiger Zeit habe ich noch gedacht, dass der klassische Weg mit “C” als erstes zu beschreiten wäre. Da man hier wirklich versteht wie ein Array funktioniert und was ein Pointer ist. Aber um z.B. Schülern das programmieren beizubringen würde ich als erstes die Web-Programmierung empfehlen, da man hier schneller zu einem sichtbaren Ergebnis kommt und z.B. Schüler somit besser motivieren kann. Auch wenn “HTML” und “CSS” keine Programmiersprachen sind, würde ich trotzdem empfehlen damit zu beginnen und anschließend via “jQuery” die ersten Dinge wirklich zu programmieren. Auf diesem Weg kann man bereits früh auf gelerntes Wissen zurückgreifen (z.B. CSS-Selektoren für jQuery oder inline CSS via jQuery ins HTML schreiben, …). Anschließend könnte man zu JavaScript und zur ersten echten Programmiersprache wechseln.
Hier einige Beispiel für eine “Hello Word” Ausgabe, welche direkt im Browser laufen (sozusagen mit GUI). Wenn man eine Browser (GUI) Anwendung z.B. via “C” oder “Java” entwickeln möchte benötigt man bereits um einiges mehr Code und / oder muss auf komplizierte Bibliotheken zurückgreifen.
Es folgenden einige Beispiele “Hello world!”-Beispiele in verschiedenen Web-Sprachen. Hier gibt es noch mehr Beispiele in anderen Programmiersprachen.
Man kann “Freie Software” als Teilmenge von “Open Source Software” verstehen, wobei der Begriff “Open Source” erst später eingeführt wurde, da man freie Software als geschäftsfreundlich und weniger ideologisch belastet darstellen wollte. Außerdem wollte man dem Begriffsproblem von „free software“ entgegenwirken, denn auch wenn viele freie Software kostenlos (free) ist, ist dies keine “freeware”.
Für die Definition von freier Software findet man folgenden Satz auf der GNU/GPL Webseite: To understand the concept, you should think of “free” as in “free speech,” not as in “free beer”.
Freie Software gewährt demnach dem Nutzer Freiheiten, was bei proprietärer Software nicht der Fall ist: z.B.:
https://govtrequests.facebook.com/: Hier kann man nachlesen, wie viele Anfragen die entsprechenden Regierungen an Facebook gestellt haben, um an unsere Informationen zu kommen oder uns bestimmte Informationen vorzuenthalten.
Es gibt es mittlerweile (zu) viele verschiedene Open Source Lizenzen und Lizenz-Versionen, welche teilweise nicht einmal miteinander kompatibel sind, so z.B. bei GPLv2 und GPLv3 welche man nicht gemeinsam in einem Programm nutzen darf:https://www.gnu.org/philosophy/license-list.html
Allgemein kann man die verschiedenen Open Source Lizenzen jedoch in folgende Kategorien einteilen: Copyleft / Copyright
Copyleft ist eine Form von freier Software, bei der die Freiheit des Endanwenders hervorgehoben wird und die Freiheit der Programmierer hinten anstellt, so kann (darf) man z.B. “Google APIs Client Library for PHP” nicht für WordPress-Plugins verwenden, da diese Bibliothek nicht mit GPL kompatibel ist.
Art des Copyleft
Starkes Copyleft
Schwaches Copyleft
kein Copyleft
Kombinationsmöglichkeit
mit proprietärer Software
keine Einbindung in proprietären Code möglich
statisches und dynamisches Linken von Code mit proprietärer Software möglich. Eigen-Entwicklungen dürfen als proprietäre Software weitergegeben werden
darf auch in proprietäre Software verwendet werden
Beispiel-Lizenz
GPL
LGPL, MPL
BSD, Apache, MIT
1.4 Geschäftsmodelle
Beispiele:
– Adobe Systems veröffentlicht Flex (Apache License 2.0) und verkauft die Flash Builder IDE. – Apple Inc. veröffentlicht Darwin (Apple Public Source License) und verkauft Mac OS X. – Asterisk (PBX), verkauft Hardware auf welcher Open Source Software (GPL) läuft. – Codeweavers verkauft CrossOver (proprietär + LGPL) und nutzt dafür als Grundlage Wine (LGPL) – Canonical Ltd. bietet Ubuntu als Open Source an und bietet technischen Support gegen Zahlung an. – Mozilla Foundation lässt sich von Google, Yahoo und anderen Unternehmen bezahlen, um z.B. die entsprechende Suchmaschine in Mozilla Firefox zu integrieren. – Oracle bietet MySQL als Open Source Version (GPL) und als Enterprise Version (proprietär) mit Support und zusätzlichen Features an.
2. Wo veröffentliche ich Open Source Software?
Allein durch die Veröffentlichung von Quellcode entsteht zur noch keine Open Source Software, aber es bleibt die Grundvoraussetzung. Mittlerweile gibt es viele Plattformen, welche sich auf Quellcode-Repositories spezialisiert haben, dabei hat man sich inoffiziell bereits darauf geeinigt, dass “github.com” als Standard für Open Source Software angesehen wird. Sowohl npm, composer als auch bower nutzen github.com als Standard-Repository.
3. Welche Open Source Software Standards gibt es?
Unix ist der Ursprung von Open Source und die Unix-Philosophie von ~1970 lässt sich noch immer auf heutige Software Projekte anwenden: „Mache nur eine Sache und mache sie gut.“
– Schreibe Computerprogramme so, dass sie nur eine Aufgabe erledigen und diese gut machen. (Packages?)
– Schreibe Programme so, dass sie zusammenarbeiten. (REST?)
– Schreibe Programme so, dass sie Textströme verarbeiten, denn das ist eine universelle Schnittstelle. (JSON?)
Es gibt viele inoffizelle Standards bei Open Source Projekten, welche ggf. jedoch auch erst von der Community erstellt oder / und überhaupt erst im laufe des Projektes erstellt werden.
3.1Open Source Lizenz für Software angeben (z.B.: LICENSE.txt) – kann man verwenden: GPL, LGPL, MIT, BSD3 – sollte man ggf. vermeiden: Creative Commons, Beerware, WTFPL – CLA (Contributor License Agreement) beachten: z.B.: Zend Framework 1
3.2Quellcode Organisatzion (z.B. “src/”, “tests/”, “lib/”) – Wie heißt das Verzeichnis für Tests? – Wo findet man die Abhänigkeiten (vendor)? – Wo findet man den Quellcode?
3.3 Dokumentation für Entwickler und Anwender – Beschreibung, Code-Beispiele, Testabdeckung, Version, Lizenz, … (z.B.: README.md) – Wie man mithelfen kann (z.B.: CONTRIBUTING.md) – Anwender-Dokumentation (nicht im Code-Repository), z.B.: – Beschreibung mit Beispielen / Bildern / Demos – Wie man Bugs melden sollte (yourbugreportsucks.com / Beispiel) – Entwickler-Dokumentation (nicht im Code-Repository), z.B.: – Wie man den Quelltext herunterlädt – Wie ist die Verzeichnis-Strucktur des Projektes – Wie installiert man das Build-System / Wie nutzt man das Build-System – Wie führt man die entsprechenden Tests aus – Wie sieht der Code-Style aus (z.B.: google-styleguide)
3.4 Plattform für Fragen und Kommunikation, z.B.: – Mailingliste / Forum – Stack Overflow – gitter.im – groups.google.com
3.5 Versionsnummern korrekt verwenden –Semantic Versioning via MAJOR.MINOR.PATCH – MAJOR: Hauptversion, wenn die API geändert wird – MINOR: neue Funktionen, welche keine API-Änderungen hervorrufen – PATCH: bei abwärtskompatibelen Bugfixes – Tag-Versionen in der Quellcodeverwaltung nutzen (z.B. git tag) – ggf. einen Changelog schreiben (z.B.: CHANGELOG.md) – Abhängigkeiten definieren (z.B.: package-versions with composer)
3.8 Issue-Tracking-System zur Verwaltung von Bugs verwenden – z.B.: github – Issue-Tracking aktivieren – Übersicht über Fehler und wer diese fixed – “Gruppenzwang”, da das Issue-Tracking für jeden einsehbar ist
3.9 Contributor-Model bei größeren Projekten, z.B.: yui3
4. Wie veröffentliche ich Open Source Software?
4.2 Beispiel: npm
# Installation von node.js, z.B.: sudo apt-get install nodejs
# Konfiguriere npm npm set init.author.name "Lars Moelleken" npm set init.author.email "lars@moelleken.org" npm set init.author.url "http://moelleken.org"
# npm User erstellen (~/.npmrc) npm adduser
# interaktiv eine “package.json”-Datei erstellen npm init
in diesem Blog-Post möchte ich erklären, wie ich mich über neue Technologien, Techniken, Standards, Pattern etc. Informiere. Dabei werde ich mich besonders auf Webtechnologien (CSS / HTML / JS / PHP) konzentrieren.
Zu Beginn unterteile ich die Informationsquellen in verschiedenen Medien “Video”, “Audio”, “Text”, “Praktisches”, welche ich wiederum in unterschiedlichen Situationen nutze. Ein interessanten Podcast zum Thema “Frontent Architektur” vor dem einschlafen oder ein Video zum Thema “DevOp” beim zubereiten vom Mittagessen, morgens in der Straßenbahn ein Buch lesen mit dem Titel “Weniger schlecht programmieren” … um nur ein paar Beispiele zu nennen. Dabei lassen sich einige Webseiten / Apps etc. nicht wirklich in einer der Kategorien einteilen oder gehören eigentlich in mehrere Kategorien.
Wenn man sich näher damit beschäftigt wie wir Informationen verarbeiten und lernen, findet man schnell Begriffe wie “Lerntypen” und “Denkstile”.
Ein Beispiel: Wenn man in der Schulzeit bereits festgestellt hat, dass man allein durch das zuhören den entsprechenden Lernstoff nicht behalten hat und die Vokabeln besser behalten kann, wenn diese farblich markiert sind. Dann ist man wahrscheinlich ein ehr “Visueller”-Lerntype.
Jedoch sollte man dennoch verschiedenen Medien (Visuell, Auditiv, Haptisch, Kommunikativ) nutzen, um sich Vorwissen anzueignen und um sich das Thema interessanter zu gestalten bzw. sein eigenes Interesse daran zu wecken. Das Vorwissen muss dabei gar kein Faktenwissen sein, es reicht vollkommen aus, dass diese Informationen sozusagen als Nährboden herhalten.
Ein Beispiel: Bevor man anfängt einen Blog-Post zum Thema “Ressourcen für Webentwickler” zu schreiben, diskutiert man mit einem Kollegen auf der Arbeit über dieses Thema und schon hat man zwei neue Projekte.
Wer heute Zeit und Lust hat, kann in Düsseldorf ab 19 Uhr bei der trivago GmbH (Bennigsen-Platz 1) beim monatlichen Treffen der “PHP Usergroup Düsseldorf” mehr über “Git” erfahren.
Bisher haben sich bereits 58 Leute für das Treffen auf www.meetup.com/PHP-Usergroup-Duesseldorf/ angemeldet. Wenn du ebenfalls teilnehmen möchte, melde dich einfach vorher bei “www.meetup.com” an und teilt dem Veranstalteter (PHP Usergroup Düsseldorf – vorheriger Link) mit, dass du kommst. So kann man sich auf die zu erwarteten Teilnehmer einstellen, danke!
Eine Einführung in das Versionskontrollsystem Git in Kombination mit einem “on the fly” Workshop. Damit du am Workshop teilnehmen kannst, solltest du deinen Laptop mitbringen und folgende Dinge schon mal vorbereitet haben:
PS: Und wer glaubt, dass in der PHPUGDus nur über PHP gesprochen wird, sollte sich eines besseren belehren lassen und sich einmal die Titel der letzten Meettups anschauen. ;) Also ggf. bis später und allen noch einen erfolgreichen Tag!
Auf der OpenRheinRuhr (Messe mit Kongress rund um das Thema “Freie Software”) habe ich meinen ersten öffentlichen Vortrag gehalten. Dazu habe ich das Thema “Open Source Workflow für Webentwickler” gewählt und mit dem doch sehr einprägsamen Titel “DO EPIC SHIT!” angekündigt.
Gegen alle Erwartungen bin ich pünklich angekommen, auch wenn die Bahn (GDL) gestreikt hat. Also hatte ich noch etwas Zeit, um noch einen `git commit` vorzubereiten, welcher dann live in dem Vortrag automatisch via Jenkins getestet und deployed werden konnte.
Und auch wenn ich den Vortrag nicht so beenden konnte wie ursprünglich geplant, da ich die Zeit irgendwie falsch eingeteilt hatte, hoffe ich trotzdem einiges nützliches gezeigt zu haben. Beim nächsten mal sollte ich dies wohl vor “echtem” Publikum testen, da die Zeit dann anscheinend anders verläuft. ;) Einige Erklärungen und Beispiele von der Demo-Webseite musste ich daher unterschlagen und reiche diese Infos im folgenden nach:
PS: Ich werde heute wieder auf der OpenRheinRuhr sein, da auch das heutige Programm sehr interessante Vorträge und Workshops biete. z.B.: Docker, SaltStack, ImageMagick. Gegebenenfalls sieht man sich dort :) wünsche allen Beteiligten viel Spaß!
Alle alten Version der Unix-Shell “bash” enthalten eine kritische Sicherheitslücke (CVE-2014-6271), so dass man Befehle z.B. über CGI-Skripte oder via DHCP ausführen kann. Ggf. benötigt nun dein Handy (z.B. CyanogenMod), dein Router oder deinen Mac / Linux / BSD und so weiter Software-Updates.
Teste dein System:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
Nachdem man die aktuellen Updates eingespielt hat (z.B. via aptitude) dann sollte die Ausgabe folgendermaßen aussehen.
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x’ this is a test
Jede neue Bash-Instanz wird nun beim Start die Funktion “foo” registrieren, so dass man diese Ausführen kann. Wenn man nun jedoch eine Funktion exportiert, führt die Bash den nächsten Befehl ebenfalls aus, da der String der “() {” nicht korrekt geparst wird. Damit können wir nun Befehle ausführen, indem wir bestimmte Strings (Funktionsdefinitionen) an z.B. ein CGI-Skript übergeben.
Heute möchte ich ein Web-Tool zur Organisation von Projekten vorstellen: https://trello.com
Trello nutzt “Listen”, welche sich auf sogenannten “Boards” befinden, um verschiedene Kategorien in einem Projekt abzubilden. Diese Listen beinhalten “Cards”, welche wiederum verschiedene Elemente (Checklisten, Bilder, E-Mails, Kommentare, etc.) enthalten können. Dabei empfehle ich das Tool einfach mal auszuprobieren, bevor man sich diesen und weitere Texte durchliest.
Als Live-Beispiel möchte ich meinen Blog nutzen. Ich versuche meine Blog-Posts nun via Trello & Google-Docs zu organisieren. Dazu habe ich einige Kategorien (Blog-Ideen, Blog-Query, Blog-Artikel und Done) angelegt und bereits einige Themen-Vorschläge eingefügt.
Weitere Überlegungen
Momentan überlege ich, wie man dieses grandiose Tool auch in der täglichen Arbeit einsetzten kann. Dazu würde ich zunächst (ganz noch Projektgröße) verschiedene Trello-Boards anlegen. Dabei kann man “Boards” auch in bestimmten “Organisations” anlegen, was ggf. eine bessere Übersichtlichkeit liefert.
z.B. einige fiktive Organisation für meine private Webseite: http://moelleken.org
Dabei können die verschiedenen Tasks zur nächsten Projektphase weitergereicht werden.
Planung: erste Ideen
Planung: konkrete Beschreibungen und Vorstellungen (hier sollten nach externe Dokumente / Bilder etc zur Beschreibung beigefügt werden)
Development: Bugs, Refactoring-Maßnahmen und neue Features können z.B. in einem Team Meeting in diese Kategorie verschoben und Priorisiert werden.
Development: jeder im Team kann sehen, wer welches Feature, Bug etc. bearbeitet (dies Übersicht kann man mit farblichen “Labels” noch verbessern)
Am Ende der Woche kann man ein Fazit ziehen und ggf. im Team vorstellen, welche Tasks umgesetzt wurden, dies förder die Motivation, bringt Strukturen in das Projekt und verteilt das Wissen nebenbei noch auf verschiedene Mitarbeitet.
Fazit
Noch kann ich nicht sagen, ob diese Überlegungen auch im täglichen “Doing” einsetzbar oder von Vorteil sind. Daher folgt in den nächsten Tagen / Wochen ein weitere Blog-Post, welcher soeben unter “https://trello.com/b/SgOH9gbE/it-blog-suckup-de” geplant wird. ;)
Mein Virtueller Server von Strato hat diese Woche erhebliche Probleme. Angefangen hat dies bereites letzte Woche, daher habe ich am 22.06.2014 eine Support-Anfrage mit der Bitte um Prüfung geschrieben, jedoch bisher nur die Antwort erhalten, dass ein überlastetet Hostsystem ggf. zu den Problemen führt und dass dies momentan geprüft wird.
Daher kann es zwischenzeitlich auf dieser Webseite noch zu erheblichen Ladezeiten kommen, ich bitte dies zu entschuldigen. Wenn jemand einen guten Tipp für einen neuen Hoster hat oder andere Schlüsse aus den folgenden Screenshots ziehen kann, schreibt mir dies bitte per E-Mail “lars (at) moelleken.org” oder einfach direkt hier als Kommentar, vielen dank! Mfg Lars
Falls jemand ebenfalls Performance-Probleme mit seinem Linux-Server hat, sollte man sich einmal folgenden aktualisierten Blog-Post anschauen:
Sehr geehrter Herr Moelleken,
ich möchte Sie mit dieser E-Mail über den Bearbeitungsstand Ihres Troubleticket informieren.
Sie hatten von Beeinträchtigungen bezüglich der Performance Ihres STRATO Virtual Server Linux berichtet.
Vorab bitte ich die Ihnen dadurch entstandenen Unannehmlichkeiten zu entschuldigen.
Erfreulicherweise kann ich Ihnen nun mitteilen, dass die Einschränkungen an Ihrem Server mittlerweile vollständig behoben wurden. Ihr Server ist damit wieder in vollständigem Umfang und mit gewohnter Performance zu erreichen.
Ich wünsche Ihnen weiterhin viel Erfolg mit Ihrem STRATO Server und stehe auch weiterhin bei Rückfragen für Sie bereit.
Gist ist ein schneller Weg, um Code-Beispiele / Konfigurationen / etc. mit anderen zu teilen oder für sich selber aufzubewahren. Jedes “gist” wird dabei als eigenes git-Repository angelegt, so werden diese automatisch versioniert und andere können davon einen Fork erstellen.
Leider gibt es keine Tags für die erstellten “gists”, so dass man sich ein System überlegen muss, wie man die entsprechenden Code-Beispiele wiederfindet z.B.:
– entsprechend aussagekräftige Dateinamen verwenden
– den Type der Datei immer korrekt angeben
– Tags in der Beschreibung hinzufügen #Tag1, #Tag2
– Beschreibung kurz halten
1.) meine “gists”
gist.suckup.de: Diese Webseite habe ich erstellt, um einen schnellen Überblick über meine gists zu erhalten, außerdem habe ich einige Code-Playground und andere Infos hinzugefügt.
2.) Gists organisieren und sammeln
www.gistboxapp.com: Auf dieser Webseite kann man den gists richtige Tags zuordnen und diese somit besser organisieren. Jedoch kann man diese Tags nicht via github / api abrufen, so dass diese nicht in z.B. der IDE angezeigt werden. Außerdem bietet die Webseite eine Chome-Addon, mit welchem man sehr einfach Code-Beispiele von anderen Webseiten als “gist” abspeichern kann.
2.) IDE-Integration
Alle großen IDEs und Texteditoren haben git / gists bereits integriert oder bieten zumindest Plugins, um z.B. selektieren Quelltext direkt als gist abzuspeichern oder gists im Quelltext einzufügen.
– PhpStorm / IntelliJ (bereits integriert)
– Eclpise (Plugin: “EGit”)
– Sublime Text (Plugin: “gist”)
– vim (Plugin: “gist-vim”)
Vorwort: Ich arbeite in Düsseldorf bei der “menadwork GmbH” als Webentwickler und vor einigen Monaten habe ich mein Betriebssystem auf Linux (Debian) umgestellt, daher musste ich meine Toolchain / Programmierumgebung neu einrichten. Vorweg kann ich schon mal verraten, dass man sehr gut und effizient damit arbeiten kann. Nur drei, vier Programme (IE, Photoshop, Outlook, MS Office) musste ich per VIrtualBox (Win7) virtualisieren.
Im folgenden wird eine Toolchain / Programmierumgebung für Webprojekte (PHP, HTML, CSS, Sass, JavaScript) eingerichtet. Diese Anleitung werden ich im parallel für Windows und Linux beschreiben.
Als erstes Installieren / Konfigurieren wir “git” zur Versionskontrolle und um Quellcode von github.com laden zu können. Auch wenn du mit wenigen Leuten oder alleine an einem Projekt arbeitest ist der Einsatz von “git” sehr empfehlenswert. Da man so auch noch nach Wochen / Monaten nachvollziehen kann, warum man welche Änderung gemacht hat und diese zudem ganz einfach rückgängig machen kann.
Es wird wahrscheinlich zu Probleme (Änderung in jeder Zeile der gespeicherten Datei) bei der Zusammenarbeit von “git unter Windows” & “git unter Linux (Mac)” geben, da diese ein anderes “line ending” haben (\n bzw. \r\n). – http://git-scm.com/book/ch7-1.html#Formatting-and-Whitespace
# Windows – Diese wandelt “LF” (\n) in “CRLF” (\r\n) Endungen um, wenn der Befehl “git pull” ausgeführt wird und wandelt dies beim “git commit” wieder zurück
git config --global core.autocrlf true
# Linux (Mac) – Diese wandelt “CRLF” (\r\n) in “LF” (\n) Endungen um, wenn der Befehl “git commit” ausgeführt wird
git config --global core.autocrlf input
-> somit sind die Dateien auf dem Repository (z.B.: github oder gitlab) und in der lokalen git-history immer mit “LF” (\n) codiert.
1.2.2) “push”
git config --global push.default simple
-> der Befehl “git push” schiebt nur commits von der aktuellen “branch” zum Repository (branch mit dem selben Namen)
git config --global color.diff auto
git config --global color.ui auto
git config --global color.status auto
git config --global color.branch auto
2.) Webserver + PHP
Als Webserver installieren wir uns lokal den “Apache”-Webserver, da diese bei vielen Web-Projekten später auch im Live-System zum Einsatz kommt und wir bereits lokal Dinge wie “.htaccess“-Umleitungen etc. testen kann.
Wenn man unter Linux bzw. Mac arbeitet, sollte man den Webserver bzw. PHP so konfigurieren, dass die entsprechenden PHP-Skript-Prozesse mit dem User des Webs laufen. Dies kann man z.B. via suphp oder via php-fpm bewerkstelligen. (Quick & Dirty: die Skripte mit dem eigenen User laufen lassen und das htdocs-Verzeichnis in das eigene Home-Verzeichnis legen)
Unter Windows braucht man sich an dieser Stelle noch keine Gedanken über User-Rechte machen, jedoch spätestens wenn man das Projekte zum ersten mal auf dem Server deployed muss man diesen Schritt auf dem Server wiederholen.
Tipp: hier findet man viele Anleitungen für die Installation von Linux-Servern -> http://www.howtoforge.de/
Unter Windows (XAMPP) ist xDebug bereits vorinstalliert und muss nur noch in der “php.ini”-Datei aktiviert werden. Unter Linux befinden sich die Konfigurationen für PHP-Erweiterungen unter “/etc/php5/config.d/”.
z.B.: für Windows, wenn xampp unter “D:\xampp\” installiert ist
Als nächsten großen Schritt werden wir uns nun eine IDE installieren hier würde ich für größere PHP-Projekte “Netbeans” bzw. “PhpStorm” empfehlen, obwohl “Sublime Text” auch seine Stärken hat und jeder der das Programm noch nicht ausprobiert hat, sollte es einmal testen!!!
3.1) Konfiguration
3.1.1) Netbeans
3.1.1.1) PHPUnit
Unter den Tools -> Options -> PHP -> PHPUnit-> kann man automatisch nach dem bereits installiertem PHPUnit und dem Skeleton-Generator suchen lassen und anschließend aus jeder PHP-Klasse ein PHPUnit-Template erstellen lassen.
3.1.1.2) xDebug
Auch dieses Tool müssen wir einmal konfigurieren unter Tools -> Options -> PHP -> Debugging
Tipp: Wir können unser PHP-Projekt nun nicht nur Debuggen, sondern auch Profilen. Indem wir den Parameter “XDEBUG_PROFILE=1” per GET oder POST übermitteln und den Output anschließend z.B.: via KCachegrind visualisieren lassen.
Auf der Webseite Packagist.org findet man alle Projekte, welche man ohne weitere Anpassungen in seinem Projekt verwenden kann und man kann seine eigenen Projekte einstellen (oder auch eigene Repositories verwenden, falls man diese nicht öffentlich machen will). z.B.: mein Profil -> packagist.org/users/voku/
4.3) Konfiguration
Man lege eine Datei mit dem Namen “composer.json” an und sucht sich seine zu installieren Bibliotheken aus, anschließend ein “composer install –optimize-autoloader” bzw. “composer update” und schon kann man die Bibliotheken verwenden (include von “vendor/composer/autoload.php” nicht vergessen).
5.) Ruby && Node.js
Bower ist auch ein Manager für externe Bibliotheken, jedoch auf JavaScript, jQuery, SASS, LESS, CSS etc. (A package manager for the web) ausgerichtet. Für die Installation muss man auch Ruby und Node.js installieren, jedoch benötigen noch andere wichtige Tools in unserer Toolchain diese Programme, daher folgt nun zuerst die kurze Installation unter Linux und die etwas ausführlichere für Windows. :P
Nachdem wir Ruby Installiert haben müssen wir noch das “DevKit” für Ruby herunterladen und in das Verzeichnis in welchem du Ruby installiert hat in das Unterverzeichnis “\DevKit” entpacken. – z.B.: “D:\xampp\Ruby200-x64\DevKit” und dann folgenden Befehl auf der Kommandozeile (ggf. muss man ruby noch zum PATH hinzufügen oder Windows mal wieder neu-starten)
ruby dk.rb init
Anschließend müssen wir die Datei “dk.rb” noch wie folgt anpassen:
# This configuration file contains the absolute path locations of all
# installed Rubies to be enhanced to work with the DevKit. This config
# file is generated by the 'ruby dk.rb init' step and may be modified
# before running the 'ruby dk.rb install' step. To include any installed
# Rubies that were not automagically discovered, simply add a line below
# the triple hyphens with the absolute path to the Ruby root directory.
#
# Example:
#
# ---
# - C:/ruby19trunk
# - C:/ruby192dev
#
---
- D:/xampp/Ruby200-x64
… und können die Installation mit folgenden Befehlen abschließen:
ruby dk.rb review
ruby dk.rb install
6.) “Bower” – bower.io
Zurück zu Bower, nachdem wir nun Ruby && Node.js installiert haben, können wir nun weiter Tools sehe einfach über die Kommandozeile via npm installieren lassen.
Sass ist ein Preprocessor für CSS, so dass man Variablen, Schleifen, Funktionen etc. in CSS nutzten kann. Große Projekte wie z.B.: Bootstrap bieten Ihren Quellcode als scss-Version an. Der Code-Style unterscheidet sich nur minimal von “normalem” CSS, wobei hier normal in Anführungszeichen stehen, da man die verschiedenen CSS-Selektoren nicht zwingend verschachteln muss. Man kann auch einfach seine bestehende CSS-Datei in eine SCSS-Datei umbenennen und per “sass” kompilieren oder eine bestehen CSS-Datei (z.B.: test.css) per “sass-convert” Konvertieren.
compass ist ein Framework, welches auf sass aufbaut und dieses um CSS3-Funktionen und z.B. automatisches erstellen und aktualisieren von CSS-Sprites bietet.
8.1) Installation
gem install compass [--pre]
Tipp: wenn man noch Browser unterstützen muss, welche keine Transparenzen via CSS (opacity) können, dann sollte man sich mal “compass-rgbapng” anschauen. Damit werden automatisch Fallback-Bilder (png’s) in der entsprechenden Farbe / Transparenz erstellt und im CSS eingebaut.
8.2) Konfiguration
Wir starten indem wir folgende Datei anlegen -> “config.rb”
# Require any additional compass plugins here.
#require "rgbapng"
#add_import_path "vendor/bower/foundation/scss/"
#add_import_path "vendor/bower/normalize-scss/"
# Set this to the root of your project when deployed:
http_path = "/"
css_dir = "css"
sass_dir = "scss"
images_dir = "images"
javascripts_dir = "js"
# You can select your preferred output style here (can be overridden via the command line):
# output_style = :expanded or :nested or :compact or :compressed
output_style = :expanded
# To enable relative paths to assets via compass helper functions. Uncomment:
# relative_assets = true
# To disable debugging comments that display the original location of your selectors. Uncomment:
# line_comments = false
line_comments = true
# If you prefer the indented syntax, you might want to regenerate this
# project again passing --syntax sass, or you can uncomment this:
# preferred_syntax = :sass
# and then run:
# sass-convert -R --from scss --to sass sass scss && rm -rf sass && mv scss sass
8.3) HowTo
Nachdem wir die Konfiguration angelegt und ggf. angepasst haben, wird mit dem folgendem Befehl automatisch (bei Änderungen) die entsprechende scss-Datei in eine css-Datei kompeliert.
Anstatt die entsprechenden CSS3-Funktionen von compass zu verwernden, erscheint es mir einfacher und Sinnvoller entsprechende Vendor-Prefixes automatisch zu erstellen und genau das macht dieses Tool! Man kann es entweder selber aufrufen, in compass oder via “grunt” (dazu kommen wir gleich) integrieren.
9.1) Installation
gem install autoprefixer-rails [--pre]
9.2.1) HowTo: Grunt + autoprefixer
(Auch wenn ich noch gar nicht zu grunt geschrieben habe, zeige ich schon mal wie, man dies nutzten kann.)
Als erstes wird das Plugin “grunt-autoprefixer” installiert und dann folgender Task in der Datei “Gruntfile.js” angelegt:
Folgendes in die compass-Konfiguration “config.rb” einfügen:
require 'autoprefixer-rails'
on_stylesheet_saved do |file|
css = File.read(file)
File.open(file, 'w') do |io|
io << AutoprefixerRails.process(css)
end
end
Grunt ist ein Task-Runner, dass heißt das Programme automatisch z.B. nach dem Speichern einer Datei ausgeführt werden können. Falls jemand das Tool noch nicht im Einsatz hat -> einfach mal Testen!!! Erst dieses Tool verknüpft alle hier vorgestellten Tools zu einer “Toolchain”. Und man ist nur noch einen Schritt davon entfernt automatisierte Tests im Browser, Live-Reload im Brower etc. zu nutzen.
Entweder man legt sich selber ein entsprechendes “Gruntfile.js” (Konfiguration) und “package.json”- Datei an oder man nutzt den Befehl:
grunt-init TEMPLATE_NAME
10.3) Video
Wie im Video erklärt wird, kann man gunt, nachdem man dies einstellt hat, mit dem Befehl “grunt watch” auf Änderungen von beliebigen Dateien, beliebige Tasks ausführen lasse. In meinem Fall lasse ich z.B. bei Änderungen von “*.scss”-Dateien diese via compass in CSS compilieren, anschließend per “autoprefixer” überarbeiten, minifizieren und zum Schluss wird automatisch ein reload von dem entsprechendem Brower-Tab durchgeführt. :)
In order to optimize the website and to continuously improve it, this site uses cookies. By continuing to use the website, you consent to the use of cookies.Ok