aron

nextversion maven plugin

Sat, 15 Feb 2020 00:00:00 +0000

Time to announce the nextversion-maven-plugin. Releases CD style. VCS tags are a thing of the past. Binaries contain the git-sha instead. Uses the last released version to decide what to name the binary.

Details here https://github.com/andreasaronsson/nextversion-maven-plugin

Maven dependency version properties

Sat, 09 Nov 2019 00:00:00 +0000

Writing maven pom files can be tedious. I rarely want to spend another minute more than I need to doing it. Thus it makes sense to figure out how to do it as efficiently as possible.

Efficiency is not only related to automation and reuse. What workflows the individual developer prefers also goes into consideration.

This post is specifically about doing updates to dependency and plugin versions.

Doing upgrades brings new features and bug fixes. They can enhance security or performance or allow the developer to remove code that is no longer needed. It can also require migration due to deprecations and changes to the transitive dependencies. Migration can entail code changes, dependency management and quite excessive troubleshooting.

To successfully upgrade a dependency. The developer must find out that there are one or more new versions available. Do the upgrade. Verify that no unintended behavior changes appear and that the application builds.

For finding out there are new versions available I have found some different tools. One is invoking versions-maven-plugin:display-dependency-updates. Another is doing a search in the browser on the depency GAV on Maven Central or Maven Repository. A third is to use an editor capable of doing queries for repositories defined in the maven settings.

Changing the values in the pom can be done manually or with a tool. Manual editing is required when migration is needed. Using VSCode I can to both operations in one.

The majority of updates (given that they are done frequently as they are in any security aware installments) are patch updates and are preferably automated. Automation can be done as described in this post https://www.baeldung.com/maven-dependency-latest-version. With subsequent test builds and checkins.

Using a capable IDE and plugins to find and update versions are important to avoid wasting time.

I often see the practice where the <properties> section is used. This can be <version.my-beloved-3pp>1.2.2</version.my-beloved-3pp> and then refered in the dependency <version>${version.my-beloved-3pp}</version>. This can seem efficient when there is no BOM and you would like to avoid editing the same version in two or three places. However, this makes it impossible to use the IDE to find and edit versions in one operation. It also prevents use of versions:use-latest-versions with configuration to update in several places at once. It also requires the pom maintainer to put information about a GAV in more than one place in the pom. When dependencies are removed it easy to forget to remove the properties. How the keys are named differ from author to author which makes mistakes more frequent.

Hence I prefer to not use properties.

Single responsibility and function reuse

Sat, 14 Sep 2019 00:00:00 +0000

Five basics principles in OOP is SOLID The first principle is Single Responsibility Principle. One reason to change leads unequivocally to smaller classes in terms of lines of code. There are many advantages that comes from using this principle. Classes becomes easier to test. Classes becomes easier to reason about. Seeing opportunities for reuse becomes easier. The way you organize code in packages in Java makes this work. In a different language where many classes are defined in the same compilation unit or file. This way a module may contain a smaller number of compilation units / files. The files on average contain more classes and functions. Depending on how the information is visualized. With an IDE classes could be lined up in one view. In a pure text editor this is much more rare. This can make it harder to spot opportunities for function reuse.

Anecdotal performance improvement maven jdk

Sat, 14 Sep 2019 00:00:00 +0000

Looking through this presentation on performance enhancements jdk 8 through 13. And these release notes for maven-3.6.2. I was inspired to see if jdk13 and maven-3.6.2 made any difference over jdk11 and maven-3.6.1. A minimal project and mvn validate. The average build times went from about 0.45 to 0.30. There is of course a wide variety of other things to measure using many other methods.

Bash windows in to survive follow up

Wed, 14 Nov 2018 00:00:00 +0000

Looking again at the Stack Overflow Developer Survey Results. It is possible to calculate a trend for “Developed for Platform” category. ‘win’ for Windows Desktop or server depending on year.

| Year | other|  win |
|------|------|------|
| 2013 | 38.6 | 61.4 |
| 2014 | 41.2 | 58.8 |
| 2015 | 42.0 | 58.0 |
| 2016 | 47.9 | 52.1 |
| 2017 | 59.0 | 41.0 |
| 2018 | 64.8 | 35.2 |

In a five years almost half of the share is gone.

