Dienstag, Februar 24, 2015

Salted Password Hashing - Doing it Right

Der Artikel crackstation.net/hashing-security.htm fasst aus meiner Sicht schön zusammen, wie man Passwort-Hashing richtig machen sollte. Es wird auch genauer beschrieben, warum einzelne Details wichtig sind, und was typische Fehler. Code-Beispiele für verschiedene Programmiersprachen gibt's auch

Mittwoch, Februar 18, 2015

Heise: Use cases 2.0 und Agile Projekte

Bei heise ist in lesenswerter Artikel, wie man die 'klassischen' Use Cases mit einem agilen Projekt-Vorgehen vereinen kann. Use Cases bieten (gerade in größeren Projekten) viele Vorteile gegenüber den z.B. im SCRUM-Umfeld eingesetzte 'User Stories'.

Use Cases decken deutlich bessser das Gesamt-Bild aller Anforderungen ab, bei einem agilen Vorgehen kann man leicht den Gesamt-Überblick verlieren.

Das bei heise beschriebene Konzept von 'Use Cases 2.0' bringt beide Welten zusammen. Über die klassischen Use Cases können alle Anfordeurngen für das Gesamt-System erfasst und bewertet werden. Eine Aufteilung der einzelnen Use Cases in 'Slices' ermöglicht es, Teile der Use Cases in einzelnen Sprints umzusetzen.

Dienstag, Februar 03, 2015

Firefox und PDF-Viewer

Seit einiger Zeit nutzt der Firefox seinen eigenen Viewer, um PDF-Dokumente anzuzeigen. Meistens ist das OK, aber ab und zu stößt das auf Probleme, vor allem bei komplexeren PDF-Dokumenten, die z.B. die Formular-Funktionen nutzen.

Wir müssen gerade in einem Projekt programmatisch auf dem Server regeln können, ob PDF-Dokumente inline im Firefox-Viewer angezeigt werden, oder als PDF-Download angeboten werden (und dann im Adobe Reader geöffnet werden). Mit ein bisschen Googlen und Ausprobieren habe ich eine Lösung über spezielle HTTP-Header-Felder "Content-Disposition" im Response gefunden.


Um PDF-Dowmloads im internen Viewer anzuzeigen, muss als Wert 'inline' übergeben werden;

Content-Disposition: inline; filename="name.pdf"

Um den internen Viewer zu umgehen, kann man stattdessen 'attachement' verwwnden
Content-Disposition: attachment; filename="name.pdf"

Donnerstag, Januar 15, 2015

Freitag, Januar 09, 2015

30 Open-Source-Tools, die ein Entwickler 2015 braucht

Noch liegt der Jahreswechsel nicht allzu weit hinter und, so dass der Artikel bei blogs.perceptionsystem.com/30-open-source-tools-programmers-2015/ noch passt: in der Übersicht sind die Tools zusammengestellt, die ein Entwickler heute kennen (und nutzen) sollte. Sicher wird nicht jeder Entwickler alle 30 Tools einsetzen, zumal die Liste eher frontend-lastig ist und sich stark um Browser-Tools und Visualisierungs-Frameworks dreht.

Aber in der Liste sind auch einige alt-bekannte Tools wie Audacity, Wireshark, Web Developer Toolbar und Apache Webserver, die ich selber schon seit langem einsetze.

Donnerstag, Januar 08, 2015

Wieviel Farbe ist es?

Lustige Idee: hierwird die Uhrzeit als Farb-Code für den Bildschirm-Hintergrund verwendet. Dann braucht man nicht mehr zu fragen "Wieviel Uhr ist es?"

Mittwoch, Januar 07, 2015

CW: 20 Tools für mehr Sicherheit am PC

In der Computerwoche ist eine nette Übersicht von Sicherheits-Tools, die man zusätzlich zu einem Virenscanner brauchen kann.

Den ganzen Tag geht mir diese blöde Witz nicht aus dem Kopf

Two password hashes were walking down the street.
And one was a salted ... password hash

Mittwoch, Dezember 31, 2014

SSL-Tests

Immer wieder hilfreich: wenn man prüfen will, ob das eingesetzte SSL-Zertifikat für einen Auftritt OK ist, kann man die folgende Web-Tools nutzen:

Dienstag, Dezember 30, 2014

Karriere-Entscheidungen, die man nach 20 Jahren bereut

