Faceted Search using Elasticsearch and WPF

Today i uploaded a quick sample on how to build faceted navigation for Elasticsearch in WPF which includes highlighting of search results. Below is a screenshot of the sample app. Enjoy!

Work tip: Disable Chrome history

If you are using Google Chrome at work you should probably disable storing history to avoid your intranet urls being synced out into the Google cloud. Here is how: How to Prevent Google Chrome From Storing Browser History. Chrome basically stores history and other data in a local SQLite database. The tip is a little bit of a hack: You first empty the database (clear history) and then prevent Chrome to modify it (by making it read-only).

When to use git-flow and GitHub Flow

Some people ask how good git-flow matches with the practice of continuous integration. In 2011, Scott Chacon from GitHub Inc. wrote a post on exactly that: GitHub Flow.

For the last few weeks we switched from git-flow to GitHub Flow - on GitHub as well as on our gitblit-Server (needs gitblit tickets, v1.4+).

Working both with GitHub Flow vs. git-flow taught us a lot. Well, the direct ticket integration alone is a big win compared to manually keeping commits and tickets consistent, i.e. basically pasting a lot of links in each of them. Apart of that, without surprise we came to the same conclusions as Scott Chacon, i.e.:

• For continuous deployment projects, github flow is way more effective because you can have dozens of commits each day going directly into production. The many branch transitions required in git-flow quickly become a bottleneck and lose their worth as quality gates. The similar holds for small projects or simple software components where git-flow is just too big a framework.


• For products with greater release cycles (weeks or months) git-flow makes sense. Example scenarios are concurring milestones (hotfix from production vs. feature for next version) or just bigger quality gates, i.e. a commit should not or can not be directly deployed to production.

Microsoft "Trill" (Predictive Analytics)

From the dotnetpro-Newsticker on 29.01.2015: Trill – eine Billion Events pro Tag:

"Microsoft Research entwickelt mit Trill eine .NET-Bibliothek, die es in sich hat: Sie verarbeitet große Datenmengen zwei- bis viermal schneller als gewöhnliche Streaming Engines..."

The paper: Trill: A High-Performance Incremental Query Processor for
Diverse Analytics

Fazit dev.talk - Docker

Yesterday, i gave an introductory talk about Docker. The bottom line: Unmittelbare Vorteile liegen weniger darin, eigene Produkte per Docker zu integrieren/installieren. Der unmittelbare Vorteil von Docker liegt oft eher darin, dass damit andere Lösungen viel leichter zugänglich sind.

Für Dependencies in Form von Bibliotheken haben ist das ja mit Dependency Managern wie Maven und NuGet schon gelöst. Das Einbinden von Fremd-Code ist damit keine Hürde mehr.
Die Integration und der Betrieb von externen Komponenten der Produkten (z.B. ElasticSearch, RabbitMQ, MongoDb, PostgreSQL, etc.) wird oft jedoch noch manuell durchgeführt, genauso wie früher das Einbinden anderer Bibliotheken.

Dass man das bisher manuell tut, macht sich auch zunächst im Einzelfall nicht wirklich bemerkbar. Beispiel ElasticSearch, nur Entwicklung: herunterladen, starten, fertig. Ist doch kein Aufwand. Wozu also Docker?

Vergrößert sich die Anzahl der Komponenten sieht das schon anders aus. Beispiel: RabbitMQ (river) + ElasticSearch + ...
Jede Komponente wird ein wenig anders bezogen, installiert und betrieben.

Berücksichtigt man jetzt nicht nur die Entwicklungsphase, sondern auch Integration/QS und Produktion wird schnell klar, dass der Aufwand über-linear, vielleicht sogar quadratisch von der Anzahl der verschalteten Komponenten/Produkte abhängt. Von der Zahl der verschiedenen Zielumgebungen ganz zu schweigen.

Das ist genau die wesentliche Aussage und Motivation der Matrix from hell. Durch die Vereinheitlichung mittels Container kann jede Komponente automatisiert bezogen, installiert, betrieben und deinstalliert werden. Und das immer gleich, egal ob Entwicklungsrechner, Integrationsanlage, Produktion oder vor Ort beim Kunden.

Damit reduziert Docker den o.a. Aufwand nahezu wieder auf O(1), zumindest was die teure menschliche Arbeit betrifft. In dieser Hinsicht bietet Docker also einen Mehrwert in Form einer Infrastruktur zum Betrieb von Komponenten/Produkten, vergleichbar mit der Infrastruktur durch Paketmanager zur Handhabung von Fremdbibliotheken.

Application Server sind tot!

Eberhard Wolff talks about The death of the application server. Recommended.

twitter/AnomalyDetection

Yesterday, Twitter published their R-Package for anomaly detection in big, time-related data on GitHub: Arun Kejariwal: Introducing practical and robust anomaly detection in a time series