Things n' Stuff Thoughts about the universe in general

The 2023 Stack Overflow developer survey results are in, and here’s my (likely controversial) take:

Rust developers are the most self-centered, with Go developers close seconds.

Here are screenshots of the very nice “Worked with vs. want to work with” graphics for programming languages, with Rust and Go highlighted:

Most people who have been involved in Linux development/administration/advocacy already know that Linux operating systems are in the middle of a big shift (or actually, almost at the end of it) in the graphics stack used in Linux desktops – from the old and gnarly X11 protocol to the new hotness: Wayland compositing. And it sucks.

This is a bit of a weird script day – the script is pretty simple but the integration is interesting. I’m scratching my own itch here and also demonstrating how to:

• Use dbus-monitor to listen to D-Bus events
• Use SystemD user services to run a session service
• Update KDE configuration safely from scripts

(more…)

That I’ve seen in a while anyway. If you go to Stack Overflow today, you’d find a helpful rubber duck in the corner that will help you solve all of your (code) problems:

(more…)

With version 8, Java finally jumped on the asynchronous programming bandwagon with its own Promise-Oriented programming model, implemented by the CompletableFuture class and a set of interfaces and implementations it uses. The model is generally useful and not as horribly complicated as we sometimes get in the Java foundation class library¹, and it lends itself to fluent programming much better than the comparable model from fluent API proponent Vert.x project.

The Problem

One thing that most asynchronous computing models suffer from – and Java’s CompletableFuture is no exception – is the loss of typed exception handling. While CompletableFuture.exceptionally() is a good model that does not introduce a lot of boilerplate², you do lose the ability of the try..catch..finally syntax to effortlessly ignore exceptions you are not ready to handle and just letting them propagate up the stack. (more…)

1. especially for things that claim to be “enterprise versions”, aughh [↩]
2. again, compare to Vert.x AsyncResult handlers. Other APIs, such as RX also do a good job in reducing boilerplate around error handling [↩]

When creating web applications, we often need to have some parts of the application configuration for the deployment environment – usually web service API endpoints have different URLs in different environments, such as using a production web service in production and a locally hosted web service during development.

Such a feature is implemented in many web frameworks and building tools for web applications, such as Gulp or Grunt. Unfortunately, when building applications using Google’s Polymer SDK, there are no such features available – reviewing the Polymer documentation one, there isn’t even any mention of how one handles such mundane tasks as configuring API URLs, except hard-coding them¹.

Developers have tried to solve this problem in different ways, from adding “environments” feature for Polymer’s internal build tool; abusing “behavior modules”; or using “app globals” custom element with complex code to share application-level state. None of these features work well or elegantly (except maybe the environments feature, if it ever gets implemented).

Here is the solution I came up with – with many thanks to Daniel Tse that described part of the implementation in this article – just using the core Polymer elements iron-ajax and iron-meta and without any custom code. Its not the most elegant thing that can be done, but it is relatively simple and works well. Its main down-side is that the application configuration is not embedded in the application during build time but loaded from an external file when the application loads – this may even be a required feature in some scenarios but its not the generally accepted practice.

(more…)

1. all iron-ajax examples, as an obvious example, use hard-coded URLs [↩]

One type of task that I often find myself implementing as a bash script, is to periodically generate some data and display or operate on it – maybe through a cron job, watch or simply a loop. Sometimes part of the process is an expensive computation (could be network based, IO intensive or simply subject to throttling by another entity). The way to deal with issues like that in modern programming languages is a caching technique known as “memoization” (based on the word “memorandum”) in the results of an expensive call is retained in memory after the first time, and returned for future calls instead of running the expensive calculation. We also need to clear the cache every once in a while, but that’s another issue.

So, how to implement in bash?

(more…)

Cloud-init is a Linux technology that allows easy setup and automation of virtual machines. The concept is very simple – the VM infrastructure provides some way of setting some custom data for each virtual machine (many providers call this “user data”), and when the operating system starts the cloud-init service reads that configuration, loads a bunch of modules to handle various parts and let them configure the system. As a user it is very convenient – you write a setup scenario using the variety of tools offered by cloud-init, you can store the scenario in a source control to allow to develop the scenario further, then just launch a bunch of machines with the specified scenario and watch them configure themselves.

The situation is much worse on the MS-Windows side of the fence: want to have an MS-Windows server configured and ready to go? Start a virtual machine, connect to is using RDP and Next, Next, Finish until your fingers are sore. Need to deploy a new version? either retrofit an existing image (again, manually) and risk deployment side effects, or do the whole process again from scratch.

Here’s a script to try to help a bit with the problem – at least on Amazon Web Services: a poor man’s cloud-init-like for MS-Windows server automation.

(more…)

The Heroku toolbelt (which I don’t remember if its mentioned in the “curlpipesh” tumbler mentioned by Amir in his response to my “Fix RVM” post), is a CLI to manage applications on the Heroku PaaS platform. As is common (and horrible) in this day and age they also offer a ‘curl|sh’ type install on their home page.

While the Debian/Ubuntu specific installer is not entirely horrible – it basically adds the Heroku Toolbelt debian repository to the APT source list, updates the package list and installs it, the “standalone” version is as horrible as it can get: download an unsigned binary from the internet, get root permissions and then do something.

For users of Fedora and other distributions, or just Ubuntu users who don’t like installing external repositories on their system, here is a simpler method to get the Heroku Toolbelt running on your system without root permissions and downloading scripts off the internet:

(more…)

On Wednesday I complained about the latest UN*X fad of installing software by running scripts from the internet, without any regard to how your operating system handles software installation.

Docker, that I complained about last time, at least has a script that takes into account the local software management solution (uses apt for Ubuntu, yum for Fedora, etc), but RVM – the Ruby Version Manager which is a popular tool among rubyists everywhere, just downloads a bunch of executable stuff (granted, most of it are scripts, but the difference is lost on most people) into arbitrary location on your file system. At least it doesn’t install system software, oh wait – it does.

While I can’t help with RVM’s desire to install system level software (that it actually needs because one of the things you want RVM to do for you is to compile ruby versions from source), I can try to help you figure out how to install RVM where you want it and use it how you want it.

(more…)