Good Java Fish

It's been a few tough years. A new job. A new role. Trying thing I never did before. Doing infrastructure as code. Going reactive. Giving talks at major conferences. Time to take a short break, breath in, breath out and try to summarize the experience. Stay tuned.

I just realized why what I don't like about Spring Framework. Don't get me wrong. I love Spring Framework. I use it daily. In fact, I am a huge fan of it. But there is a constant "something is wrong" buzz in the corner of my mind. And I finally caught it. The name is Obscurity Yes, all the Spring annotation fairy dust magic just works. It is great. It removes boilerplate code. It is supposed to make your code easier to read and maintain. And it does - to a point when it doesn't. A simple example: @Scheduled(fixedDelayString="${execution.delay_ms}") public void scheduledJob(){ // your code goes here } Easy, right? A few lines of code, a configurable property to define a delay between runs, what can be more simple? A few questions: How do you know what threadpool this scheduled job used? How do you to configure the threadpool? How do you test the scheduling part of your code? Ouch, painful!

Goal : To determine the most efficient way to perform high-volume sampling. Set-up : The sampler's goal is to give permission to sample use a given sampling rate; (approximately) each 1000th request should result in actual sampling. There are several samplers: AtomicSampler: uses AtomicInteger to keep track of sampling attempts;  RandomSampler: uses an instance-wide Random instance to determine if a sample should be taken.  RandomSampler2: uses a local Random instance to determine if a sample should be taken, which is initialized each time.  XorShiftSampler: uses a XOR-Shift algorithm to produce psedo-random numbers ( http://www.javamex.com/tutorials/random_numbers/xorshift.shtml )  Before actual measurement each sampler is called 50K times to warm it up and give a hot-spot compiler a chance to compile the samplers' bytecode into a native high-performance code. Then 10 runs are performed, using a variety of scenarios. 10M sampling attempts are performed during each

A while ago I mentioned the possible need of brushing up our multi-threading skills. Having said that, I cannot but share the post I came across a few years ago in the RSDN.ru forum . Disclaimer: I am not the author of the original post, I merely translated it, hoping its content can be useful. Lately, many Java Developer job openings started to include Java concurrency/multi-threading as one of the requirements. As a response, many developers immediately added the corresponding line to their resumes. Being the one who runs interviews, I'd like to dispel some of the misunderstanding that is related to the term. I'd like to split all multi-threading-related projects into 3 levels: the ones that use multi-threading; the ones that are based upon multi-threading and the ones which are multi-threading itself. The first level ("the ones that use") includes projects that are meant to run in the multi-threaded enviroment. E.g., there is BlahBlahFactory class and you n

Herb Sutter has a great, albeit lengthy article about future of computing .   Five years from now we want to be delivering apps that run well on an isolated device, and then just run faster or better when they are in WiFi range and have dynamic access to many more cores. The makers of our operating systems, runtimes, libraries, programming languages, and tools need to get us to a place where we can create compute-bound applications that run well in isolation on disconnected devices with 1,000-way local parallelism… and when the device is in WiFi range just run faster, handle much larger data sets, and/or light up with additional capabilities. I cannot but agree with him. We already feel the need to think in multi-threaded way even when we design trivial things. And we already cloud-bound - think iCloud, Gmail or any other of dozens of cloud services out there that we use daily. So maybe it is a time to brush up the multi-threading skills and/or get hands-on experience with

Not all of us like doing pair programming with junior developers. It can be hard to explain some concepts that are obvious to you, your short-term productivity can suffer, they can be too irritating with their stupid questions and so on. However, pair programming is one of the best ways to learn and teach and to spread knowledge among team members. After all, if you have to rely on that junior (or not-so-junior) developer, you want him to be as smart and competent as possible, don't you? Here is a couple of tricks that help me make the process more efficient and less painful for me.