Articles

Vibe Coding, Kotlin, Finance, and Data Visualization

Recently, I came across a paper discussing an experiment and tried to reproduce it. Here’s a brief summary: - Portfolio A: In a bull market, grows by 20%; in a bear market, drops by 20%. - Portfolio B: In a bull market, grows by 25%; in a bear market, drops by 35%. - Bull market probability: 75%. According to the paper, both portfolios should have a one-year expected return of 10%.

Treat life like a marathon, not like a sprint

Like most of us, I am daily flooded with thoughts about life, my objective position in it, whether I am missing anything, or whether I need to do better. Am I providing enough for my family? Is my career on track? Am I being healthy enough? Am I just passing through life instead of aiming to strive? Those thoughts have been slowly mitigated, but they never got away. Over time, I have been slowly accepting this reality, and I came to realise that all the marathon training and long-distance running have helped me come to terms with these facts.

Uploading SARIF Reports to GitHub

Recently I wanted to add Lint reports to a repository on GitHub. The goal is to report potential Lint violations when new code is committed, to make sure that all the committed code is lint-warning-free and pretty. My first idea was to look for a GitHub action that could run ./gradlew lint and report it as a PR comment. After asking about ideas in the Android Study Group, Carter Jernigan and Justin Brooks suggested me to upload directly the SARIF files into GitHub.

KotlinConf 2024 announcements

The first day of the KotlinConf 2024 is over, and there has been a significant amount. After 5 years the conference happened again at The Bella Center in Copenhagen, a fantastic venue close to the historical center of the Danish capital. The last two weeks have been intense, with the Google I/O announcing another set of relevant features for Android and Kotlin developers. Most notably, Google is now supporting KMP for Android development.

HTTP chunk requests with Android and ktor

In this very short article, I will explain briefly what is a chunk or streamed HTTP request, what are the benefits of using it, and how it works in Android. Android apps use HTTP requests to download data from a backend. This information is stored and processed on the app to make it functional. HTTP requests are executed using different frameworks on Android. The most common ones are Retrofit or OkHttp.

My Investing Summary of 2022

Another solar rotation passed, and the world experienced a plethora of unexpected events. In the aftermath of the Corona epidemic that altered the course of the last couple of years, we had the unfortunate invasion of Ukraine by Russian forces, the tightening of Corona measures in China (and toward the end of the year, their withdrawal and gradual reopening of the economy), an ongoing economic recession, the rate hike by the FED and the general uncertainty of the most immediate future.

KMP, iOS Developers and Production

Kotlin Multiplatform (or KMP, KMM Mobile, etc) has been widely used for a number of years in applications that are currently in production. JetBrains compiled a website listing some of the companies that are currently using KMP. Since the advent of the mobile platforms we enjoy today, there has always been a certain market interest to push multiplatform technologies, such as Cordova, Xamarin, and others. With more or less success, those technologies aimed to provide a unified framework to develop multiple codebases, mostly focusing on the aspect of pricing (create code once, deploy multiple times).

A recapitulation of investing in pandemic times

It has been around 14 months since the pandemic started. We have all been affected by it to a greater or lesser degree, and the investing world has not been an exception (although surprisingly, the stock market is one of the winners of the pandemic). In this post I will share how the pandemic changed my investment thesis, the things I learned, and the mistakes I did. 14 months into the crisis of our generation (and with a few months to recover whatever the new normal will be), we now know that things will never be the way they used to be.

A short story of randomness (I)

I have always been fascinated by the above comic strip. A discussion on randomness and determinism becomes as much a philosophical issue as it is a practical one. They are used in a variety of applications: from the obvious cryptography, gaming or gambling to the less evident politics or arts. How can we be sure that a number is random? Will observing the process mine our efforts on generating the random number, similar to the observation of a cat inside a box with a decaying radioactive atom?

From Java to Kotlin and back (III): Calling Java from Kotlin

This article is part of a series. You can find the remaining article of the series here: From Java to Kotlin and back (I) — Calling Kotlin from Java From Java to Kotlin and back (II): Calling Kotlin from Java In this last chapter of the series, we will evaluate consideration when calling Java code from Kotlin. One could argue that even in this situation happens often, keeping considerations in mind for some code that might legacy is not that practical.

KMP, iOS Developers and Production

Planted May 25, 2022

Kotlin Multiplatform (or KMP, KMM Mobile, etc) has been widely used for a number of years in applications that are currently in production. JetBrains compiled a website listing some of the companies that are currently using KMP.

Since the advent of the mobile platforms we enjoy today, there has always been a certain market interest to push multiplatform technologies, such as Cordova, Xamarin, and others. With more or less success, those technologies aimed to provide a unified framework to develop multiple codebases, mostly focusing on the aspect of pricing (create code once, deploy multiple times).

Some of the frameworks that have paved the way for KMP in the past

There are however multiple considerations as to why the cost is not the only aspect that can benefit from maintaining a single codebase:

  • Quality increase: a single codebase is easier to maintain and audit. We do not longer need to develop several of them to be deployed on multiple platforms, so certain tasks tend to get easier, such as bug maintenance.
  • One single tech stack: hiring in tech is generally an arduous task. Senior engineers are difficult to find, and it is harder to convince them to change between companies unless a decent offer is provided. Keeping a single tech stack allows your company to focus on a tech stack that can be hired and maintained.
  • Feature teams: a common approach in mobile is to separate teams by platform (iOS, Android). Instead, an interesting approach is to create feature teams, that can focus on a given feature and develop know-how on how it works. This is an interesting long-term approach that can be considered under certain companies’ circumstances. Using a single technology stack makes this approach feasible.