Aufgrung der gerade etwas 'hochkochenden' Unzufriedenheit einiger Kollegen fand ich diesen Artikel bei LinkedIn sehr interessant. Manchmal trifft man berufliche Enscheidungen, bei denen man (bei kurzem Nachdenken) eigentlich genau weiß, dass sie falsch sind. Und wenn man sich selber mal 20 Jahre weiter denkt. dann wird man die folgenden Karriere-Entscheidungen sicher bereuen:

  • Vortäuschen, jemand zu sein der man nicht ist
  • Karriere-Entscheidungen allein aufgrund des Geldes treffen
  • Annehmen, man kann im Job etwas grundsätzlich Falsches ändern.
  • Sich mit dem zufrieden geben, was man hat
  • Überstunden
  • Zuückstellen von Freunden oder Familie zugunsten des Jobs
  • Versuchen alles zu kontrollieren
  • Keine Risiken eingehen aus Angst, eine falsche Entscheidung zu treffen
  • Nur an sich selbst denken
  • Das eigene 'Glücksgefühl' nicht bedenken

Sonntag, Dezember 21, 2014

Sortier-Algorithmen

Immer wieder nett anzusehen: Wer mal eine anschauliche Erklärung verschiedener Sortier-Algorithmen braucht:

algo-rythmics.ms.sapientia.ro/dance/

Freitag, Dezember 19, 2014

Zehn Punkte, die man als Entwickler können sollte, aber vermutlich nicht an der Uni gelernt hat


Ich bin cschon vor einiger Zeit über den folgenden Artikel gestolpert, finde ich eine ganz nette Zusammenfassung:
blog.newrelic.com/2014/06/03/10-secrets-learned-software-engineering-degree-probably-didnt/

  • Version control systems
  • How to write
  • Regular expressions
  • Using libraries
  • SQL
  • Tool usage: IDEs, editors, CLI tools
  • Debugging
  • Defensive programming
  • Teamwork
  • Working on existing code

Donnerstag, Dezember 18, 2014

Regressions-Tests auf CSS-Dateien

Ein hilfreicher Hinweis von unseren Frontend-Entwicklern: Immer wieder stosse ich in Projekten auf Probleme, weil Frontend-Entwickler Änderungen in CSS-Dateien vornehmen, die dann an anderen Stellen unerwartete Quereffekte haben.

In Java hat man solche Probleme seit langem viel besser im Griff (wenn denn die entsprechende Tool-Unterstützung auch im Projekt genutzt wird). Aber Methoden wie Compiler, Coding Standards, Tools zur statischen Code-Analyse, Unit Tests, usw. sind im CSS-Umfeld (übrigens genauso bei JavaScript) eher unbekanntes Neuland.

Grundsätzlich geht das aber auch besser. Auf den Seiten css-tricks.com/automatic-css-testing/ und css-tricks.com/automating-css-regression-testing/ ist zusammengestellt, was man denn so tun kann, um Tests für CSS-Dateien besser zu automatisieren.

Mittwoch, Dezember 17, 2014

Technische Schulden

Ich bin in der Wikipedia auf einen Artikel zum Konzept der "Technischen Schulden" gestossen. Damit werden (später entstehende) Kosten bezeichnet, die man aufgrund von schlechter technischer Umsetzung in Projekten aufnimmt.

Wie alle Schulden, zahlt man auch auch technische Schulden Zinsen. Und diese Zinsen werden höher, je länger man die Schulden nicht zurückzahlt

Einige der Beispiele aus der Wikipedia klingen erschreckend vertraut:

  • Hintanstellen technischer und fachlicher Softwaredokumentation
  • Fehlende technische Infrastruktur wie Versionsverwaltung, Datensicherung, Build-Tools, Kontinuierliche Integration
  • Hintanstellen, Verzicht oder ungenügende Umsetzung automatisierter Modultests und Regressionstests
  • Fehlende Coding Standards und Code Ownership
  • Missachtung von TODO oder FIXME oder XXX Hinweisen im Code
  • Missachtung von Codewiederholungen und anderen Code Smells
  • Verwendung von Programmierungs-Anti-Pattern
  • Missachtung von Compilerwarnings und Ergebnissen statischer Code-Analyse
  • Hintanstellen der Korrektur von zu großem oder zu komplexen Code und Design
  • Fehlerhafte Definition oder Umsetzung der Architektur durch enge Kopplung, zyklische Abhängigkeiten der Komponenten oder das Fehlen geeigneter Schnittstellen und Fassaden

Wieder da...

Nachdem ich diesen Blog lange habe schleifen lassen, habe ich mich dazu durchgerungen wieder mal etwas zu posten. Wasser Marsch!