Working with MQTT protocol in Java usually means using Eclipse Paho FOSS library as a client (it’s even used by Spring for MQTT support in Spring Messaging).
Using Paho to send messages with Quality of Service (QoS) bigger than zero though might result in error/exception “Too many publishes in progress” in case many messages are sent in short period of time.
The straightforward fix to that is of-course not to use QoS other than zero, but there are other ways to remedy that problem.
There is an awesome UNIX/Linux utility called GPhoto2 (www.gphoto.org) that allows one to control DSLRs via USB. The amount of control is quite significant – one can make shots, download files and/or previews of photos, control aperture, exposure, ISO and many other settings that DSLRs expose (and even control focus servo, though with a bit of a hassle there).
The utility calls for a web interface – ever since I saw it I though how good would it be to control DSLR via WiFi from something like a Raspberry Pi (with battery) running GPhoto2. So I’ve started working a web interface for GPhoto2 – GPhoto2Server ( github.com/mvmn/gp2srv ), written in Java.
And now I’ve got first alpha version working. So I made a little video of it.
In order to get GPhoto2 on Raspberry Pi I’ve used this awesome project: github.com/gonzalo/gphoto2-updater.
And in order to make Raspberry Pi create own WiFi network I’ve used tutorial+distribs of hostapd from Adafruit: learn.adafruit.com/setting-up-a-raspberry-pi-as-a-wifi-access-point/overview.
I’ve been reading again today some articles that mentioned quines, and decided that I should try to write a quine myself – right away, without looking up any techniques for quine writing.
In around half an hour or so it was done. Checking Wikipedia subsequently revealed that I’ve used same approach as everyone else – put source code contents into string array, and take care to output it properly twice.
Here’s the code of my quine in case anyone’s interested. Continue reading
Recently I’ve discovered that there is a plethora of platform-specific utilities that can repeatedly capture region of the screen and then save the resulting images as an animated GIF. To me this sounds like a perfect task for JVM, since JVM includes support for screen capturing and creating animated GIF images, and all this comes with cross-platformness.
Thus I took the time to implement such utility. And here it is:
Executable JAR of first complete release can be downloaded here:
Let’s start with the demo right away!
(UPD: see demo on Raspberry Pi at the end of the post)
Here is the GIF that shows the utility in action. This gif was produced by second instance of the utility capturing the screen part where the demoed instance was displayed. Nice, huh? I ran screen capturing while I ran screen capturing so I could capture screen while I capture screen (-;
Eclipse WTP Tomcat and JBoss adapters have a certain bug that I’ve encountered recently, and due to conditions it occurred in it took almost a detective work to figure out.
I added a video below with all the details and a little demo – just for fun.
Long story short, the bug occurs on starting the server (be it Tomcat or JBoss) from Eclipse. When starting it Eclipse WTP Server Adapter starts a thread called PingThread that tries to connect to the server. If connection is OK, server is considered to be “Started”. Otherwise it’s shown as “Starting”, and if there’s a startup timeout configured, after the time of timeout passes server gets killed.
A couple of times in my life of java programmer I used a trick to put some code ending with “return false;” within Eclipse’s conditional breakpoints just for sake of having that code executed each time JVM goes over the breakpoint, but without the actual suspension of the thread. Or well, suspending would happen anyway, but Eclipse will resume thread automatically after executing the code due to “return false” in the end which would indicate “false” for breakpoint condition value to the Eclipse. As a result program will continue to execute, and no suspending that would require manual resuming (or any interaction) would happen.
The simplest example of the case when one can need that would be logging some variable value of which changes in a loop, and you want to know it’s last value before something happens in the system (say exception occurs). Nothing simpler than just putting a breakpoint to a next line after variable assignment, and setting “System.out.println(theVariable); return false” as a breakpoint condition.
The question that bugged me though was wether I can do it in more controller way. For example from Groovy Shell, which is currently my favourite tool for quickly running several lines of ad-hoc Java code, i.e. for scripting using Java (previously I used BeanShell for that). And it turned out that one can do that fairly easy using JPDA/JDI.
Sometimes it is necessary to obtain a content of the portlet programmatically in hooked JSPs, but the APIs do not make it clear at all how to accomplish that.
There are some suggestions on the web on how this can be achieved, but the code seems to be somewhat complex, which makes it a problem to use in hooked JSPs.
For hooks there is a simpler method, but it relies on being executed in hooked JSPs by referring to some classes in portal-impl.jar: