As you may know, we're trying many ways to reduce our impact on the environment as a family. For example, we didn't fly for several years, focussing instead on vacations that are easier to reach. We're also growing part of our own food organically, making a lot of our own products and almost exclusively using public transport.

A year ago now, we got solar panels installed on our roof and it's time for a small retrospective.

TL;DR : The installation cost around 5€ (4k€ after government subsidies), and we were able to generate over 80% of our yearly consumption (used 30% straight up) and save just short of 1k€ in year 1.

First, our consumption

In this post, we'll only be talking about electricity. Our house heating (and warm water) is done using hot water pipes from the city, so it won't be part of the equation here.

As you may know already, the first thing to do if you are trying to lower your impact on the environment is not to recycle, but to start by reducing your consumption. Yup, it all starts by reducing.

We leave in a 100m2 house that is connected on both sides. We do not own an electric car, and we have two kids. In 2022, our yearly consumption was just above 3000kWh. If I believe the data from our energy contractor, our monthly consumption is about 45% smaller than similar families, which is kind of nice. (If you're interested btw, the average American household consumed 10,632-kilowatt hours (kWh) of electricity last year 😓😱) .

This is all done without many sacrifices btw, we're just using mostly "dumb" appliances and avoiding to run the dryer, for example.

The experience, and the setup

Interested to further see how to reduce our house's footprint, we invited Energie N at home, a group of volunteers who comes and tells you based on your house installation which optimizations are the most impactful. (If you're searching for help by the way, I recommend checking for similar groups in your area. They have lots of experience visiting many houses and it's been extremely helpful).

For example, I learnt that dry air is cheaper to heat that humid air. Which is very logical if you think about it, but I never had before 🤓.

Based on their recommendations, we decided to look into installing solar panels on our house. Solar panels are extremely common in the Netherlands (more than 25% of households have them now!!) so there's a plethora of companies to choose from. They do everything online, using cadaster and aerial imagery to plan your future installation. Here is our part of the contract looked for us, without them even having to come

Now, I have to say that not everything is flawless with those methods. As you can see, the space we have to install those panels is limited because of the roof extension we have in our bedroom. There's also legal requirements for margins on each side of your roof to avoid taking space off of your neighbor's roof. The first contractor who came over realized that there was a 5cm discrepancy between his plans and our actual roof and had to cancel the installation...

We contracted a second company, who back then had a 16 months waiting time (due to the war in Ukraine and the energy prices exploding)! Luckily, a few weeks later another customer cancelled their installation date in our street and we could get them installed very fast.

The whole installation took less than 3 hours, and was flawless. Super happy with our contractor.

A year later, the results

We're now a year later. Let's have a look at the results!

We do not have batteries in our installation. The way it works in the Netherlands at the moment, is that the energy you generate is either used direction by your house, or sent back to the grid. The energy you send back to the grid is removed from your bill on a 1/1 ratio.

Last year, our 6 panels generated a total of 2393kWh. The cool thing is that you really can see we had a very sunny spring, but a crap summer 😅. I'm curious how it'll compare to next year.

Out of this energy, we sent almost 1600kWh back to the grid.

This means we used directly just over 30%, or 800kWh. If the conditions of energy delivery were to change, it might actually be worth installing batteries, because it seems that we sent back over two thirds of what we generated.

After all this, our leftover usage is 2226 -  1591 = 635kWh, which means we generated almost 80% of our total consumption! In terms of financials, we saved just shy of 1k€ this year, meaning that I'd expect our installation to be profitable within the next 4 years if all goes well.

However, if we

And in terms of CO2 emissions?

This will be a very rough calculation here, because I'm not including the cost of the solar panels manufacturing, and the values I will be giving change all the time, but overall if we look at the numbers :

On a normal day, 1kWh generates roughly 500g of CO2 (In 2023 the average emissions of Netherlands were 421 g CO2eq/kWh.). Meaning that us generating 2393kWh this year leads to a reduction of 1150kg of our CO2 footprint, 400kg of which we didn't even send back to the grid. Not bad, that's almost 10% of our combined footprint!

Next steps and conclusion

Overall, I'm super happy about the whole setup. We're reducing our footprint, while saving money, raising the value of the house and for absolutely no trouble. Hard to do better.

I think we've about done what we could for energy production in the household. I think the next big thing for us will revolve around insulation, looking at getting better windows and more. I'll post about this another time!

Hope you liked this post, maybe it can motivate you too!

TL;DR : we have been using the AAARRRP framework as a visual and easy way to align with stakeholders which types of activities are the most relevant for our customers. It can look like this

Let's dive into it!

Some context

Even though I have been doing Developer Relations for a few years unofficially or semi-officially, it was only two years ago that I got my first official role as a Developer Advocate. And after just a few months, I was offered to lead the team. We're a small team of three (me included) and our team falls under engineering.

It was never really an issue for us to create a strategy on what to achieve, or how to achieve it. We focussed on our 3 pillars: Code, Content and Community and selected the most relevant activities.

For example, being a B2B company we knew that running the conference circuit wasn't the most efficient way to create value, for the simple reason that people wouldn't be able to sign up for our services. We quickly decided instead to embed ourselves close to documentation and provide many samples for the companies who were using us, bringing a lot of internal feedback at the same time.

But even though we had no doubt about our priorities, it wasn't always as clear for higher management, nor other stakeholders. After all, Developer Relations was a relatively new thing inside the company and only a few people had direct experience with the domain in the past. And we all know that even for companies seasoned with DevRel, measuring impact and making sure activities align are a difficult topic.

We received a lot of challenging questions over time regarding our priorities :

• We see that the insert competitor DevRel team is very present on Youtube. How is it that your are not doing the same?
• How is it that your Twitter account gets very few likes compared to insert other company.
• Why do we not see many community contributions on your GitHub account, compared to insert large company?
• Would you please join us at the booths for insert conference, we want to increase hiring.

All those questions are very fair, and they deserve clear answers. Thing is, they were quite obvious for us given the context we had and it was a struggle for me to communicate those answers at scale and in a strategic way (understand : Find a way that people understand those answers, and hopefully give enough context that they come to the same decisions by themselves).

It's after reading about the AAARRRP framework that a potential solution came to mind 😊.

Quick sideline about priorities / activities

My point with this method is to focus on how to communicate in a scalable way the type of activity we plan on focussing on, not the exact activity performed.

For example, we might want people to understand that writing code samples is the most impactful activity we can do.

However, we will not use it to communicate which code sample to write. For this, we might instead use a combination of data sources like documentation statistics, or support tickets for example. I may write more about this later in another article.

A quick intro about the AAARRRP framework

I'm not going to expand myself much about this, because I would be ripping off the original article. I recommend you to go read it instead if you have never heard of it before.

Here is the very minimal version. As Developer Relations team, we can operate on several key moments of the customer journey :

Depending on the type of company we're working on and the strategic priorities of that company, some of those parts will be more crucial than others.

Early on, many SAAS products want to focus on awareness and acquisition to drive as many new customers in as possible, and grow fast (The famous MAD) .

As your product grows in maturity, you may want to increase the "stickiness" of your product and increase retention, or work on activation of additional features for your existing customer base.

Typical DevRel activities that we carry have impact of different parts of that funnel (usually several at the same time).

Note: The original post also adds weight to the equation in order to select activities. We will not here, for simplicity's sake. The whole idea stays valid here.

From AAARRRP to strategic communication

Note: All those charts have been altered and do not contain internal information 😊

So far, nothing new under the sun. That's where we'll go just one step further and use the content above for strategic communication.

Let's say that based on the current context, we decide to focus on activation, retention and product.

• We can draw this as a chart to help communication with stakeholders.
• We can also draw (rough, given we do not have internal knowledge) equivalent charts for other companies in the space for comparison.
• We can even draw our own chart year on year, to show how our activities vary as priorities shift, or impact decreased (law of diminishing returns).
• Now for the key part : We use these charts to validate assumptions with  stakeholders, who will be able to derive the corresponding activities themselves.

For example, given the decision above we can draw this:

With those priorities agreed, the common understanding is that we should focus on activities like Code Samples, Guides, Tutorials, and answering Stack Overflow questions.

Again, we can more easily explain why we have a lesser focus on social media and the conference circuit that others by comparing main focuses between entities.

Once the shape of our strategy is agreed to, the type of activities expected become clearer for everyone and we can focus on the impact of those activities. And if the priorities change, it's always time to come back to the drawing board 🎉.

Let's imagine now that our company's internal focus heavily shifts towards "closing deals" because we need to extend our runway. It might be time for the DevRel team to start acting on the Revenue part of the funnel, reduce Product efforts and do Pre-Sales activities. We can update the plan, propose a new shape and double check with stakeholders that the change fits the new landscape :  

Of course, whether the type of activities to be carried on fits DevRel well, is sustainable long term and more is another discussion altogether. The main point here is to make your priorities clear and communicate them accordingly.

About the scale of priorities

One question you might wonder is : How do you calculate the scale of each priority in your bar chart?

Well, so far our method isn't very scientific 😊. We mostly want to show relative priorities of activities and as such we're using a set number of points and sharing them across the different axes of the chart. For example, pick 70 points (10 per angle) and subdivide. The chart then helps us make decisions quarter to quarter or day to day. Of course, when drawing other team's chart, all numbers are best effort and based on impressions.

As we use these graphs more, we're experimenting with other ways to measure that could be more relevant. For example incorporating alignment and relevant weights that the original AAARRRP article mentions.

A word of conclusion

Overall, the only thing we've been doing is taking the AAARRRP framework as an inspiration to clearly visualise what our team focusses on and bring some clarity internally. We've been using it on all of our presentations and internal pages focussing on our team's strategy.

It has helped to focus discussions with stakeholders more on how much impact we can bring, rather than what activities to carry and why and it's really been useful for us.

Having joined DevRelCon this year I know that internal communication is always a strong topic in DevRel teams. Maybe this can help bring some clarity on the topic!

Cheers, and talk soon.

Julien

This is the online version of the article with the same name I wrote for the Dutch Java Magazine 😊.

In the previous edition of the magazine, we discussed how the JetBrains HTTP Client could be used to run HTTP Queries, automate them and even use them in your CI/CD pipelines. Just like Postman, but text based and can be part of your source code. Pretty cool.

For reference, it could look like this.

### Github API - Traffic per day

GET https://api.github.com/repos/{{owner}}/{{repo}}/traffic/views?per=day
Accept: application/vnd.github+json
X-GitHub-Api-Version: 2022-11-28
Authorization: Bearer {{github_key}}

With an environment file that looks like this :

{
  "dev": {
    "github_key": "not_that_easy",
    "owner": "jlengrand",
    "repo": "elm-firebase"
  }}

Now, that is very nice, but it requires a lot of manual work. Wouldn’t it be nice to be able to automate this? Fortunately, most of us developing APIs also generate OpenAPI Specifications for them. When I looked however, there was no OpenAPI generator yet available for the Jetbrains HTTP Client. This is the story of how I've implemented it from scratch, and how you could too if you find yourself in the same situation! We'll use the JetBrains HTTP Client as a practical example, but the knowledge is transferable 🙂.

The OpenAPI generator project contains a core engine, as well as many packages with each a specific generator (Java, Ada, …). The Jetbrains HTTP Client generator is actually published, and you can find the merge request as well as the documentation on GitHub. If you have installed the last available OpenAPI generator release, you can actually try it out in a terminal as such :

$ openapi-generator generate -i https://api.opendota.com/api  -g jetbrains-http-client -o dotaClient

At its core, the idea of the OpenAPI generator is quite simple : It takes a specification file (JSON or YAML), transforms it into a set of objects in memory, and uses those objects to generate code / files using mustache template files.

You can actually find most of that logic in the DefaultGenerator source file of the library. There, you can see that actions are separated into 3 groups :

• models (basically data types)
• operations (actual operations)
• supporting files (environments, READMEs, …).

Each of those is illustrated by a method, and takes separate objects as inputs :

 …
  void generateModels(List<File> files, List<ModelMap> allModels, List<String> unusedModels) {…}
…
    void generateApis(List<File> files, List<OperationsMap> allOperations, List<ModelMap> allModels) {...}
…
    private void generateSupportingFiles(List<File> files, Map<String, Object> bundle) {...}
…

You can find the actual source file on GitHub. The objects for each of those methods are large Map classes that contain the necessary data in a semi-structured format. Here is an example of how allModels looks like:

As you can see, the object is essentially a lot of key/value pairs that are quite recognisable and directly come from the OpenAPI specification file.

To create our own client, we will take advantage of this nice work. Let's dive into it. We first clone the repository

$ git@github.com:OpenAPITools/openapi-generator.git; cd openapi-generator

We can then use the /new.sh script to generate a few placeholder files for us. We'll be generating a client, and since we're not creating any bugs we won't be generating test files.

$  ./new.sh -n java-magazine-client -c

Creating modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/JavaMagazineClientClientCodegen.java
Creating modules/openapi-generator/src/main/resources/java-magazine-client/README.mustache
Creating modules/openapi-generator/src/main/resources/java-magazine-client/model.mustache
Creating modules/openapi-generator/src/main/resources/java-magazine-client/api.mustache
Creating bin/configs/java-magazine-client-petstore-new.yaml
Finished.

The library nicely generates a client generator for us, as well as some template files and even a config so we can test it easily! The config uses the well known petstore by default.

This is how the config file looks like :

generatorName: java-magazine-client
outputDir: samples/client/petstore/java/magazine/client
inputSpec: modules/openapi-generator/src/test/resources/3_0/petstore.yaml
templateDir: modules/openapi-generator/src/main/resources/java-magazine-client
additionalProperties:
  hideGenerationTimestamp: "true"

It nicely mentions to the OpenAPI generator library which generator to use, which sample OpenAPI file to use as input, where the mustache template files are located and where to store the output

Let's run it!

$ ./mvnw clean package # package once to have the generator inside the generated jar
$ ./bin/generate-samples.sh bin/configs/java-magazine-client-petstore-new.yaml

Let's see what the generated output looks like :

We haven't done any work yet, and our generator is already spitting out things! Unfortunately, as we can see, all those files are empty. That's because our mustache template files also are empty. Let's fix that now!

We'll start by customizing the JavaMagazineClientClientCodegen to fit our needs. We want a very minimal implementation that fits in this article, so we'll actually decide to NOT implement any supporting files (the README), nor Models and instead focus solely on the API. The way to do this in a custom generator is to extend the postProcessOperationsWithModels from the CodeGenConfig interface. We change the .zz extension into .http files that will be recognised by IntelliJ. And because in this specific (simplistic) case, we will not need any alterations to the OperationsMap object we can actually only call the super method. Our final class looks like this :

package org.openapitools.codegen.languages;
import org.openapitools.codegen.*;
import java.io.File;
import java.util.*;
import org.openapitools.codegen.model.ModelMap;
import org.openapitools.codegen.model.OperationsMap;

public class JavaMagazineClientClientCodegen extends DefaultCodegen implements CodegenConfig {

    public CodegenType getTag() { return CodegenType.CLIENT; }

    public String getName() { return "java-magazine-client"; }

    public String getHelp() { return "Generates a java-magazine-client client."; }

    public JavaMagazineClientClientCodegen() {
        super();

        outputFolder = "generated-code" + File.separator + "java-magazine-client";
        apiTemplateFiles.put("api.mustache", ".http");
        embeddedTemplateDir = templateDir = "java-magazine-client";
        apiPackage = "Apis";
    }

    @Override
    public OperationsMap postProcessOperationsWithModels(OperationsMap objs, List<ModelMap> allModels) {
        return super.postProcessOperationsWithModels(objs, allModels);
    }
}

Note: At first glance, the method and variable names may look a bit like magic. It is because most of the logic comes from DefaultGenerator, and CodeGenConfig. If you feel lost, those two classes are where it's at.

Now that we have our baseline, what we want to do is work on our mustache files. Those files are basically templates that will be fed into the processing pipeline to generate our .http files.

We know we want one file per main API endpoint, with some documentation. We also want the @name unique identifier from the Jetbrains HTTP Client to be able to reference our code. Finally, we want to add the supported content type for the calls.

If we look at the data object available for operations, we end up with this, where each {{item}} notation is the value of the item key inside the object.

## {{classname}}
{{#operations}}
{{#operation}}

### {{#summary}}{{summary}}{{/summary}}
# @name {{operationId}}
{{httpMethod}} {{basePath}}{{path}}
{{#consumes}}Content-Type: {{{mediaType}}}
{{/consumes}}
{{/operation}}
{{/operations}}

We can see it clearly if we look at the object during processing

Note: Unfortunately, to my knowledge the best way to dive into the data model is still to go pause at runtime, I haven't yet found a complete data model documentation online. If you do, let me know!

Let's rerun the generation and see what we get now :

$ ./mvnw package 
$ ./bin/generate-samples.sh bin/configs/java-magazine-client-petstore-new.yaml

Great! Only API files, and one per API, as wanted. Let's see what they contain!

## PetApi

### Add a new pet to the store
# @name addPet
POST http://petstore.swagger.io/v2/pet
Content-Type: application/json
Content-Type: application/xml

### Deletes a pet
# @name deletePet
DELETE http://petstore.swagger.io/v2/pet/{petId}

Looks great to me! Let's try to run one of the calls

It works just fine, and we get a 200 response as well. Success!

Now, there's only one little issue. The variables!  In the Jetbrains HTTP Client format, variables are written as {{variable}}. OpenAPI implementations only have single braces. We need to fix that!

What we'll be doing here is implement a custom mustache lambda that doubles up the braces when it finds them. The lambda is essentially a string replacement

public static class DoubleMustacheLambda implements Mustache.Lambda {
        @Override
        public void execute(Template.Fragment fragment, Writer writer) throws IOException {
            String text = fragment.execute();
            writer.write(text
                    .replaceAll("\\{", "{{")
                    .replaceAll("}", "}}")
            );
        }
    }

In order to make it available in our Generator, the openapi generator library offers the same mechanism as for the rest : We have to override a ready-made method.

    @Override
    protected ImmutableMap.Builder<String, Mustache.Lambda> addMustacheLambdas() {

        return super.addMustacheLambdas()
                .put("doubleMustache", new JavaMagazineClientClientCodegen.DoubleMustacheLambda());
    }

The code above is added to our JavaMagazineClientClientCodegen class.

Next, we also need to modify our mustache template to add that lambda at the right location (around the path parameter). If that path is a variable, the braces will then be doubled

## {{classname}}
{{#operations}}
{{#operation}}

### {{#summary}}{{summary}}{{/summary}}
# @name {{operationId}}
{{httpMethod}} {{basePath}}{{#lambda.doubleMustache}}{{path}}{{/lambda.doubleMustache}}
{{#consumes}}Content-Type: {{{mediaType}}}
{{/consumes}}
{{/operation}}
{{/operations}}

Et voilà! Running the sample again, we can now use variables as they are meant to be inside IntelliJ!

In the sample below, I'm using the following local environment file :

{
  "dev": {
    "petId": 3
  }
}

There is still a lot more to do with this generator. READMEs, payload, auth, headers, … But now it's a matter of updating the mustache files as we want.

I'd love to have a more fleshed out generator, because it'd be an amazing and cheap way together with the client CLI to have a great automated integration tests pipeline and get people running in second with your API.

I hope this article made you feel like trying to create your own OpenAPI generator. The only limit is your imagination! And as you can see, the merging process is actually relatively pleasant, because the volunteers of the project LOVE to see people bringing out new ideas to life.

Happy to hear your thoughts, as always!

TL;DR : You can run a full Supabase instance inside Test Containers quite easily. See this repository.

In my last article, I was listing a few attempts I had done at running tests against my Kotlin Supabase application. The way the Supabase-Kt library is built makes it hard to mock, and I ended up building a minimal Docker Compose setup that was mimicking a Supabase instance.

In this second part, we're gonna push the madness further and actually run a FULL SUPABASE instance locally, still using Test Containers.

Right after I finished pushing my repository last week, I realised that Supabase actually offered a Docker Compose file to self-host their platform. So I decided to push the madness further and see how easy it was to use that file inside TestContainers. In short : Relatively easy.

The setup

The setup isn't actually much different from my homecrafted Docker Compose. version. Here it is in its entirety.

A few notable things:

• I'm relying on a local clone of Supabase, and point a ComposeContainer to the src/test/resources/supabase/docker/docker-compose.yml file.
• The setup uses an .env file, so I use a dotenv implementation to grab the parameters there and make the code slightly dynamic.
• I have to run a database statement to populate and flush my database in between tests. The Docker Compose setup from Supabase comes with persistent volumes, which needs to be accounted for.
• I don't have test for those here, but all services (auth, functions, storage), ... should actually be supported, given that we're running a full local instance.

import io.github.cdimascio.dotenv.dotenv
import io.github.jan.supabase.SupabaseClient
import io.github.jan.supabase.createSupabaseClient
import io.github.jan.supabase.postgrest.Postgrest
import kotlinx.coroutines.runBlocking
import org.junit.jupiter.api.AfterAll
import org.junit.jupiter.api.Assertions.assertEquals
import org.junit.jupiter.api.BeforeAll
import org.junit.jupiter.api.Test
import org.testcontainers.containers.ComposeContainer
import org.testcontainers.junit.jupiter.Container
import org.testcontainers.junit.jupiter.Testcontainers
import java.io.File
import java.sql.DriverManager


@Testcontainers
class MainKtTest {

    @Test
    fun testEmptyPersonTable(){
        runBlocking {
            val result = getPerson(supabaseClient)
            assertEquals(0, result.size)
        }
    }

    @Test
    fun testSavePersonAndRetrieve(){
        val randomPersons = listOf(Person("Jan", 30), Person("Jane", 42))

        runBlocking {
            val result = savePerson(randomPersons, supabaseClient)
            assertEquals(2, result.size)
            assertEquals(randomPersons, result.map { it.toPerson() })

            val fetchResult = getPerson(supabaseClient)
            assertEquals(2, fetchResult.size)
            assertEquals(randomPersons, fetchResult.map { it.toPerson() })
        }
    }

    companion object {

        private const val DOCKER_COMPOSE_FILE = "src/test/resources/supabase/docker/docker-compose.yml"
        private const val ENV_LOCATION = "src/test/resources/supabase/docker/.env" // We grab the JWT token from here

        val dotenv = dotenv{
            directory = File(ENV_LOCATION).toString()
        }

        private val jwtToken = dotenv["SERVICE_ROLE_KEY"]
        private val dbPassword = dotenv["POSTGRES_PASSWORD"]
        private val db = dotenv["POSTGRES_DB"]

        private lateinit var supabaseClient: SupabaseClient

        @Container
        var container: ComposeContainer = ComposeContainer(File(DOCKER_COMPOSE_FILE))
            .withExposedService("kong", 8000)
            .withExposedService("db", 5432)   // Handy but not required

        @JvmStatic
        @AfterAll
        fun tearDown() {
            val dbUrl = container.getServiceHost("db", 5432) + ":" + container.getServicePort("db", 5432)

            val jdbcUrl = "jdbc:postgresql://$dbUrl/$db"
            val connection = DriverManager.getConnection(jdbcUrl, "postgres", dbPassword)

            try {
                val query = connection.prepareStatement(
                    """
            drop table public.person;
        """
                )

                query.executeQuery()
            } catch (ex: Exception) {
                println(ex)
            }
        }

        @JvmStatic
        @BeforeAll
        fun setUp() {
            val supabaseUrl = container.getServiceHost("kong", 8000) + ":" + container.getServicePort("kong", 8000)
            val dbUrl = container.getServiceHost("db", 5432) + ":" + container.getServicePort("db", 5432)

            supabaseClient = createSupabaseClient(
                supabaseUrl = "http://$supabaseUrl",
                supabaseKey = jwtToken
            ) {
                install(Postgrest)
            }

            val jdbcUrl = "jdbc:postgresql://$dbUrl/$db"
            val connection = DriverManager.getConnection(jdbcUrl, "postgres", dbPassword)


            try {
                val query = connection.prepareStatement(
                    """
                create table
                    public.person (
                                    id bigint generated by default as identity not null,
                                    timestamp timestamp with time zone null default now(),
                                    name character varying null,
                                    age bigint null
                ) tablespace pg_default;
                """
                )

                query.executeQuery()
            } catch (ex: Exception) {
                println("Error is fine here. This should actually run only once")
                println(ex) // Might be fine, this should actually run only once
            }
        }
    }
}

To achieve those results, a few manual steps are required. The Docker Compose file provided by Supabase uses container_name parameters, which aren't supported by Test Containers.

I needed to :

• Clone the Supabase repository locally
• Copy the env file
• Run some magic to remove container_name
• Once in a while, the Supabase repository will have to be pulled

The results

The results are as outrageous as I expected them to be, if not more : All tests are running fine, though it takes almost 1 minute to run them. The ComposeContainer is starting no less than 12 containers (!!!) so it is to be expected.

Obviously, that setup is not to be used for unit testing. That being said, I find it absolutely freaking cool to be able to recreate your complete environment locally that easily, and I'd definitely consider that an option for bigger integration tests. The confidence I didn't have with my home brewed Docker Compose file is much higher now, given that it's directly provided by Supabase. No network needed to run my tests, pretty cool.

What more

My original complete intent was to build a small layer on top of the Docker Compose file, kinda like AtomoicJar does it with its modules. It would have been cool to have a simple interface for a Supabase instance to start, while providing a locally for starting scripts, user roles, maybe a new set of credentials, ...

Here is how they describe it for NGinx for example. I would have loved to have something similar :

@Rule
public NginxContainer<?> nginx = new NginxContainer<>(NGINX_IMAGE)
    .withCopyFileToContainer(MountableFile.forHostPath(tmpDirectory), "/usr/share/nginx/html")
    .waitingFor(new HttpWaitStrategy());

All of the implementation I've seen extend from GenericContainer though, not ComposeContainer so I've decided to hold that off and keep it simple for now.

Could maybe be something for the future, who knows.

In conclusion

That was a fun experiment, in which I've learnt more about TestContainers 😊. I'm as happy as usual with the way Supabase shows love for their users. Providing a seemless Docker Compose like this allows for a great experience. And I'm also impressed with TestContainers and how they can run such complex flaws without breaking a sweat!

If anything, I'd like them to at least ignore the container_name parameter if possible. I've seen many folks being blocked by it, and I can imagine many cases, like this one where people are not in control of their compose file. I don't necessarily ask for support, but an option to ignore without throwing an exception would be great.

That's it folks, till next time!

TL;DR : The easiest way I found to test my database service is to mimick Supabase using Docker Compose and Test Containers. Here's the code

(Also, have a look at Part 2 of that blog here).

In case you don't know it, I'm a big fan of Supabase. I love that they're a viable alternative to Firebase. I love that they're built on top of Open-Source pieces. I love how innovative they are, and how much they give back to the community. And as you already know it, I love Kotlin as well.

Lately, I've been building a side-project which consists of a Ktor webapp, and uses Supabase-Kt to communicate with the database. I've been looking into ways to test my Kotlin component that interacts with the database, and it's been harder than expected.

In this article, I'll dive into several methods I've been looking into and why I finally decided to go for a Docker Compose / Test Containers solution. You can check the example repository here AND THE FINAL CODE HERE.

What I want to achieve

Let's imagine a minimal code example that contains a Person data class, and wants to save/fetch persons via a SupabaseClient. It can look like this:

@Serializable
data class Person (val name: String, val age: Int)

@Serializable
data class ResultPerson (
    val id: Int,
    val name: String,
    val age: Int,
    val timestamp: String
)

fun main() {
    val supabaseClient = createSupabaseClient(
        supabaseUrl = "",
        supabaseKey = ""
    ) {install(Postgrest)}

    runBlocking {
        savePerson(listOf(Person("Jan", 30), Person("Jane", 42)), supabaseClient)
    }
}

suspend fun getPerson(client: SupabaseClient): List<ResultPerson> {
    return client
        .postgrest["person"]
        .select().decodeList<ResultPerson>()
        .filter { it.age > 18 }
}


suspend fun savePerson(persons: List<Person>, client: SupabaseClient): List<ResultPerson> {
    val adults = persons.filter { it.age > 18 }

    return client
        .postgrest["person"]
        .insert(adults)
        .decodeList<ResultPerson>()
}

The SQL definition of our table looks like this

create table
    public.person (
                    id bigint generated by default as identity not null,
                    timestamp timestamp with time zone null default now(),
                    name character varying null,
                    age bigint null
) tablespace pg_default;

We want to be able to test that our functions behave properly. For the sake of this minimal example, I've decided to filter all non adults, but you can imagine any other use case where the functions contain some business logic.

First attempt : Mock Supabase

When unit testing code using third parties that I don't have control over, my first reflex is to try and mock it.

It stopped being fun really quickly. The Supabase-Kt library is making use of a lot of inline function and I ended up having to  mock more and more parts of the library and never managed to get a functional tests.

The short version is that because they are as the name indicates, inlined, inline functions cannot be mocked in Kotlin. So that was the end of that experiment

The MainKtTestMock file of my example repository reflects that attempt.

class MainKtTestMock {

    private lateinit var supabaseClient : SupabaseClient

    @BeforeTest
    fun setUp() {

        supabaseClient = mockk<SupabaseClient>()
        val postgrest = mockk<Postgrest>()
        val postgrestBuilder = mockk<PostgrestBuilder>()
        val postgrestResult = PostgrestResult(body = null, headers = Headers.Empty)

        every { supabaseClient.postgrest } returns postgrest
        every { postgrest["path"] } returns postgrestBuilder
        coEvery { postgrestBuilder.insert(values = any<List<Path>>()) } returns postgrestResult
    }

    @Test
    fun testSavePerson(){
        val randomPersons = listOf(Person("Jan", 30), Person("Jane", 42))

        runBlocking {
            val result = savePerson(randomPersons, supabaseClient)
            assertEquals(2, result.size)
            assertEquals(randomPersons, result.map { it.toPerson() })
        }
    }
}

Here's the final error I encountered :

java.lang.IllegalStateException: Plugin rest not installed or not of type Postgrest. Consider installing Postgrest within your supabase client builder
	at io.github.jan.supabase.postgrest.PostgrestKt.getPostgrest(Postgrest.kt:172)
	at MainKtTestMock$setUp$1.invoke(MainKtTestMock.kt:34)
	at MainKtTestMock$setUp$1.invoke(MainKtTestMock.kt:34)

Second attempt: Encapsulate the Supabase Client

My second attempt was to get around the problem by encapsulating the problematic client inside a class of mine that I can then control.

It can be as simple as this :

class DatabaseClient(private val client: SupabaseClient){
    suspend fun savePerson(persons: List<Person>): List<ResultPerson> {
        val adults = persons.filter { it.age > 18 }

        return client
            .postgrest["person"]
            .insert(adults)
            .decodeList<ResultPerson>()
    }
}

And my test can then look like this (see MainKtTestSubclass):

class MainKtTestSubclass {

    private lateinit var client : DatabaseClient

    @BeforeTest
    fun setUp() {
        client = mockk<DatabaseClient>()
        coEvery { client.savePerson(any<List<Person>>()) } returns listOf(ResultPerson(2, "name_2", 2, "timestamp_2"))
    }

    @Test
    fun testSavePerson(){
        val fakePersons = listOf(Person("name_1", 1), Person("name_2", 2))

        runBlocking {
            val result = client.savePerson(fakePersons)
            assertEquals(2, result.size)
        }
    }
}

My main issue now is that because I have to indicate every single time what my output should be. It also just displaces the problem, because I don't really have any nice and clean way to check that my business logic works as intended, since I'm mocking it.

Third attempt : Ktor mock

The main contributor of the project gave another possible workaround in the GitHub issue I created : mock the internal Ktor engine of the Supabase client.

See the MainKtTestMockEngine :

class MainKtTestMockEngine {

    private val supabaseClient : SupabaseClient = createSupabaseClient("", "",) {
        httpEngine = MockEngine { _ ->
            respond(Json.encodeToString(Person.serializer(), Person("name_1", 16)))
        }
    }

    @Test
    fun testSavePerson(){
        val randomPersons = listOf(Person("Jan", 30), Person("Jane", 42))

        runBlocking {
            val result = savePerson(randomPersons, supabaseClient)
            assertEquals(2, result.size)
            assertEquals(randomPersons, result.map { it.toPerson() })
        }
    }
}

This is actually not a bad idea, it's light and it gets the job done is a clear and readable way. Those tests are also fast to run.

My main issue with this method would be that to test my business logic I'd have to dive into the received requests of the mock engine every time, which is a little cumbersome and prone to lots of maintenance.

I do want to investigate it further though.

Proposed solution : Test Supabase db

Now, one semi obvious solution would be to fire up a test database in supabase itself, and test there!

That'd work. I even do it to test my release deployments!

It has some obvious downsides though:

• We couldn't be further away from unit tests, since we're testing on the cloud
• Tests run slower, require internet, and also require a setup database. Cleanup can also be a mess
• I'd be terrified to run that against the wrong database
• It uses my bandwidth and projects, that either are limited, or I have to pay for!

Final solution : Docker Compose and Test Containers

I had one last idea, and that's the one I've decided to stick with for now. It leverages the fact that at its core, Supabase is built on a lot of Open-Source. And when we're using the Supabase client, we're essentially interacting with a glorified PostgreSQL / postgrest combo!

I've decided to create a Docker Compose setup that would mimick the actual Supabase production setup and connect to this instead.

A few things had to be taken into account for this to work :

• I had to redirect all my postgrest calls to /rest/v1, which is the path that Supabase expects. So a GET on /persons should actually be on /rest/v1/persons.
• postgrest uses JSON Web Tokens for authentication, so we have to set that up as part of the test class.

One last thing to note is that I would have to do MORE work in case I start using any of the other services of Supabase (say auth for example).

The Docker Compose setup looks like this :

version: '3'

services:
  ################
  # postgrest-db #
  ################
  postgrest-db:
    image: postgres:16-alpine
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=${POSTGRES_DB}
      - DB_SCHEMA=${DB_SCHEMA}
    volumes:
      - "./initdb:/docker-entrypoint-initdb.d"
    networks:
      - postgrest-backend
    restart: always

  #############
  # postgrest #
  #############
  postgrest:
    image: postgrest/postgrest:latest
    ports:
      - "3000:3000"
    environment:
      - PGRST_DB_URI=postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgrest-db:5432/${POSTGRES_DB}
      - PGRST_DB_SCHEMA=${DB_SCHEMA}
      - PGRST_DB_ANON_ROLE=${DB_ANON_ROLE}
      - PGRST_JWT_SECRET=${PGRST_JWT_SECRET}
    networks:
      - postgrest-backend
    restart: always

  #############
  # Nginx     #
  #############
  nginx:
    image: nginx:alpine
    restart: always
    tty: true
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
    ports:
      - "80:80"
      - "443:443"
    networks:
      - postgrest-backend

networks:
  postgrest-backend:
    driver: bridge

Note that a few auxiliary files are needed for this to work. You can find everything in the test/resources folder of the example GitHub repository.

There is :

• A short nginx.conf file.
• An SQL file to setup the database (note that in my actual repo, this guy already exists since I need it to setup production :)).
• a .env file to list all my environment variables

Once that is done, it is already possible to run $ docker-compose up -d and to run your application against localhost like if you were interacting with the real Supabase.  (don't forget to call $docker-compose down --remove-orphans -v to kill and delete all containers once you're done).

To make the magic complete, we're gonna use the power of TestContainers to run this as unit/integration tests. My final MainKtTestTestContainers test class looks like this :

import io.github.jan.supabase.SupabaseClient
import io.github.jan.supabase.createSupabaseClient
import io.github.jan.supabase.postgrest.Postgrest
import kotlinx.coroutines.runBlocking
import org.junit.jupiter.api.Assertions.assertEquals
import org.junit.jupiter.api.BeforeEach
import org.junit.jupiter.api.Test
import org.testcontainers.containers.ComposeContainer
import org.testcontainers.junit.jupiter.Container
import org.testcontainers.junit.jupiter.Testcontainers
import java.io.File

@Testcontainers
class MainKtTestTestContainers {

    // The jwt token is calculated manually (https://jwt.io/) based on the private key in the docker-compose.yml file, and a payload of {"role":"postgres"} to match the user in the database
    private val jwtToken = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjoicG9zdGdyZXMifQ.88jCdmcEuy2McbdwKPmuazNRD-dyD65WYeKIONDXlxg"

    private lateinit var supabaseClient: SupabaseClient

    @Container
    var environment: ComposeContainer =
        ComposeContainer(File("src/test/resources/docker-compose.yml"))
            .withExposedService("postgrest-db", 5432)
            .withExposedService("postgrest", 3000)
            .withExposedService("nginx", 80)

    @BeforeEach
    fun setUp() {
        val fakeSupabaseUrl = environment.getServiceHost("nginx", 80) +
                ":" + environment.getServicePort("nginx", 80)

        supabaseClient = createSupabaseClient(
            supabaseUrl = "http://$fakeSupabaseUrl",
            supabaseKey = jwtToken
        ) {
            install(Postgrest)
        }
    }

    @Test
    fun testEmptyPersonTable(){
        runBlocking {
            val result = getPerson(supabaseClient)
            assertEquals(0, result.size)
        }
    }

    @Test
    fun testSavePersonAndRetrieve(){
        val randomPersons = listOf(Person("Jan", 30), Person("Jane", 42))

        runBlocking {
            val result = savePerson(randomPersons, supabaseClient)
            assertEquals(2, result.size)
            assertEquals(randomPersons, result.map { it.toPerson() })

            val fetchResult = getPerson(supabaseClient)
            assertEquals(2, fetchResult.size)
            assertEquals(randomPersons, fetchResult.map { it.toPerson() })
        }
    }
}

All of the magic happens at the beginning, to setup a fake Supabase URL and connect to it. Once that is done, we can write our tests as easily as ever, since we're actually interacting with an actual light Supabase clone! (For reference, the tests take about 2 seconds to run on my machine)

A word of conclusion

It took me a little while to get all these tests running, but I'm very happy about the final result. It might not be the best solution for production grade apps, but the trade off of running test containers for my side project definitely makes up for the fact that I literally have no boilerplate to run and can avoid using mocks.

I'll check in the future how much I can extend the docker compose image as I get to use more Supabase services. Maybe it would be nice of Supabase to offer that image themselves so we can test easily and avoid using the cloud where not necessary :).

Check here for part 2 of the article.

This blog is not meant to judge anyone, nor to make anyone feel guilty in any way. Apologies if it comes out the wrong way.

What I mean to share here is a personal journey we've embarked on as a family a couple years back. I do realise how privileged we are to be able to have such a position. Oh and by the way I'm always looking for ways to do better, so please do voice your opinion if you have good ideas.

It's quite clear by now that we humans have a strong impact on the Earth's  climate. And it's also quite clear things aren't changing as fast as they need to to make a meaningful difference globally.

As a new Developer Advocate (I've only been in the field for two years officially), my impact on the world around me is something I keep in the back of my head pretty much every day. I want to go with you through some of these thoughts today.

Advocating through individual actions?

As an individual, there are a few directions you can go to reduce your impact on climate:

• Individual actions : That's the easiest thing to do, but also what has the least amount of impact. Reducing your footprint might feel good, but it doesn't really help in the grand scheme of things.
• Group actions : Voting, supporting political groups, protesting, boycotting, ... Basically helping change the system any way you can as a part of society.

Thing is, part of my job as a Developer Advocate is to be public. Of course, I'm not a Kylian Mbappé, or a Rihanna, ... I'm pretty much a nobody. But I still have a voice in certain niches. Through my job I am spending some of my time in online communities. I like to believe that my individual actions (and those of my family) can ripple to others because I have a few means of promoting them around me.

In this blog, I will focus on the individual actions that I do to reduce my impact on the climate. I'll also limit myself  to the ones that have a relationship with my job as Developer Advocate. I won't go into investing or producing food for example. I have enough other blogs on these topics 😊.

Traveling, conferences and the airport's life

Most of the Developer Advocates I meet are public folks. They travel A LOT. If you want to maximize your presence as a Developer Advocate, you want to participate in as many events as possible; which typically means flying. The funny thing is, often the public figures are the same from one conference to the next; meaning that as a speaker 60% of the folks you meet are the same in Germany as they were in UK the week before.

I can't help but think how destructive we are as a group living this completely unsustainable way of living. "it's part of the job". When I see " ATL ✈️ CDG ✈️ TYO✈️ WLG ✈️  AMS ✈️ ATL" on my favourite social media, the first thing I think is that this flight path alone would place me in the top 1% of flyers worldwide.

I've managed to not board a plane since 2019. Not for holidays, not for work. If I go to a conference, I'll take the train to go there. If I can't, well then I'll either send someone who lives closer, or simply not go. And it's not even a sacrifice, actually. I love the train. I can work in it, read books, no security gates to go through, or rough passport control, not dumb dumb 2 hours before rule, no shoes removal involved. The only thing I may miss is the mini bar, but that's a me thing 🍾.

I'm not saying I'll never fly. That'd be hypocritical. For example I dream of visiting Korea. But I want to reduce it as much as I can, for as long as I can because it's by far the easiest way to cut my emissions. Flying accounted for 40% of my yearly footprint until 2019. And I wasn't a Developer Advocate yet back then. This is something I made clear when joining my current employer, and they agreed. If we have to go to many conferences overseas, we'll hire a developer advocate over there to do the work.

And to be fair, it's not like our company suffers from this. Instead of travelling, we're releasing more samples, more content, more experiments, and I sincerely think we're simply serving our customers better. Most of them don't go to conferences. They want stuff that works well, with a good developer experience, that is well documented, and feel welcome with the product. Heck, it's even more inclusive in a way : Not everyone can afford to take days off and travel to go and see you. Online content is available for everyone to see, and it's more scalable by definition. Of course, this is personal experience and your mileage may vary.

One of the things that infuriates me though, is that even to this day flying is the cheapest option anywhere. Taking the train from Amsterdam to Barcelona takes me 2 days and costs 400 euros, while flying there is 30 euros and only 2 hours. Our governments have to do better...

One last thing : Until about 100 years ago, we've never been used to travel that much. People would do one trip to Italy in their life, and be amazed. Travelling has become a complete commodity. But we've also never been as connected as today! Phones, internet, apps, MOOCs, videos, ... There are so many ways to stay in contact with each other. There has to be better options than flying somewhere to do my advocacy!

The picture is not all dark though, I've seen several people doing so much better than me, like Liz Rice biking to go to a conference in April 🤯. There are many other folks as well taking the train to travel.

About conference planning

Conference planning is a hard problem. Most people go to only a few conferences a year. And they're going to the most appealing ones. If you can get huge names to come to your conference, it's typically a nice way to ensure your tickets are sold. I hear that problem very much, especially post COVID where many conference organisers have piled up huge costs due to unexpected cancellations.

At the same time, I have seen some things at conferences that sometimes disturbed me. Without having to be political, conferences are definitely a place where organisers can send a strong message. The huge majority of the talks I have given that were climate related either happened in the very first slot of the morning before most people wake up, or in the last slot while most of the attendees were already enjoying some beer.

In one instance, I gave a climate related talk at 8h in the morning. That talk was followed by 3 cryptos talks. In another case, I've seen someone give a "reduce your CO2 emissions in the cloud" talk. That person flew all the way from South America to Europe to give a talk to 40 people. As much as I appreciated the chat, I found it hard to believe that one of the main cloud companies in the world didn't have someone in Europe at the ready to give that talk. That hampered the message of the speaker by a lot to me.

Again, I'm not complaining at all about my spot in the conferences here. There are gazillions of speakers better than me 😊. My main point is that the programmation of talks is definitely sending a message to a huge amount of humans at the same time. Conferences aren't typically very clean events in terms of emissions or amount of waste produced. Maybe we can make them matter even more?

The past years, I've been part of redaction commissions for magazines, and in the review committee of a few conferences. Without being completely biased, that's one of the places where I can help sending a message. Having more local speakers, inviting speakers with strong topics on stage, .... (And this goes for much more than climate by the way, diversity, inclusion, ...).

Again, the picture is not completely dark. I've seen great examples of conferences who really outdid themselves to make sure that all the messaging was aligned from one end to the other. There are many great examples, but the best I have seen is DevFestLille. Vegetarian options by default, with reusable cutlery, an adapted programmation, speaker dinner in a local restaurant using locally produced food, sustainable gifts and more... They go much deeper than this, putting accessibility and inclusivity at the core of their values. I admire that conference. Check it out.

Who to work for?

Here's another one of my main struggles: As a Developer Advocate, you're by definition at the forefront of your company and how it presents itself to developers. As such, it is crucial that you're in line with the values they represent.

I am fortunate with the fact that this is something that I really find at Adyen today. Of course, Adyen is here to make profit, but that's obviously OK and I'm definitely here to help. What's important (for me) is that it does it in an ethical, sustainable way. And in this sense it does much more than the large majority of the companies I've been working for. I don't want to blatantly sound like I'm promoting Adyen here, but "building an ethical business and driving sustainable growth for our merchants" is one of the core principles of Adyen since its inception. And it also adds words to action. For example Adyen dedicates 1% of its net revenue to programs that are meant to positively impact ESGs in line with the UN SDG commitment. And it combines global action like this, with local actions on the ground. It also accomodates with my travel choices, as long as it doesn't impact my work. Of course, it's always possible to do more. But it's more than I've ever seen in my career so far.

There's a whole lot of other jobs in DevRel in the industry and I can't say that I associate with all of them. There's been a large amount of advocacy positions open in Web 3, Crypto and NFT related tech lately for example. Historically, those technologies are not particularly known for their clean or efficient computing. Finding positions that line up with my values, is something that I personally struggle with at times,  

I do see some VERY interesting positions as well though. For example, I admire Asim Hussain's work and the Green Software Foundation he founded. Most cloud providers are heavily invested in reducing their and their customer's footprints. That's partly why they love your serverless workloads so much 😅.  

Another example who brightened my day a while back is Jamund, finding his way into sustainability at AWS :

I have been looking for opportunities in the sustainability domain, but fact of the matter is there doesn't seem to be much yet for Developer Advocates (and DevRel in general).

We're in a great position to challenge the status quo

It may not be true for everyone, but turns out most of us are compensated very well. Of course, I'm not saying we're rich. There's still rent to pay, tuition for the kids, supporting folks around you, ... Especially given how shaky the industry has been the past year. I'm not saying any of us has it easy. That being said, looking at the world inequality database humbled me. I am in a favored position to make a difference on the market, simply because I have enough wealth to have all my major needs fulfilled and I have a platform available to me.

I was impressed to see the impact that many Developer Advocates did supporting Ukraine the past year for example. People like Alina are inspiring. As I was saying above, Asim is also a great example for substainability. As shown in the past, we are in a position to help make a difference.  

Educating yourself, and listening to others

One of the nice things of being a Developer Advocate is that whether physically or virtually, you get to meet a lot of people. And your job is pretty much to learn new stuff and share it. I like that as part of my profile I get to share some of the things I've learnt about climate and sustainability. I've given talks on the topic, I've raised awareness internally and externally. I've been sharing our journey online.

Of course, many are doing it much better than me, and I am very well aware that posting photos of potatoes won't fix the climate crisis. But I've met people along the way who gave me energy to do more, try new things, learn new stuff. We animated a panel last years with 3 other folks on sustainability in tech. I've helped run an online conference dedicated to Simpler and Cleaner Tech.

In France we say "les petits ruisseaux font les grandes rivières" ("They say that small streams make big rivers."). My only goal is to be surrounded by many more of those little streams 😊. Not to feel good about myself and not feel guilty. But more as a way to do ever better every day.

But why do this job at all then?

Some of you might ask "but after all those issues, why be a Developer Advocate at all then"? And that'd be a great question. I ask it to myself every day.

And the answer is relatively short as well : because I absolutely love my job to bits, and it took me years to find something that I liked, that someone would pay me for, and that I'd be good at. I do think that we're also something the world needs. Human seek connection, and we have a role to play there. Given all of the positive examples I've given above from all those inspiring folks, I  do see a way to do my job in a way that lines up with my internal voice. You all inspire me to do better every day.

That's it for now. I really hope this blog doesn't come as moralizing; that really wasn't the point, quite the opposite. I'll be at DevRelCon next week, maybe we can chat there (or in the train on the way 😛). Or any other time, you can hit me on Twitter, Mastodon, or by subscribing :).

And if you've recently been laid off, and are still searching for a new gig; I'm so sorry. The industry hasn't been great for us the past year. If that helps I know that Adyen is searching for a Team Lead Internal Developer Advocacy and a friend of mine at DHL is searching for an internal Developer Advocate in the Netherlands to kickstart their advocacy program. Hit me up.

Cheers,

Julien

The past week, KotlinConf took place in Amsterdam. It was my very first KotlinConf ever, and to be fair I had been excitingly waiting for it for a long time 😊.I'll be trying to share some of my excitement as well as my impressions here. This post is obviously biased, for official news I recommend you directly go to the source!

The community

The first and main reason for me to go to the conference was to meet all the community again, as always. I've had a glimpse of it a couple months back at the GDE summit, but even more people were there this time 😊.
Many known faces of course, from Louis to James, Duncan, Trisha or Amanda, who was also speaker at the very first conference I spoke at (in Belarus, how times change...) but also so many people I know online for a long time and who I finally got to meet. Isa, a content creator from Spain, Sebastian, which content I follow not only because of the Kotlin magic but also to learn more about the craft of content creation itself. And I finally got to meet Margaryta, who introduced me to the GDE program and came with the whole family (seriously though, more kids at conferences!)

Somehow, I still didn't manage to Josh and Svetlana ^^. That'll be for another time.

And of course, there's all the new folks. Most notably Salih, we nerded about developer advocacy and leadership.

The new stuff

The Keynote announcements were quite exciting to be honest. From the announcement of Kotlin Notebooks (been wishing for this for a long time, try them out!), to obviously the K2 compiler and much of the goodies that come with it. The notebooks announcement (as well as some of the ML/AI related talks at the conference) also hint at Kotlin becoming a potential alternative for Python for ML engineers out there in the future. Why not?
I care a lot about the language features but even more about the ecosystem, and seeing more companies joining the Kotlin Foundation was the best news of the day to me. It is a great step for a long living healthy language and I'm sure it'll help drive adoption further.

The venue

I really liked all of the sponsors that were present at the event. The venue was also dope for me, with a large Jetbrains booth in the middle stuffed with Product and Engineering folks. After all, Kotlin is a creation of Jetbrains and having the product smack in the middle of everyone with demos running at all times was super cool. Of course, you know me as a big Jetbrains fan so it was really a nerd fest for me.

Sponsors also made a lot of sense, and I liked that they were from various industries and domains. Hardware, Multiplatform, server, small and big companies, they were all represented and that was really cool.

Quite a few of the companies who also have a large impact on the community via their contributions made it a strong part of their booth and I liked it a lot. From Xebia (47deg) with Arrow, Kodein or even http4K, it was nice to have strong players present as well and see industry support for the ecosystem.  It is obviously a big PR and recruitment move for them, but hey I find it smart and it's a strong win/win situation in my opinion.

The sessions

I spent most of my time roaming around talking to people, so I won't describe all of the sessions I joined but instead I want to give some items which I really liked or who caught my attention particularly.

First, I wanna start with the one session which was an absolute blast for me : Video Game Hacking using Kotlin/Native by Ignat Beresnev. It was fun, entertaining, I've learnt stuff, delivery was amazing and the topic was great as well. Surprisingly, it packed a whole lot of punch for a lightning talk. Honestly though, what's more fun that learning about memory hacking and seeing cars appear straight in GTA, all of that in Kotlin. The presentation is full of well timed jokes, and honestly it grew me as a speaker. I can't recommend it enough.

Then, there was the crash course on compilers by my colleague Amanda. Damn, it's impressive to see deep dive talks from people who are really passionate about their craft. Imposter syndrome hit hard there, and the room was absolutely packed! I have to admit that the topic was quite far from my usual dabblings and I'm still unsure what I could build a compiler plugin for ^^, but I've definitely learnt a lot about how Kotlin works under the hood!

Compose, compose and compose

You probably know it, I'm a backend guy. I make do with frontend if I have to, mostly using Web Components. I tried Compose back in the past, mostly for web but I really never got excited about it. I mean, I really do like the components idea and the language is a blast but maybe it was too early. Things weren't documented as much as I wanted to, reloading was slow, tooling wasn't quite there yet, ... I really wasn't reaching the experience that I wanted.

I have to say however that they did manage to hype me up for it again during the conference.

First, Sebastian Aigner adnd Nikita Lipsky announcing Compose Multiplatform on iOS with a banging demo and a flawless (and fun) distribution.
Then John O'Reilly and Martin Bonnin building a Kotlin Multiplatform conference app in 40min live on stage. I mean, of course those speakers rock, they're seasoned and it's clear they're having a blast on stage. But it's also hard not to get seduced seeing so much code reuse between the front and the backend of an app and seeing it run both on android and iOS in minutes.

I also went to see Victor Kropp talk about how they used compose to build the Jetbrains toolbox (use it if you don't yet, it's great!). The toolbox is one application that I quite admire, it's lean and mean while still getting the job done. It's always there for you and damn, it's pretty. So when I learnt it was built using Jetpack Compose for Desktop, my interest for compose obviously grew even more.

Finally, adding the Compose for web demos (using WASM) constantly running on the Jetbrains booth, it's hard not to get a little excited about the future for Kotlin.
I've been into the industry for a little while and one learns to be pessimistic and cautious over time, but has the time finally coming where I can use one language (that I love, sorry Javascript) across all my stacks?

How much compose is too much though?

One thing however bothered me a little bit during the conference, is the amount of Kotlin Multiplatform / Android relative to the server content that was present there. In terms of content, sessions, but also sponsors and visitors. I might be biased really, because that's something that I seem to see in the ecosystem already. Let's have a quick look at it.

The numbers I'm about to give are not precise, because the frontier between Multiplatform and backend is not always crystal clear, but if we look at the ~80 talks present at the conference, I counted about 20 compose related talked, and 30 backend related ones. The rest is either compiler, platform, community, ... related.
It's honestly better than I was expecting, much likely because I used the conference as an opportunity to learn more about Compose.
Out of those 30 backend talks though, more than 12 of those are coroutines related one way or another. That's massive and there's clearly something to see here ^^.

If we look at the Kotlin Foundation partners, the Kotlin partners are Jetbrains, Google, and the newly announced ones are Gradle, Shopify and Touchlab.
Of course, all of those are invested in backend as well with Kotlin being the default for backend at Google those days for example. But even keeping Jetbrains apart (even though it obviously is MASSIVELY invested in KMM), touchlabs and shopify are heavily weighting in the KMM ecosystem. And Google is obviously behind most of the Jetpack Compose and Android technologies. That leaves us with Gradle, which arguably is mostly involved in tooling.
It might be too black and white statement, but as far as I see today most of the partners are more influential in the KMM part of the ecosystem.

Obviously, as I mentioned this is a bet that I'd love to see succeed. The more successful KMM is, the better the whole ecosystem will become. At the same time, I can't stop thinking that there is SO MUCH backend Java going on out there, it feels a little like a missed opportunity. Java is also has been getting a fresh look lately with the faster release cadence and the accrued amount of DevRel going on around it. It looks to me like backend folks aren't being seduced by the language as much as they could be.

In any case, KotlinConf was an amazing experience for me, it was really great to be around so many folks in the ecosystem and seeing how vibrant it becomes over time. And a big thanks to Jetbrains for all of the hard work. Definitely count me in for next time :).

See ya!
Julien

TL;DR : I've created the first version of an openapi-generator for the jetbrains HTTP Client, and together with the CLI runner it allows you to play against APIs without ever going out of your terminal and it can even run in your CI/CD pipeline. See repository here

I work a lot with APIs, whether for an app I develop myself, or to interact with others. Most people I know tend to use Postman for this. But I don't quite like the product any more, and it forces me to move out of my IntelliJ environment which really kills my productivity.

With a combination of the Jetbrains HTTP Client and OpenAPI generators we can do much better, in a semi automated way and even reuse our code on our CI/CD. Let's dive into how!

A quick introduction to the Jetbrains HTTP Client

A lot of people don't know about the Jetbrains HTTP Client, which is a Jetbrains proprietary text file format that allows you to run API requests easily.

One thing I love about it is that it's integrated into the IDE, and it can generate those requests for you. For example, looking at this Spring Boot Kotlin Sample, next to each Mapping there is a "Open in HTTP Client" option in the gutter.

When clicking it, it will generate a scratch file for this request :

You can do many things with those requests, like setting Content-Type, sending body payload and more but I'll direct you to the documentation for more.

The one thing that I want to show you here is that it defines variables for you that you can fill in using a separate configuration file. Pick an environment, and fill in a value for the variables you need. You can either create a public file, or a private one for, say, API Keys.

Running the request gets me the response, as expected, and it's even saved in a log file for me.

The best thing about all this is that everything is a text file, so I can put my request file with its config in a folder in my repository, pushes it to my repository together with my source files and I suddenly have an easy way to interact with my API.

I hope that by this time you're convinced of the value of the Client 😊. But wait, we can do much more!

Generating full API Clients

Many of you are probably aware of the OpenAPI specification (formerly swagger files). It is basically a standard to describe your API. If you write a spec file for it, you basically write a "contract" for how your API works. The nice thing about it is that you can then use this contract to automagically generate a lot of things for your API! That can be clients, in the language of your choice, mock servers, or even documentation. There is a great project for this, conveniently called OpenAPI Generator.

During the Christmas holidays, I set myself on a quest to create a simple generator for the Jetbrains HTTP Client, which didn't exist yet. As of yesterday, it's released! Let's look through it with an example!

I'm a big DOTA 2 player, and let's imagine I want to start playing with the Open DOTA API. Conveniently, it provides us with an exhaustive OpenAPI specification file. Let's have a quick look

As we can see, it describes the location of the API, as well as what kind of HTTP Calls you can make with the associated parameters.

Let's generate a full HTTP Client for it. First, we install the OpenAPI Generator

$ brew install openapi-generator

Then, we generate the client in a new folder

$ openapi-generator generate -i https://api.opendota.com/api  -g jetbrains-http-client -o dotaClient

✨That's it!✨

When we open the folder in IntelliJ, we're presented with a few very nice things (Here is the GitHub repo if you want to see it for yourself):

• First, a complete documentation with all available endpoints and how they work in the README. Each call is clickable and link to locations in our source code.

• Then, an Apis folder with all available calls and their related documentation. Here is the generated code for the Heroes endpoints :

## HeroesApi

### GET /heroes
# @name heroesGet
GET http://api.opendota.com/api/heroes

### GET /heroes/{hero_id}/durations
# @name heroesHeroIdDurationsGet
GET http://api.opendota.com/api/heroes/{{hero_id}}/durations

### GET /heroes/{hero_id}/itemPopularity
# @name heroesHeroIdItemPopularityGet
GET http://api.opendota.com/api/heroes/{{hero_id}}/itemPopularity

### GET /heroes/{hero_id}/matches
# @name heroesHeroIdMatchesGet
GET http://api.opendota.com/api/heroes/{{hero_id}}/matches

### GET /heroes/{hero_id}/matchups
# @name heroesHeroIdMatchupsGet
GET http://api.opendota.com/api/heroes/{{hero_id}}/matchups

### GET /heroes/{hero_id}/players
# @name heroesHeroIdPlayersGet
GET http://api.opendota.com/api/heroes/{{hero_id}}/players

Now let's create en environment file and run all those calls for a given hero. Let's use the id of my favourite hero : Crystal Maiden.

{
  "dev": {
    "hero_id": "5"
  }
}

Just like this, I can start running queries against the API, and for example see which players have the most wins with Crytal Maiden :

I can also decide to run the Health endpoint and see whether the DOTA or Steam servers are down 😊

Objective reached! I can play against external APIs locally, in source code, without having to use any tool like Postman and without going out of IntelliJ.

Adding tests

Running endpoints is nice, but we also want to be able to make sure expectations are fulfilled! Thankfully, there is a way to do this the the HTTP Request client :

### GET /heroes
# @name heroesGet
GET http://api.opendota.com/api/heroes


> {%
    client.test("Request executed successfully", function() {
        // client.assert(response.status === 200, "Response status is not 200");
        client.assert(response.body.length == 126, "DOTA 2 currently has 123 heroes");
    });
%}

This should fail, as DOTA 2 currently has 123 heroes :

Going even further

I've always been a bit frustrated at Jetbrains for their HTTP Client, because it was completely bound to Intellij. As amazing as it is, I can't spend a lot of time crafting nice custom API calls if I still have to create tests for my CI anyways. At the end of the day, it's double the work for me.

But last month, they announced something that filled me with joy  : A CI runner for the HTTP Request files! All of a sudden, all the work we did above became 1000x more useful!

Let's have a look into it :

• We download the (preview, for now), tool and unzip it:

$ curl -f -L -o ijhttp.zip "https://jb.gg/ijhttp/latest
$ unzip ijhttp.zip

• Finally, we run it against the files we have generated above, with our environment file:

$ ./ijhttp/ijhttp Apis/HeroesApi.http --env-file Apis/http-client.env.json --env dev

Et voilà!

$./ijhttp/ijhttp Apis/HeroesApi.http --env-file Apis/http-client.env.json --env dev                                 ✔ ╱ 6s  ╱ 10:23:37 
┌─────────────────────────────────────────────────────────────────────────────┐
│                      Running IntelliJ HTTP Client with                      │
├──────────────────────┬──────────────────────────────────────────────────────┤
│        Files         │ HeroesApi.http                                       │
├──────────────────────┼──────────────────────────────────────────────────────┤
│  Public Environment  │ hero_id = 5                                          │
├──────────────────────┼──────────────────────────────────────────────────────┤
│ Private Environment  │                                                      │
└──────────────────────┴──────────────────────────────────────────────────────┘
Request 'heroesGet' GET http://api.opendota.com/api/heroes
Failed HeroesApi.http#0 Request executed successfully
Request 'heroesHeroIdDurationsGet' GET http://api.opendota.com/api/heroes/5/durations
Request 'heroesHeroIdItemPopularityGet' GET http://api.opendota.com/api/heroes/5/itemPopularity
Request 'heroesHeroIdMatchesGet' GET http://api.opendota.com/api/heroes/5/matches
Request 'heroesHeroIdMatchupsGet' GET http://api.opendota.com/api/heroes/5/matchups
Request 'heroesHeroIdPlayersGet' GET http://api.opendota.com/api/heroes/5/players



6 requests completed, 1 have failed tests
RUN FAILED

We still have our failing test, which will fail our CI. Task failed successfully!

The last step to have a complete setup is to setup a CI action. Let's use GitHub actions for this, fix our failing test, and see what happens:

name: Run API tests based on Jetbrains HTTP Client

on: push

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-java@v3
        with:
          distribution: 'temurin'
          java-version: '17'
      - name: Downloads and runs the Jetbrains HTTP Client CLI
        run: |
          curl -f -L -o ijhttp.zip "https://jb.gg/ijhttp/latest"
          unzip ijhttp.zip
          ./ijhttp/ijhttp Apis/HeroesApi.http --env-file Apis/http-client.env.json --env dev

We checkout, set the Java version to 17 and run the ijhttp package like we did locally.

Success! We now have reliable CI tests using Jetbrains HTTP Client requests!

Going further

There is so much more I could talk about, like the fact that the HTTP Client supports other protocols like GraphQL, handles redirections and more, but I'll keep it to this for now.

Do keep in mind that the Jetbrains HTTP Client generator is still in a very early phase at the moment. For example, I have no support for authentication or most headers at the moment. It won't break anything, but you might have to add things manually to the generated files.

But hey, I do welcome requests and contributions!

Hope you found the read useful. Feel free to ping me on Mastodon or Twitter!

Just like for many other people, the end of the year is a good time to stop for a second and look back at what one has accomplished. I'm notoriously bad at celebrating my successes, always instead looking at the next thing. So please bear with me for this one time humblebrag post.

So let's dive in, here's a dive into what's happened for me last year, professionally and at a more personal level (which, honestly I'm even more proud of :)).

At work

My debuts into DevRel

2022 was my first professional year in the realm of Developer Relations! I can't believe it took so long for me to find what many would call Ikigai. Something I love, I'm good at, and I can be paid for!

I absolutely love my job, and even though it's clear I can do much much better, the world around me seems to agree with the fact that I'm doing OK at it. I think it's genuinely the first time in my professional career where I feel like I exactly belong in the environment I evolve in, and I make a direct impact.

So there's that!

From entity, to team

Last year ended in a rocky way, with my manager (and mentor) living the company and Adyen deciding to change it's strategy. It took me (and us) a while to figure out what we were going to be doing. After all, Adyen being a closed product, what value can Developer Relations bring ? Turns out, a lot!

A year later, we now officially are our own team, with a clear strategy. I have the chance and honor to lead 3 motivated folks with a different set of strenghts, and it really feels like we can move mountains together. And it's so much fun as well, I'm super proud of them, and what we've done together.

Moving the needle

Talking about this, our team helped create a lot of brand awareness for Adyen. Collectively, we talked to over 6 thousand (!!) people, gave over 30 conference talks and in total reached over 150k folks. It's mad to think about it, especially for a team team where everyone is basically starting up in DevRel 😊.

But even more important, we also helped a lot bring awareness about Developer Experience inside the company, so much so that it's becoming one of the priorities for 2023. It's a great achievement, because it'll improve even further our focus for our merchants, and bring many internal teams together. We're definitely looking forward 2023.

Meetups, and Conferences

I've been quite present on the conference scene this year, even though it's definitely not one of my main objectives. It brings me crazy amounts of energy to meet folks, share knowledge and to get people excited. I'm proud of the fact that I've started speaking of things that are much closer to my heart as well (sustainability). It's also the first year that people actually started contacting me to speak at conferences, and that honestly feels amazing. This year is also the very first time I was invited on a podcast, to talk sustainability and DevRel, and it felt great!

This year, I've also helped reboot the Amsterdam DevRel salon and learnt a lot from the folks there. It's definitely different to organize a Meetup for people who's job it is to speak 😊. Gaining a lot of value from it, and there's demand for it. Our first 2023 session expect almost 50 people!

Oh, and thanks to Floor for helping organize!

Industry recognition

I love spending time create awareness for tools I love. And if you know me, you definitely are aware I'm in love with Kotlin and Gitpod.

Even though it's definitely not a main goal for me, it feels seeing recognition for my efforts. In 2022, I became a Kotlin Google Developer Expert as well as a Gitpod Hero. There's some nice perks to it, but being closer to the community gives me so much energy every day, I'm super grateful about it.

Blogging and Writing

Even though I definitely didn't spend as much time as I wanted to writing this year, I still managed to write a few pieces on this blog and in written magazines. Again, the pleasure I take writing is nothing compared to the joy of hearing that it helped someone or getting feedback.

From speaker, to reviewer

It's been a couple years already that I help the Dutch Java community by being one of the editors of the Dutch Java Magazine. I also absolutely love JFall above all other conferences, and try to always have a speaking slot there.

This year, I had the honor to be part of the selection committee as well for the talks. It was great having the opportunity helping shape this conference that I love so much. That, and helping first time speakers prepare for their talk as well.

And at home

As I was mentioning, even though I'm quite happy with how my work life turned out last year, I'm even prouder of everything we achieved at home.

No compromises

It's been a few years already that we're conscious about out footprint on the planet, and we've decided to drasctically reduce our impact anywhere we could. And one of the major items there is flying. As of 2018, plane travel totalled almost 40% of my CO2 footprint. I decided to stop flying, unless really necessary.

Combining this with being a Developer Advocate is not always simple. After all, a big part of our job is to be at conferences, close to our audience. Well I managed to be present at over 15 conferences this year, without ever boarding a plane. I've also done absolutely no compromise on the topics I wanted to present.

Turns out, you can go far with the train. I've even managed to go all the way to Barcelona 😊. I'm happy to see it's possible, and glad Adyen was nice enough to give me the extra bandwidth necessary for this.

Producing a good chunk of our food

It's been a couple years we try to buy less, and produce some of what we consume at home. It started with many home products (washing powder, dishwasher tablets, detergent, ...) and last year we started the gardening experiment.

We went bigger this year, with a 200m2 garden! It was quite the task, actually much more than we expected. Especially with close to 0 previous experience ^^. Almost 60% of everything we planted died 😅.

But even then, we managed to produce over 160 kg of food this year! This is by far my proudest achievement with the family. We are, and have been quite largely feeding ourselves with our own produce. We made cans, froze a lot, and it's such a joy to create meals that come 100% from stuff you grew yourself! We're definitely planning on doubling down on this next year.

Gardening also made us so much more aware of the climate emergency. When you're in the field, you realize how f*ed and unreliable the weather is becoming. I'm glad about it, because it's something we can't ignore anymore and we can bring our kids on the journey. Acting is definitely better than plain despair.

So what's with 2023?

It's hard to reflect back without ending with a glimpse at what's coming. This year will be slightly different than last year, but even more exciting.

I'll most likely be less present at conferences, as we will be focusing a lot more on content creation with the rest of the team. This means that I'll get my hands much more dirty and that's great! I actually already managed to do a minor Open-Source contribution to OpenAPI early this year so that's a great start.

So, more content. I also will dive much deeper into Developer Experience, and especially how to measure it. Developer Advocacy definitely ties into Developer Experience, being on the forefront of the product and I want to learn better to convince stakeholders by leveraging numbers. Finally, I will learn the business side of software. This is one of the parts I have been missing in the past years, and it's a gap I want to fill. I want to be generating revenue myself this year, by learning to recognize gaps in product offerings.

So let's get to it! So what are your plans for 2023?! I'm mostly available on Mastodon and Linkedin those days 😊, though you can still find me on Twitter...

TL;DR : I found and fixed a tiny bug in OpenAPI, learnt about the library, jackson and git in the process.

Yesterday, I was sharing some tips on how to get started with OpenAPI generators. Turns out, within minutes of me starting to use the library, I found a bug that was causing heap space exceptions. This blog is about what I learnt while fixing it 😊.

Facing the bug

The first thing I started doing while testing the application, before even creating my own generator was running a few existing generators for languages I know. I started with Kotlin, and added the debug flags to it to see what kind of objects were generated by the OpenAPI parser.

Within minutes, I was running the Kotlin (of course) generator, with the debugSupportingFiles global property activated.

After a few seconds, the process crashed with a Java heap space exception:

[main] INFO  o.o.codegen.TemplateManager - writing file /Users/julienlengrand-lambert/Developer/openapi-generator/samples/client/petstore/kotlin/http/client/docs/UserApi.md
[main] INFO  o.o.codegen.DefaultGenerator - ############ Supporting file info ############
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at com.fasterxml.jackson.core.util.TextBuffer.carr(TextBuffer.java:967)
	at com.fasterxml.jackson.core.util.TextBuffer.expand(TextBuffer.java:928)
	at com.fasterxml.jackson.core.util.TextBuffer.append(TextBuffer.java:682)
	at com.fasterxml.jackson.core.io.SegmentedStringWriter.write(SegmentedStringWriter.java:58)
	at com.fasterxml.jackson.core.json.WriterBasedJsonGenerator.writeRaw(WriterBasedJsonGenerator.java:605)
	at com.fasterxml.jackson.core.util.DefaultIndenter.writeIndentation(DefaultIndenter.java:94)
	...

Not knowing at all what I was doing, I asked for directions on the Slack channel of the project and got suggestions within minutes with ideas of things to try out.

For me, the main question was : Is it only happening on my machine 😬?

Justin was nice enough to file a bug for me, and I started diving into the problem.

Finding the culprit

Turns out, the issue only happens in debug mode, with that specific flag set. It was also happening for all of the generators I tried, and all the specification files. Extending the heap size to humongous values wasn't helping. It had to come from the code somehow.

After a little while, I could track down the line that was creating the crash. It was all happening in the DefaultGenerator (which all generators extend from), and only if the debug flag was set. Makes sense.

if (GlobalSettings.getProperty("debugSupportingFiles") != null) {
	LOGGER.info("############ Supporting file info ############");
	Json.prettyPrint(bundle);  // BIG BOUM, BIG BADABOUM 
}

Jason, again, very helpful on Slack, mentioned that the objects generated by the generators can contain infinite loops. Those loops, when trying to transform them into a JSON file would crash the JVM. That's also what was showing in the stack trace of the exception.

It was time to track down when the bug was introduced!

Git bisect to the rescue!

I won't go deep into how git bisect works. You can read about it yourself. The basic idea is that you provide git with a valid commit (before the bug was there) and a faulty commit (with the bug). You'll also need a quick way to see if the bug is present (in my case, running the run configuration and seeing the heap space crash).

Git will iteratively select commits and ask you to tell him whether the bug is there, until you know precisely the ONE COMMIT which introduced the problem.

It basically looked like this :

$ git checkout master # clean state
$ git bisect start
$ git bisect bad HEAD # bug in there
$ git bisect good v5.0.0 # no bug
$ git bisect good # no crash
$ git bisect bad # crash
$ git bisect good
$ git bisect bad
$ git bisect good
$ git bisect bad
$ git bisect good
$ git bisect end
$ git bisect reset # back to work, let's check the bug now

Honestly, I never had to use it in the past in my professional life and I feel blessed to have an extra tool in my box now 😊. The whole thing was sorted in less than 5 minutes 😅.

Understanding the bug

Once we know the commit which introduced the issue, it's easy to track down where exactly the problem is. Look, it's right there :

    /**
     * @return contentTypeToOperation
     * returns a map where the key is the request body content type and the value is the current CodegenOperation
     * this is needed by templates when a different signature is needed for each request body content type
     */
    public Map<String, CodegenOperation> getContentTypeToOperation() {
        LinkedHashMap<String, CodegenOperation> contentTypeToOperation = new LinkedHashMap<>();
        if (bodyParam == null) {
            return null;
        }
        LinkedHashMap<String, CodegenMediaType> content = bodyParam.getContent();
        for (String contentType: content.keySet()) {
            contentTypeToOperation.put(contentType, this);
        }
        return contentTypeToOperation;
    }

Once you understand what the method does, it's quite clear why the heap explodes. This method is basically adding to an object, the object itself, but with a key of a certain type of format. No wonder it generates infinite loops when the JSON parser runs through it 😊.

Now, the actual problem is not that method itself. The real issue is that it's not called anywhere 😅. It shouldn't be run at all. Actually, there's literally 0 direct usages of the method in the whole library (even in the toString method)

Obviously, the method is used. But only in the Python template, where it is actually working as expected.

class BaseApi(api_client.Api):
{{#if bodyParam}}
    {{#each getContentTypeToOperation}} // Our method here
    {{> endpoint_args_baseapi_wrapper contentType=@key this=this}}

    {{/each}}
    {{> endpoint_args_baseapi_wrapper contentType="null" this=this}}

{{else}}
    @typing.overload
    def _{{operationId}}_oapg(
    {{> endpoint_args isOverload=true skipDeserialization="False" contentType="null"}}
{{/if}}

Still, placing a breakpoint makes it clear enough that Jackson DOES enter the method when converting the object to JSON.

I tried upgrading Jackson and other shenanigans, until one of my colleagues made it all obvious : "Would your method start with get or set by any chance?".

Finally, it all made sense : Jackson uses reflection to convert the object into JSON representation. Somehow, it takes the class and goes through all of the getters and setters iteratively. The method was assumed to be a getter, hence creating the crash.

Fixing the bug

As usualy with software, once we know what the problem is it's actually quite easy to fix it. And even then, I went through 2 iterations.

My first thought was to add the @JsonIgnore annotation to the method, to tell Jackson to ignore it. It worked.

    @JsonIgnore // The magic line
    public Map<String, CodegenOperation> getContentTypeToOperation() {
        LinkedHashMap<String, CodegenOperation> contentTypeToOperation = new LinkedHashMap<>();
        if (bodyParam == null) {
            return null;
        }
        LinkedHashMap<String, CodegenMediaType> content = bodyParam.getContent();
        for (String contentType: content.keySet()) {
            contentTypeToOperation.put(contentType, this);
        }
        return contentTypeToOperation;
    }

I didn't quite like it though. It put some direct dependency to Jackson in a place there wasn't before, and there was no clear explanation either. The me from the future would have hated me for doing this.

The second attempt was, I think, better and that's the one which got merged : Rename the method to remove the get 😅.

public Map<String, CodegenOperation> contentTypeToOperation() {
        LinkedHashMap<String, CodegenOperation> contentTypeToOperation = new LinkedHashMap<>();
        if (bodyParam == null) {
            return null;
        }
        LinkedHashMap<String, CodegenMediaType> content = bodyParam.getContent();
        for (String contentType: content.keySet()) {
            contentTypeToOperation.put(contentType, this);
        }
        return contentTypeToOperation;
    }

William was nice enough to add a test to test for future regression. I wasn't sure how to do this (how to you test for "no crash of the JVM"). Well, you don't, because the crash isn't there. Here is his commit :

# test debugSupportingFiles
          ./bin/generate-samples.sh ./bin/configs/python.yaml -- --global-property debugSupportingFiles

A word of conclusion

Most of what I've learnt about OpenAPI happened through this bug. The folks on Slack are super helpful and they've been gentle giving directions while expecting me to do the work.

I write a lot of open code, but I don't work much in other people's libraries and that felt super nice. the bug should be closed in the coming weeks I expect.

Thanks everyone, and happy new year already ! 🎉

Don't hesitate to reach out if you have any questions! I'm mostly available on Mastodon and Linkedin those days 😊, though you can still find me on Twitter...

TL;DR : In this article, I'm sharing some tips and tricks on how to get productive with creating OpenAPI generators

Lately, I've started dabbling more and more with OpenAPI. The OpenAPI specification is a super useful way to describe the API that you're exposed to your users, both internally and externally.

Some of you may also have heard about those under the name of "Swagger files". They're both kinda the same in the common speak, though OpenAPI is an open standard (lead with the OpenAPI Initiative) and Swagger is a set of tools built by a company (SmartBear). Some of those tools are Open-Source, while others have a pro license. I won't go into the details of the specification here, there are plenty of great getting started resources, typically for different technologies. Here's one for Java and Spring.

Generators are the parts who take the OpenAPI model that's being created from a definition file, and generates server / client code and / or documentation. Or anything you want, really. There's many generators available out of the box, so typically what you want is use or adapt one of them. It's not always the case though. For example, there is currently no generator available for the Jetbrains HTTP Client.

That's where my story begins 😊, but that's for another day!

Using the debugging flags

Typically, if you're playing with a generator, you either want to generate a model file (your data structure), an operation file (your logic), or a supporting file (basically anything else, READMEs, docs, ...).

At its core, the idea of OpenAPI is quite simple : It takes a specification file, transforms it into a set of objects in memory, and uses those objects to generates code / files using mustache template files. You can read more about it here.

That's why it's crucial to have a good look into those objects, so that you can find where the data you need is located inside your mustache template. Here, debugging flags become vital. There's 3 of them, whether you want to see the data to generate models, operations or supporting files.

You can use respectively debugModels, debugOpenAPI and /or debugSupportingFiles. and you set them by running the desired  generate command with the correct flag. For example

$ java -cp modules/openapi-generator-cli/target/openapi-generator-cli.jar org.openapitools.codegen.OpenAPIGenerator generate -g java -o out -i petstore.yaml  --global-property debugModels=true

I won't print the entire output here because it's huge, but as part of the output it will basically spit a giant json representation of all the models available inside that specified yaml file. Here's a tiny part of the beginning :

[ {
  "importPath" : "org.openapitools.client.model.Category",
  "model" : {
    "anyOf" : [ ],
    "oneOf" : [ ],
    "allOf" : [ ],
    "name" : "Category",
    "classname" : "Category",
    "title" : "Pet category",
    "description" : "A category for a pet",
    "classVarName" : "category",
    "modelJson" : "{\n  \"title\" : \"Pet category\",\n  \"type\" : \"object\",\n  \"properties\" : {\n    \"id\" : {\n      \"type\" : \"integer\",\n      \"format\" : \"int64\"\n    },\n    \"name\" : {\n      \"type\" : \"string\"\n    }\n  },\n  \"description\" : \"A category for a pet\",\n  \"xml\" : {\n    \"name\" : \"Category\"\n  }\n}",
    "dataType" : "Object",
    "xmlName" : "Category",
    "classFilename" : "Category",
    "unescapedDescription" : "A category for a pet",
    "isAlias" : false,
    "isString" : false,
    "isInteger" : false,
    "isLong" : false,
    "isNumber" : false,
    "isNumeric" : false,
    "isFloat" : false,
    "isDouble" : false,
    "isDate" : false,
    "isDateTime" : false,
    "isDecimal" : false,
    "isShort" : false,
    "isUnboundedInteger" : false,
    "isPrimitiveType" : false,
    "isBoolean" : false,
    "additionalPropertiesIsAnyType" : false,
    .........

Running and Debugging a generator

Whether you want to play with an existing generator or create a new one, the existing documentation tends to offer you to compile and run the generators using the generic ./mvnw clean package followed by ./bin/generate-samples.sh bin/configs/spring-boot.yaml (replace with the file you want to use) command. The first one will compile the source, while the second one will use the created openapi-generator-cli.jar and actually run the code.

For example, the config file spring-boot.yaml :

generatorName: spring
outputDir: samples/server/petstore/springboot
inputSpec: modules/openapi-generator/src/test/resources/2_0/petstore.yaml
templateDir: modules/openapi-generator/src/main/resources/JavaSpring
additionalProperties:
  artifactId: springboot

will run the command

$./modules/openapi-generator-cli/target/openapi-generator-cli.jar org.openapitools.codegen.OpenAPIGenerator generate \
-g spring \
-i modules/openapi-generator/src/test/resources/2_0/petstore.yaml \
-o samples/server/petstore/springboot \
-t modules/openapi-generator/src/main/resources/JavaSpring \
--additional-properties=artifactId=springboot

Useful, but quite cumbersome. On top of this, you typically want to be able to run / debug code as you go directly in your IDE.

Using IntelliJ, you can do it by creating a run configuration as such :

Set the OpenAPIGenerator class to run from the openapi-generator-cli jar file. Pick your generator name, input yaml file and output folder (the same as in the config file described above and set the working directory to be the root of the openapi-generator git project. You're done!

Now you can go in the generator's CodeGen file, (for example JMeterClientCodegen if your generator name is jmeter ) and set breakpoints where you want 😊.

Setting breakpoints in the right locations

As described above already OpenAPI generators take a specification file, transform it into a set of objects in memory, and use those objects to generates code / files using mustache template files.

Typically, generators will take those existing objects and add or modify some of their content to fit the output to be generated. Most generators will extend from DefaultCodeGen. That's where you will find the most useful locations to set breakpoints to see what to change and where.

The most interesting part of this class is located in the generate method. You will also be able to find the lines that are being used to print the debugging flags by searching for the Json.prettyPrint calls. Here's an example for the models (as of now, line 566 of DefaultCodeGen :

if (GlobalSettings.getProperty("debugModels") != null) {
    LOGGER.info("############ Model info ############");
    Json.prettyPrint(allModels);
}

Once you're in there, you can dive into the data and find out what you want to do with it.

Extending the default generator

(Thanks Beppe for the tip!)

Most generators typically add extra bits of necessary information inside their objects, for example inside the bundle for supporting files : bundle.put("distinctPathParameters", distinctPathParameters); . The trick is to find where to do this.

Luckily for us, the smart developers of OpenAPI have created locations to do just that! You'll want to search for the methods called postProcess* in DefaultCodeGen, those are placeholders that are set at the end of the various generatemethods that you can override at your convenience in your custom generator.

Here is what a completely useless generator could do :

@Override
public Map<String, Object> postProcessSupportingFileData(Map<String, Object> bundle) {
    bundle.put("bloggingAt1AM", "isFun");

    return bundle;
}

Which you could then use inside a `README.mustache` template, for example :

# Important announcement

{{bloggingAt1AM}} // Will print "isFun" once ran

Generating custom lambdas

One of the super powers of mustache is its lambdas, which you can declare in the templates. There is a list available on the mustache website, but the OpenAPI templates define a few more. You can search the code for any class implementing the Mustache.Lambda interface 😊.

You can easily create new lambdas as well by implementing that interface yourself.

Here is a concrete example : Typically, parameters are surrounded with braces when using a generator. For example, for a GET request, with a petId parameter it will come out like this : DELETE http://petstore.swagger.io/v2/pet/{petId}.

That being said, The Jetbrains HTTP Client defines parameter with double braces (!). I need this to have a valid call : DELETE http://petstore.swagger.io/v2/pet/{{petId}}.

Instead of having to play around a lot with the templating, I decided to create a custom lambda for this in my generator. This is how it looks like :

public class JetbrainsHttpClientClientCodegen extends DefaultCodegen implements CodegenConfig {

    @Override
    protected ImmutableMap.Builder<String, Mustache.Lambda> addMustacheLambdas() {
       return super.addMustacheLambdas()
                .put("doubleMustache", new DoubleMustacheLambda());
    }

    public static class DoubleMustacheLambda implements Mustache.Lambda {
        @Override
        public void execute(Template.Fragment fragment, Writer writer) throws IOException {
            String text = fragment.execute();
            writer.write(text
                    .replaceAll("\\{", "{{")
                    .replaceAll("}", "}}")
            );
        }
    }
}

Two things happen here :

• I create a DoubleMustacheLambda class that implements Mustache.Lambda that  itself implements the execute method. The execute method does nothing else than rewriting some of the generated text.
• I override the addMustacheLambdas method, and use it (just like for my data in the previous tip) to insert my custom lambda.

Once that is done, I can use it inside my api.mustache template! For example :  {{#lambda.doubleMustache}}{{path}}{{/lambda.doubleMustache}}

Finding OpenAPI spec files to test with

One of my struggles when playing around with OpenAPI Generators is to find files to test stuff with. After a little while, sample files and the PetStore don't cut it any more. I was searching for actual OpenAPI spec from the real world, like for the GitHub API, Heroku, Digital Ocean, .... you name it.

I asked on the official Slack channel and folks were most helpful. They suggested two main things :

• The OpenAPI directory (which somehow I didn't know existed!)
• A google search to find speccs generated by redocly (which, again, is a tool I didn't know existed ^^)

Armed with those two, it's much easier to go on and try things out. Hope this helps you too!

A word of conclusion

I hope those tips will help you hit the ground running with OpenAPI generators. Most of the tips directly come from the open Slack channel, the folks there are super useful. The official documentation is nice, but I honestly found it quite sparse, and once you dive in, a lot of the advice comes down to "have a look at the other generators for inspiration". I find it logical, because in 99% of the cases, the generator that you need already exists! If it doesn't though, you're in for some fun.

Hopefully I'll save you a couple hours this way!

Don't hesitate to reach out if you have any questions! I'm mostly available on Mastodon and Linkedin those days 😊, though you can still find me on Twitter..

This blog's been on my mind for a while, but I've never felt like I was well placed to write about it. I probably am not. Please accept my clumsy words for what they are.

It took a loooong time for me to realize how privileged I am on a daily basis. Being a white male, born in a wealthy country, with a masters degree in a very favored technical field. I'm not ashamed of it, there's a lot of work behind who I am today. But there's, let's be honest also a huge part of genuine randomness / luck and the very large support of a whole family for many years. We all need to be aware of it.

Interestingly, I was the very first one in the family to study past A level. My parents saved for decades for us to be able to study. I went to school for a while to a place where surgeons, pilots and politicians sent their kids. It's only years later that I realized why it was hard for me making friends there. It's funny because even now with both of us making very comfortable salaries we own a cheap car, never went on lavish vacations and still shop in the "no food waste" of the supermarket.

Anyways, long story short even in a field like Tech where we're all comfortable compared to many other places, one quickly realises not everyone is born equal. And I'm talking at all levels, whether it's race, gender, seniority, age, ...

In this post, I'll discuss things I see, and things I try to do to "do my part" (for the lack of a better word) at work and outside of it. I'm not an example, but maybe you can find inspiration yourself (and teach me some more!). _Note: It goes without saying that there's enough material in each of those items to write a whole book about. I try here to bring some ideas to others, and hopefully get some more, nothing else .😊

It all starts with awareness

You create the reality you're in. About 6 years ago, I realized that more than 80% of what I was reading / watching and the people I was following on the bird app were (typically older) white males. There's nothing wrong about it of course, but it's also far from great. And the thing is, that's typically self-perpetuating because that's simply how the algorithms works!

So I actively started searching for "different" sources. And honestly they're not hard to find. Start following Kolokodess and you'll discover a whole world of Nigerian and many more tech rockstars (just to name a few).

Again, the point is not to reason in terms of numbers, but honestly your day is much more interesting if you see content from a various diverse panel of people. It'll give you ideas, perspectives and motivation in many more forms; as well as make you way more aware of other people's struggles (even some you would have never imagined).

I've seen people do follow Fridays, and they're great ways to get hear about new great folks! (If you start doing those, try to spotlight some less visible folks as well. I really feel like it's always the 50 same Java profiles we see at times 😊).

Mention it when you see it, and actively help with it

The next step is to mention it when you see it. And let's be clear, I don't want to get into the positive discrimination discussions. I have opinions about it but we don't even need to go there because there's definitely enough quality content out there coming from ALL directions without having to lower any kind of bar.

The trick though (at least for me) is not to blame an event as it's happening because it's obviously too late but to try and be there early to voice it and bring solutions. And it starts locally and with oneself. I try to ask how the lineup looks like when I'm speaking/helping somewhere and I'm happy to propose other folks who I believe would bring a different light to the discussion if I see that we all come from the same types of backgrounds.

The win / win / win situations

That's actually one of the parts I love at my job : helping new voices be heard and get more stories out there! A practical example from my time at ING : We would sponsor many conferences every year and many of those conference came with a "sponsor slot". Basically a free slot for a speaker. What typically happened is that the folks from marketing were super busy, or simply less on the floor than us and would go for the same 2/3 speakers every time. Every time I heard a cool story on the floor (and check on the person she's up for talking about it), I'd inform Marketing!

It's a win / win / win situation, because ING is happy to have more speakers available, new speakers get an easy way in the circuit and the world gets to hear new stuff! Our seasoned speaker typically don't need help to find speaker slots as they already are know in the circuit 😊.

I realise I'm talking about conferences a lot, but the same applies for everything : blog writing, team creation, new projects, ...

Creating opportunities

If you're active in projects, communities, another thing you can help with is to create opportunities for folks, and try to make them less intimidating to reach.

That's why I love the shorter Bite Size formats at conference, or the good-first-issue tag of GitHub. They help make the achievement more accessible for newcomers. Don't think you can talk about a topic for 45 minutes? Hey, you can speak about it for 15 then right? How about 5? Everyone has 5 minutes of content to say about something! Another trick is to bring a co-speaker with you! I had the chance to present a talk together with Apoorva last month and it was an absolute blast! As a bonus, we only had 20 minutes of content each to prepare 😊. Don't know much about the project and new to Open-Source? This issue is reserved for you and we'll help you with it as well!

(Heck to this day even I always start my talks as bite sizes, and then move on to longer formats as I gain confidence about the topic).

There's many, many declinations to this idea. Are you a team lead? Organize internal knowledge sharing sessions, it's less scary to speak to your team first. Then make it cross teams, ... Find you own idea!

When I joined the redaction commission of the Dutch Java Magazine, one of my first proposals was to create a "tweet" format. It's intimidating to write 4 pages in a printout magazine for anyone. So start with a 280 characters thing to share something you like. You can always write an article about it later!

And for the ones in the back : This is absolutely NOT about lowering the bar. This is about simply making things more accessible. And I believe it benefits us all. The tweet format has gotten only good feedback by readers so far, they love the simplicity of it.

Keep mentoring, and start sponsoring

Most of the folks I know love to mentor others. Whether it be junior, newer employees or less represented groups. That's great, and it definitely helps. But an article from Gergely lately made me aware on the difference between mentoring and sponsoring and realise I could do more.

While mentoring focuses on teaching / coaching someone with their skills, be it programming or even soft skills; sponsoring means you are expected to give public and external support to your buddy. The difference is important, because with sponsorship you're putting skin in the game by advocating for your buddy to your management (or any other place).

It can take many forms, like taking a new risky project, leading an analysis, taking the sponsored keynote spot at a conference... You want to amplify your buddy's successes (spread them out), boost them and give them access to your network. The effects can be much more empowering than mentoring, seen that way.

It's a pipeline problem

You've probably heard this in one form or other, maybe in several forms even. "Women don't apply to our jobs". "Only caucasian males sent an abstract to the conference", "We can't find team leads internally", ...

I'm not an expert on the topic, though it's clear by now that we don't have the same behaviours when it applies to job seeking (as well as many other things).

I won't dive into the details of writing an inclusive job offer; my main question is whether you personally accept the status quo and get on with it.

When we organized SimpleWebConf over a year ago, 97% of the 250 abstracts we received for the conferences were from caucasian males. Again, without talking about the quality of the abstract, according to statistics about 80% of the Tech workforce in Europe is male. For an online conference, we could do better! So we asked some groups to relay our CFP and also directly asked folks we knew would do an amazing job to join us. In the end, we ran an online session with 30 folks from 3 continents across many topics like accessibility, sustainability we're very proud of (dang, that's back when Fred K. Schott was just starting to introduce Astro!).

And that's also where I come back to my very first point : The more diverse your network is, the easier it is to promote your content / opportunities in various communities and create something you're proud of. (And by extension, the more diverse your CFP committee is, the easier it is to have a diverse conference... In hindsight we could have done much better there.)

The same goes on the workplace, I believe. The more diverse your workplace is, the easier it is onwards. At Adyen, we typically try to always include different people from diverse backgrounds (in all senses of the word) during the interview rounds. And again, I believe it's a win / win situation because it helps get a less biased view of the candidate, but also offer them a better inside view of the company from many different perspectives.

Be open about salary

In the Netherlands, discussing salaries is kinda taboo. And still, I do my best to be open about it (to a point where I've literally been shushed by some HR folks in the past). Thing is, keeping secret about salaries favorises only one entity : the company. Sharing salaries makes employees strong, and on good way to reduce discrepancies between folks is for them to be aware of other people 's salary to know if they're compensated fairly.

I won't go about sharing other people 's salaries, of course, nor will I blast mine out there on Twitter ( our salaries in Tech really feel disconnected from many others at times). But I'll definitely be open about it in conversations.

Respect others, and avoid assumptions

There's so much to unpack with this one, and I don't know how much it really ties into the topic. To me at least, it's very central to how I try to improve.

Being French (does it really have to do with this?), I have a very cynical humour and I am very quick to judge people. It has served me well in the past, but it's also a very big barrier to expand your horizon.

Cynical humour or edgy jokes might be fine in some context (maybe with close friends, or applied to yourself) but they also typically exclude parts of the population. One good friend one day made me realise that quite literally 80% of my vocabulary for insults had to do with people getting money for sex, or lady parts. Once you see it, it's hard to unsee. This type of behaviour definitely builds walls faster than bridges and I actively tone them down.

I've screwed up in the past, and I regret it.

Assuming things is also a great way to exclude people. "Are you from marketing?", "Where do you originally come from?" : I'm guilty of asking those. As an expat, the first thing I want to talk to with people is food and it's so hard not to ask where their origins lie to ask them about their food culture. But after having spent days on booths next to colleagues at conferences and heard the sheer amount of times the question pops out, it really made me realise how much of a burden than can be. The depth of Holly's analysis on dress code is compelling, if not saddening!

Giving space to others

Another thing that I genuinely try to improve and still have a long way to go  is simply giving space to others. In conversations, in meetings, and many other settings. When talking about things, especially techy stuff, it's easy to be passionate and monopolise the discussion. And some folks find it much harder than others to raise their voice.

The meeting is closing, and you realise that damn, your newest colleague who just joined hasn't said a word about the topic. Well, ask them up. If you see someone not raising his voice at all, give them an opportunity and genuinely ask them their opinion. And ideally, make sure you don't put them on the spot. You can do that for example by texting them first in online meetings.

Apologising

On that topic, one thing that I see much too rarely is simple, plain and genuine apologies. We all screw up. How life would be boring without that! Well, we have a saying in French that goes "a fault confessed is half forgiven".

There is no shame in apologising (though I do know it is a culturally loaded statement). In fact, I deeply respect the folks who can recognise their mistakes and apologise.

So make an apology, either in private to the person you did wrong or publicly, and do better next time.

We're in it together

There's one last thing I see that I do want to mention, because it pains me. I was raised to be polite to everyone, whoever they are.

It's crazy the amount of people who won't greet the barista, the cleaner, the receptionist or even the bus driver. Personally, it gives me the same feeling as if I saw someone littering. Damn, I wish I could make coffee as good as my barista. I have so much to learn from them. Without the cleaners, there's no way our office could function for more than a couple days.  They deserve the same, if not more respect than others!

So next time you run an Meetup, go the extra mile for the person who has to keep the building open for you and bring them a can and a piece of pizza. Have a chat with them. You wouldn't be able to be there without them.

I knew this article would be waaaaay longer than I expected. There's much to say about the topic, and still I feel like I have so much more to learn about it. I'm keen on hearing how I can further improve. It might sounds cheesy (and it may well be), but at the end of the day I'd genuinely like all those differences between us to simply not matter.

Whoever we are, we enrich each other. It's really exhausting to me to see how polarised we are becoming online and offline. I really wish we simply could coexist and improve day by day. And to go full circle, I once again realise how privileged I am to be able to say that...

Hit me up on Mastodon or Twitter (for the time being) and let me know what I missed!

Have a good one,

It's a habit I picked up back at school, and it never left me. Every day, in every meeting, I take notes on a paper notebook. You'll rarely find me with a laptop in a Meeting. And I recommend you try it too.

Let's dive a bit into why it works for me, in no particular order.

Politeness

Have you ever seen someone type on their keyboard in a meeting, or typing on their phone ? What did you think of it? It might be because I'm getting old, but it always disturbs me. I never know if that person is writing their grocery shopping list, answering a comment on Facebook or taking notes on what we are discussing about.

And I've seen it happen as well in front of me. Sometimes, it's really been disturbing to the meeting even, depending on the person types in front of me. The screen is acting as a barrier between me and the person in front of me as well in physical meeting, making it especially awkward (that's also why I tend to avoid sitting right in front of someone when I can avoid it by the way).

Typing in a meeting, or being one's phone feels impolite to many, even if they won't tell you. Writing on a piece of paper doesn't. So I prefer to write!

One thing though : depending on the context, I actually ask first if it's ok to take notes. For example when I interview someone, I don't want them to be startled by me writing down what they are saying 😇.

Memory

I've always been the writer time. Wanna learn something? Write it again and again. So interestingly, I very rarely come back to my notes.

I don't write now so I can remember later, I write so I remember now! 😊. I really don't get the same effect by writing on a keyboard. There is something linking my memory to my hand writing that I can't explain, but it's there.

Focus

My mind, just like many of you, races all over the place and I find it super difficult to stay focused in meetings, especially if they are virtual and there are many folks in the room. We live in worlds of constant interruptions and with out laptops and phones around we quite literally have interruption boxes right in our hands all day long.

Having a notebook and a pen with me helps me stay focused on what is being said instead of having my mind wander off. My hands are busy so I won't check my socials or my emails, or procrastinate

On top of this, it's literally been proven that fidgeting and doodling help with focus, so I definitely use that to my advantage. In meetings, you can find me doodle all over the place on my notebook as things are being said so I can keep focus 😊.

Writing is typically faster than typing (for me)

Typing is fast, but being used to it, using abbreviations and writing only a few words down to carry ideas I actually write faster than I type. And that becomes especially true on the go, when I want to save things down from my phone.

I always happen to carry a notebook around in my pocket and that's the fastest way for me to put ideas down on paper.

(Well ok for this one, ONE thing actually started competing with my notebooks : voice notes from my watch 😊).

It just feels good

Seriously though. To me, writing things down feels amazing. I can't imagine not doing it. Scratching paper, with a nice pen, is one of the nicest feelings I know. Just like reading an old book smelling like old paper in a cozy chair 😊.  Amazing.

Writing is getting lost

I'll end with this. It's more of a generic remark but I see that more and more of my friends tend to lose their writing habit. It's something that they've done at school, ut stopped practising for many years now and writing literally feels weird to them.

I might be getting old fashioned, but to me it's worrying. I don't want to lose my writing habit, and I want my kids to see me write and read at home.

Some limitations

Even though I love writing, and my notebooks, things aren't perfect. For meetings, I'd like to be able to simultaneously write things down, but also have them translated to a document for later sharing and collaboration.

I haven't found a good solution so far. Tried an iPad with the paperlike cover, but it's still bulky and feels different. I thought about trying the remarkable a few times, but I love my notebooks too much so I haven't taken the step to.

I'm curious now, what do you think about it? Do you still write? Do you disagree? Do you have tips? Let me know on Twitter!

Have a good one!

TL;DR: The data class copy method in Kotlin creates shallow copies and data classes are NOT immutable data structures by themselves. They become immutable though, if all of their properties are immutable themselves (_val_).

Note: You can run all the samples listed here by clicking that link

Earlier this week, I gave a Kotlin introduction training to about 50 folks at Adyen. I think most of them appreciated the training and I even got some nice feedback

One fun thing about the training is that most of the audience was coming from a C/C++ background and they asked many questions about references / values, shallow or deep copies and how Kotlin manages memory. Suffice to say I wasn't ready for it ^^. This blog summarises my findings after the training.

A quick recap about Data Classes

In Kotlin, data classes are specialised structures that are meant hold data (as the name suggests).

data class Address(val number: Int, val street: String, val city: String)

data class User(val name: String, val age: Int, val address: Address)

They come with additional goodies compared to normal classes, among which:

• generated hashCode and equals method. (Equals is smart as well, checking if all properties and sub properties have the same value)
• A smart toString method that displays the data content nicely

Duh, that's just like Java Records, I hear you say. Yeah, except that data classes also come with the copy method, which is in my opinion give them all their power. With that copy method, you can create a new copy of an existing instance, while modifying some data at the same time. Here is an example:

val bob = User("Bob", 42, Address("12", "rue des peupliers", "Paris"))
val anOlderBob = bob.copy(age = 43)

As I was presenting this to the C++ folks, I heard the same question pop up at three different places at the same time : Is anOlderBob a shallow, or deep copy of bob?

In other words, if bob changes address now, does anOlderBob get affected?

Silence in the room.....

Benefits of Immutable data classes

See, I've been interested in Functional Programming for a little while, and I know that most of them heavily rely on immutable data structures. One of the main reasons for this is thread safety. If your data cannot be modified any more once it has been written, you are by definition thread safe and you are certain not to have synchronisation issues. I even think that the first person who taught me this was the one and only Martin Odersky.

Thing is, the huge majority of applications out there are in the business of moving data around. And if you cannot modify existing objects, well it also means that you're gonna have to create many many more objects to compensate for it right?

Let's take an example :

data class User(val name: String, val age: Int)

val users = listOf(
        User("Bob", 42), 
        User("Georges", 12), 
        User("Emily", 25), 
        User("Amy", 46))
val olderUsers = users.map { it.copy(age = it.age + 1) }

>> [User(name=Bob, age=42), User(name=Georges, age=12), User(name=Emily, age=25), User(name=Amy, age=46)]
>> [User(name=Bob, age=43), User(name=Georges, age=13), User(name=Emily, age=26), User(name=Amy, age=47)]

Here, we are creating a list of 4 users and then creating a new list with each user older by one year. Because our users are all immutable, we have to create a new copy for each user.

For more serious applications, the obvious outcome is that this type of copying has to be shallow (meaning our new object's properties link to the memory location of the parent properties), because otherwise the performance hit of creating so many objects would be prohibitive.

Well, now let's verify it.

Playing around with Data Classes

Let's run a few tests to make sure our assumptions are correct (or not). We create FantasyHero, a data class that has mutable and immutable properties, of primitive and more complex types.

enum class WEAPONS{
    AXE, SWORD, WAND, BOW
}

enum class CLASS{
    WIZARD, WARRIOR, PALADIN, THIEF
}

data class Origin(val city: String, var country: String)

data class FantasyHero(
	var name: String, 
    val weapons: MutableList<WEAPONS>, 
    var heroClass: CLASS?, 
    val origin: Origin = Origin("Utrecht", "The Netherlands")
)

First, let's check that everything behaves as expected

val gandalf = FantasyHero(
	"Gandalf the Grey", 
    mutableListOf(WEAPONS.WAND), 
    CLASS.WIZARD
)
val anotherGandalf = FantasyHero(
	"Gandalf the Grey", 
    mutableListOf(WEAPONS.WAND), 
    CLASS.WIZARD
)
val gandalfCopy = gandalf.copy()


val betterGandalf = gandalf.copy(name="Gandalf the White")

println(gandalf)
println(anotherGandalf)
println(betterGandalf)

println(gandalf == anotherGandalf)
println(gandalf == gandalfCopy)
println(gandalf == betterGandalf)
println("--")
println(gandalf === anotherGandalf)
println(gandalf === gandalfCopy)
println(gandalf === betterGandalf)

>> FantasyHero(name=gandalf the grey, weapons=[WAND], heroClass=WIZARD, origin=Origin(city=Utrecht, country=The Netherlands))
>> FantasyHero(name=gandalf the grey, weapons=[WAND], heroClass=WIZARD, origin=Origin(city=Utrecht, country=The Netherlands))
>> FantasyHero(name=gandalf the white, weapons=[WAND], heroClass=WIZARD, origin=Origin(city=Utrecht, country=The Netherlands))

>> true
>> true
>> false
>> --
>> false
>> false
>> false

That all checks out. We created 2 different instances with the same data and they are considered equal (because we check the property values against each other, not the object instances). The straight copy of our instance is equal as well, while the instance where we modified a property isn't any more. And we also check that all instances of heroes are different. They are not the same object. All good, we can continue

Mutating "complex" properties

First, let's give our Wizard an extra weapon. We all know he yields a sword as well after all. Since we expect copies to be shallow copies here, we would expect the list of weapons to be changed in all copies of the hero if we change the original list. And that's exactly what happens :

gandalf.weapons.add(WEAPONS.SWORD)
println(gandalf.weapons)
println(anotherGandalf.weapons)
println(gandalfCopy.weapons)
println(betterGandalf.weapons)

>> [WAND, SWORD]
>> [WAND]
>> [WAND, SWORD]
>> [WAND, SWORD]

// Same behaviour in case we change one of the later copies btw
anotherGandalf.weapons.remove(WEAPONS.SWORD)
println(gandalf.weapons)
println(anotherGandalf.weapons)
println(gandalfCopy.weapons)
println(betterGandalf.weapons)

>> [WAND]
>> [WAND]
>> [WAND]
>> [WAND]

In the same manner, modifying a property that is a data class itself yields the same types of result, all copies are affected :

gandalf.origin.country = "France"
println(gandalf.origin.country)
println(anotherGandalf.origin.country)
println(gandalfCopy.origin.country)
println(betterGandalf.origin.country)

>> France
>> The Netherlands
>> France
>> France

Mutating a simple property

So far so good. Let's change Gandalf's name!

gandalf.name = "Gandalf the Blue"
println(gandalf.name)
println(anotherGandalf.name)
println(gandalfCopy.name)
println(betterGandalf.name)
    
>> Gandalf the Blue
>> Gandalf the Grey
>> Gandalf the Grey
>> Gandalf the White

When mutating the String property of our Wizard, we see that the name change isn't propagated to any of the copies.

Doing the same test with an Enum leads to a similar result

gandalf.heroClass = CLASS.PALADIN
println(gandalf.heroClass)
println(anotherGandalf.heroClass)
println(gandalfCopy.heroClass)
println(betterGandalf.heroClass)

>> PALADIN
>> WIZARD
>> WIZARD
>> WIZARD

Now, that had me confused at first. Confused enough to ask on the Kotlin Slack actually (thanks for the help folks!) . Are the copies holding references to the same values or not? Well, it turns out that they are and the explanation goes back to the basics of Kotlin / Java :  References are immutable, so modifying them literally leads to referencing a new Object instead. The behaviour has nothing to do with data classes :

var heroClass = CLASS.WARRIOR
val theClass = heroClass
heroClass = CLASS.WIZARD

println(heroClass)
println(theClass)

>> WIZARD
>> WARRIOR

When copying data classes around, the constructor passes references to all of the properties, and all of those references are immutable.

Conclusion

Just like we expected, the data class copy method create shallow copies of instances. We would have saved time just checking the documentation actually:

Now back to our question : Are data classes thread safe? Well now I realize that there's been a confusing in my head during the training. Data classes have little to do with immutability, they are a convenient way to work with objects purely holding data. However, you can make them immutable by making sure all of their fields are immutable themselves. That's what I typically do, and you probably should too 😊.

Further reading

Interestingly, Romain pointed at a KEEP in the Twitter thread which quite literally discusses the topic mentioned here. I'm keen on seeing what's gonna happen with Value Classes in the future.

Hit me up @jlengrand, if you have questions or remarks, I'm always up for learning new things 😊

TL;DR : Just starting with Kotlin/JS, I found it hard to use large NPM libraries like Firebase. But my past experiences with Elm and its system of ports helped me find a suitable solution. The GitHub repo is here

TL;DR2 :You can skip the introduction and go straight into the implementation here.

TL;DR3 : You can test the demo here

I'm a backend engineer by trade. But those days, pretty much any idea I have to scratch my own itch can be solved using a simple front-end attached to some basic serverless database like Firebase or Supabase (Big Fan here!).

It's totally fine, except that it leaves me very little time to play around with my dear friend Kotlin 😬. For that reason, and because Kotlin Multiplatform hit 1.0 a couple months back I decided to spend the last weeks diving into Kotlin/Js.

I won't spend much time describing it, but in short Kotlin/JS is letting you write Kotlin that gets transpiled into Javascript, and that can run in your frontend (or you backend, for that matters). Now, there are many reasons why people would or would not want to do that. For me, it's mostly about my experience as a developer. I want to be enjoying myself after a long day of work. And boy I've been spoiled by Elm in the past with Developer Experience, so suffice to say that the bar is high 😁.

In this blog, I want to dive into a specific part of my experience : using large NPM libraries in my projects. I'll use Firebase as an example.

The problem

Let's say that I want to use Firebase Auth and Firestore in my project. I'll need access to a couple functions from the library. Namely :

// A function to sign up / login
const userCred = await signInWithPopup(auth, provider);

// Another one to log out
await signOut(auth);

// One function to add document
await addDoc(collection(firestore, `users/${uid}/messages`), {
    content : message
});

// one to get the list of messages
const querySnapshot = await getDocs(collection(firestore, `users/${uid}/messages`));
  querySnapshot.forEach((doc) => {
    console.log(doc.data()
});
    
    
// finally also a method to automatically get updates are new messages are created to avoid having to fetch messages ourselves
const q = query(collection(firestore, `users/${uid}/messages`));
onSnapshot(q, (querySnapshot) => {
    const messages = [];
    querySnapshot.forEach((doc) => {
        callback(messages);
    });
});
    
    

Now, let's look at the different ways I have to use those from Kotlin/JS.

Using external declarations

External declarations are a way to describe the javascript so that Kotlin can make use of its static typer. The best use case isn't it. You're using Javascript, but typed and in Kotlin. It looks like this :

@JsModule("is-sorted")
@JsNonModule
external fun <T> sorted(a: Array<T>): Boolean

At first sight, that sounds like a great idea. Except it's more complex than it looks like. The signInWithPopup method needs a provider, and the auth API. We need to basically setup the project. In Javascript, it concise and easy :

const firebaseApp = initializeApp(FIREBASE_CONFIG);
const provider = new GoogleAuthProvider();
const auth = getAuth();
const firestore = getFirestore(firebaseApp);

Thing is, those declarations contain a lot of complexity, and they're heavy to describe. Here is what firebaseApp in the console :

It's not an impossible job, I just think it's too much given that we're literally never gonna use that firebaseApp again except for instantiating what we need.

Using dynamic imports

Another option that the Kotlin/JS documentation offers is using the dynamic keyword. The keyword basically disables the type checker.

You could basically decide to do it like this :

val firebase: dynamic = require("firebase/app").default
    
val firebaseConfig: Json = json(
	"key" to "value"
    ...
)
val firebaseApp: dynamic = firebase.initializeApp(firebaseConfig)

Well, of course it's possible but we're then literally removing all the reasons for me to use Kotlin in the first place?! I don't get any type checking any more, less smart completion, error handling, . . .

For me, that's just not an option.

Using Dukat

I think the folks building Kotlin/JS are very well aware of that problem, and they know that everyone is not going to start creating adapters for every single NPM package on Earth. That's a massive work in the first place and even more to maintain. Plus, pretty much all of the Javascript ecosystem offers Typescript definitions those days for their libraries, which is pretty much what we want isn't it?

Enters project Dukat, which aims at leveraging those Typescripts definitions and automatically generate Kotlin external declarations from them. A brilliant idea if you ask me. It looks like this :

$ npm install -g dukat
$ mkdir test; cd test 
$ npm install firebase
$ dukat firebase/app/dist/app/index.d.ts

Which generated a bunch of files like this :

A brilliant idea indeed, but still in very early stage :). So far, none of the libraries that I have tried to convert have really worked and I ended up spending time in generated Kotlin files trying to fix issues, including converted es5 itself. Not fun

On top of that, the development of Dukat has currently been paused as the new IR compiler is being stabilised.

Using a library

Of course, there are folks that have tried to solve that issue before and offer solutions. Namely, the firebase-kotlin-sdk mostly solves that issue in my case.

To be honest, it looks great. I've played around with it just a bit and it would have filled my needs and more. It's also active, and has multiplatform support.

I'm not sure why I didn't go that direction. There are two main reasons : I didn't really want to add  a library dependency on top of a library already. We'll be running in the browser and want to be light remember? It looked like overkill for 4 functions. On top of that, the library introduces additional concepts and I didn't want to have to dive into additional documentation. Learning Kotlin/JS itself was well enough.

 Remember those good old Elm ports?

At that point I had been struggling between options for a few days. As I was having coffee with my old friend Swen he told me "What don't you just do like we were doing with Elm ports?". HA! There was the nice option I was searching for the past few days :).

A step back, Elm intro

For those of you that never heard about Elm understand what I'm talking about, I have to explain a little. Elm is a pure functional language for the front-end. What that means is that if you write something in Elm, you pretty much CANNOT have runtime exceptions. And of course, everything is strongly typed.

(Seriously though, Elm has been a mind blowing experience for me, try it out).

Now, that sounds nice, but it doesn't play nice with Javascript at all. When you write Elm, the runtime makes sure you are safe. But in the Javascript world on the other end, you benefit from all the nice libraries and APIs; even if they can fail.

To solve that problem Elm introduces the concept of ports, which are a way to bridge from the unsafe world of wild Javascript into the nice, clean world of Elm.

Ports basically allow you to avoid a full rewrite by letting you create strong interface that you define as unbreakable, so that you can interact with your Javascript.

And we're back with Kotlin

It might not be very crystal clear just yet, but there is nothing complex I promise. We'll apply the same concept of ports here in our Kotlin app. What we will do is :

• Define a clear interface of what we need in Javascript using external declarations
• On the Javascript side, create a thin layer to do the heavy lifting for us
• On the Kotlin side, enjoy that safe typed layer, free of anything that we do not require.

Let's come back to the Javascript functions we need in Kotlin :

import {FIREBASE_CONFIG} from "./constants";
import { initializeApp } from "firebase/app";
import { getAuth, signInWithPopup, GoogleAuthProvider, signOut } from "firebase/auth";
import { collection, addDoc, getFirestore, getDocs, onSnapshot, query}  from "firebase/firestore";

const firebaseApp = initializeApp(FIREBASE_CONFIG);
const provider = new GoogleAuthProvider();
const auth = getAuth();
const firestore = getFirestore(firebaseApp);

const userCred = await signInWithPopup(auth, provider);
await signOut(auth);

await addDoc(collection(firestore, `users/${uid}/messages`), {
    content : message
});

const querySnapshot = await getDocs(collection(firestore, `users/${uid}/messages`));
  querySnapshot.forEach((doc) => {
    console.log(doc.data()
});
    
const q = query(collection(firestore, `users/${uid}/messages`));
onSnapshot(q, (querySnapshot) => {
    const messages = [];
    querySnapshot.forEach((doc) => {
        callback(messages);
    });
});
    
    

On that side, we create our own API layer, with only what we need. The inputs we'll get, and the output we need in our Kotlin app.

const firebaseApp = initializeApp(FIREBASE_CONFIG);
const provider = new GoogleAuthProvider();
const auth = getAuth();
const firestore = getFirestore(firebaseApp);

export async function logIn(){
    const userCred = await signInWithPopup(auth, provider);

    return {
        accessToken: userCred.user.accessToken,
        email: userCred.user.email,
        uid: userCred.user.uid,
    }
}

export async function logOut(){
    await signOut(auth);
}

export async function saveMessage(uid, message){
    await addDoc(collection(firestore, `users/${uid}/messages`), {
        content : message
    });
}

export async function getMessages(uid){
    let messages = [];

    const querySnapshot = await getDocs(collection(firestore, `users/${uid}/messages`));
    querySnapshot.forEach((doc) => {
        messages.push({
            id: doc.id,
            content: doc.data().content
        })
    });

    return messages;
}

export async function syncMessages(uid, callback){
    const q = query(collection(firestore, `users/${uid}/messages`));
    onSnapshot(q, (querySnapshot) => {
        const messages = [];
        querySnapshot.forEach((doc) => {
            messages.push({
                id: doc.id,
                content: doc.data().content
            })
        });

        callback(messages);
    });
}

And on the Kotlin side, we now can declare our own thin API layer

external interface AppUser{
    val email: String
    val uid: String
    val accessToken: String
}

external interface AppMessage{
    val id: String
    val content: String
}

@JsModule("@jlengrand/firebase-ports")
@JsNonModule
external object FirebasePorts{
    fun logIn() : Promise<AppUser>
    fun logOut()

    fun saveMessage(uid: String, message: String)
    fun getMessages(uid: String) : Promise<Array<AppMessage>>

    fun syncMessages(uid:String, callback: (Array<AppMessage>?) -> Unit)
}

// And we can use those in my app directly like this
Button(attrs = {
    onClick {
        error = null
        FirebasePorts.getMessages(user!!.uid)
            .then { messages = it }
            .catch { error = it.message }
    }
}) {
    Text("Retrieve messages manually!")
}

And that's it really, there is nothing more. By writing 50 lines of Javascript that I can easily test, I lifted the need for the whole interoperability with the Firebase library in my Kotlin app.

Even better, my Kotlin does not even contain any reference to Firebase any more 🤯. I could just as well change the implementation on the Javascript side to using Supabase and it would work just as nicely. Firebase has become an artifact of implementation.

Conclusion

It's been a long intro, so I'll write some words of conclusion 😃.

Kotlin/JS is still in its infancy, but I like the power of having access to my favorite backend language to write front-end as well. Let's see what the future holds.

Interacting with the Javascript ecosystem is still a tough cookie though. There are many options, all with their own drawbacks. I believe that the "Elm Ports method" has some great stuff going for it though:

• No compromises on the Kotlin side, with no dynamics
• No need to dive into the library's interface to create the Kotlin external declarations.
• A clean interface, that can even be used as a layer of separation of concern
• No need for an extra library, you are in control of the whole lot

Of course, it will be way less interesting if you want to build multiplatform modules, or if you use the capabilities of the library extensively.

You can find an example implementation using the code described above on that GitHub repository.

I hope you liked the post, let me know what you think, it's the very beginning of my Kotlin/JS journey 🎉.

Some references :

• The image of this post comes from here
• Stack Overflow question, using Dukat with Firebase
• Someone else using Kotlin/JS with Firebase
• The very same demo, also from me, but in Elm