DEV Community: Marc Reichelt

It's Time to Act

Marc Reichelt — Thu, 23 Jan 2025 12:06:04 +0000

So here we are, living our lives. Just trying to get by. Trying to find our bit of happiness in the world. And then the world implodes.

All I wanted is to live in peace. To be around people I care about. Mostly mind my own business. To find meaning in my work, and to make my small contribution to make the world better. But I realized there are people working on burning the world to the ground, quite literally: dictators, fascists, greedy oligarchs and corporations are on track to destroy the world and everything we love, just to secure even more trillions of dollars in profits for themselves. How can we possibly cope with that?

The oil and gas industry worldwide made 2.8 billion dollars in pure profit - every single day over the last 50 years (source). We're facing an industry that can afford to buy elections, politicians, news outlets, TV channels, social media, create and fund pro-oil NGOs, and much more - and most of that with the profits of a single day. To add to that, it's in their interest to fund fascists, in order to destabilize governments. More power for very few people with money, less power for everyone else.

The evil forces are shockingly resourceful, organized, and loud. That means we have to be even more resourceful, organized, and even louder. Resourceful in numbers. Organized against evil. And our message has to be heard loud and clear from the rooftops: empathy and love!

Build your home-base: Talk with friends! Donate to causes you find worthy, like fact-checking news outlets and activists. Speak out if you see intolerance. Attend pro-democracy demonstrations. Boycott companies that spread fake news or extreme statements, and the ones that support extremists: Boycott Tesla, Meta, and fake-news spreading media. And if you haven't, close or at least abandon your accounts on Twitter/X, Facebook, Instagram! Join Mastodon and Bluesky, and rediscover the joy of having a like-minded and tolerant community! Spread the word on the positive news, because there are many!

I'd like to end this post on a personal note. To this day, my favourite band is the German punk-rock band Die Toten Hosen. I always liked their songs, and their lyrics connected with me in a special way due to personal experiences.
It just so happened that many years ago, while attending a live concert in Frankfurt, the front singer Campino threw an open beer can into the audience - and I was the lucky one to catch it, among many others who wanted to catch the can thrown by their idol. But the can landed exactly with the open hole around my middle finger, so I got a pretty scar. I've always laughed it off as a funny thing: "Hey, see - now I'll always remember my favourite band!"

Today, I decided it's time to lift that finger again - to send one message:
Fuck intolerance!

It's time to act. Let's get to work.

PS: follow me on Mastodon and Bluesky if my post resonates with you!

Kotlin is so nice – it prevents bugs 🐛 before you add them…

Marc Reichelt — Fri, 19 Jun 2020 15:57:03 +0000

You all know those awesome colleagues who don't let go - after your team fixes a bug, they go the extra mile and make changes that no team member will fall into that trap again. They prevent future developers from making the same mistakes!

Well, Kotlin and IntelliJ are doing exactly that - for millions of developers worldwide! These are just a few examples of how Kotlin prevents bugs before you even make them.

No more `switch/case`

If you start with Java (or C or C++), you'll make this mistake a few times before learning how to avoid it. Let's see some Java code:

static void printOperatingSystem(OperatingSystem operatingSystem) {
    switch (operatingSystem) {
        case windows:
            System.out.println("Windows");
        case mac:
            System.out.println("Mac");
        case linux:
            System.out.println("Linux");
    }
}

If you call printOperatingSystem(OperatingSystem.linux), this will print Linux. But if you call it with printOperatingSystem(OperatingSystem.windows), this will actually print:

Windows
Mac
Linux

That's because we need to put a break at the end of each case to not fall into the next one. For many developers, this might seem like a simple mistake - because once you learn about it, you learn to avoid it, and it goes into your muscle memory.

But what if the language would not let you do these mistakes in the first place? Let's see how you would write this in Kotlin:

fun printOperatingSystem(operatingSystem: OperatingSystem) {
    when (operatingSystem) {
        OperatingSystem.windows -> println("Windows")
        OperatingSystem.mac -> println("Mac")
        OperatingSystem.linux -> println("Linux")
    }
}

No more break to forget, and it's easier to read as well.

Equality instead of instance check

In Java, if you use ==, this will actually check the instance of an object - not the content. What's really weird is that when you try this out with a simple check like in the third line of the next example, this will actually 'work' - because Java will optimize the Strings to exist only once in memory:

String one = "1234567";
String two = "1234567";
System.out.println("one == two: " + (one == two)); // prints true

String three = two.replace('7', '8').replace('8', '7'); // that's still the same
System.out.println("two == three: " + (two == three)); // prints false

Modern IDE tools thankfully warn you about this by giving you a message String values are compared using '==', not 'equals()' and an auto-fix, but it would be nice if the language itself would choose the most-used equality operator as the default. Kotlin does:

val one = "1234567"
val two = "1234567"
println("one == two: " + (one == two)) // prints true

val three = two.replace('7', '8').replace('8', '7')
println("two == three: " + (two == three)) // true, as we would expect :-)

NullPointerExceptions

This is old news for Kotlin devs, but still: every time you avoid nullable types in your codebase prevents these bugs from happening. Every time you hit the . on a variable or a long expression and Kotlin tells you: "Wait a second, actually that could be null!" is another bug being prevented.

This is a win-win-win: Users love stable applications, developers love if they don't have to go on a multi-hour bug hunt how that null value actually made it into the database, and product owners love it as well when developers can use their time to implement new features (and not go on multi-hour bug-hunts instead).

Here's some Java code:

String city = user.getAddress().getCity();

But actually, the user does not have an address, so getAddress() can return null. If you didn't develop the best practice to use @NonNull and @Nullable annotations, these bugs are going to happen. And they do - all the time. Tony Hoare did call the null reference a billion dollar mistake for a reason.

Kotlin will save you here:

The beauty about these prevented errors is how Kotlin and the IDE do this. They prevent you from making these mistakes while you are typing. And usually, it feels so nice when they offer you an auto-fix directly at your fingertips.

Coroutines

I have to say I made this mistake in Java quite more times than I thought I would. Let's see some Java code:

new Thread() {
    @Override
    public void run() {
        // do something cool here
    }
}.run();

Do you see the mistake? Of course, I called run() instead of calling start(). So the code will just do the thing you defined in run - but it will not do that on the thread, like you expected it to. Today, IntelliJ and other IDEs give you a warning here - but wouldn't it be nice if you didn't need to learn the difference in the first place? What if the tooling would prevent you from making this mistake?

With Kotlin Coroutines, the IDE will write an error directly when you try to call a suspending function from your regular, non-suspending code:

EDIT: I want to highlight a good comment by AndroidDeveloperLB: Of course Coroutines are something very different than Java Threads. He mentioned that there is a nice thread() utility method in Kotlin's stdlib. With that, you can write the code above correctly like this (and automatically starting the thread as well):

thread {
    // do something cool here
}

I think this is another great example how Kotlin makes existing APIs easier to handle - with less code and less possible bugs! ❤️

Code you don't have to write/generate is code without bugs (usually)

When we write code, we will make mistakes. That's even true for Kotlin code. 😉

