It seems that „Building microservices“ finally made it to general availability. Actually, I’ve been following the book quite a while now, signed up (and bought the ebook version) pretty early during its early-access phase, and, finally, am pretty pleased with what the result looks like…
In one of our modules we make use of unirest client library for Java in order to access remote REST endpoints. As, right now, this involves quite some communication, we were looking into response caching which seems both an obvious idea and yet something that is defined pretty well in HTTP and, too, implemented pretty well in apache httpclient which lives at the core of unirest. And actually, even though
Last week, the Java part of our system went productive after a major runtime update – and it did so not on top of the Glassfish application server we’ve been using so far but rather re-structured into multiple modules embedding a current version of Eclipse Jetty. This is a fairly large change and quite a step, still sort of a work in progress and, after all, once again something worth
Stumbled across unirest last nite while ultimately feeling a bit unhappy with Java EE / JAX-RS frameworks. These folks in some way got my mind re-sorted a bit. I am still playing with this, yet there are a few things I already like about that one: It’s available. Same as some things I saw on Spark, Sinatra, Mojolicious earlier, it helps to see a REST client framework making an equal
Recently been into working with OSGi modules built on top of Apache Felix using the Eclipse bndtools. This ain’t fun all the time, but it works. However, I am then and now using visualvm for profiling and monitoring issues. With OSGi, at least the VisualVM profiler doesn’t work out of the box but instead causes a lot of fun just like this: java.lang.NoClassDefFoundError: org/netbeans/lib/profiler/server/ProfilerRuntimeCPUFullInstr at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Caused by:
Though I mostly use (server-sided) Java technology in my day-to-day work, I am then and now intrigued by Python as a straightforward, accessible scripting language which is easy to learn, easy to teach and immensely powerful in many situations. However, there are situations in which I just wished to have frameworks from the Java world available in Python… SOAP, to start with. Fortunately, Jython has been around for quite a
Deleted code doesn’t contain bugs, they say. I always felt kind of unsafe with the idea of actually and straightforward removing code while into refactoring smaller or larger parts of the systems – after all, same as it doesn’t contain bugs, deleted code also doesn’t contain business logic anymore which might not be what you want at times. Yet, trying to clean up parts of (the Java / Java EE
More than once, the last couple of weeks I repeatedly stumbled across situations in which I had to remember the infamous Law Of The Instrument in order to explain some peoples attitude towards technology and overall technological decisions. I am not sure if this „law“ holds completely true all the time, but I am sure there are some valid points to it.