The bash on windows improvement allows more developers to use Windows while developing for other platforms. At the same time more Microsoft things are being ported to linux.

NTFS is still the biggest gripe. Along with very slow search and system updates.

The junior and the senior developer

Wed, 07 Feb 2018 00:00:00 +0000

Junior and senior quantifies professional maturity. It does not describe age or years spent in the industry. Professional maturity indicates how valuable a developer is for the employer.

Problem solving

Junior starts to think on how to solve it. Realizes it is possible to solve. Can see the path to the solution. Perhaps gets a tad excited about the prospect. Gives estimate based on how long it takes to implement. This estimate is wrong. It is too optimistic.

Senior starts to think on how to solve it. Takes into account the effort needed for sufficient readability. Adds time for future maintenance and bugfixes. Gives estimate based on as many of the above constituents as senior is capable of. Tries hard to give as much information along the way as possible. This estimate is wrong. It is a little too optimistic.

The outcome depends on promises made to the customer. Perhaps developers have not been involved. Then it might be impossible for a team of developers to do a good job. The recipient of the feature is very disappointed with the junior. The recipient is disappointed with the senior but respects him.

Maintaining code

Both are very busy.

Junior works hard. Perhaps with no regard for his on stress levels. Tries not to complain too much. Feels important because he is in high demand. Prefers the code written in house. Finds reasons to keep the home grown code.

Senior tries not to work too hard. Spends a lot of time thinking about how to decrease the cost of maintenance for his employer. If an opportunity presents itself to introduce third party code. Then senior is keen on deleting the old code. Unsentimentally because senior put a lot of effort into writing the code.

Discussions

Both advocate their ideas with a passion.

Junior has a very hard time changing his mind. Invests emotionally in arguments. Can become offended if not listened to.

When new information reaches senior. Then senior immediately has a change of mind. Completely devoid of prestige.

We cannot maintain

Sun, 02 Apr 2017 00:00:00 +0000

A large organization involves many people working together. A large and complex product can have many requirements. Say we split requirements into two categories. One relates to customers and the core business. The other consists of functionality that a user can not immediately observe. These things can be configuration, deployment and logging.

With many teams involved it is easy to spot opportunities for reuse. Avoid reinventing the wheel. It is desirable to have a product that is easy to maintain. Maximising use of available third party libraries is a given in this context.

Two ways are conceivable to achieve this. Either write your own wrapper that teams must use. Or provide written instructions for teams to follow.

With a wrapper comes the cost of maintaining the wrapper itself. This includes maintaining well written documentation. Teams and new team members needs education on using the wrapper. In time the third party libraries release new versions. They can contain new features that makes the product better or reduces work. Then the maintainers of the wrapper may need to make changes to make the feature available.

With a written instruction use audits to ensure compliance. Any problems that occur due to non-compliance by teams are bugs. We can assume that teams consists of talented individuals. Following a written instruction is an easy task. Interacting with third party libraries can be easier for a new employee. Third party libraries with a large user base are likely to be familiar. They also have on average well written documentation.

When in doubt do not write a wrapper. It may seem tempting as first glance. Doing well at communicating instructions can prove a lot more efficient.

OOP data or behaviour

Wed, 22 Feb 2017 00:00:00 +0000

I have put a significant effort into understanding OOP. Years ago I remember thinking that my knowledge was becoming mature. An important concepts is that data and procedures to manipulate the data go together. Applying the principles in my daily work made me reconsider some aspects. One aspect that I started to use was to do the opposite. Classes contained data or procedures. Actually not as clean cut as that but rather that I created two kinds of classes. One kind I tried to make as dumb as possible. Free from logic. Data and accessors only. The other kind had logic. I wrote tests for both kinds. The kind that contained data wasn’t very interesting to test. We tested them anyway to please the coverage metrics gods.

A handful more years have passed since then. I have delved deep into the realms of functional programming. Today I frown on void methods and methods without parameters. I am much more picky about making classes members of other classes. There are many examples of how it has affected the way I think.

Thinking back I realize something. We may have understood some of these things on a subconscious level.

Romannumerals kata

Sun, 22 Jan 2017 00:00:00 +0000

More JAVASLANG kata! Last time it was Bank OCR This time the Roman Numerals. Some usage of property based testing. Rare cases seems hard to catch with property based testing. Perhaps this is something I will learn to overcome when I become more proficient.

