The Kotlin language has a large number of features that can be classed as syntactic sugar — they make the language just a bit nicer to use and read, mostly by eliminating repetitive code.

A common form of repetitive code comes when you want to work with Maps. Maps will almost always come up in some form or another, often when communicating with external systems (e.g. JSON data coming in). They’re popular for their flexibility and use in inter-language operations— keys can be strings and data can be any value. …

Even for a small application, it will often become desirable to change settings when the app runs rather than when it is compiled. A configuration file full of the various settings for the application is not uncommon in this scenario, where changes to the settings can be made and the app restarted with the new settings — the only question is what format should this settings file be?

JSON and YAML are both popular choices, as are Java Properties Files and sometimes INI files and other application-specific text formats. They all have their pros and cons, but all fall in the same category— they are a fixed list of properties and their values. Some may be easier for a person to read than others, some may support nested lists or sets where others don’t, but in the end they’re mostly equivalent. …

For a few years now, Kubernetes (pronounced coo-burr-net-eez, abbreviated to k8s) has been getting a lot of attention and hype in the DevOps world. However, it’s very hard to see what it does without having used it in a real world scenario.

From the kubernetes page

Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.

It groups containers that make up an application into logical units for easy management and discovery. …

There are plenty of stories out there telling us of the advantages of CQRS — The Command and Query Responsibility Segregation pattern. The simple version is that we should separate Commands (user requests that change the data) from Queries (user requests that request data or some calculation on it), and that the data model we use often shouldn’t be the same for the two cases. Queries should never cause a change in the state of the system — no database writes, no file access — while Commands should only do these things and should not return data.

For example, in a REST endpoint, a GET request is a query, while a POST would be a command. However, the two use the same data model. For many apps this is fine, but if you have an app that deals with a high volume of transactions (e.g. every time a user clicks it makes a data entry) and all queries are aggregates (how many users are based in Europe), using the same data model is not appropriate. You could have separated endpoints — one GET only and one that is POST only, at which point you have achieved CQRS without even thinking about it. But what about the internals of your application? How do you deal with these? …

This is part of a series about building a User Defined Type system using Kotlin. If you haven’t read the previous parts (Part 1 and Part 2), I recommend catching up before you do.

In part 1 and 2, we implemented a simple but powerful User Defined Type system. We can describe a type and create instances of that type, and the code to do so is fairly easy to use from Kotlin. Our example usage looks like this:

While we can create a type and instance, this is a User type system, we need to be able to get the types to and from a User. …

This is part of a series about building a User Defined Type system using Kotlin. If you haven’t read the previous parts (Part 1 and Part 2), I recommend catching up before you do.

The Type system we defined is powerful and flexible. Unlike some UDT systems, it allows a type to be defined in code as easily as from user data, and to be used almost like a Kotlin type, as long as all you want to do is move data around. So we’re going to add some more features.

First, it would be nice to more easily access, from code, the properties of a UDT. It’s possible with the data class we’ve defined, but you’d have to iterate the list of properties, we’ll fix that with a similar utility to the one we used in the DType for its fields. As well as a map indexing the values, we’ve added a generic get method to the class, so we can get a typed value concisely. …

This is Part 2 of a series on User Defined Types in Kotlin. If you haven’t read Part 1, I recommend catching up on it before proceeding.

In part 1, we defined a User Type System. It was simple, but flexible. However, it’s still lacking one important feature, creating instances of the Types we define. As it stands, the Type system looks like this:

(Notice that since part 1, I’ve added a fieldsByIdentifier method to DType. This is just for more readable access to the type’s fields. …

Eventually, most developers end up working on a project with User Defined Types. Often it’s the basis of a customisable forms system. For me, it was a school record system in which different schools tracked different pupil statistics.

When working with UDTs, it can be tempting to reach for a dynamically typed language, such as Javascript, and relying on the lack of strong typing to handle the changing type schema. However, a strongly typed UDT can be made in very few (<500) lines of kotlin, taking advantage of some of its features.

For a UDT, we need to be able to serialize not just the instances, but the type information too. For inspiration, we can look at Google’s Protobuf Struct types. Google have already worked out the hard details of how to structure a Type message — we’re going to adapt it slightly. …

Our current project relies on using ROS to interact with a drone and control station (GCS). The drone and GCS both communicate via MAVLink, so the obvious answer is to use Mavros. Mavros connects to the drone and control system and forwards messages between the two, while making a lot of status information available on ROS topics, and allowing commands to be sent to ROS topics to control the drone.

This seemed like a good idea at first, but there was a problem for our project, we actually wanted to intercept the messages and add some logic to decide if they should be forwarded. Mavros - running as a node - unfortunately, provides no way to intercept the messages. We tried modifying the Mavros source to our needs, and ended up breaking its ability to receive messages. …

James

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store