Guideline für Open Source Software

 SLIDES

  1. Was ist Open Source Software?
    1. Geschichte
    2. Freie Software Open Source Software
    3. Lizenzen
    4. Geschäftsmodelle
  2. Wo veröffentliche ich Open Source Software?
  3. Welche Open Source Software Standards gibt es?
    1. Lizenz
    2. Quellcode-Organisatzion
    3. Dokumentation
    4. Kommunikation
    5. Versionsnummern
    6. Abhängigkeitsmanagement
    7. Testabdeckung
    8. Issue-Tracking-System
  4. Wie veröffentliche ich Open Source Software?
    1. Beispiel: npm
    2. Beispiel: bower
    3. Beispiel: composer
  5. Beispiel-Repository

1. Was ist Open Source Software?

Freiheit 0: Das Programm zu jedem Zweck auszuführen.

Freiheit 1: Das Programm zu untersuchen und zu verändern.

Freiheit 2: Das Programm zu verbreiten.

Freiheit 3: Das Programm zu verbessern und diese Verbesserungen zu verbreiten, um damit einen Nutzen für die Gemeinschaft zu erzeugen.

1.1 Geschichte

1893: AT&T wird gegründet

1911: IBM wird gegründet

1969: AT&T beginnt mit der Entwicklung eines quelloffenes Betriebssystem – Unix

1972: Dennis Ritchie veröffentlciht die Programmiersprache C

1975: Microsoft wird von Bill Gates und Paul Allen gegründet

1976: Apple wird von Steve Jobs, Steve Wozniak und Ron Wayne gegründet

1977: Universität von Kalifornien in Berkeley entwickelt einen Fork von Unix BSD

1980: Unix wird proprietär

1981: 86-DOS wird von Microsoft gekauft und an IBM verkauft ~ MS-DOS

1984: Richard Stallman beginnt mit der Entwicklung eines freien Betriebssystems – GNU

1985: Richard Stallman gründet eine gemeinnützliche Organisation Free Software Foundation

1985: NeXT wird von Steve Jobs gegründet

1987: IBM und Microsoft veröffentlichen ein proprietäres Betriebssystem – OS/2

1987: Andrew S. Tanenbaum Minix veröffentlichen ein freies Betriebssystem – Minix

1988: MIT-Lizenz wird veröffentlicht

1988: NeXT, Inc. veröffentlicht ein proprietäres Betriebssystem, ein Fork von BSD – NeXTStep

1989: Richard Stallman schreibt eine Lizenz für Freie Software: GNU General Public License

1991: Linus Torvalds entwickelt einen freien Kernel – Linux

1993: Ian Murdock beginnt mit der Entwicklung eines freien Betriebssystems – Debian (GNU/Linux)

1993: Open-Source-Community veröffentlicht ein freies unixoides Betriebssystem – FreeBSD 1.0

1993: Microsoft veröffentlicht ein proprietäres Betriebssystem – Microsoft_Windows_3.1

1995: Rasmus Lerdorf entwickelt eine Skriptsprache für Webanwendungen PHP

1995: Sun Microsystems entwickelt eine objektorientierte Programmiersprache Java

1995: Netscape entwickelt eine Skriptsprache für Client-Webanwendungen – JavaScript

1996: erste Version des Betriebssystems Debian wird veröffentlichtDebian 1.1 (GNU/Linux)

1998: Goolge wird von Larry Page und Sergey Brin gegründet – Google

1998: Organisation, zur Förderung von Open-Source-Software wird gegründet OSI

2000: Apple veröffentlicht ein freies unixoides Betriebssystem, einen Fork von NeXTStep (FreeBSD) – Darwin

2001: Microsoft veröffentlicht ein proprietäres Betriebssystem Microsoft Windows XP

2001: ein freies Onlinelexikon geht online Wikipedia

2001: gemeinnützliche Organisation für freie Software (Europa) wird gegründet FSFE

2001: gemeinnützliche Organisation für freie Lizenzen wird gegründente Creative Commons

2002: freie Software wird im deutschen Urhebergesetz rechtskräftig – Linux-Klausel

2003: ein freie Software zur Verwaltung von Websiten wird veröffentlicht WordPress

2005: Linux Torvalds beginnt mit der Entwicklung einer freien Versionsverwaltung – git

2008: Google Chrome (freeware) / Chromium (free) wird veröffentlicht Chrom[e|ium]

2008: Google veröffentlicht ein freies Betriebssystem – Android

2009: Joyent Inc. entwickelt freie serverseitige Plattform für Netzwerkanwendungen – NodeJS

2012: Microsoft veröffentlicht ein proprietäres Betriebssystem Microsoft Windows 8

2013: Mozilla veröffentlicht ein freies Betriebssystem – Firefox OS

2014: Open-Source-Community veröffentlicht ein freies unixoides Betriebssystem – FreeBSD 10.0

2015: Linus Torvalds veröffentlicht eine neue Version seines freien Kernels – Linux 4.0

Umsatz: Um zu verdeutlichen, wie viel Geld mit Software (Computer) verdient werden kann, auch mit Open Source Software …

Apple: 182,8 Mrd. USD (2014)
AT&T: 128,8 Mrd. USD (2013)
IBM: 92,8 Mrd. USD (2014)
Microsoft: 85,8 Mrd. USD (2014)
Google: 66 Mrd. USD (2014)
Red Hat: 1,33 Mrd. USD (2013)
Mozilla: 0,3 Mrd. USD (2013)
Canonical (Ubuntu): 0,065 Mrd. USD (2014)