Code here https://github.com/andreasaronsson/kataromannumerals

Tests should read like prose

Sat, 21 Jan 2017 00:00:00 +0000

Expressing solutions to problems is at the heart of programming. Cognitive load slows you down. Not using natural language adds to the cognitive load. Writing software benefits from using natural language. This is something I think of very often in my work.

When using JUnit I use the Junit4 API assertThat whenever possible. This enables me to write

assertThat(result, is(expected))

Compare this to Junit3

assertEquals(expected, result)

Junit5 is in development. It surprised me to see that they are using what I perceived as “Junit3 syntax”. In the user guide we find the explanation. The assertThat API is reserved for third party assertion libraries like hamcrest or assertj. The more powerful API is open to extension and pluggable.

An excellent choice.

Programming across borders

Fri, 02 Dec 2016 00:00:00 +0000

In our new reality change happens faster and faster. This puts pressure on programs and systems to adapt to change. Building blocks become ever larger to help meet expectations on feature deliver rates.

Using as small as possible least common denominators like standard libraries and the types defined there puts a healthy pressure on the semantic intricacies that needs to be communicated. Surprisingly often one can get the job done with less.

One consequence is that large monoliths are becoming less common. A corollary of this is that developers write smaller programs more often. What follows is the number of boundaries increase. We need protocols and API’s to share information.

A protocol is a system of rules that allow two or more entities to communicate. Simplicity in these rules is an advantage. It is desirable for efficiency at scale to make the system usable and easy to change. The amount of effort needed to understand the rules and implement them needs to be small.

Abstractions like user defined types can be a way to enable code reuse. It can limit the number of ways to do a certain operations and make it harder to make mistakes. Abstractions can model the domain and document code. Using a compiler capable of providing a sound type system the usage can prove efficient. Sometimes these abstractions comes from a third party like an open source library.

When programs transmit information over a protocol the compiler is not there to help. This means that each type or abstraction must have a representation. The representation must follow the rules. This requires translation. When data reaches the receiving end translated back to the original form. These translations can become cumbersome and are good candidates for automation and code generation. Even when using code generation and automation. The translated representation will often require more data transmission in the end.

Communication is important to do well. Being succinct can be hard but it has benefits. Adding a third party library types to a programmatic API will in most cases force the user to also adopt this library. Transmitting more data will affect performance and possibly saturate network connections.

It is good to put a healthy pressure on the semantic intricacies. Using as small as possible least common denominators helps. These can be standard libraries and archetypal types. Surprisingly often one can get the job done with less. An interesting mental model to aim to emulate is the mouse with one button or less is more.

Bank OCR kata

Sun, 19 Jun 2016 00:00:00 +0000

All aspects of functional features in programming languages are interesting. This makes JAVASLANG intriguing. I have spent some time reading up on it. I think that it could give some of the advantages of Scala without some of the drawbacks.

Quite often when I write something these days I feel the urge to try it with JAVASLANG. I am especially interested in two things. To see how hard it is to make it play nice with other parts of the vast Java ecosystem and how usage affects compile times. Both things are pretty severe drawbacks with Scala (especially compile times).

So far I am getting the notion that compile times are longer. I have done no measurements so I won’t take that to heart. You can find one of my experiments where most nice things are nowadays; Github

Developers perspective on predictability and velocity

Sun, 12 Jun 2016 00:00:00 +0000

Being agile means working towards being predictable and being fast. Repeated measurement are a prerequisite for progress over time. An interesting thought is that without measuring predictability and speed accountability remains a mirage.

Predictable

Optimum is to be able to tell in a short amount of time; minutes or days when a feature is ready. Worst case is to promise to deliver a features and then breaking that promise. It is easy to end up in a perpetual lie where each promise is done in earnest. When the team then fails to deliver in time it has no repercussions.

Measuring predictability

The team need a data series over comparisons between prognosis and outcome.

Fast

A feature is done when it works in production without interruptions. Granted there are vast possibilities to interpret things. It is important to decide what is in scope and what is not. Success is when there is an agreement between the consumer and the producer. The negotiating skill will play an important role.

Measuring how fast

Simple in theory if you have engaged stakeholders and all features are of equal size.

The road there

