Kategorie: Software-Development

Tag 225/2016: Offline Dokumentation

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!

Tag 216/2016: Streisand

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.

Tag 207/2016: TPS und LSD

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.

 

Tag 202/2016: Minimum viable product

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.

Tag 195/2016: nginx response filter

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;
}

Tag 181/2016: Projekt stackshare.io

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.

Tag 175/2016: Tests

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.