1.2 Freie Software Open Source Software

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.

http://www.heise.de/newsticker/meldung/Amazon-loescht-gekaufte-Kindle-eBooks-6887.html: Hier hat Amazon Kindle-eBooks („1984“ und „Animal Farm“ von George Orwell) von extern gelöscht, da der Verkäufer die nötigen Rechte zum verkaufen gar nicht besaß.

http://blogs.technet.com/b/mmpc/archive/2014/01/09/tackling-the-sefnit-botnet-tor-hazard.aspx: Hier wurde ebenfalls Software von extern gelöscht – Microsoft löscht Tor-Software nach Trojaner-Befall.

1.3 Lizenzen

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

softwaremodels

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.

quick-guide-gplv3-compatibility.de

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.1 Open 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.2 Quellcode 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.6 Abhängigkeitsmanagement für verwendete Bibliotheken nutzen, z.B.:
     – PHP: Composer (packagist.org)
     – JS / Node.JS: npm
     – HTML / CSS / JS: bower

3.7 Testabdeckung und automatische Tests bei jeder Änderung
     – Unit-Tests / BDD / TDD, z.B.:
          – PHP: PHPUnit / phpspec
          – JavaScript: mocha, Jasmine, qUnit
     – Frontend-Testing, z.B.:
          – CasperJS / DalekJS / Selenium
     – automatisierte Tests
          – Travis CI (Linux)
          – AppVeyor (Windows)

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

# Abhänigkeiten & Tests hinzufügen

npm install mocha --save-dev


npm install chai --save-dev

# Veröffentliche dein Paket

npm publish

4.2 Beispiel: bower

# Installation von node.js, z.B.:

sudo apt-get install nodejs

# Installation von bower

npm install -g bower

# interaktiv eine „bower.json“-Datei erstellen

bower init

# Veröffentliche dein Paket

bower register <my-package-name> <git-endpoint>

4.3 Beispiel: composer

# Installation von composer, z.B.:

curl -sS https://getcomposer.org/installer | php

# interaktiv eine „composer.json“-Datei erstellen

composer init

# Veröffentliche dein Paket
https://packagist.org/packages/submit

5. Beispiel-Repositories

https://github.com/voku/node-lettering

https://github.com/voku/bower-lettering

Quellen / Links:

– eine Liste von offiziellen „Open Source“ Lizenzen: http://opensource.org/licenses/alphabetical

– eine Liste von Programmiersprachen und deren Lizenzen: http://en.wikipedia.org/wiki/List_of_open-source_programming_languages

Gespräch: Unterstützen von Open Source Projekten: https://www.radiotux.de/index.php?/archives/7995-RadioTux-Sendung-Maerz-2015.html

– Support for Open-Source Software: https://www.bountysource.com/

– Easy Pick (einfach zu behebende Bugs) -> z.B.: https://github.com/symfony/symfony/issues?q=is%3Aopen+is%3Aissue+label%3A%22Easy+Pick%22

– Help your favorite open source projects: http://www.codetriage.com/

Statistik über freie Lizenzen auf github: http://ostatic.com/blog/the-top-licenses-on-github

– Erklärung zu freie Lizenzen: http://www.webmasterpro.de/management/article/freie-lizenzen.html

A Beginner’s Guide to Creating a README: https://thechangelog.com/a-beginners-guide-to-creating-a-readme/

Starting An Open-Source Project: http://www.smashingmagazine.com/2013/01/03/starting-an-open-source-project/

qUnit vs Jasmine vs Mocha: http://www.techtalkdc.com/which-javascript-test-library-should-you-use-qunit-vs-jasmine-vs-mocha/

Which programming language has the best package manager?http://blog.versioneye.com/2014/01/15/which-programming-language-has-the-best-package-manager/

– Erstelle Packages via bower: http://bower.io/docs/creating-packages/

Open-Source-Lizenzen: http://www.heise.de/open/artikel/Open-Source-Lizenzen-224724.html

Think about the license! http://lucumr.pocoo.org/2009/2/12/are-you-sure-you-want-to-use-gpl/

– Linus Torvalds says GPL v3 violates everything that GPLv2 stood for: https://www.youtube.com/watch?v=PaKIZ7gJlRU

GNU – Free Software: https://www.gnu.org/philosophy/free-sw.en.html

GNU/GPL: https://www.gnu.org/copyleft/gpl.html

GNU/Packages: http://www.gnu.org/manual/blurbs

FreeBSD über Vor- und Nachteile von GPL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/bsdl-gpl/gpl-advantages.html

– Geschäftsmodelle für Open-Source: http://t3n.de/magazin/geschaftsmodelle-open-source-unternehmer-welche-ansatze-221154/

– Open-Source-Finanzierung (Podcast): http://chaosradio.ccc.de/cr209.html

Admin meets Frontend

… oder was „JavaScript“ und „Shell-Script“ gemeinsam haben.

Zu beginn muss ich zugeben, dass ich bei meinen ersten Skripten auch nicht auf den Sichtbarkeitsbereich von Variablen (Scope) geachtet habe. Wenn man sich jedoch etwas mit Softwareentwicklung auseinandersetze stellt man schnell fest, dass globale Variablen direkt aus der Hölle kommen und nichts im Quelltext zu suchen haben.

Range_of_Variables

