Color blindness

Ishihara test, a color perception test
for red-green deficiencies

Recently I was tasked with redesigning a report in a way that would make it friendlier for people who can't tell apart red and green. The report provides information in a tabular format, using colors to provide visual cues about the data.
For the rest of us, all colors are made of 3 components - red, green and blue. Microsoft's page on color blindness shows how other colors are composed from the three. It also goes to show how different colors will be perceived by people with color deficiencies.
In order to adapt the existing web page, while preserving the user experience of existing users, I'm going to tweak the colors used.

There are some resources available on the web to aid in the task:

• Choosing safe colors - this page provides a sample selection of 10 distinguishable colors, together with a hint how they could be perceived by people with color deficiencies
• Websafe colors  for color-blind people - this page lists a set of colors, and also links to Color Oracle, an open-source color blindness simulator
• A nice theoretical background is provided on Designing For, and As, a Color-Blind Person

And finally, there's always the option of using other cues (instead of or together with color) to denote some properties of the displayed information.

ElasticSearch result merging

I was curious how ElasticSearch handles merging multiple result sets (one from each shard) into a single sorted response. In my last post I went over a few methods of merging multiple sorted streams. Then I went to search how ES handles this.
I assumed that ES uses a priority queue. Searching for PriorityQueue in Elasticsearch resulted in a bug report containing interesting stack trace.
It appears that SearchPhaseController.sortDocs is the method responsible for merging results.
In current version the sortDocs method uses Lucene's TopDocs.merge to do the sorting. The merge method uses priority queue containing one record for every input stream, removing and adding streams for every output record.
Quick look at the PriorityQueue implementation reveals updateTop method; this method's JavaDocs claim it to be "at least twice as fast" compared to removing & adding.
Modifying the method to use updateTop instead of pop/add was a rather trivial exercise. The new version is not twice as fast as the old one; the speed gains were on the order of 20-80%, depending on the input provided.
The patch was accepted, so next ElasticSearch's release is likely to contain the improved version.