Auch dieser Tag geht vorbei.
Zwei Programme machen die Dokumentationen unterschiedlichster Projekte offline verfügbar und durchsuchbar: Dash und Zeal.
Zeal orientiert sich dabei an Dash und bedient die Windows- und Linux-Welt (Lizenz GPL v3, Source auf Github).
Dash hingegen ist für MAC OS und iOS verfügbar, erlaubt den kostenlosen Test, fordert aber gelegentlich zum Kauf einer Lizenz auf.
Es gibt eine Reihe Integrationsmöglichkeiten in IDEs und diverse Tools zur Steigerung der Produktivität.
Definitiv einen Blick wert!
Streisand sets up a new server running L2TP/IPsec, OpenConnect, OpenSSH, OpenVPN, Shadowsocks, sslh, Stunnel, and a Tor bridge. It also generates custom configuration instructions for all of these services. At the end of the run you are given an HTML file with instructions that can be shared with friends, family members, and fellow activists.
Ein sehr lehrreiches und cooles Repository. Der Server wird komplett mit Ansible aufgesetzt, nach 10-15 Minuten ist die Arbeit erledigt und das System provisioniert.
Hast Du z.B. einen Account bei Digitalocean musst Du nur im Bereich „API“ einen Key erzeugen und diesen zum Start des Streisand-Scripts angeben. Am Ende steht in einem lokalen Verzeichnis die generierte Dokumentation bereit.
Ich bewundere das Toyota-Produktionssystem (TPS), ein in Jahrzehnten aus Beobachtung und Handeln gewachsenes Set an Konzepten, Kernbestandteil des 2001 beschriebenen Toyota-Wegs.
Die Fülle an Ideen, Konzepten und Prinzipien fordern geradezu dazu auf, sie auch auf andere Bereiche zu übertragen, weg von der Automobilbranche. Kein Wunder, dass beispielsweise in der Software-Entwicklung viele Gemeinsamkeiten zwischen der Lean production und den Agile methods bestehen (Kundenfokus, kontinuierliche Verbesserung, Qualität usw.).
Der Eintrag Lean software development (LSD) gibt erste Hinweise und weiterführende Links.
Heute mit jemand telefoniert, der seine Geschäftsidee tatsächlich mit einem Minimum-viable-product – Ansatz testet, wie er mir kurz darauf (online) demonstrieren konnte.
In product development, the minimum viable product (MVP) is a product with just enough features to gather validated learning about the product and its continued development. Gathering insights from an MVP is often less expensive than developing a product with more features, which increase costs and risk if the product fails, for example, due to incorrect assumptions.
Just enough features um zu prüfen, ob die Idee tragfähig ist. Just enough features um sich potentielle Partner für die weitere Entwicklung auszuwählen, Leute anzusprechen; demonstrieren zu können, dass man es ernst meint.
Ein Ansatz, der so vielen Projekten helfen würde, schneller ans Ziel zu kommen. Noch bevor die ganze Maschine anrollt und sei diese noch so agil. Stattdessen sind gefühlt 90% aller Projekte kurz nach Projektstart in der Perfektionsfalle gefangen, trotz bester Vorsätze.
Deshalb habe ich mir auch verkniffen, die Geschäftsidee vorab zu kritisieren: Der Prototyp steht, der Aufwand war gering, das erste Feedback aka. Realitätscheck kann kommen. Dann sehen wir weiter.
Tomorrows legacy systems are going to be microservices.
Das Zitat ist willkürlich aus dem Vortrag genommen und ohne Kontext, aber ich find’s lustig.
Dem „Temporal Coupling“, so wie Adam Tornhill es im Vortrag verwendet, muss ich tatsächlich mal etwas Zeit widmen.
Wer nginx als Proxy verwendet, konfiguriert im Regelfall die Header, die an den Upstream weitergegeben werden, z.B. den Host-Header oder die IP-Adresse des eigentlichen Clients (und nicht von nginx selbst) als X-Real-IP oder X-Forwarded-For. Darüber hinaus ist es oft notwendig, Redirects des Upstream zu erkennen und auf einen anderen Host oder Port umzuschreiben, gleiches gilt für Cookies.
In seltenen Fällen muss man aber noch weiter gehen und nicht nur die Header, sondern den Response umschreiben, z.B. bestimmte im HTML enthaltene Strings (Formular-Ziele, Script- oder CSS-Links).
Dafür gibt es das ngx_http_sub_module:
location / {
sub_filter '<a href="http://127.0.0.1:8080/' '<a href="https://$host/';
sub_filter '<img src="http://127.0.0.1:8080/' '<img src="https://$host/';
sub_filter_once on;
}
Wenn die halbe Welt eine Information auf deiner Website will, dann reicht unter Umständen der kleine Shared-Hosting-Webserver oder der über DSL via externem DNS-Dienst angebundene Raspberry-Pie nicht mehr aus. Wenn zur Weihnachtszeit Millionen Menschen Fußwärmersocken beim großen Shop ordern, werden virtuelle Maschinen im Dutzend hochgefahren. Wie skaliert man sein Projekt? Wie macht man es hochverfügbar? Seiten wie z.B. highscalability.com geben einen guten Einblick über Konzepte und Lessons learned.
Doch es geht noch „granularer“ – ein interessantes Projekt hab ich jetzt in irgendeinem Newsletter erwähnt gefunden: stackshare.io. Es informiert darüber, welche Projekte welchen Software-Stack, also die Kombination aus Anwendungen, Tools, Utilities aber auch Strategien, einsetzen. Sehr interessant! Über alle Elemente kann abgestimmt und kurz begründet werden, was man daran besonders schätzt. Bei „Slack“ z.B. die einfache Integration, bei „Sentry“ die Konsolidierung ähnlicher Fehler, bei „nginx“ dessen Performance usw.
Aus den Daten und Angaben, die stackshare von Entwicklern und dem Feedback gewinnt, lassen sich interessante Einblicke gewinnen, siehe den Blog-Post „The Next Generation of Software Stacks“ (Slack, GitHub und Amazon EC2 als Hauptbestandteil des Software-Ökosystems). Zukünftige Software muss in hohem Maße Integrationsfähigkeiten zu anderer Software und Diensten aufweisen.
Ich glaube, die Seite werde ich noch öfter besuchen, dort gibt es noch viel zu entdecken.
Good night and good luck.
Ah, Codeception. Ein Projekt zum Testen von (PHP-)Anwendungen, Frameworks, APIs. Der Spruch „Write and execute a test for an existing app in less than 5 minutes“ stimmt tatsächlich.
Das PHAR Archiv ist schnell geladen, die Teststruktur mit codecept bootstrap gleich initialisiert und die Methodennamen für die Tests sind sofort verständlich.
Aus dem Quickstart-Beispiel:
$I->amOnPage('/'); ⇒ I am on page '/'
$I->click('Enter'); ⇒ I click 'Enter'
$I->see('Welcome'); ⇒ I see 'Welcome
Man kommt schon recht weit mit dem integrierten PHP-Browser, für komplexere Sachen mit Javascript-Erfordernis kann via Selenium Webdriver, PhantomJS u.a. eigentlich jede beliebige Konstellation getestet werden.
Ist das zu testende Projekt per BASIC-AUTH geschützt? Braucht es spezielle Cookies für den Zugriff? Muss z.B. in der Datenbank eine bestimmte Ausgangssituation wiederhergestellt werden? Kann alles in der via bootstrap angelegten Konfiguration hinterlegt werden. Natürlich können auch Screenshots gemacht werden, was im Fehlerfall sehr hilfreich ist.
Weil das Erstellen der Tests wirklich unkompliziert ist, sollte jeder, der es noch nicht kennt, unbedingt mal einen Blick drauf werfen.
Viele Blogs und Content-Management-Systeme sind ziemlich mit dem Apache-Webserver verheiratet, insbesondere machen sie reichlich Gebrauch von den verfügbaren Apache-Modulen (rewrite, setenvif, expires, auth_basic, deflate, unique_id uvm).
Eingebürgert hat sich, dass die Einstellungen in dezentrale Konfigurationsdateien geschrieben werden, bei Apache in der Voreinstellung als .htaccess definiert (veränderbar mit der AccessFileName-Direktive). Manche Plugins passen die .htaccess-Dateien sogar sehr häufig an, beispielsweise um IP-Adressen zu blockieren oder durchzulassen.
Der Aufbau der .htaccess-Datei ist dabei leicht verständlich, da von oben nach unten zu lesen. Eine kurze if-Abfrage ob das entsprechende Modul vorhanden ist, danach die spezifischen Anweisungen. Hin und wieder gibt es vielleicht Konfigurationsfehler mit unschönen HTTP-Statuscode-500 „Internal Server Error“ Meldungen, weil die AllowOverride-Direktive in der Hauptkonfigurationsdatei eine spezifische Einstellung nicht erlaubt – aber im großen und ganzen hat sich das Schema bewährt (wenn auch nicht unbedingt unter dem Gesichtspunkt der Performance).
Seit einiger Zeit wird nun der Webserver nginx immer beliebter und dieser kennt keine dezentralen zur Laufzeit gelesenen Konfigurationsdateien. Vor allem die CMS‘, die stark auf mod_rewrite setzen und eine Menge Umleitungsregeln definiert haben, können oft nicht so schnell migriert werden.
Für PHP-Anwendungen mit großer mod_rewrite-etc.-Abhängigkeit, die aber trotzdem gut performen sollen, habe ich ein Setup mit nginx + Microcaching + Request-Limits, Apache mit mod_event (statt prefork) + mod_proxy/fcgi + PHP-FPM ausprobiert. Da gibt es zahlreiche Stellschrauben für die Performance; Hauptvorteil ist, dass die Ressourcen explizit definiert sind und eigentlich kaum der Fall eintritt, dass die Maschine 100% Last erreicht. Allerdings bin ich zu Beginn gleich in eine Situation geraten, in der ein CMS nicht mit PHP 7 lauffähig war, die ältere (distributionseigene) PHP-Version aber noch nicht den fastcgi-Patch hatte, der die besondere Art der sprechenden Pfade des CMS erlaubt hätte. So ist das Leben.
Trotzdem: Der Mittelsmann, hier Apache mit mod_event, soll auch noch weg. Eher früher als später. Glücklicherweise beginnen mehr und mehr Projekte, Profile für nginx zu entwickeln. Manche Anweisungen in liebgewonnenen oder unbedingt notwendigen Plugins lassen sich mit geübtem Auge auch selbst umschreiben. Dass nicht mehr die Reihenfolge, sondern die Spezifität der Anweisung entscheidend für die Ausführung ist, kann durchaus in unüberschaubare Situationen führen. Gute Kommentare oder auch Tests können da Abhilfe schaffen.
Ich baue gerade ein kleines Ansible-Playbook, in dem Apache nicht mehr vorkommt und nginx via fastcgi direkt mit PHP-FPM kommuniziert. Neben der Performance auch ein Gewinn an Übersichtlichkeit und einem Prozess weniger, dessen Ressourcen man messen, schätzen und anpassen muss.
Vor ein paar Tagen hat mir ein Kollege diesen Link geslackt: Why Britain banned mobile apps.
“If you believe in the open internet that will always win” (Ben Terrett, former head of design at the UK Government Digital Service)
Statt den Schwerpunkt auf Apps zu setzen, verbunden mit hohen Kosten, ständigem Aktualisierungsdruck und dem Problem der Reichweite, setzt man auf Web-Apps und Responsive-Design.
Deshalb bin ich auch auf die Talks der Cross-Platform-Conference XPC 2016 gespannt (Keynote Christin Heilmann), hatte heute aber nur Zeit für die Keynote.
Dort hat Christian einen aktuellen Post „State of the gap“ von Remy Sharp erwähnt, der äußerst lesenswert ist. Was kann man mittlerweile mit den Browsern umsetzen, ohne eine Technologie wie Phonegap nutzen zu müssen? Es hat sich einiges getan, von der Abfrage des Ladezustands der Batterie über Nutzung der Kamera, App-Manifesten und der nativen Installation der Web-App auf dem Homescreen.
Einen Einstieg in die Thematik gibt die Projektseite zu den Progressive Web Apps auf developers.google.com.