One way to improve is to adopt a zero defect strategy. This means that the team does not tolerate any outstanding issues (reported bugs or the like). They are promptly dealt with. Decide if it is worth the investment. If not clearly communicate this at the earliest opportunity. Decide if it is a bug in existing features or new functionality. If it is a bug drop planned work and fix it. Else put in backlog and prioritize.

A second way is to measure and adress build problems. This can be failing builds on any level (component, integration and system tests). Count the incident rate. Then adress the ones that occurs most often first. It can also be execution time. Mixing integration testing with the step where the binaries are created is a common cause.

A third way is to keep things tidy. Make sure documentation is built with the product and updated. Remember to update or enhance the documentation whenever there are questions from users or the team itself. Eradicate warnings and errors in the build logs. Make ample use of static analysis to help find flaws and adress them as they are discovered. The earlier the better.

Finally there can be architectural flaws as the underlying cause for all of the above. As soon as possible attempt to adress these flaws. Be careful to have enough experience to have high confidence in proposed improvements. For larger changes this is even more important.

All this requires a hefty amount of discipline. Keep in mind that your responsibility is to maximize the output for the team in a year from now. This means it can be pragmatic to take a shortcut at times. However, it is hard to estimate when the shortcut is worth taking. Extremely hard since the amount of information about the future drastically shrinks the further into the future one tries to foresee. This makes the prospect high risk and should not be taken lightly.

References

https://www.thoughtworks.com/continuous-delivery https://www.cprime.com/resources/what-is-agile-what-is-scrum/

Bash windows in to survive

Sat, 02 Apr 2016 00:00:00 +0000

Looking at the Stack Overflow Developer Survey 2016 Results it is possible to calculate a trend. Taking some of the figures and putting them in an orgmode document (which is also a spreadsheet if one wishes) renders the following table:

| Year | *nix |  win |
|------+------+------|
| 2013 | 38.6 | 61.4 |
| 2014 | 41.2 | 58.8 |
| 2015 |  42. |   58 |
| 2016 | 47.9 | 52.1 |

In a few years the developer share drops nearly ten percent. Developers not so much. One can suspect that this triggered the recent bash on windows improvement whis is excellent and will be a relief for many developers.

If they replaced the NTFS file system with something better and some other things it starts looking really interesting.

Alternative error handling in maven plugin

Sun, 29 Nov 2015 00:00:00 +0000

This is a small example for anyone writing maven plugins and feels the need for increased testability at the unit test level.

On tools used when compiling artifacts

Artifacts can be runnable programs, documentation, libraries etc. There are many things that fall into this category; compilers, project management, analysis etc. These tools tend to be most conservative when it comes to compatibility with other tools. These requirements have consequences on the behaviors they exhibit and what patterns they follow. To emphasize productivity is is important to manage complexity and enable reuse. The paradigm convention over configuration combats complexity and makes reuse easier.

Error handling in maven plugins

Plugins extend the AbstractMojo and implements the execute method. Whenever a plugin wants to signal a ‘failed build’ the contract states to throw a MojoFailureException. When an unexpected problem occurs the plugin is required to throw a MojoExecutionException. Guide to plugin development.

Maven as a project management tool deals to a large extent with side effects. Essentially maven takes a set of instructions and then produces a side effect. Checked exceptions are a good fit in this domain.

Functional principles

In functional programming pure functions are a key part. They have a plethora of advantages on several levels. One of them being testability. Say a caller wants to verify a set of inputs. A function that always produces a return value is preferable over a function that does not. A method that throws a checked exception may return a value, or not. Imagine you ask someone a question that you feel is important. Then imagine someone answering you, smiling, “Yes. Or no.”. An efficient way to annoy your co workers.

Now for the example

It will not be possible to write pure functions here. Instead we can use a property from the pure functions. The property to always produce a return value. This value can be propagated or checked immediately. Unit tests will verify it immediately. When propagated it will be used to create a checked exception. This is what we need to communicate with the layer above us.

The usual pattern:

void methodThatWillBeCalledByExecute() throws MojoExecutionException {
    // Do work and throw on error
}

With the above method an error will be propagated and the build will fail. All good but hard to test in a unit test.

Using Google guava or Java 8 it is possible to use the option monad or the option type. Below the Optional from Java 8 is used:

Optional<IOException> methodThatWillBeCalledByExecute() {
    try (file.createNewFile()) {
      // write
    } catch (IOException e) {
      return Optional.of(e);
    }
    return Optional.absent();
}

