In order to take full advantage of Kotlin, we have to revisit some best practices we got used to in Java. Many of them can be replaced with better alternatives that are provided by Kotlin. Let’s see how we can write idiomatic Kotlin code and do things the Kotlin way.
Coding with Kotlin is great fun. But things are getting really interesting when we try to use Kotlin in conjunction with popular frameworks like Spring Boot and Vaadin. The development with those frameworks can benefit a lot from Kotlin. However, we have to pay attention to some pitfalls.
We at Spreadshirt have started to use the JVM language Kotlin in a couple of services. This ended up in great enthusiasm. Kotlin allows us to significantly reduce the boilerplate and to write more robust and readable code. In fact, I don’t want to write Java anymore. In this post I like to show you why.
Developing with Python was a refreshing and pleasant experience. After working with Java for a while, you may forget how verbose and clumsy this language is sometimes. But Python shows how simple and powerful a programming language can be. Let me show you some examples.
Testing RESTful Web Services can be cumbersome because you have to deal with low-level concerns which can make your tests verbose, hard to read and to maintain. Fortunately, there are libraries and best practices helping you to keep your integration tests concise, clean, decoupled and maintainable. This post covers those best practices.
Java has checked exceptions and is out on a limb. Is there a reason, why other languages like C++, Objective-C, C#, Kotlin, Scala don’t support this concept? What is the problem about checked exceptions and what can we do instead? And most important: What do water wings and checked exceptions have in common? This article gives the answer to all of these questions and shows why unchecked exceptions are the better choice.
From time to time I review code of my colleagues. Especially for a younger developer giving feedback to an older and experienced developer is hard. The colleague has to be open-minded for feedback and criticism. For this, it’s helpful to communicate how code reviews should be considered. I’m convinced that doing so will increase the acceptance of your feedback. But let’s get more concrete.