KMP has a nice adoption curve in Android teams since the language and most of the tooling is shared. In fact, JetBrains carried out a survey on KMP usage during the first semester of 2021, and the results are quite satisfying. From the above-mentioned survey, these are my personal takeaways:

Almost half of KMM users (48.4%) share more than half of their codebase.

Satisfaction is close to 99%.

It would have been interesting to have a breakdown of the satisfaction based on the platform where KMP was used, where I suspect numbers would have differed. Particularly, iOS developers seem to have a harder time working with KMP for a variety of reasons.

This post aims to provide the drawbacks of currently applying KMP on production from the iOS side. KMP is a dynamic technology that evolves constantly (and JetBrains is a company that listens to its user base when releasing new software), so if you end up reading this article, keep in mind the date when this was written. Without any other prolegomenon, here there is a non-exhaustive list of some of the main challenges when using KMP on the iOS side of things:

Debugging iOS

Currently, we have mainly two options to debug code on iOS: we can either use the Xcode Kotlin Plugin from Touchlab (which can be installed on Xcode) or the Kotlin Multiplatform Mobile for AppCode (which can be installed on AppCode).

Touchlab is a fantastic company that has been doing a lot of good for the Kotlin and KMP communities. The Xcode Kotlin Plugin is not perfect, and nobody expects it to be. There are currently reported issues with autocompletion, crashes with different Xcode versions, and more. This is intrinsic to the nature of being a third-party plugin developed for a language and stack that is not natively supported by Apple on its framework (and it will probably never be).

AppCode is the JetBrains IDE to develop Swift applications, and it is arguably a better IDE than the one provided by Apple. Until not too long ago, Xcode was unable to refactor Swift code, whereas AppCode was able to do it. It has better tooling, interface, and more. On the other side, it is not the official IDE from Apple, and it lacks some other things, like proper Interface design. As it stands today, no solution is perfect, and debugging KMP on iOS is still painful.

Interoperability via Objective-C

KMP interacts with iOS via Objective-C, not Swift. The tool being used for that effect is Cinterop. This means that, if something is not supported on Objective-C, it does not matter whether Swift supports it or not. And there is a good number of examples of this. For instance, Exhaustive Enums, Default Arguments and others.

Exhaustive enums

Enums in Objective-C are represented as Integers, vs. reference types in Kotlin. If you try to switch over Enums on Swift, it would be like applying a switch on any other class: Swift is not aware that there is a finite number of numbers of instances for that Enum, as Kotlin does. There is a Feature Request filled for this at YouTrack, so if you have interest feel free to take a look at it.

Default arguments

Default arguments (or arguments) in Swift are possible. For instance, the following function provides a default argument:

If we do not specify the parameter nice, the default will be taken instead:

Now, why can’t we use it on KMP, if Swift supports default arguments? Because (again), the interoperability happens via Objective-C. So default arguments cannot be used when using a KMP-generated artifact on iOS. Instead, arguments need to be specified.

Lack of support from certain APIs

Codable is an API introduced with Swift 4 and used to serialize and deserialize data, for instance into or from a JSON format.

kotlinx.serialization provides this functionality for Kotlin, but you can’t directly generate a Codable implementation when exporting Kotlin classes to Swift (again, with a YouTrack entry here). Whereas it is technically possible to use kotlinx.serialization all along, it would be reasonable to expect a Codable implementation when using KMP, being the framework of reference on iOS. You can imagine a team of Swift developers having certain doubts about adopting KMP when they will not be unable to use Codable.

Support for native dependencies is limited

Kotlin/Native provides integration with the CocoaPods dependency manager, via the CocoaPods plugin and Cinterop tool. However, if you have a dependency that is as well dependent on another library, this is currently not supported by KMP (YouTrack ticket).

Complex concurrency model

The concurrency and memory model at KMP is complex, and it eventually feels that it is mutually exclusive between iOS and Android. It is not uncommon to have changes that make one or the other platform crash. Until very recently, coroutines were in fact Single Threaded, and this only changed with the advent of 1.6.1-native-mt a month ago.

The issue of how frozen objects work, and how to work with immutable objects and so escalates quickly, and it can soon become a daunting task.

Is then KMP ready for production?

KMP is ready for production, and the case studies of JetBrains prove it.

Like with any other technology at the edge of possibility, an exercise of caution is always positive. KMP relies on too many edges and platforms over which JetBrains have no control at all, so expect versions to get broken when new Android or iOS versions are released, as well as with new Swift versions. Over time, I got to collect a checklist that I aim to apply on any project before going too wild on KMP:

  • Use it with caution: there is no need to go 100% KMP. A modularized project will allow you to perform experiments on smaller modules and evaluate whether you can benefit from KMP or not.
  • Shared components: very likely your purpose to use KMP is to share components between platforms, so before starting using it check which components are more convenient to share in your project. Identifying a codebase that can be shared (and subsequently, determine whether KMP has been useful or not) is a gentle and thoughtful approach.
  • Keep versioning in mind: Kotlin/Native changed its versioning at some point in history, and now it is bonded to the version of Kotlin itself. However, JetBrains maintains a website with the current stability of Kotlin Components, and as of today some of the Kotlin/Native components are Beta. Apply your own casuistry here, and determine whether the stability of KMP is good enough for your organization.

Thanks to the JetBrains crew from Munich that is always so helpful with feedback and support, and specifically Eugene Petrenko and Sebastian Sellmair. Like always, thanks Marton Braun for your review. You guys rock!

I write my thoughts about Software Engineering and life in general on my Twitter account. If you have liked this article or if it did help you, feel free to share, 👏 it and/or leave a comment. This is the currency that fuels amateur writers.