Variablen sind zumindest in der Shell und in JavaScript zunächst global, selbst innerhalb von Funktionen und werden erst durch den Zusatz „var“ bzw. „local“ zur lokalen Variable. In vielen anderen Programmiersprachen erkennt man den Scope einer Variable direkt im Zusammenhang, ist z.B. eine Variable innerhalb einer Methode deklariert, so ist diese nur innerhalb dieser Methode verfügbar. Wird die Variable jedoch innerhalb der Klasse deklariert, so ist diese für die ganze Klasse und somit für alle Ihre Methoden verfügbar.

Es folgen ein paar Beispiele, wo der Inhalt (Title der Beiträge) des RSS-Feeds von „planet.ubuntuusers.de“ ausgegeben werden soll.

JS-Beispiel: mit globalen Variablen

test-1

Um dies selber zu testen, öffne die Verlinkte Datei im Browser (leere Webseite) und öffne die Entwicklertools (F12), schalte die Ansicht auf „Konsole“ und lade die Seite neu. Im Quelltext sind ausschließlich globale Variablen verwendet, jedoch funktioniert dieses Script „leider“ wie gewünscht. Das Problem mit globalen Variablen ist, dass man den Quelltext dadurch ggf. schwerer lesen kann und diesen nicht wiederverwenden kann. Wenn man z.B. verschiedene Funkionen als unterschiedlichen Skripten zusammenfügt oder zusammen nutzen möchte, welche jedoch ebenfalls globale Variablen nutzen, dann können da sehr eigenartige Ergebnisse bei herauskommen.

JS-Beispiel: mit lokalen Variablen

test-1_1

test-1_1_2

 

In den DevTools von Chrome kann man jetzt den entsprechenden Variablen-Scope sehen. Jedoch ist der Quellcode noch nicht wirklich wiederverwendbar, da wir das zu lösende Problem (also das laden und parsen einer JSON-Datei) nicht auf eine eigene Abstraktionsschicht gebracht haben.

JS-Beispiel: mit lokalen Variablen und Klassen

test-1_2

In diesem Beispiel wurde nun die Klasse „PlanetUbuntuuserJsonData“ erstellt welche wiederum von der Klasse „JsonData“ dessen Eigenschaften (Variablen & Methoden) erbt. Leider ist der Quelltext hierbei von zirka 50 auf zirka 80 Zeilen erhört worden und funktioniert dabei z.B. nicht im IE < 10. (siehe Kommentare im Quelltext)

JS-Beispiel: ohne Variablen + jQuery

test-2

Dieses Beispiel benötigt zwar die „jQuery“-Bibliothek, welche jedoch bereits entsprechende Funktionalitäten kapselt. Vergleich man diesen Quellcode mit der Vorherigem Version, kann man schnell erkennen, das entschieden weniger Quellcode deutlich besser zu lesen ist. ;-)

Shell-Beispiel: mit globalen Variablen (test_1.sh)

test-bash

In diesem Beispiel sind wieder sehr viele globale Variablen verwendet und wieder funktioniert das entsprechende Skript „leider“ trotzdem. Die Funktion „parse_json()“ gibt nicht einmal einen Rückgabewert zurück, dafür teilen sich die beiden Funktionen die Variablen. Und im Grunde könnte man den ganzen Quelltext auch einfach ohne Funktionen untereinander schreiben, dies hätte den selben Effekt.

Shell-Beispiel: mit lokalen Variablen (test_2.sh)

Die entsprechende Ausgabe ist bereits im Vorherigen Bild zu sehen. Bei Shell-Skripten kommt es seltener vor, dass man dessen Funktionalität wirklich wiederverwenden möchte, jedoch ist der Quelltext deutlich besser zu lesen, wenn man entsprechende Rückgabewerte und Übergabeparameter verwendet.

Quellen / Links:
– Shell: Advanced Bash-Scripting Guide
– Shell: Coding-Style-Guide von „Oh My Zsh“
– JS: Sichtbarkeitsbereich (Scope) von Variablen
– JS: Objektattribut

 

Server-Probleme im Zeitalter von HTTP/2

Ich hatte heute das Problem, dass einige Webseiten extrem langsam bis gar nicht mehr vom Webserver ausgeliefert wurden. Also prüfe ich als erstes mit „htop“ ob die CPU ausgelastet ist, danach via „iotop“ die Festplatte, mit „iftop“ den Traffic, mit „netstat“ die offenen Netzwerkverbindungen und via „free“ wie viel Speicher noch zur Verfügung steht. Und die Hardware war nicht mal ansatzweise ausgelastet. Nach einigen weitere Tests ist schnell aufgefallen, dass nur „http“-Anfragen betroffen waren. Selbst eine einfach GET-Anfrage eines Bildes ist zeitweise fehlgeschlagen.

Die größte Änderung am Vortag war, dass eine Webseite mit zirka 1 Millionen Usern komplett auf „https://“ umgestellt wurde. Daher habe ich kurzfristig wieder auf „http://“ umgestellt, jedoch ohne eine Änderung festzustellen.

linux_kill_9
Quelle: http://www.reddit.com/r/ProgrammerHumor/comments/27vcjg/signal_kill/

Zeitgleich ist aufgefallen das der MySQL-Prozess nicht korrekt neugestartet ist, somit liefen zwei MySQL-Server (ps aux | grep mysql), wobei nur einer wirklich Anfragen angenommen hat. Der zweite Prozess wollte sich nicht mehr via „service mysql restart“ neustarten lassen, hat die Fehlermeldung „Can’t connect to local MySQL server through socket ‚/var/run/mysqld/mysql.sock‘“ produziert und wurde daher via „kill“ getötet und anschließend der MySQL-Server neugestartet.

Dies hat auch das Problem mit den langsamen Webseiten behoben, zumindest kurzweilig. Danach hatten „http“-Anfragen wieder Probleme. Im „error“-Logfile (/var/log/apache2/error.log) vom Apache habe ich dann endlich eine Meldung gefunden, welche mich auf die richtige Fährte gebracht hat: „server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers settings“

website-download-with-spdy

Vor einer Woche hatte ich das „SPDY„-Protokoll auf dem Server aktiviert und getestet, alles hat ohne Probleme funktioniert. Dann habe ich gestern die bereits erwähnte Webseite komplett auf „https“ umgeroutet und noch immer kein Problem festgestellt. Am Morgen wurden dann Newsletter versendet und eine ganze Menge Leute sind in kurzer Zeit via „https“ auf die Webseite gekommen, da das „SPDY“-Protokoll nur mit „https“ arbeite haben diese User nicht die üblichen Anfragen  (HTTP 1.0 / 1.1) an den Server gestellt, sondern durch Multiplexverfahren mehrere Anfragen gleichzeitig verarbeitet werden.

http-diagram-spdy
Quelle: http://stackoverflow.com/questions/10480122/difference-between-http-pipeling-and-http-multiplexing-with-spdy

Die erste Intuition, dass es etwas mit der „SSL“-Umstellung zu tun hatte war schon mal nicht verkehrt, jedoch hatte ich die entsprechenden Einstellungen nur in der „.htaccess“ auskommentiert, die „https“-Verbindungen jedoch nicht zurück nach „http“ umgeleitet …

RewriteCond %{SERVER_PORT} !^443
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

… und den Apache nicht neugestartet, somit waren die aktuellen Anfragen noch aktiv und Nutzer welche auf der Webseite waren haben weiter „https“-Anfragen generiert.

Im nächsten Schritt musste nun festgestellt werden, wie viele Apache Prozesse bzw. gleichzeitige Verbindungen einstellt werden mussten und wie man dies am besten konfiguriert. Die Apache-Dokumentation sagt hierzu folgendes:

„The MaxRequestWorkers directive sets the limit on the number of simultaneous requests that will be served … For non-threaded servers (i.e., prefork), MaxRequestWorkers translates into the maximum number of child processes that will be launched to serve requests. The default value is 256; to increase it, you must also raise ServerLimit.“

Also habe ich via …

netstat -anp | grep -E ":80|:443" | grep ESTABLISHED | wc -l

… bzw. zur groben Orientierung via …

ps aux | grep apache | wc -l

… herausgefunden wie viele http(s) Anfragen bzw. Apache Prozesse aktuell vorhanden sind und habe diese Einstellungen zunächst entsprechend hoch eingestellt („/etc/apache2/mods-enabled/mpm_prefork.conf“), so dass die Webseite wieder korrekt funktionierte. Anschließend habe ich die zuvor beschriebenen Befehle verwendet, um die endgültigen Einstellungen zu ermitteln. Die folgenden Einstellungen sind an einen Server mit 32G Arbeitsspeicher getestet und sollte nicht einfach übernommen werden.

<IfModule mpm_prefork_module>
ServerLimit                                    1024
StartServers                                        1
MinSpareServers                              32
MaxSpareServers                          250
MaxRequestWorkers              1024
MaxConnectionsPerChild             0
</IfModule>

————————————————–

Lösung: Wenn man das „SPDY“-Modul aktiviert und später auf „SSL“ umstellt, sollten man vorher die Apache-Konfiguration anpassen! ;)

————————————————–

Es folgt noch ein kleines Tutorial, wie man „SPDY“ für Apache installieren kann. Jeder der bereits auf „nginx“ umgestiegen ist, kann dies ggf. bereits ohne weitere Installation ausprobieren: http://ginx.org/en/docs/http/ngx_http_spdy_module.html

Installation: SPDY für Apache 2.2

Download: https://developers.google.com/speed/spdy/mod_spdy/

# z.B.: wget https://dl-ssl.google.com/dl/linux/direct/mod-spdy-beta_current_amd64.deb
dpkg -i mod-spdy-*.deb
apt-get -f install

Installation: spdy für Apache 2.4

apt-get -y install git g++ apache2 libapr1-dev libaprutil1-dev patch binutils make devscripts fakeroot
cd /usr/src/
git clone https://github.com/eousphoros/mod-spdy.git
## wähle deine Apache Version  
# z.B.: git checkout apache-2.4.7
# z.B.: git checkout apache-2.4.10
cd mod-spdy/src
./build_modssl_with_npn.sh
chmod +x ./build/gyp_chromium
rm -f out/Release/mod-spdy-beta*.deb
BUILDTYPE=Release make linux_package_deb
dpkg-i out/Release/mod-spdy-beta*.deb

Video:

Links:

– Projekt Webseite: http://www.chromium.org/spdy/

– Quellcode: https://code.google.com/p/mod-spdy/wiki/GettingStarted

– „mod_spdy“ für Apache 2.2: https://developers.google.com/speed/spdy/mod_spdy/

– „mod_spdy“ für Apache 2.4: https://github.com/eousphoros/mod-spdy

– Online-Test für „SPDY“: https://spdycheck.org/

– Präsentation zum Thema „HTTP/2“ von @derschepphttps://schepp.github.io/HTTP-2/

– Browserkompatibilität mit „SPDY“: http://caniuse.com/#search=spdy