The above method is now a little easier to write a small test for. In the calling code, in this example the execute method, we can now use

public void execute() throws MojoExecutionException {
  Optional<IOException> result = methodThatWillBeCalledByExecute();
    if (result.isPresent()) {
      throw new MojoExecutionException(result.get());
    }
}

Note that the use of isPresent is considered a code smell and in most cases getOrElse is prefered. Compare:

if (!optionVar.isPresent()) {
  return DEFAULT_CONSTANT;
}
return optionVar.get();

with the more concise

optionVar.getOrElse(DEFAULT_CONSTANT);

In the first alternative you risk making a mistake in the conditional. There are also more lines which hurts readability.

Leading Behaviours

Sun, 26 Apr 2015 00:00:00 +0000

Here are some thoughts on desirable behavioural patterns for developers.

At first I was thinking about writing about anti-patterns in behaviour or anti-behaviours. That would be instant irony. Anyways, seeing this clever tweet made me think and the term for this would be Leading Behaviours. An idea here is to coin the terms Leading Patterns and Leading Behaviours. Using the word ‘leading’ signals that they may not be leading forever which I believe is true for both terms. Juxtaposed to “best” - there can only be one best and one does not expect best to change. Not as frequent anyways.

Desirable consequences of Leading Behaviours would be to inspire others, energize others and in general be supportive. It should only in a way that promotes other developers to adopt Leading Behaviours. This proverb is one example of how one could practice leading behaviours.

Fearlessness

In a balanced approach to solving problems fear will play a small role. Especially true in problem domains new to the individual. This enables developers to try out practices and tools. This is essential when striving to work at as high an abstraction level as possible. It will also be a great help to make pragmatic and earthbound decisions. It will make it easier to concentrate on doing the most important things rather than some peripheral issue. Time is spent on what is most important to a larger degree.

Detached decision making

Anything an individual invests much time and energy into will have a profound effect on that person. Staying emotionally detached allows the developer to stay rational. It will make it easier to avoid logical fallacies when reasoning. It is highly beneficial to know these by heart. This enables one to avoid wasting time an navigate successfully in many different contexts. Aptness to take into account all relevant factors is important. Likewize is realizing that it is very common with trade offs when making choices. A mind very open to new information allows rapid stance changes as any significant new information is presented. Previous experiences and only a real help when there is no other path of reasoning available. This is more and more true in a world where change is one of the ever fewer constants. More important to make novel deductions from the current set if variables.

Emotional involvement

Various emotions and feelings are the impetus behind our actions. Perhaps the most potent character trait of them all is passion for our field of work. This makes developers spend that extra time and energy. This enables them to delve deeper and excel at whatever is needed to grow mentally to be able to grasp the most enigmatic concepts. Being dissatisfied and looking for ways to improve written and code not yet written is the hallmark of a developer that will learn massive amounts during a career. A sign of maturity is where there is a complete objectiveness when evaluating code. Self awareness is priceless here.

Is TDD dead takeaway

Sun, 26 Apr 2015 00:00:00 +0000

Watching (again) the discussions about TDD and subsequent presentations and pondering them for a while I have reached an important conclusion for how I should regard my own reactions and thought patterns. I have come to realize that being prepared to throw away code without giving it a second thought is a Leading Behaviour. Naturally this is only the cases where the code and the features it brings can no longer be motivated by the existence of requirements.

What took longer time without me realizing it what that the same applies to tests. Let’s say I have written tests that give me a healthy dose of confidence. Then I can change things and be quite certain that I didn’t break anything. Now we can roughly divide tests into two categories: tests that test how something is implemented and tests that only verify behaviour. During implementation a test that tests how code is doing something is often quite handy. It can help you write the code faster. Yet as soon as the functionality is verified it instead becomes an impediment. We are no longer free to change the code. Maintainability is paramount. How easy it is to change code is very important for maintainability. It makes sense to delete these tests. Only keep tests that verify a behavior outside in, keeping implementation details a secret from the important tests. We would like for this not to reduce code coverage but if it does in places it is a price we should be prepared to pay.

Private projects a necessity?

Sun, 22 Mar 2015 00:00:00 +0000

