One of the software applications I work on uses Git as version-control and has a traditional (if somewhat old-fashioned) branching strategy: a branch per feature/bugfix, an integration branch, a release-testing branch, and release branches. Different users/tools are responsible for merging between these branches so it can sometimes be rather difficult to know whether a local Git branch has been merged to any specific target.
My employer has a large Java-based application which uses Sybase ASE as its data store, and a mysterious stored procedure sp_jdbc_getprocedurecolumns (which we never call directly) is causing performance problems. It took quite a lot of work to track down why; if you’re having similar problems then see the explanation here.
I recently needed to track down some performance problems in a large (Java-based) application. My employer already uses Prometheus for monitoring, so it seemed time for me to get to grips with its concepts and instrument the application with appropriate metrics then create some matching Grafana dashboards.
Learning Prometheus/Grafana turned out to be a little harder than I thought so I have written up what I learned in case it is helpful to someone else.
And yes, it did help to track down the problem(s).
A colleague recently pointed out that the following command can be pasted into either Firefox or Chrome to get an editable window for keeping notes. The text can even be saved afterwards..
data:text/html,<html contenteditable>
You can adjust the font-size, etc with inline styles, eg:
data:text/html,<html contenteditable style="line-height:1.5;font-size:20px;">
Another colleague pointed out a nice “retro console” variant:
data:text/html,<html contenteditable style="background:black;color:lime;font-family:monospace">
On a similar topic, a browser window can also make a nice JSON pretty-formatter (read-only):
data:application/json,{"yo":1}
Are you building Java software using a Maven multi-module structure, and using mvn versions:set to update the version-numbers on each release? If so, there is a much better way.
The book “Accelerate: Building and Scaling High Performing Technology Organisations” is best known for its four “DevOps metrics” Lead Time for Change, Deployment Frequency, Mean Time to Restore, and Change Fail Rate. However there is quite a lot of other interesting content in the book too, addressing software development and deployment at mid-to-low management level.
I’ve written up my opinions of the book here (mostly positive), and would be interested in what you think..
I’ve written the occasional OAuth2 client application over the years but never really understood what was going on with client-ids, secrets, grants, scopes, and so forth. However I’m currently involved in a project to migrate a large IT system to using OAuth2 and OpenID Connect, so it is clearly time to learn this stuff properly.
After some long research, I have written an architectural introduction to OAuth2 and OpenID Connect summarizing what I have learned - mainly for myself, but maybe you will find it helpful too. Warning: it is pretty long (17,000 words)!
I’ve finally got around to learning Kotlin, a popular language best known for running on the JVM and competing with Java.
Not only is Kotlin a “better Java”, it is also the recommended language for writing programs for the Android platform. It can also be compiled to Javascript, ie can compete with things like Typescript as a “type-safe language for browser-hosted code”. Interestingly, it is also working on “native” support for compiling to various machine-codes (eg x86, ARM). Most interestingly of all, it is working on compiling to WebAssembly for high-performance cross-platform applications.
My personal notes on Kotlin are available, but they are probably not of interest to anyone but me.
What might be interesting is that I recently converted a demo Spring/JPA program from Java to Kotlin.
Change: (1075 - 1368)/1368 = 21% fewer lines of code
That’s not world-changing, but definitely worth having.
In general, I found the Kotlin version of this app easier to read, and less likely to have bugs. Programming was also more fun. I’ll be using Kotlin where possible in the future.