I ❤ ~/

Vor einiger Zeit habe ich bereits einen Blog-Post über meine „.dotfiles“ geschrieben, jedoch habe ich mich damals mehr auf die Installation beschränkt und habe keine Beispiele gezeigt, so dass man den Vorteil der .dotfiles nur schwer erfassen konnte.

Außerdem benötigt man ggf. nur einige Funktionen oder Dateien um sein System an an seine Bedürfnisse anzupassen. Auf der Webseite GitHub ❤ ~/ gibt es sehr gute .dotfiles Sammlungen, welche man einfach „forken“ und anpassen und nutzen kann.

PS: wer sich bisher nicht mit „git“ auskennt, sollte sich einmal eines der folgenden interaktiven git-Tutorials anschauen:
try.github.io/
pcottle.github.io/learnGitBranching/
gitreal.codeschool.com/


Beispiele zu meinen .dotfiles:

Navigation:
https://github.com/voku/dotfiles/blob/master/.aliases#L75 easier navigation via aliases

Farben für die Kommandozeile:
https://github.com/voku/dotfiles/blob/master/.aliases#L116color for ping / traceroute / ps / top / ...

difflight & filename auto-completion via zsh

Nützliche Shortcuts: z.B. date_*
https://github.com/voku/dotfiles/blob/master/.aliases#L295
more useful shortcuts

Copy&Past via „getclip“ und „putclip“: https://github.com/voku/dotfiles/blob/master/.aliases#L368copy text via "getclip" & putclip

kill & pkill via z-shell: https://github.com/voku/dotfiles/blob/master/.redpill/lib/4_completion.zsh#L122kill & pkill via z-shell

grep & ack: https://github.com/voku/dotfiles/blob/master/.aliases#L242grep & ack

git via z-shell: https://github.com/voku/dotfiles/blob/master/.gitconfiggit via z-shell

„ls“-aliases: https://github.com/voku/dotfiles/blob/master/.aliases#L196optimized "ls"-aliases

vim » Automatisch zur letzten Position springen 
https://github.com/voku/dotfiles/blob/master/.vimrc "vim" » jump to last position

vim » Schell-Suche via „#“ "vim" » quick search via "<#>" or "*"

vim » markieren Leerzeichen am Ende der Zeile"vim" » highlight trailing spaces in annoying red

vim » Tabs nutzen
https://github.com/voku/dotfiles/blob/master/.vimrc#L564
vim » NERD Tree via „,“ + „-„
https://github.com/voku/dotfiles/blob/master/.vimrc.bundles#L18"vim" » "tabs" & "file-view"

vim » Autovervollständigung via Tabulatur-Taste
https://github.com/voku/dotfiles/blob/master/.vimrc#L755"vim" » tab-completion


Erklärungen zu meinen .dotfiles:

.config_dotfiles

In dieser Datei kann man Einstellungen für meine .dotfiles vornehmen. Wenn du z.B. deinen Standard-User-Namen in der Variable „CONFIG_DEFAULT_USER“ hinterlegst, wird diese nicht mehr in der Shell-Prompt angezeigt.

.path

In dieser Datei kannst du Pfade zu deinen Ausführbaren Dateien einfügen, so dass du diese ohne Angabe des Pfades ausführen kannst.

Diese Datei ist nicht im öffentlichen Repository und ist via „.gitignore“ aus git verbannt, da es vertrauliche Informationen enthalten kann. z.B.: export PATH=“$HOME/utils:$PATH“

.load

In dieser Datei laden wir weitere optionale Einstellungen, welche ggf. gar nicht installiert und somit auch nicht geladen werden müssen.

.colors