Apparently, some companies make it more or less mandatory for their applicants to have one or more private projects that they are working on and being proud of. I have been one of those people that gets completely engulfed in work for my employer for quite long stretches of time. It certainly does not seem impossible to be among the best developers without having private projects and some dreams of creating a startup with at least one of them. I can tell for certain that it is possible to meet people at your workplace that are significantly less interested in our field of work without spending hardly any time on private projects for years on end. For some reason people I meet that only seem to think about creating software when they are at work prefer microsoft windows to a larger degree.

Anyways, I have tried to see the advantages, especially in the long term of pouring my extra energy into private projects rather than trying to excel at my workplace. I now think that I might be less frustrated with the shortcomings or lack of ambition of my peers. The strong longing for using better tools - especially compilers - I can get access to way easier. Some more blogging might help too I guess. At this time I plan to use github and bintray. And if I don’t find something better I will use a jenkins instance on my personal server for building. Already this looks significantly better compared to what I have at my workplace. As a project I plan to rewrite an old project I worked on during my days in the students commune that I inherited from previous students but this time in a functional language.

Github and maven-release-plugin setup

Sun, 22 Mar 2015 00:00:00 +0000

Assuming you have a Github account setup you can use the maven-release-plugin to push the changes associated with a release to github. Further, assuming you have set up the github account with an ssh key you can configure the maven-release-plugin to push your changes not requiring entering a password every time a release is created. It appears to be canon to use the term “cut a release” for this activity. Eventually I’ll get around to asking my english speaking friends about this. Anyway, this requires you to have an <scm> element in your project description file. It must look like this:

<scm>
  <connection>scm:git:git@github.com:username/projectname.git</connection>
  <developerConnection>scm:git:git@github.com:username/projectname.git</developerConnection>
  <url>https://github.com/username/projectname</url>
</scm>

The data inside the elements is a colon separated (only the first two is significant for the plugin making up three partitions in all). The first two parts; scm and git tells it to use the maven-scm-plugin and its git executor. The rest is passed in as an argument. Now to the thing that made me spend a good amount of time before getting this to work. There is some debate on whether a “proper” URL shall end with a slash or not. I have been in the pro-add-slash camp and yesterday I came to regret it. It turns out that adding a trailing slash to the <developerConnection> makes the invocation of mvn release:prepare fail complaining about either missing repo or failure to authorize. The error messages led me to believe that I had constructed the data in error so I tried using ssh:// and slash instead of colon etc.

Another problem I encountered was when I tried to use the release:prepare-with-pom goal. I was then hit by MRELEASE-539.

The future for maven-release-plugin is questionable. The approach has been bemoaned and I do see there are merits to using an alternative approach like described especially since other, well working plugins are used in combination. It would probably be relatively easy to create a wrapper plugin to automate those tasks. Also, when Maven 4 arrives with continuous delivery support using maven-release-plugin looks even less fitting.

With hope this helps someone.

Learning Scala and functional thoughts.

Sun, 23 Nov 2014 00:00:00 +0000

Incredibly enough it is more than two years ago now I took the MOOC Scala course at Coursera Functional Programming Principles in Scala . In this text I try to reminisce what the learning experience was like.

Looking back now I realize it has affected me profoundly. These days I pick other youtube videos to watch as functional programming is much more interesting. It has also changed my way of thinking when I write code. As I have become aware of what makes it hard to reason about the constituents more and more of my energy is spent on these things. The course is highly rewarding and I am sure it has been improving since I participated.

When I first saw the syntax I noticed the use of parenthesis instead of brackets as I was accustomed to in Java. My thought then was ‘why change that which is not broken’. After studying some more I realized that this was that it followed logically from the fact that ‘everything is an object and a function’. Another aha-moment for me was when I was writing tests for the code I has written. I realized that the tests was really testing the things I was interested in testing. The amount of bolt-and-nut problems one has to solve when working with a language this elegant is minute compared to what I do in my regular work. Exceptions, nulls and mutating state even if only for external iteration keeps getting in my way.

Functional thinking has made such a deep impression on me. However, as always with any tool I use I soon find many things I dislike about it. The things that prevents me from doing even more Scala today are compile times, weird inconsistencies that probably follows from putting all kinds of features into the language at a senseless pace. This is highlighted in detail by the mesmerizing Paul Phillips. I believe that Martin Odersky is spot on with his plans to simplify the language in the coming years. Today it feels a bit like a research experiment to me.