Mein Tool Empfehlung für Kollaboration und Kommunikation in der Softwareentwicklung

1. Pair Programming
1. Git
2. Junit
3. Videokonferenz
1. Jitsi
2. Appear
3. Slack
2. Andere Kollaboration
1. Whiteboard: https://awwapp.com/
2. Wiki: Confluence
3. Kollaborativer Editor: http://meetingwords.com
4. Terminfindung: Kalenderly
5. Abstimmung: 
3. SCRUM 
1. JIRA
2. Schätzen: Pointing Poker https://www.pointingpoker.com
3. Retro: Retrium

Universelles Apple Zubehör seit fast 30 Jahren

Es gibt ein Werkzeug oder Hilfsmittel das ich seit fast 30 Jahren für meine Apple Geräte brauche.

Früher habe ich damit 3,5' Disketten aus meinem Mac befreit, heute säubere ich damit die Ladebuchse von meinem iPhone, damit ich es laden kann. Ich bin schon darauf gespannt, wann Apple dieses universelle Tool selbst vermarktet - wie wäre es mit iClip X oder MacClip Pro - Karl Klammer wäre sicher stolz.

Prüfen von Java Libs auf bekannte Verwundbarkeiten

Es gibt ein gutes Tool mit dem man Java Libs auf bekannte OWASP Schwachstellen prüfen kann. Dieses Toll gib es als Plugins für diverse Build-Werkzeuge. Man kann es aber auch Out-Of-The-Box nutzen:

Installation:
brew install dependency-check

Für Grade gibt es ein Plugin, wenn man dieses nich nutzen möchte kann man alle Dependencies herunterladen, mit folgenden Grade Task:
task getDeps(type: Copy) {
   from sourceSets.main.runtimeClasspath
   into 'runtimeX/'
}


Ausführen und Erzeugen eines Report mit gefundenen Verwundbarkeiten
dependency-check --project haupt --scan runtimeX/ --suppression config/dependencyCheck/suppressions.xml --suppression config/dependencyCheck/suppressNetty.xml


In dem Report findet man gelegentlich False-Positive Warnungen, diese kann man mit Hilfe der Saupression-Dateien unterdrücken.


Link:

1. https://www.owasp.org/index.php/OWASP_Dependency_Check

Prüfen von JavaScript Libs auf bekannte Verwundbarkeiten

OWASP ist hoffentlich für viele Entwickler eine bekannte Quelle, wenn es um Sicherheit von Software geht.
Mit Hilfe des Programms retire kann man seine JavaScript Libs auf OWASP bekannt Verwundbarkeiten prüfen:

Installation von retire via Yarn:
yarn global add retire

Prüfen auf JS Verwundbarkeiten:
retire -v --js --jspath myProject

Die Option -v sollt man möglichst mitgegeben, um zu sehen, das retire funktioniert bzw. der angegebene Pfad OK ist.

1. Ursächliche JavaScript Library identifizieren und CVE-Vulnerabily verstehen
2. Version der JavaScript Library anpassen
3. Library in der Datei _.retireignore_ gegebenenfalls aufnehmen

Natürlich sollte man diesen C heck natürlich regelmässig wiederholen.

Postgresql Zombie Prozesse finden und beenden

Zombie gibt es überall, auch in Form von Queries in Datenbanken wie hier der Postgresql DB. Diese Zombies können auf unterschiedliche Weise entstehen, z.B. wenn eine Javaanwendung eine Query mach und in eine Excption gerät und dann die Ressourcen, d.h. hier die DB Query aufräumen. Die DB wartet dann ewig, dass die Java Applikation sich das Ergebnis der Query abholt, vergebens.

Mit der folgenden SQl Query kann man Zombies finden, hier Queries die älter als 30 Minuten sind.

select pid, age(query_start, clock_timestamp()), usename, query 

FROM pg_stat_activity 

WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'

AND query_start < NOW() - INTERVAL '30 minute'

Anschliessend kann man sie beenden:

select pg_terminate_backend(pid)

Einige nützliche Links

1. https://gist.github.com/rgreenjr/3637525
2. https://stackoverflow.com/questions/35319597/how-to-stop-kill-a-query-in-postgresql
3. https://jobs.zalando.com/tech/blog/hack-to-terminate-tcp-conn-postgres/?gh_src=4n3gxh1
4. 
   

Nerd Kram: Happy #PiDay

Mit leichter Verspätung.

Warum ich keine mehr Konfigurationsdatei brauche.

In der heutigen Softwareentwicklung, also ich meine Java, Docker und die Cloud, brauche ich keine Konfigurationsdateien mehr. Warum? Ganz einfach, eine Konfigurationsdatei ermöglicht es, das Setup von Programmen an die eigenen Bedürfnisse anzupassen und die Software neu zu starten. So machen es viele Programme wie der Apache Server oder Postgres. Hier machen Konfigurationsdateien Sinn.

Wenn ich mich im Cloud Umfeld bewege und individuelle Wegwerf-Software mit Docker erstelle und deploye, dann gibt es diesen Anwendungsfall nicht mehr, dass ich ein Konfiguration anpasse und dann die Software neu starte.

Im der Welt von Docker, Cloud und Continuoude Deployments kann ich die Konfiguration im Code ändern, ins GIT einchecken und warten bis meine Continuouse Deployment Pipeline mir nach wenigen Minuten eine neue Softwareversion ausgerollt hat. Fertig, jetzt brauch ich eine Properties oder YAML Dateien mehr. Das ist für Softwareentwickler einfacher als sich via VPN auf Hosts, und dann auf Docker Container anzumelden und Änderungen an der Konfiguration durchzuführen. In den letzen Jahren in denen ich mich in diesem Umfeld bewege ist mir dieser Fall nicht vorgekommen.

Aber, Secrets wie Access-Keys, Passwörter oder Benutzernamen gehören natürlich nicht so plain in den Code und auch nicht ins GIT. Solche geheimen Daten kann man dann ggf. in verschlüsselten Konfigurationsdateien speichern.