Hier definieren wir einige Farben, welche dann in den folgenden Dateien verwendet werden können. z.B.: COLOR_BLACK=\e[0;30m

.exports

Variablen in Shell-Scriptes verhalten sich so ähnlich wie in JavaScript. Variablen sind Standardmäßig „global“, dass heißt selbst Variable innerhalb einer Funktion sind anschließend auch außerhalb der Funktion verfügbar. Daher verwenden wir „local“ innerhalb von Funktionen, für Variablen welche nur innerhalb der Funktion zur Verfügung steht sollen. Außerdem können wir Variablen via „export“ exportieren, so dass diese nicht nur zur Ausführungszeit, sondern anschließend ebenfalls allen Kindprozessen als Umgebungsvariable zur Verfügung stehen.

.icons

Wie die Farben werden auch die entsprechenden Icons exportiert, so dass wir diese anschließend in Funktionen etc. nutzen können.

.aliases

In dieser Datei werden Abkürzungen für komplexe Befehle oder / und Fallbacks definiert, welche anschließend als Befehl ausgeführt werden.

z.B.:
alias starwars=’telnet towel.blinkenlights.nl‘
alias sgrep=’grep -R -n -H -C 5 –exclude-dir={.git,.svn,CVS}‘

.bash_complete // completion.zsh

Auch wenn die „Z-Shell“ (zsh) bessere Tabcompletion bietet, kann man auch in der „Bash“ einige  Tabcompletion-Features nutzen.

z.B.:


apt- [Tabulator]
apt-g [Tabulator]
apt-get [Tabulator]
apt-get i [Tabulator]
apt-get install [Tabulator] [Tabulator]
apt-get install apa [Tabulator]

.functions

Hier habe ich einige praktische Funktionen gesammelt, welche ich öfters nutze und nicht als Plugin auslagern möchte.

z.B.:
lman() -> „Open the manual page for the last command you executed“
netstat_free_local_port() -> „get one free tcp-port“
iptablesBlockIP() -> „block a IP via ‚iptables'“

Überlegungen: In der „normalen“ Programmierung nutzt man lowerCamelCase für normale Variablen / Funktionen und Methoden, jedoch sind eigentlich alle Funktionen in der Shell lowercase z.B.: whoami, updatedb, killall. Ich mich dafür entschieden mich bei neuen Funktionen und Aliases an einem Original-Befehl zu orientieren, so dass man diese nicht neu lernen muss, sondern diese via [Tabulator] nutzen kann.

.extra

Auch diese Datei ist nicht im öffentlichen Repository und ist via „.gitignore“ aus git verbannt, da es vertrauliche Informationen enthalten kann. Hier kann man alle zuvor gesetzten Variablen, Einstellungen, Funktionen überschreiben oder ergänzen.

„gzip“ für Webseiten

Um das Verhalten von „gzip / deflate“ besser zu verstehen, möchte ich als erstes ganz kurz auf den Algorithmus hinter der Komprimierung eingehen. Dafür muss man zumindest zwei Grundlegende Theorien verstehen. Zum einen die sogenannte Huffman-Kodierung, dabei geht darum Text mit möglichst wenig Bits (0 || 1) zu übersetzen.

Es folgt ein einfaches Beispiel:

String: „im westen nichts neues“

Die Länge des Strings beträgt 22 Zeichen, was bei einem 4-Bit-Code (0000, 0001 …) eine Anzahl von 22 * 4 Bit = 88 Bit ergeben würde.

Berücksichtigt man jedoch die Häufigkeit der wiederkehrenden Zeichen, kann man für bestimmte Zeichen, welche oft im String vorkommen, kürzere Bit-Codes nutzen.

huff1

Als erstes Zählen wir die Anzahl der vorkommenden Zeichen. Die Zeichen welche die geringste Häufigkeit aufweisen werden anschließend als erstes miteinander Verknüpft und jeweils addiert.

huff4

Wie man bereits erkennt bekommen die Zeichen welche nicht so häufig auftreten längere Strecken und somit gleich auch längere Bit-Codes.

huff7

Wenn man alle Zweige verknüpft hat, entsteht daraus dann ein Binär-Baum, welcher von oben nach unten gelesen wird.

Die eindeutigen Bit-Codes sind nun z.B.: 00 für e, 100 für n, 1011 für t und so weiter. Nun benötigen wir nur noch 73 Bit anstatt 88 Bit, um den String binär darzustellen. ;)

Das zweite Prinzip hat auch mit Wiederholung von Zeichen zu tun. Die sogenannte „LZ77″ Kompression, welche wiederkehrende Muster in Strings erkennt und durch Referenzen von vorherigen Strings ersetzt.

Es Folgt ein einfaches Beispiel:

String: „Blah blah blah blah blah!“

 vvvvv     vvvvv     vvv
Blah blah blah blah blah!
      ^^^^^     ^^^^^

Wenn man nun die Wiederholung durch eine Referenz angibt, welche aus der Länge des Wortes (“ blah“ = 5) und Länge der Wiederholungen. („lah blah blah blah“ = 18). Daraus ergibt sich anschließend der folgende komprimierte Text.

Blah b(5,18)!

… aber nun endlich zum praktischen Teil! Es folgen ein paar Beispiele und Überlegungen im Zusammenhang mit Webseiten / Webservern.

1.) „gzip“, ABER weniger ist manchmal mehr

Bei kleinen Webseiten und schwachen V-Servern kann es vorkommen, dass die serverseitige Komprimierung im Gesamtkontext keinen Geschwindigkeitsvorteil bietet, da die Komprimierung ggf. mehr Overhead (Payload, CPU-Rechenzeit, Verzögerung der Auslieferung) mit sich bringt als es Vorteile (geringere Dateigröße) bietet. Zumal viele Dateien (Bilder, CSS, JS) nach dem ersten Seitenaufruf im Cache sind und nicht wieder vom Server ausgeliefert werden müssen. Gerade für mobile Geräte macht die Komprimierung jedoch fast immer Sinn, daher würde ich die Komprimierung immer aktivieren!

PS: hier noch ein Blog-Post zum Thema Webseiten Beschleunigen

moelleken_org-gzip
mit gzip
moelleken_org-nogzip
ohne gzip

GRÜN = Download
GELB = Wartet
BLAU = Verbindung zum / vom Server

Bei „nginx“ gibt es zudem ein Modul (HttpGzipStaticModule) welches direkt vorkomprimierte Dateien ausliefert, anstatt diese bei Anfrage zu komprimieren. Jedoch muss man bisher selber dafür sorgen, dass eine entsprechende Datei mit dem selben Timestamp vorhanden ist. (z.B.: main.css & main.css.gz) Falls jemand hier eine Alternative oder ein einfaches Script zum erstellen der zu komprimierenden Dateien hat, meldet euch bitte bei mir oder einfach in den Kommentaren.

2.) „gzip“, ABER nicht für alles

Zunächst sollte man bereits komprimierte Dateien (z.B. JPEG, PNG, zip etc.) nicht noch zusätzlich via „gzip“ ausliefern, da die Dateigröße im schlimmsten Fall noch steigen kann oder zumindest wird für sehr wenig Dateigröße, sehr viel CPU-Zeit auf der Server (Komprimierung) und auf dem Client (Dekomprimierung) verbraucht.

