Interesting that GOOG are still doing these big-bang releases — I guess crunching the data to come up with new weights/rules is a heavyweight, time-consuming process
Dublin Cycling Campaign’s survey results: estimated 20,000 bikes stolen per year in Dublin; only 1% of thefts results in a conviction
The Hospira drug pump vulnerabilities described here sound pretty horrific
+1 to ALL of this. We are doing exactly the same in Swrve and it has radically improved our release quality
Good explanation of this NLP tokenization/feature-extraction technique. Example result: “Jimi/B-PER Hendrix/I-PER played/O at/O Woodstock/B-LOC ./O”
Excellent deep dive into a production issue. Root causes: crappy error handling code in Zookeeper; lack of bounds checking in ZK; and a nasty kernel bug.
This honestly fits a narrow niche, but one that is gaining in popularity. If your messages take > 100?s to process, or your worker threads are consistently saturated, the standard ThreadPoolExecutor is likely perfectly adequate for your needs. If, on the other hand, you’re able to engineer your system to operate with one application thread per physical core you are probably better off looking at an approach like the LMAX Disruptor. However, if you fall in the crack in between these two scenarios, or are seeing a significant portion of time spent in futex calls and need a drop in ExecutorService to take the edge off, the injector may well be worth a look.
Links for 2015-05-08
permalink. Both comments and trackbacks are currently closed.. Bookmark the