But it's nice if we don't have to wrote some code (mostly boilerplate) in the first place. More often than you'd like, you'll find projects with code like the following (even if tools like Lombok exist, some projects don't use them).
Of course, this is a really bad legacy project, so let's say there are no unit tests either.

I added an error in the Java code – let's see if you can spot it!

class User {

    private final String firstName;
    private final String lastName;
    private final Address address;
    private final PhoneNumber phoneNumber;

    User(String lastName, String firstName, Address address, PhoneNumber phoneNumber) {
        this.firstName = firstName;
        this.lastName = lastName;
        this.address = address;
        this.phoneNumber = phoneNumber;
    }

    public String getFirstName() {
        return firstName;
    }

    public String getLastName() {
        return firstName;
    }

    public Address getAddress() {
        return address;
    }

    public PhoneNumber getPhoneNumber() {
        return phoneNumber;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return false;
        if (o == null || getClass() != o.getClass()) return false;
        User user = (User) o;
        return Objects.equals(firstName, user.firstName) &&
                Objects.equals(address, user.address) &&
                Objects.equals(phoneNumber, user.phoneNumber);
    }

    @Override
    public int hashCode() {
        return Objects.hash(firstName, lastName, address, phoneNumber);
    }

    @Override
    public String toString() {
        return "User{" +
                "firstName='" + lastName + '\'' +
                ", lastName='" + firstName + '\'' +
                ", address=" + address +
                ", phoneNumber=" + phoneNumber +
                '}';
    }
}

Did you find it? There, in the equals method, the first line should actually return true in the instance check. Because right now, it will wrongfully return false for the same instance. Wait, you found a different error? That's because I actually tricked you a little. There are actually two errors here! There, in the getLastName method, I wrote return firstName.

Oh wait, there are more: I exchanged firstName and lastName in the constructor as well. That's not an error in itself, but I'll guarantee you that some colleagues will have a small look at the class, see the members, and instantly conclude that firstName is the first parameter of the constructor. And they'll wish me to the ground of the deepest sea when they find out what I've done. 😇

Oh, and in the toString() method, this will actually print the last name as the first and vice-versa. Good luck finding that bug.

And did I mention that I removed the lastName from the equals method because that felt like a good idea to fix an entirely unrelated function, that now depends on this mistake to be there? These things happen all the time. At least I kept the hashCode() function correctly. But with a developer like me, you can never know.

All in all, there are 5 errors in this code! And that with only 4 members. And in big projects, you will only find out about these bugs later on when some user reports a weird behavior. And then the bug-hunt begins.

With 20 or more members, it becomes extremely common to forget to re-generate this code, or manually add the appropriate lines in the specific functions. Sometimes, some of the necessary changes get lost due to someone not resolving a Git merge conflict properly. 😱

Long story short: not having to write this code in the first place is a blessing! In Kotlin:

data class User(
    val firstName: String,
    val lastName: String,
    val address: Address,
    val phoneNumber: PhoneNumber
)

There. Constructor, equals, hashCode, toString, getters, setters, copy function, @NonNull annotations - all done for you under the hood. Not giving someone like me the opportunity to mess this up. 😅

Sealed classes with `when`

In the Java switch/case and if/else world, it's easy to forget to handle a particular case. Let's say we have this Java code:

CreateUserResult result = createUser(credentials);

if (result instanceof Success) {
    User user = ((Success) result).getUser();
    System.out.println("User " + user.username + " created");
} else if (result instanceof OtherError) {
    String message = ((OtherError) result).getMessage();
    System.out.println("Other error occurred: " + message);
}

This creates a user, prints it out on success, and prints the error if it couldn't be created. The type CreateUserResult is actually a Kotlin sealed class, and one developer added another case that is not handled yet by the Java code - but the IDE does not show any errors. The type is defined like so:

sealed class CreateUserResult {
    class Success(val user: User) : CreateUserResult()
    class OtherError(val message: String) : CreateUserResult()
    class UserDoesAlreadyExist(val username: String) : CreateUserResult()
}

So there actually is another type, called UserDoesAlreadyExist, which handles the special case that the username is taken already. Let's say the Java code above was written with a Kotlin when statement, the developer who added UserDoesAlreadyExist would have gotten an error instantly and could have fixed it directly:

val result = createUser(credentials)
val message = when (result) {
    is Success -> "User ${result.user.username} created"
    is OtherError -> "Other error occurred: ${result.message}"
}
println(message)

The when is used as an expression here, and that way Kotlin says it must be exhaustive. So this will show up in your IDE:

Easy enough, the IDE can add the remaining branches automatically for you and it's easy to add the remaining code:

val message = when (result) {
    is Success -> "User ${result.user.username} created"
    is OtherError -> "Other error occurred: ${result.message}"
    is UserDoesAlreadyExist -> "Error: user ${result.username} does already exist"
}

Another possible bug, prevented before it could even ship to production!

Final thoughts

These are only a few examples how Kotlin prevents bugs from happening. But actually, Kotlin is full of these. If you use Kotlin: what are your favorite examples of Kotlin preventing bugs before you could even write them? I'd be happy to read your comments!

If you didn't start using Kotlin yet, I hope you got a small taste of how it could make your developer life better! Because not adding bugs 🐛🐛🐛 in the first place is much better than having to spend days or weeks in hunting them down.

Have an awesome Kotlin! 🎉

If you liked this post, please give it a ❤️, click the +FOLLOW button below and follow me on Twitter! This will help me stay motivated to create many more of these posts! 😊

Cover photo by Louis Tsai on Unsplash.

My posts on dev.to: which topics would you like to read about?

Marc Reichelt — Fri, 12 Jun 2020 12:53:40 +0000

// Detect dark theme var iframe = document.getElementById('tweet-1271416542366924801-15'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1271416542366924801&theme=dark" }

Origin story: TechBits by iteratec

Marc Reichelt — Fri, 05 Jun 2020 10:08:46 +0000

Last november I played around with the idea of creating screencasts. Before, I only tweeted my thoughts and I blogged on Medium. Since I already gave a lot of talks in my life, and I kind of got used to people hearing my voice, creating a screencast would be the next step. I already bought a Blue Yeti microphone years ago for the possibility of creating a podcast or recording music with my guitar - but I didn't take the time to create a podcast or a screencast (yet).

This is the origin story how 'TechBits by iteratec' came to be.

The possibility

In my company iteratec, all employees can take some days of their work time off and use it for anything they want. This is called Innovation Frei-Day (page in German). Its a combination of the German word 'frei' (free as in freedom) and 'friday'. It doesn't have to be on a friday - you could also take a whole week - but it's a really nice possibility to do whatever innovative stuff you want, alone or as a hackathon with colleagues, read a book or whatever else you desire.

I think this is pretty cool, because it's not always possible to try out the things we want when we are constrained by the projects we're on and by the tools we use there. This is the chance to break free and do something that brings you forward. Or plainly to have fun! 😊

The idea 💡

Do you know these moments when you talk to a colleague that works on something else, and suddenly in your conversation she comes up with this amazing trick that will cut your build time in half? Or she shows you a keyboard shortcut for your favorite IDE, and from that day on your coding experience is just way more fun? Or you find out about a new tool that you didn't know about, but could totally have used months ago?

That's what I want to capture in screencasts: Random bits of tricks and tools that made me more productive. Of course some watchers will already know these. But for some, these will be new - and maybe it will spark a light in their minds, and make them be more productive and happier!

And would be even cooler: to have colleagues contribute ideas and screencasts to those TechBits as well, and publishing them on the iteratec YouTube channel.

Brainstorming

In order to find ideas I wanted to create screencasts for, I used a technique called 'journaling'. You take a piece of paper and a pen, and you write down everything that comes to your mind. Everything. Even when you think about nothing, you can write down 'right now I am thinking about nothing'. I first read about this particular form of this technique in the book Search Inside Yourself by Chade-Meng Tan. It's a book about mindfulness, but I found that this technique helped me a lot in finding nice ideas.

The setup: Plain and simple

This is how I recorded the screencasts: In my company's office in Frankfurt, with a lovely view outside on the river Main:

Nothing special. Just my MacBook. The Blue Yeti microphone, connected with a USB cable. A coffee, because I love drinking coffee. And my notes from the aforementioned brain dump.

On my Mac, I created a new user called 'iterabits' (this was my first draft name for the project) to not show any confidential data or having pop any notifications in on me. I even created a small checklist to check that I was all set for a screencast: Closing the door (with a small hand-written sign that said Recording in progress), turning off my phone and having everything open for the thing I wanted to show.

Initially, I wanted to record the screencast and do a second voice-over with the microphone later. I quickly dropped that idea, as that would have meant I would need to record twice for each screencast (and time it correctly). Also, I felt that having the tipping sounds and me doing mistakes live would make it more authentic.

Then, I started QuickTime and recorded the screen. The first time, it took me 3 attempts. It got better for the second and third time. Then I edited them with iMovie, and added a small outro from our company.

Let's see the results!

The first 3 screencasts 🎉

🍿 TechBit #1: Using Docker as a playground 🎬

🍿 TechBit #2: Faster C and C++ builds with ccache

🍿 TechBit #3: IntelliJ - Discover & learn new shortcuts easily 🎬

Future

How did you like these? Did you learn something new? Or do you have new tips / ideas what I should do as another screencast in the future? Let me know: I'd love to read your comments, or write me on Twitter! Thanks. 🙂

Cover photo by Shahadat Rahman on Unsplash.

The hidden Kotlin gem you didn't think you'll love: Deprecations with ReplaceWith

Marc Reichelt — Fri, 29 May 2020 09:49:04 +0000

This is one of the features in Kotlin that is enabled by IntelliJ IDEA and the Kotlin language working together like a charm, in order to give you a pleasant developer experience. If you look at the replaceWith documentation, you'd probably move on and never give it a second look. Maybe you'll click through to the documentation of the Deprecated annotation. At least the ReplaceWith docs say what this enables. But because there are no examples, you might just close your browser tab and code on.

But wait! There is so much to love about this. Trust me.

Deprecation of subSequence in Kotlin's stdlib

Let's start with an example. In Kotlin 1.3.72, there still is an extension function String.subSequence that takes a start and an end index. But the Kotlin creators wanted it to be more explicit, so they added a new variant that takes startIndex and endIndex as parameters instead. So they deprecated the old one with the @Deprecated annotation - you can see how they did this here. So if you use the old variant, you'll see it striked through like this:

But because they added a replaceWith parameter on that deprecation, IntelliJ will offer you to fix this automatically if you hit Alt + Enter on it - and you can also decide to automatically fix this in your entire project!

Live in action it looks like this:

And all the person deprecating the old variant needed to do was to add this one liner before the old variant, worrying only about the code itself, and by doing this enabling millions of developers to be able to change their code in seconds:

@Deprecated("Use parameters named startIndex and endIndex.", ReplaceWith("subSequence(startIndex = start, endIndex = end)"))

Wouldn't it be nice if you could do the same? Yes, you can!

Replace all the things

Let's use a simple example to start. Say, you have a codebase where someonce decided to put the word do in front of lots of methods, like doLogout(). But it's an API, so you can't just get rid of these - you'll have to guide developers to use the new variant logout() instead. This is how:

@Deprecated(
    message = "Use simpler logout() instead",
    replaceWith = ReplaceWith("logout()")
)
fun doLogout() {
    logout()
}

And automatically, doLogout() will become ~~doLogout()~~ for those who use it. And by pressing Alt + Enter and auto-applying the fix, developers now can update this to logout() in the entire project.

Ok, but what about this example? Here, we have the parameters in a peculiar order and a peculiar naming, and we want to be able to clean that up, without breaking the project for anyone:

fun doLogin(pwd: String, usr : String) {
    login(usr, pwd)
}

Well actually, you can use the names pwd and usr in your ReplaceWith string, and IntelliJ will automatically insert the expressions used for pwd and usr into the replaced code!

@Deprecated(
    message = "Use simpler login instead with correct parameter order",
    replaceWith = ReplaceWith("login(usr, pwd)")
)
fun doLogin(pwd: String, usr : String) {
    login(usr, pwd)
}

fun login(username : String, password: String) {
}

I didn't see the implementation, but if I would take a good guess this has to work by the IDE taking the old Abstract Syntax Tree (AST), building the new AST of the ReplaceWith string, and copying over the expressions to the right placeholder positions. If anyone finds where this logic is implemented, please send me the GitHub link - I'd love to include it in this blog post! 🌟

Because it's so nice, here's how this looks if you apply it in the IDE:

It can do even more: add more code, and imports

Let's say we have the doLogin method from before, but instead of using two parameters, we want to insert a new Credentials data class that sits in the auth package:

package auth

data class Credentials(
    val username: String,
    val password: String
)

This is how we do it:

@Deprecated(
    message = "Use simpler login with Credentials",
    replaceWith = ReplaceWith(
        expression = "login(Credentials(usr, pwd))",
        imports = ["auth.Credentials"]
    )
)
fun doLogin(pwd: String, usr: String) {
}

When a developer applies the auto-fix with Alt + Enter, this will automatically add an import as well as fixing the code in-place! This time, let's fix multiple occurrences at the same time, because this looks so cool. Imagine having hundreds of these in your code base, in dozens of files - all fixed automatically! 🎉

Deprecated can do more

That's it for now about ReplaceWith! One more thing about @Deprecated annotation: you can add a DeprecationLevel to it as well. The default is WARNING. But if you want to up the game and you want all developers to finally move over to the new API, you can force them by making this an ERROR. These have to be fixed first, otherwise their code won't compile. And finally, once all developers have moved over, you can even set this to HIDDEN - so no one will even see the old method anymore. This is useful if you still want to be binary-compatible. Here is how you can use all these:

@Deprecated(message = "", level = DeprecationLevel.WARNING)
fun warning() {
}

@Deprecated(message = "", level = DeprecationLevel.ERROR)
fun error() {
}

@Deprecated(message = "", level = DeprecationLevel.HIDDEN)
fun hidden() {
}

And here is how they will look when used:

I hope this will be a nice addition to your Kotlin toolbox!

Recap

So to recap, using @Deprecated with ReplaceWith lets you:

deprecate old code, and automatically suggest the desired change
this desired change will be available to all developers working on that code, and they can apply your code change with Alt + Enter instantly
it can even re-order the old parameter values if you need them to, or let you add entire new code constructs and imports
add deprecation levels to decide how fast users of the old code need to fix this
be more productive and have more fun!

Edit: Russell Wolf added a comment on Twitter that you can use this feature also for discovering APIs, which I think is really cool:

// Detect dark theme var iframe = document.getElementById('tweet-1266384210589372416-137'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1266384210589372416&theme=dark" }

Have an awesome Kotlin! 🎉

If you liked this post, please give it a ❤️, click the +FOLLOW button below and follow me on Twitter! This will help me stay motivated to create many more of these posts! 😊

Cover photo by Malcolm Lightbody on Unsplash.

What are your Kotlin fail stories? #discuss

Marc Reichelt — Fri, 22 May 2020 10:18:51 +0000

Hello fellow developers! Kotlin has been around for a while, and maybe not every part of our journey was a piece of cake. 🍰

Was there a project where Kotlin left you in the dark? I want to know about it! What failures (epic or not) did you experience - and how did you move forward? Often, failure stories tell us what things need to be improved. At the very least they make us feel less alone.

Maybe you tried to introduce Kotlin in a company or a project, but for some reason you were rejected? I totally feel you!

Please share your Kotlin fail stories! I'll share mine in the comments as well! 👇

📸 Kotlin Photo Contest - Thank you for your submissions! 🎉

Marc Reichelt — Fri, 15 May 2020 10:01:41 +0000

Two weeks ago I kicked off the 📸 The Kotlin Royalty-free Photo Contest. Back then, if you wanted a Kotlin photo for your Kotlin blog post or your new presentation, you were left on your own. Not any more!
I want to give a huge applause to the 3 contributors: Kübra Harmankaya, Louis Tsai, and Matt McKenna! 👏👏👏

Without further ado, let's show the photos!

Submissions

The first Kotlin photo submitted was by Kübra Harmankaya, showing #kotlineverywhere being truly everywhere – this time on the beach:

Photo by Kübra Harmankaya

The first Kotlin code picture was sent in by Louis Tsai. Awesome!

Photo by Louis Tsai

Kübra sent in a photo of a laptop with Kotlin stickers on it. I have to say I love the combination of flowers and tech!

Photo by Kübra Harmankaya

Matt McKenna submitted not one, not two, but 7 Kotlin photos! His collection on Unsplash is called Kotlin in the Wild. I selected 3 photos to show you here. The first one is a photo of colorful Kotlin code:

Photo by Matt McKenna

This one shows Kotlin on a wooden table. I think this not only is a beautiful photo, but it also makes me want to leave my homeoffice, go to the nearby park, set up a WiFi hotspot, and work from there!

Photo by Matt McKenna

And this one here has a colorful blur of lights in the background, which I think looks great:

Photo by Matt McKenna

But how could I even select 3 photos out of 7? I think all photos of Matt are great - so I recommend you visit his page on Unsplash and pick your personal favorite:

All submissions by Matt McKenna

I added two Kotlin photos myself. If you ever need a photo of just the Kotlin logo in the wild, we've got you covered:

Photos by Marc Reichelt (me)

Thank you! 🎉👏🌟

This goes to you, Kübra, Louis and Matt. Thank you so much for your amazing submissions! All likes ❤️ on this blog post belong to you!

Dear readers: if you want to see the original photos and future ones, follow them on Unsplash and on Twitter to stay up to date!

Kübra Harmankaya on Unsplash and on Twitter
Louis Tsai on Unsplash and on Twitter
Matt McKenna on Unsplash and on Twitter

And don't forget to give them credit when you use their photos! 😊

A note on Unsplash

If you do a search for 'kotlin' on Unsplash, you will notice that only 2 photos appear - even though nearly all of the photos have 'kotlin' either in the title or in the list of tags - or both. I reached out to Unsplash on Twitter, but haven't received an answer so far:

// Detect dark theme var iframe = document.getElementById('tweet-1257681035741069312-686'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1257681035741069312&theme=dark" }

Maybe Unsplash has a manual selection process that I was not aware of. Long story short: To see all photos of this contest, you can find them on Twitter by searching for #KotlinPhotoContest – or by bookmarking this blog post. Or by Googling for 'Kotlin Photo Contest'. 😉

You have awesome Kotlin photos? Share them!

This contest might be over, but it was there in the first place to kickstart having beautiful Kotlin photos, available for everyone. It served that purpose well. Now, if you have more Kotlin pictures to share yourself, you can use the existing photos as inspiration and add new photos to Unsplash yourself! I'll be happy to like & retweet your photos on Twitter if you add @mreichelt to your tweet.

Have an awesome Kotlin! 🎉

Cover photo by Nenad Rakicevic on Unsplash.

A Kotlin developer's view on Flutter/Dart tooling (part 1)

Marc Reichelt — Fri, 08 May 2020 10:37:30 +0000

Small thing in advance: Comparing Flutter to native development was quite a hot topic (pun intended), and still is. I'm not looking for a 'winner' here. I think there are pros and cons on both sides. Often it is good to look over the fence and see what other languages, tools or ecosystems have to offer. And only by pointing out the flaws and by learning how others do it better we can improve things in our own beloved world. So let's improve!

As you might have guessed from my other blogposts, I'm a huge fan of Kotlin. For me, this began when I first used Kotlin around 3 years ago. Back then, my coworker and friend Niklas and I built a backend in 100% Kotlin. It was one of the most pleasant development experiences I've ever had. Since then, I've built a bunch of apps and other software with it, and was very pleased with the language and the tooling.

Fast-forward to today, me and an awesome team are developing a Flutter app for a customer since end of last year. And in Flutter, as you might already know, you'll write almost no Kotlin code (only if you need to have some native functionality). Almost the entire codebase is written in Dart. And having spent some time with Flutter & Dart, I gathered quite a few examples were the tools and the language were lacking and left me in the rain, in a way I didn't expect.

Think you really like something? Or: what a deprivation test is

To explain to you how I felt I better explain what a deprivation test is. FastCompany has an article on how GitHub uses deprivation testing for product design. The basic idea is: Someone has a thing. That could be a product, feature or more. Now you give that person a new thing, and let that person use that for some time. Now comes the deprivation part: You take that new thing away from that person. So the person now is back using the old thing. And then you observe their emotions and you collect feedback. Was it ok for them to go back? Or are they missing the new thing - and why?

I'm sure everyone of you had multiple moments of that in the past. Maybe you had a smartphone that broke, and you had to use an older feature phone for some time, only to be infuriated by it. Or you already used and loved Git, and were forced to use Subversion again because a project didn't migrate yet. Or you had to go back to your old coffee beans because your go-to coffee beans were out of stock, only to find out you hadn't notice how much you liked your go-to coffe beans already.

To me, I had a very strong deprivation moment when going back to a Java project after developing in Kotlin. I couldn't really tell it before, but it made me love Kotlin even more - because I discovered that the vast amount of small improvements were making my coding experience so much better than I expected. I couldn't even tell it before what was making me so much happier - but I could tell very easily when those things disappeared.

And to get back to the topic, I also had a strong deprivation moment when switching from Kotlin to Flutter/Dart. Which I didn't expect, because I actually used Dart (without Flutter) before starting with Kotlin to learn about and implement an interpreter. Coming from Java I thought Dart was quite nice. But coming from Kotlin, my perspective changed completely. What was I missing? Without further ado: Let's dive in!

Dart, coming from Kotlin

Missing null safety

The first thing hits hard. For a long time (and still), Dart had no null safety like Kotlin built-in. So you'll find having to write a lot of these (Dart):

  Person({@required this.name, @required this.age})
      : assert(name != null),
        assert(age != null);

Instead of this (Kotlin):

class Person(val name: String, val age: Int)

And your IDE won't show an error if you write something like Person(name: null, age: null) in Dart. Brace yourselves for NullPointerExceptions.

I can't wait for the Dart team to finalize the support for null safety (they are working on it since 1.5 years), and hope the Dart/Flutter ecosystem - including all the packages and plugins - catches up quickly. If someone of the Dart teams reads this: I think you are doing an amazing job - take your time to finish this feature! 👏 I really hope we'll be able to use it soon.

No data classes / sealed classes

Yep, no data classes in Dart built-in. The class above was actually written like this (Dart):

class Person {
  final String name;
  final int age;

  Person({@required this.name, @required this.age})
      : assert(name != null),
        assert(age != null);

  // toString, equals, hashCode not shown for brevity

}

In Kotlin, the example above was only missing the data keyword:

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

There are tricks to get something like this in Dart by using generators, but come on - it's 2020, and even Java 14 has records now.

I want to highlight a talk by Pascal Welsch named Making Dart more like Kotlin, in which he highlights a pretty new package freezed by Remi Rousselet. This generates code so you can get something like data classes - and even sealed classes - in Dart. It looks promising, but I didn't get my hands on it yet. Still, I believe these features must come to the Dart language as a standard.

Enums

Enums in Dart can't have any fields. So this is basically what you can do with enums:

enum Environment { prod, test }

Want to add a backend URL to all those? Write a switch/case. Want to add a lambda that initializes something for them? Write a switch/case. In Kotlin (as in Java) you can just add them as constructor parameters:

enum class Environment(val url : String) {
    prod("https://prod"),
    test("https://test")
}

Semicolons;

Semicolons in Dart are everywhere! This is something that I really wouldn't have assumed I would notice, but after spending a lot of time in Kotlin, it actually is noticable, and having no semicolons would make the code more readable.

_privateFields

Dart has no private keyword. Private fields are written with underscore prefix. I really can't stand this, this tiny thing spreads over the whole codebase…

final _message = 'please release me';

void doSomething() {
    why(_message);
    println('is ${this._message}');
    final bar = _message + _message + _message + ' so hard';
}

The new tabs vs. spaces: 'single quotes' vs. "double quotes"

Yep, you can write strings either way:

String a = '$foo $bar';
String b = "$foo $bar";

It's basically the same. And I can't even imagine how many commits there must be out there that change single quotes to double quotes, or the other one around. I mean, developers like to argue about small things anyway. Would be boring otherwise, wouldn't it? 😛

if / switch can not be used as expressions

This is a really useful feature in Kotlin, and I didn't think I would miss it. Boy, was I wrong. Let's see a cool example from Kotlin, where we use the combined power of sealed classes, smart casts, and the return value of when:

val result = createUser(credentials)
val message = when (result) {
    is Success -> "User ${result.user.username} created"
    is UserDoesAlreadyExist -> "Error: user ${result.username} does already exist"
}

Yes, when can be treated as an expression - and the Kotlin compiler will show you an error if you forget to handle a possible branch (less bugs!).

Only constant values for optional parameters

I noticed this when I tried to make a lambda parameter non-nullable in Dart, like this:

void doSomething({Function something = (){}})

This is the error you'll see:

I tripped a few times over this (not only for lambdas), and it's kind of sad this doesn't work.

Constructors

One thing that already hit me a few times in Dart is that final fields can not be set in the constructor body. Let's see this simple example, where I have two classes ServiceA and ServiceB, where the second depends on the first, and I want to initialize them in my class:

class MyClass {
  final ServiceA serviceA;
  final ServiceB serviceB;

  MyClass(){
    this.serviceA = ServiceA();
    this.serviceB = ServiceB(serviceA);
  };
}

To do that we would have to implement a series of constructors instead:

class MyClass {
  final ServiceA serviceA;
  final ServiceB serviceB;

  MyClass(this.serviceA, this.serviceB);

  MyClass.foo(this.serviceA) : serviceB = ServiceB(serviceA);

  MyClass.bar() : this.foo(ServiceA());
}

As you can see, this grows quite a bit and makes the code unreadable. And we only had one field that depended on the other. Imagine having 3 or more dependent fields. Yikes.

await: Easy to forget

Let's see this code:

Future<void> doSomethingImportant() async {
  // something important here
}

Future<void> main() async {
  doSomethingImportant();
}

In the default Dart Lint configuration, it'll just let you do this - and depending on how your code executes, the important stuff will never run. Because you forgot to add an await keyword in front of the doSomethingImportant() call. And the IDE didn't warn you. There is a Lint option called unawaited_futures from the pedantic package that will prevent you from this. But that option really should be the default.

Kotlin, with Coroutines, will prevent you from accidentally forgetting this:

suspend fun doSomethingImportant() {
    // something important here
}

fun main() {
    doSomethingImportant();
}

The IDE shows an error directly, and you must either make that method suspend as well or wrap it in something like runBlocking:

Oh, and by the way: You can wrap suspending functions in runBlocking in Kotlin. You can't in Dart. The only possible option is to slap await and async up to the top-most caller, which might be the main method - forcing you to add those keywords in every function of that stack, sometimes forcing you to entirely re-do your architecture if you missed this. Sometimes, programming languages have to be pragmatic to not stand in the way.

Collection API is bad

Lists in Dart are mutable by default. If you're used to Kotlin, you'll know how many nice collection functions there are. Most of them are missing in Dart. And in order to have immutable collections, you'll have to write your own. And did I mention that lists don't have equality defined?

final a = [1, 2, 3];
final b = [1, 2, 3];

void main() {
  // prints false
  print(a == b);

  badMethod(a);
  // a has now changed - good luck in finding those bugs introduced by mutable collections
  print(a);
}

void badMethod(List<int> a) {
  print(a);
  a.add(4); // please don't do this
}

Of course Dart devs will say that you can use const instead of final to get immutable values. And indeed, if we would write const a we would get an exception when we call a.add(4):

Uncaught Error: Unsupported operation: add

But the point of Kotlin's immutable collections is that you didn't even have an add method to call in the first place.

Again, there are nice libraries out there that deal with this. But this is something that belongs to the language itself - otherwise projects will never settle on a common language.

Here is an example how a nice method like associateBy (which does exist in the dartx package, but does not exist in Dart) could help every Dart developer to easily create a map from a list:

Map<int, Person> associateById(List<Person> people) {
  return people.associateBy((person) => person.id);
}

If you use Kotlin, you'll get used to use these functions all the time.

So many missing stdlib functions

If you come from Kotlin, there are so many extension functions that make your life easier. Just look at all those extension functions defined in String.kt. There are removePrefix, removeSurrounding, substringBefore, just to name a few. All those together are a massive improvement in developer productivity.

Again, Dart developers noticed this - and finally that we have extension functions in Dart, we can use those to make code much better. Some Dart developers built the great dartx package, which adds all sort of functions to the standard types. And again, this should be something that every Dart developer should be able to rely on in every project - without setting anything up.

Questionable default implementations

If you ever handled files and directories in Dart, you'll see that Directory and File have no equality defined. If you ever tried to create a set of these: nope, you'll have to convert them to absolute String paths instead in order for the set to work.

Another example is the use of dynamic in APIs. Have a look at the stdout of the ProcessResult class. It's dynamic. According to the documentation:

Standard output from the process. The value used for the stdoutEncoding argument to Process.run determines the type. If null was used this value is of type List<int> otherwise it is of type String.

So we have to just cast to String and hope it works. Type-safety is important: please don't use dynamic if you can avoid it.

Wow, that was already a bunch. And I didn't even run out of things I wanted to write about.

If you are a Flutter or Dart developer, and you stumbled over at least a few of these things: you're not alone! I feel your pain. Maybe you found even more things I didn't mention: Please write me on Twitter. I want to collect more of these, so we have a good overview what we as a community can improve in the future.

As I started this blog post I had in mind to write about the shortcomings of Dart as well as Flutter tooling. I realized there is so much I found with Dart - I didn't even get to the Flutter bit yet. That's why there will be a part 2 of this post soon! Follow me on Twitter and click the +FOLLOW button below to get the new post while it's hot!

Cover photo by Christopher Burns on Unsplash.

📸 The Kotlin Royalty-free Photo Contest

Marc Reichelt — Fri, 01 May 2020 10:37:14 +0000

The Kotlin photo contest is finished! See the submissions here:

📸 Kotlin Photo Contest - Thank you for your submissions! 🎉

Marc Reichelt ・ May 15 '20

#kotlin #photos #unsplash

Some time ago I was creating a Kotlin talk. And while drafting the slides I did some research which images I could show. So I did what I prefer to do most: Open unsplash.com and look there. If you don't know it, Unsplash is an amazing site which offers freely usable images for everyone. And the quality of the images is stunning! What's even better is that you can use all the photos for commercial and non-commercial purposes. But this time, I typed the keyword 'kotlin'. At the time I write this blog post, this is what I found: Gaining emptiness!

Logically, I thought: Alright, Kotlin is too specific. Let's search for 'code' instead. And indeed, some beautiful images came up. Here some examples.

This one here is really nice: the lighting, the colors, the scene set just perfectly – but it's showing JavaScript:

Photo by Clément H

This one here shows only code on screen, and emphasises the syntax highlighting. But who of you would even write (or read) minified code? Usually, we developers prefer nice, tidy code instead.

Photo by Markus Spiske

Here are two developers working together on something. Wouldn't it be nice if we could have photos of developers working on a Kotlin project, or with some Kotlin cups or stickers nearby?

Photo by NESA by Makers

I found pictures of JavaScript, Python, CSS, HTML, Java, PHP and even a photo of some SVG code. That's nice if you were looking for those. But no sign of Kotlin.

Wouldn't it be nice to have some photos that show how clean and readable Kotlin can get? Wouldn't it be nice, the next time you create a blog post, a talk or simply a web page, to have a collection of diverse Kotlin photos to pick from? Wouldn't it be nice to show the world your favorite language?

🌟 The Contest

I proudly present to you: The Kotlin loyalty-free Photo Contest!

Create photos or pick favorites of which you already made, and upload them to Unsplash. Remember to add kotlin to your photo title Tag your photos with kotlin, as well as all other tags that are fitting. Whether it is Kotlin code, a group of Kotlin developers, or photos with the Kotlin logo: The more creative the photos are, the more fun! 🎨

The contest runs for 2 weeks and ends on May 15th. Then I will create another post - highlighting the 7 most noteworthy photos!

🚨🚨🚨Update🚨🚨🚨: Your photo might not appear in the search results for 'kotlin' instantly, even after a few days. I contacted Unsplash about this. Don't worry though: Just post a link to your photo on Twitter with the hashtag #KotlinPhotoContest, or leave a comment below! I'll make sure no awesome photo gets overlooked! 🙂

The Fineprint

Quality over quantity: Please don't upload any photo you have, but pick just one or very few personal favorites, and make sure those are of high quality.
Rights: You must own the rights to the photos you upload.
License: If you upload photos to Unsplash, you agree to their license and submission guidelines. Be aware that if you upload a photo there that anyone will be able to use your photo anywhere for free, without having to give you credit (though many will give you credit anyway).
Stay safe! We are experiencing a pandemic. Whether you are at work, home or in nature: Always remember to maintain a safe distance, wash your hands and overall: stay safe.

Stay in contact

I can't wait to see the photos you come up with! If you share your Unsplash photo on Twitter, use the hashtag #KotlinPhotoContest to share and communicate with others. Also, @ me with @mreichelt, and I'll promise to not be shy with likes and retweets! 😊

If your reading this post and you have a different language that is close to your heart - feel free to give your language some love! For example, I didn't see photos for Swift, Rust, Dart (with Flutter) and many more…

Make your code beautiful with Kotlin Property Delegates

Marc Reichelt — Fri, 24 Apr 2020 10:05:47 +0000

My colleague Andreas Feldschmid and I are about to prepare advanced Kotlin topics for the second day of a two-day Kotlin training. It's pretty amazing that we are now Kotlin trainers at our company iteratec - and I'll write another blogpost about how that came to be in the upcoming weeks. By the way: if there is anything that you would love to learn in an advanced Kotlin training: please leave a comment below or write me on Twitter! 📩

In order to select topics for this training, we were talking about lots of Kotlin features and libraries. And one topic that came up were Delegated Properties. He heard about them, but didn't use them yet. So I quickly opened IntelliJ and showed him this example.

Small recap on properties

This is pretty standard: In Kotlin, we can define mutable properties with var and values with val. Let's see some code:

class Preferences {
    var username : String = ""
}

Here, we have a property username. And each mutable property has a getter and a setter, which you can override. By the way, if you don't know the syntax by memory, you can simply type Alt + Enter on username and get the quick action for that:

There's more to read about that in the Kotlin docs on properties. But instead of implementing properties yourself, you can instead create delegated properties, where the getter and setter are provided someplace else.

Awesome code with delegated properties

A delegated property, as described in the Kotlin docs is simply defined by using the by keyword and a delegate instance:

class Preferences {
    var username : String by Delegate()
}

This can be any class that implements the operator functions getValue and setValue. You can copy those from the documentation - but you can simply let IntelliJ create that class for you. And there are interfaces ReadWriteProperty and ReadOnlyProperty available which can help you with the syntax as well.

As an example, we'll create a FileDelegate that reads and writes text to a file, and takes a file name as parameter:

class Preferences {
    var username: String by FileDelegate("username.txt")
}

class FileDelegate(val fileName: String) : ReadWriteProperty<Preferences, String> {

    override fun getValue(thisRef: Preferences, property: KProperty<*>): String {
        val file = File(fileName)
        return if (file.exists()) file.readText() else ""
    }

    override fun setValue(thisRef: Preferences, property: KProperty<*>, value: String) {
        File(fileName).writeText(value)
    }

}

Now we can access the content of the file username.txt by accessing the property! Isn't that cool?

fun main() {
    val preferences = Preferences()
    println(preferences.username)
    preferences.username = "Marc"
    println(preferences.username)
}

Even better, we now can reuse the same functionality with multiple properties:

class Preferences {
    var username: String by FileDelegate("username.txt")
    var accessToken: String by FileDelegate("accessToken.txt")
    var favoriteFood: String by FileDelegate("favoriteFood.txt")
}

Wouldn't it be nice if we could even generate the filename according to the name of the property? Easy as pie, because each KProperty has a property.name we can use:

class FileDelegate : ReadWriteProperty<Preferences, String> {

    override fun getValue(thisRef: Preferences, property: KProperty<*>): String {
        val file = File(property.name + ".txt")
        return if (file.exists()) file.readText() else ""
    }

    override fun setValue(thisRef: Preferences, property: KProperty<*>, value: String) {
        File(property.name + ".txt").writeText(value)
    }

}

While only a small change, this makes the code even more readable. Of course, this comes at a cost we should be aware of: If someone refactors a property name, the filename will change, too. If we are willing to accept this, the code will read like this:

class Preferences {
    var username: String by FileDelegate()
    var accessToken: String by FileDelegate()
    var favoriteFood: String by FileDelegate()
}

And in addition, because we extend from ReadWriteProperty<Preferences, String>, we can let type inference automatically get the String return type:

class Preferences {
    var username by FileDelegate()
    var accessToken by FileDelegate()
    var favoriteFood by FileDelegate()
}

Let's say that favoriteFood.txt is generated by a different program, and we only want to read it here. We can just change var to val, which effectively hides the setter:

   val favoriteFood by FileDelegate()

I think this can come in pretty handy, and delegated properties can make your Kotlin projects nicer to read. Some things you could use delegated properties for:

Reading/writing things from disk
Caching values as well (instead of reading them again every time)
Reading/writing shared preferences in Android (see this great blog post on how to do that)
Getting something from the network (although you'll have to call runBlocking if you use coroutines, as this mechanism currently does not support suspending coroutines - at least not that I know of)
Do logging

Wait, there's more!

The Kotlin documentation on delegated properties contains more knowledge. For example, I already knew about the lazy delegate from Kotlin's stdlib, which can be used to get and store the result of some expensive operation:

val lazyValue: Int by lazy {
    calculateAnswer() // takes 7.5 million years to print 42
}

What I didn't know was that you can define the thread safety mode (as lazy is synchronized by default, which can add more overhead than you would expect):

val lazyValue: Int by lazy(mode = LazyThreadSafetyMode.NONE) {
    calculateAnswer() // takes 7.5 million years to print 42
}

Another useful thing I didn't know yet was that you can delegate to a map, like so for an immutable map as stated by the Kotlin docs:

class User(val map: Map<String, Any?>) {
    val name: String by map
    val age: Int     by map
}

Have an awesome Kotlin! 🎉

If you liked this post, please give it a ❤️, click the +FOLLOW button below and follow me on Twitter! This will help me stay motivated to create many more of these posts! 😊

Cover photo by Anton Sulsky on Unsplash.

Handling SIGINT in Kotlin Native

Marc Reichelt — Wed, 15 Jan 2020 09:11:03 +0000

Just 2 weeks ago Patrick Lemke on the Kotlin Slack in the #kotlin-native channel asked an interesting question:

I was intrigued by this question. A SIGINT is the event sent to a process if you press Ctrl + C in the shell, and that usually exits a process. So how would you actually handle events like SIGINT in Kotlin Native? 🤔

At first I thought this would be hard to implement. I tried to create a small example. On my way I not only managed to implement this, but discovered how Kotlin tooling and documentation can help you in solving similar problems. Onward!

How C/C++ handle SIGINT

At first it's probably a good idea to read about how these interrupts are actually created in C/C++. I searched for 'handle sigint c/c++' on Google and found a page on C++ Signal Handling. Basically, you define a function in C++ and you can register it as a signal handler by calling the signal function (that's the only C++ code I'll show here):

void signalHandler(int signum) {
    // your logic here when interrupt happens
}

int main () {
    // register your handler function - can be SIGINT, SIGABRT, or others
    signal(SIGINT, signalHandler);

    // ever-running code here that can/will be interrupted
}

Calling `signal` in Kotlin Native

Now let's find out how we can call that function in Kotlin Native! First, I opened IntelliJ, and created a new Kotlin Native project with Create New Project -> Kotlin -> Native | Gradle. This automatically creates a sample main file. Let's see if it can find a signal function. And jackpot - there it is, and it can be imported!

And SIGINT and the other constants can be found as well:

I think this is tooling by IntelliJ/Kotlin is pretty amazing. It looks simple, but there is actually a whole lot going on under the covers. The POSIX bindings are created automatically for you and the platform(s) you target, and they are already indexed, waiting for you to type-and-complete.

Now, moving to the second parameter: we already know this is a lambda. But what the heck is a CPointer<CFunction<(Int) → Unit>>? - and how do I get one? I had no idea, because I've never done this before in Kotlin (although I know what a pointer is). So I googled for 'kotlin cpointer cfunction', and landed on this excellent Kotlin documentation: Mapping Function Pointers from C

And there it is - scrolling down I find exactly what I need: Passing Kotlin Function as C Function Pointer Using that, we now know that Kotlin provides a helper function called staticCFunction. Let's use that!

So a trivial example might be that we print something forever. And then we will interrupt it. Here's my first, trivial implementation:

fun main() {
    signal(SIGINT, staticCFunction<Int, Unit> {
        println("Interrupt: $it")
    })
    while (true) {
        println("running")
        sleep(1)
    }
}

When we compile this (by clicking the Build button), it will create a binary with the name of our project and a .kexe ending. For me, it created a file under build/bin/macos/debugExecutable/kotlin-native-signal.kexe. I wanted to call the main method directly via the common 'green arrow run button', but that wasn't there. For now, we'll use the commandline - but I hope JetBrains continues to improve the tooling around Kotlin Native (see that section further down).

So let's call the program in a shell, and press Ctrl + C after 2 seconds to interrupt it:

$ build/bin/macos/debugExecutable/kotlin-native-signal.kexe
running
running
^CInterrupt: 2
running
running
running
[program continues, does not exit]

Nice, it does handle the interrupt! 🙂

But we didn't actually exit the program in our interrupt handler - so now the program will continue forever. Unless we kill it with killall… 😈

# in a second shell:
$ killall kotlin-native-signal.kexe

# in the first shell this will kill the program:
[1]    66077 terminated  build/bin/macos/debugExecutable/kotlin-native-signal.kexe

To improve this program, we can call the (POSIX function!) exit in the interrupt. Also, we can use staticCFunction to create a CPointer reference to an existing Kotlin function as well. Here's the improved version, with imports added for reference:

import kotlinx.cinterop.staticCFunction
import platform.posix.SIGINT
import platform.posix.exit
import platform.posix.signal
import platform.posix.sleep

fun handleSignal(signalNumber: Int) {
    println("Interrupt: $signalNumber")
    exit(0)
}

fun main() {
    signal(SIGINT, staticCFunction(::handleSignal))
    while (true) {
        println("running")
        sleep(1)
    }
}

Finally, when we interrupt the program with Ctrl + C, it will run our handler code and exit.

IntelliJ: A tooling improvement suggestion

When I wrote this blogpost I wanted to run the main method directly from the editor. But where usually I expect to find a green run icon of happiness there was just an empty grey area:

At first I tried the free community edition of IntelliJ. Next, I tried IntelliJ Ultimate. I opened the same project. Ultimate suggested I install a plugin, so I did that:

Nevertheless: even after doing that and restarting the IDE, Ultimate didn't show me the green run button. In the 'Run Configurations', I got a new entry 'Kotlin/Native Application' - but it didn't detect my Kotlin Native executable, so I couldn't select that.

Finally, I tried CLion. I installed an additional plugin for Kotlin Native. Still, no run icon to the left of the main method. But at least I got a run configuration that way, and I could run & debug the Kotlin Native program from the IDE! 🎉

So for tooling, I have the following wishes:

I'd love to have that green run icon. It's there in C/C++ programs in CLion and in all Java projects, so why not here?
IntelliJ Community could make the suggestion that run/debug is only supported in the commercial tools.
IntelliJ Ultimate and CLion should behave consistently. What works in CLion should work in Ultimate as well.

Conclusion

This was a fun ride! It's so amazing that we can use POSIX APIs and more (iOS & MacOS libs, etc.) in Kotlin Native - and the coding tooling is great already. There are still some things that could be improved. Then again, Kotlin Native is still a relatively new technology. But it's already on a good way to becoming stable!

If you liked this post, please give it a ❤️ and follow me on Twitter!

Christmas Hacking: Squeezing Kotlin Native into Docker

Marc Reichelt — Wed, 25 Dec 2019 22:49:39 +0000

Some time ago, I had a conversation with my fellow GDG organizer Randy Gupta. He's a Google Developer Expert on cloud, and he blew my mind when he said that you can create Docker images containing a single, self-contained executable. Think about it: no libraries, no package manager - just a single program doing it's job. That's amazing!

So because I love Kotlin, I wondered how far we can take this using Kotlin Native. With that, we can compile Kotlin code as an executable. Then we can add this to a Docker image. Let's begin, and have some fun! 😊

Kotlin, Go Native

As a first step, we'll create a simple hello world program and compile that to native. There's a good tutorial to start. Our hello_world.kt program:

fun main() {
    println("Hello, World!")
}

Now we can compile and run it natively:

$ kotlinc-native hello_world.kt -o hello_world

$ ./hello_world.kexe
Hello, World!

$ file hello_world.kexe
hello_world.kexe: Mach-O 64-bit executable x86_64

Ok, this works! But as you can see, because I ran this on my Mac, this created a Mac executable. For Docker, we will need a Linux executable. We can pass -target linux as a parameter to kotlinc-native to do that:

$ kotlinc-native -target linux hello_world.kt -o hello_world_linux

$ ll *.kexe
-rwxr-xr-x  1 mreichelt  mreichelt   607K 25 Dez 19:06 hello_world.kexe
-rwxr-xr-x  1 mreichelt  mreichelt   375K 25 Dez 19:14 hello_world_linux.kexe

$ file hello_world_linux.kexe
hello_world_linux.kexe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.16, BuildID[xxHash]=421d2b66bd8de945, not stripped

Ok, cool - we have a Linux binary! Docker will be so happy… 🎉

Docker + Kotlin Native = ❤️

Let's pack this into a Docker image using a Dockerfile:

FROM ubuntu
COPY hello_world_linux.kexe /hello_world
ENTRYPOINT ["/hello_world"]

Now, we can build the Docker image & run it:

$ docker build --tag hello_kotlin .
Sending build context to Docker daemon  5.179MB
Step 1/3 : FROM ubuntu
 ---> a2a15febcdf3
Step 2/3 : COPY hello_world_linux.kexe /hello_world
 ---> 9438118fba59
Step 3/3 : ENTRYPOINT ["/hello_world"]
 ---> Running in 2454425124e7
Removing intermediate container 2454425124e7
 ---> 47b7a9b05993
Successfully built 47b7a9b05993
Successfully tagged hello_kotlin:latest

$ docker run --rm hello_kotlin
Hello, World!

$ docker image list hello_kotlin
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
hello_kotlin        latest              47b7a9b05993        2 minutes ago       64.6MB

Yay, it works! Think of what you can do now:

Compile Kotlin code to a native binary
- you don't have to use the CLI compiler - this should work for your Gradle-builds from the IDE as well!
no need for the JVM, so our Docker image already has 64.6MB in size (not more than 600MB)! 🌟

And because Docker caches the lower layers (for us it's Ubuntu), there is no actual need to make this smaller. This will be the best result for most people, because if you need a shell or other Ubuntu tools, this image will give you that flexibility. But if you're courious how we could make this smaller, and you're willing to leave some comfort behind: read on!

Honey, I Shrunk the Docker Image

Docker offers a way to create images from scratch. So let's do that - we create a file shrinked.Dockerfile, and we'll build a new Docker image hello_kotlin_shrinked containing only our Kotlin Native executable!

FROM scratch
COPY hello_world_linux.kexe /hello_world
ENTRYPOINT ["/hello_world"]

So let's build and run that:

$ docker build --tag hello_kotlin_shrinked . --file shrinked.Dockerfile
[…]
Successfully tagged hello_kotlin_shrinked:latest

$ docker run --rm hello_kotlin_shrinked
standard_init_linux.go:211: exec user process caused "no such file or directory"

Hmm, that didn't work out. The reason is simple: the Kotlin Native compiler created a dynamically linked binary, meaning this file contains references to some shared libraries (.so files on Linux, .dll on Windows). Bummer!

I couldn't find any option for the kotlinc-native compiler to build a static, self-contained executable. I played around a little, but I didn't find anything close to how Go creates self-contained binaries. I found this excellent blog post on how to do this from Go.

I also asked around in the #kotlin-native channel of the Kotlin Slack. I got a reply by Dominic Fischer that there's an -include-binary option which could do what I want. I didn't come around to try that out yet, but if I do I'll update this post. Thanks, Dominic!

So, our binary doesn't run because it can't find those shared libraries. What happens if we add those to the Docker image directly? We can find which are needed by using the ldd tool. Let's use our previously created, Ubuntu-based Docker image to debug this. We're overriding the entrypoint to be a bash. Also we can mount the current working directory to /host if we need this later.

$ docker run --rm --volume $(pwd):/foo --entrypoint /bin/bash -it hello_kotlin

root@a34eeb5c7bef:/# ldd /hello_world
    linux-vdso.so.1 (0x00007ffc187bd000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1a39a92000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1a396f4000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1a394d5000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1a392bd000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1a38ecc000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f1a39c96000)

Ok, so now we know which shared libraries we need! linux-vdso.so.1 is a special library - it is directly provided by the Linux kernel. So we only need to care about the others.

I copied the entire Ubuntu content over to my host, and I created 2 empty directories lib and lib64 and copied over only the mentioned files and symbolic links from the original Ubuntu image. Let's see how this looks:

Now we can modify our shrinked.Dockerfile and add those libs:

FROM scratch
COPY lib /lib
COPY lib64 /lib64
COPY hello_world_linux.kexe /hello_world
ENTRYPOINT ["/hello_world"]

Let's see if we can now build and run this!

$ docker build --tag hello_kotlin_shrinked . --file shrinked.Dockerfile
[…]
Successfully tagged hello_kotlin_shrinked:latest

$ docker run --rm hello_kotlin_shrinked
Hello, World!

$ docker images 'hello_kotlin*'
REPOSITORY              TAG                 IMAGE ID            CREATED              SIZE
hello_kotlin_shrinked   latest              a66abb1efa53        About a minute ago   4.54MB
hello_kotlin            latest              47b7a9b05993        3 hours ago          64.6MB

Wow, that's cool - we now have a Docker image of 4.54MB in size that runs a Kotlin Native binary successfully. Party time! 🎉🎆🎄

Conclusion

We looked at how to cross-compile a Kotlin program for Linux. Then we created a Docker image, using that program as an entrypoint. By leaving the JVM behind, we could already produce a Docker image of 64.6MB, most of which coming from the Ubuntu image itself.

Then, we entered the danger zone and looked at how we can strip most things of Ubuntu away. We included only the necessary libraries, and that way we got the image down to 4,54MB.

Some final note: If you compile your own (real) Kotlin Native program, you probably need more files than you might think. Using https connections? I bet you'll need the SSL root certificates provided in each Linux distro. Using some Kotlin Native libs? Maybe some of those add references to other native .so libs, and your program won't start otherwise. So always test sensibly!

If you liked this post, please give it a ❤️ and follow me on Twitter!
I would love to know more if you use this somewhere. Also, I'm pretty sure there must be some tools / tricks out there that would help in this matter. If you know something I don't: please write! 🙌

Cover photo by Denise Johnson on Unsplash.

DEV Community: Marc Reichelt

It's Time to Act

Kotlin is so nice – it prevents bugs 🐛 before you add them…

No more switch/case

Equality instead of instance check

NullPointerExceptions

Coroutines

Code you don't have to write/generate is code without bugs (usually)

Sealed classes with when

Final thoughts

My posts on dev.to: which topics would you like to read about?

Origin story: TechBits by iteratec

The possibility

The idea 💡

Brainstorming

The setup: Plain and simple

The first 3 screencasts 🎉

🍿 TechBit #1: Using Docker as a playground 🎬

🍿 TechBit #2: Faster C and C++ builds with ccache

🍿 TechBit #3: IntelliJ - Discover & learn new shortcuts easily 🎬

Future

The hidden Kotlin gem you didn't think you'll love: Deprecations with ReplaceWith

Deprecation of subSequence in Kotlin's stdlib

Replace all the things

It can do even more: add more code, and imports

Deprecated can do more

Recap

What are your Kotlin fail stories? #discuss

📸 Kotlin Photo Contest - Thank you for your submissions! 🎉

Submissions

Thank you! 🎉👏🌟

A note on Unsplash

You have awesome Kotlin photos? Share them!

A Kotlin developer's view on Flutter/Dart tooling (part 1)

Think you really like something? Or: what a deprivation test is

Dart, coming from Kotlin

Missing null safety

No data classes / sealed classes

Enums

Semicolons;

_privateFields

The new tabs vs. spaces: 'single quotes' vs. "double quotes"

if / switch can not be used as expressions

Only constant values for optional parameters

Constructors

await: Easy to forget

Collection API is bad

So many missing stdlib functions

Questionable default implementations

More

📸 The Kotlin Royalty-free Photo Contest

📸 Kotlin Photo Contest - Thank you for your submissions! 🎉

Marc Reichelt ・ May 15 '20

🌟 The Contest

The Fineprint

Stay in contact

Make your code beautiful with Kotlin Property Delegates

Small recap on properties

Awesome code with delegated properties

Wait, there's more!

Handling SIGINT in Kotlin Native

How C/C++ handle SIGINT

Calling signal in Kotlin Native

IntelliJ: A tooling improvement suggestion

Conclusion

Christmas Hacking: Squeezing Kotlin Native into Docker

Kotlin, Go Native

Docker + Kotlin Native = ❤️

Honey, I Shrunk the Docker Image

Conclusion

No more `switch/case`

Sealed classes with `when`

Calling `signal` in Kotlin Native