gzip_images

Ich empfehle an dieser Stelle mal wieder die „.htaccess„-Datei vom HTML5-Boilerplate, welche bereits viele Einstellungen für den Apache-Webserver liefert. Außerdem gibt es dort auch eine optimierte Konfiguration „nginx.conf“ für den nginx-Webserver.

3.) „gzip“, ABER nicht immer

Die „gzip“-Komprimierung kann Ihre Stärken bei größeren Dateien viel besser ausspielen, da wir ja bereits im theoretischen Teil gelernt haben, dass die Komprimierung auf Wiederholungen aufbaut und wenn wenig wiederkehrende Zeichen und Muster vorhanden sind lässt es sich schlecht komprimieren.

Beim „nginx“-Webserver kann man die minimale zu bearbeitende Dateigröße angeben, sodass eine 6 Byte große Datei mit dem Inhalt „foobar“ bei schwacher „gzip“ nicht auf 40 Byte vergrößert wird.

gzip_small_file

4.) „gzip“, ABER nicht so hoch

Zudem sollte man nicht mit der höchsten Komprimierungsstufe komprimieren, da man pro Komprimierungsstufe immer weniger Erfolg bei immer mehr CPU-Zeit bekommt. Man sollte weniger stark komprimieren und dadurch Rechenleistung /-zeit einsparen, um die Webseite schneller ausliefern zu können.

gzip_level

test2_1.js.gz (schwache Komprimierung)
test2_2.js.gz (normale Komprimierung)
test2_3.js.gz (starke Komprimierung)

5.) „gzip“ + Minifizierung

Durch Minifizierung von CSS und JS kann man die Dateigröße ebenfalls reduzieren, auch wenn man nicht an die Dateigröße von komprimierten Dateien herankommt, außerdem sinkt der Erfolg der Komprimierung, da wir durch die Minifizierung bereits einige Wiederholungen minimiert haben.

Es folgt ein Beispiel mit „jquery.js / jquery.min.js“:

Zustand

Größe der Datei

gewonnene Größe durch die Komprimierung

nicht minifiziert + nicht komprimiert Datei

250 kB (¼ MB)

nicht minifiziert + schnelle Komprimierung

76,3 kB

173,7 kB

nicht minifiziert + normale Komprimierung

68,3 kB

181,7 kB

nicht minifiziert + hohe Komprimierung

68 kB

182 kB

minifiziert + nicht komprimiert Datei

82,3 kB

minifiziert + schnelle Komprimierung

30,8 kB

51,5 kB

6.) „gzip“ + Komprimierung verbessern

Im Gegensatz zur Programmierung, wo man Wiederholungen vermeidet, sollte man im Frontend (HTML, CSS) gezielt Wiederholungen nutzen, um die Komprimierung zu optimieren. So zeigt  das folgende Beispiel wie man die Dateigröße durch die korrekte Positionierung von Attributen der HTML-Tags verbessern kann.

Zwei Dateien mit dem selben Dateigröße, nur die Reihenfolge der Attribute in der zweiten HTML-Dateien („test1_2.html“) wurden nicht in der selben Reihenfolge angegeben.

html_order_3
test1_1.html
html_order_2
test1_2.html

html_order

Wie man in dem Bild erkennen kann, haben wir die Dateigröße der HTML-Datei um zirka 10% reduziert indem wir den Komprimierungsalgorithmus  bei der Arbeit unterstützen. ;)

Videos:

 

ShellShock – Sicherheitsproblem bei der Unix-Shell $(bash)

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

Technische Erklärung:

