Recently I tried to visualize the current state of a circuit breaker in Grafana as a Stat. The monitored system is based on Spring Boot and resilience4j while gathering metrics using Micrometer and InfluxDB.
When trying to visualize all states in a single Stat I first only get a single Stat per circuit breaker state. Combining all to a single Stat wasn’t as easy as I expected.
Read more
Using the Spring Boot Devtools can help to increase your development speed. Simply put the corresponding Spring Boot Starter into your application’s dependency tree and voilà—restart, reload, development-optimised settings, … (obviously I’m still in the “wow-that-is-sooooo-amazing”-phase and haven’t had any issues with the devtools so far. Which explains my enthusiasm.).
Nonetheless, including the Spring Boot Devtools in your application will also start a LiveReload-Server:
The
spring-boot-devtoolsmodule includes an embedded LiveReload server that can be used to trigger a browser refresh when a resource is changed. LiveReload browser extensions are freely available for Chrome, Firefox and Safari from livereload.com.(Taken from https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using-boot-devtools-livereload
And that’s where the fun begins: most of the plugins are outdated; don’t connect to a LiveReload-Server, but rather simply refreshe the current tab in a given interval; or aren’t that popular (in downloads/likes/whatever) that I would want them to be running in my browser.
But there is another solution: a little JavaScript (livereload-js) which could be included in your HTML. This little script connects to a LiveReload-Server and reloads the current page whenever the server tells it to.
I recently evaluated whether to use memcached-session-manager [1] for one of our webapps. Although memcached-session-manager bases on spymemcached [2] for communicating with memcached, I was surprised that it uses a significant different algorithm for selecting a memcached instance (out of a pool of given memcached instances) than the native implementation of spymemcached.
Spymemcached selects the instance by calculating a hash of the element’s key and using that hash to determine the instance. Simplified this could be done by compute:
server = serverlist[hash(key)%serverlist.length]
To distribute the elements uniformly on all nodes often Consistent Hashing [3], e.g. KETAMA, is used as hash function. See [4] for details.
In contrast to that, memcached-session-manager doesn’t use hashing at all – it simply “selects the memcached node randomly” [5] (excluding failover nodes). After that the node id is encoded in the session id like 72d9ffcb00d836b3248d8bd95ce2e641-n1.tomcat1 (“n1”). All further accesses are selected by this value.
On my last code review session I stumbled over that lovely piece of code:
Boolean wrapper = foo();
boolean primitive = Boolean.parseBoolean(""+wrapper);
A somehow interesting way of converting a Boolean to it’s primitive.
I guess this was done to avoid a NullPointerException in case wrapper is null. But it violates one simple rule: write readable code.
Of course, this line isn’t hard to understand—but do you know for sure the outcome of the parseBoolean-method when the argument is null or an empty String? Is it ‘false’, ‘true’ or will the method throw an exception? To make it even worse: “”+wrapper will return the String “null” (yep – a String of length 4) when wrapper is null. Can parseBoolean handle this too?
So how to (really) avoid a NullPointer here? Simply use:
Boolean wrapper = foo(); boolean primitive = wrapper == null ? false : wrapper.booleanValue();
or (cooler but a little less readable):
Boolean wrapper = foo(); boolean primitive = wrapper != null && wrapper.booleanValue();
On the attempt to update VisualSVN on my Windows XP I struggled with the following exception quite a long time:
Custom action UninstallWMISchemaExecute failed: Diese Datei ist keine gültige MOF-Datei. (0x8004401e)
UninstallWMISchemaExecute when updating VisualSVN
I was never faced with WMI before so I started from scratch and choosed to try’n’error. A great help was the artikel found in [1] and after a while I succeeded—but: I still have no clue why my solution worked, nor could I assure that it is side-effect-free. So use on your own risk!
sc config winmgmt start= disabled (make sure there is a blank between 'start' and 'disabled')
net stop winmgmt
cd C:\WINDOWS\System32\wbem rename Repository Repository-old
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM
was an entry which recreated the faulty *.mof all over again.
sc config winmgmt start= auto