(http://seclists.org/oss-sec/2014/q3/650)
Das Problem ist, dass das man zwischen unterschiedlichen Bash-Instanzen Variablen und Funktionen teilen kann.

export foo='() { echo "bar" ; }'
bash -c 'foo'

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.

Links:

http://www.heise.de/newsticker/meldung/Bash-Luecke-ShellShock-ist-noch-nicht-ausgestanden-2403607.html

http://www.heise.de/newsticker/meldung/ShellShock-Standard-Unix-Shell-Bash-erlaubt-das-Ausfuehren-von-Schadcode-2403305.html

http://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-025

 

V-Server Problem bei Strato

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.

– Server-„Load“: > 10
– CPU-Auslastung : ~ 0%
– I/O-Auslastung: ~ 0%

——————————————

Reaktionszeit: 1/2 Min. für den SSH-Login  :-(

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

 

server_vmstat

server_iotop

server_top

 

Falls jemand ebenfalls Performance-Probleme mit seinem Linux-Server hat, sollte man sich einmal folgenden aktualisierten Blog-Post anschauen:

-> Server-Analyse: http://suckup.de/linux/linux-server-analysieren/

 

UPDATE: 02.07.2014 15:59

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.

 

Multi-Platform Mobile Apps via Ionic

Ionic ist ein Frontend-Framework, mit welchem man via HTML5 / JavaScript und CSS native Apps bauen kann. Diese Apps können via „Apache Cordova“ auf native Funktionen (Kamera, GPS, etc.) der Geräte zugreifen. Zudem wird Google’s JavaScript Framework „AnguarJS“ genutzt und natürlich wird auch „SASS“ unterstützt.

Vorbereitung

Man kann Multi-Platform Mobile Apps sowohl unter Windows, Linux oder Mac OS X entwickeln, jedoch ist die Vorbereitung unter Linux / Mac OS X um einiges einfacher.

Ich empfehle an dieser Stelle mal wieder die „.dotfiles“ zu installieren.

cd ~ 
git clone https://github.com/voku/dotfiles.git 
cd dotfiles 
source bootstrap.sh

# Standard- & Webworker-Tools installieren

~/dotfiles/firstInstall.sh

Bei der Frage nach den „webworker tools“,  muss diese mit „y“ beantwortet werden.

# Android SDK installieren

sudo ~/dotfiles/android_sdk_install.sh

# Java installieren

sudo add-apt-repository -y ppa:webupd8team/java
sudo aptitude update
sudo aptitude install oracle-java7-installer

# Ant installieren

sudo apt-get install ant

 

Nachdem die Installation komplett abgeschlossen ist, muss die „~/.extra“-Datei angepasst werden.

z.B.:

#!/bin/bash                                                                                                                                                                                                       

DEFAULT_USER="lars"
GIT_AUTHOR_NAME="Lars Moelleken"
GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME"
git config --global user.name "$GIT_AUTHOR_NAME"
GIT_AUTHOR_EMAIL="lars@moelleken.org"
GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"
git config --global user.email "$GIT_AUTHOR_EMAIL"
git config --global push.default simple

# java - example
export JAVA_HOME=/usr/lib/jvm/java-7-oracle
export JDK_HOME=$JAVA_HOME
export JRE_HOME=$JAVA_HOME
export PATH=$JAVA_HOME/bin:$PATH

# android - example
export ANDROID_SDK_ROOT=/usr/local/android-sdk/
#export ANDROID_NDK=/usr/local/android-ndk/
export ANDROID_HOME=$ANDROID_SDK_ROOT
export PATH=$ANDROID_SDK_ROOT/tools/:$ANDROID_SDK_ROOT/platform-tools/:$ANDROID_SDK_ROOT/build-tools/19.1.0/:$PATH

 

PS: bei Debian (sid) musste ich noch ein wenig nachhelfen, so dass die Android-SDK auch korrekt funktioniert:

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install lib32z1 lib32stdc++6

 

Beispiel-App für Android erstellen

ionic start planet-ubuntuusers
cd planet-ubuntuusers
rm -rf www/
git clone https://github.com/voku/planet-ubuntuusers-app www
ionic platform android
ionic build android

Man kann die App nun im Browser (ionic serve), im Android Emulator (ionic emulate android) oder direkt auf seinem Android-Gerät (ionic run android) ausprobieren!!!

 

Links

Es folgen ein paar Links zur App / API / Dokumentation  und zum Beispiel-Quellcode

ANDOIRD APP-DOWNLOAD:
 http://suckup.de/planet-ubuntuusers-json/PlanetApp-debug.apk

QUELLCODE ZUR APP:
https://github.com/voku/planet-ubuntuusers-app

SCREENSHOT:
Planet App

JSON-API: 
http://suckup.de/planet-ubuntuusers-json/json.php

HTML-OUTPUT VIA TWIG:
http://suckup.de/planet-ubuntuusers-json/

QUELLCODE ZUR API:
https://github.com/voku/planet-ubuntuusers-json (in zirka 2 Minuten geschrieben & deployed -> composer is great!!!)

 

DOKUMENTATION:
https://docs.angularjs.org/
http://ionicframework.com/docs/
http://cordova.apache.org/

Kurztipp: lokalen offenen Port finden (bash)

Habe soeben folgende Funktionen zu meinen dotfiles hinzugefügt, um einen freien lokalen Port zu finden. Diese werden wiederum verwendet, um z.B. die „phpserver„-Funktion auszuführen.

# -------------------------------------------------------------------
# netstat_used_local_ports: get used tcp-ports
netstat_used_local_ports()
{
  netstat -atn | awk '{printf "%s\n%s\n", $4, $4}' | grep -oE '[0-9]*$' | sort -n | uniq
}

# -------------------------------------------------------------------
# netstat_free_local_port: get one free tcp-port
netstat_free_local_port()
{
  read lowerPort upperPort < /proc/sys/net/ipv4/ip_local_port_range
 
  # create a local array of used ports 
  local all_used_ports=($(netstat_used_local_ports))

  for port in $(seq $lowerPort $upperPort); do
    for used_port in "${all_used_ports[@]}"; do
      if [ $used_port -eq $port ]; then
        continue
      else
        echo $port
        return 0
      fi
    done
  done 
}

 

Web Development mit Linux (Video)

Im folgenden Video zeige ich kurz (~ 5 min.) wie meine Toolchain im Live-Betrieb aussieht, dabei nutze ich unter anderem Sublime Text, PHP, Twig, Grunt, Sass, Compass, LiveReload und ein paar Funktionen aus den „dofiles“ (z.B. phpserver).

 

Wer den Beispiel-Code aus dem Video selber ausprobieren möchte, hier die Zusammenfassung:

sudo apt-get install git

cd ~
git clone https://github.com/voku/dotfiles/
cd dotfiles/
./firstInstall.sh
./bootstrap.sh
cd ~
vim ~/.extra #1

cd ~
mkdir Projects/
git clone https://github.com/voku/twig-wrapper-example/
cd twig-wrapper-example/
npm install
grunt watch

cd ~/Projects/twig-wrapper-example/
phpserver

#1 füge deine persönlichen Git-Einstellungen hier hinzu

 

Wer mehr Infos oder Erklärungen zu den hier verwendeten Tools haben möchte, sollte sich einmal folgende Videos anschauen: suckup.de/howto/html/moderner-build-development-workflow-via-bower-grunt-yeoman/