Kotlin
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Null Safety
-
Section 4: Object-Oriented Kotlin
-
Section 5: Functional Kotlin
-
Section 6: Coroutines
-
Section 7: Collections Deep Dive
-
Section 8: Type System Deep Dive
-
Section 9: Interop and Tooling
-
Section 10: Kotlin DSLs and Patterns
-
Section 11: Testing and Quality
-
Section 12: Server-Side Kotlin
-
Section 13: Practical Projects
-
Section 14: Interview Practice
-
Section 15: More Practice Exercises
-
Section 16: More Standard Library
-
Section 17: Multiplatform Kotlin
-
Section 18: kotlin.collections In Depth
-
Section 19: kotlin.text In Depth
-
Section 20: kotlin.ranges and kotlin.sequences
-
Section 21: kotlin.io and File Handling
-
Section 22: kotlinx.coroutines Deep Dive
-
Section 23: kotlin.reflect
-
Section 24: Android Development with Kotlin Overview
-
Section 25: Kotlin Multiplatform Deep Dive
-
Section 26: Kotlin for Backend Deep Dive
-
Section 27: Kotlin Design Patterns
-
Section 28: Advanced Language Features
-
Section 29: More Practice Exercises
-
Section 30: More Interview Practice
-
Section 31: Kotlin Type System Deep Dive
-
Section 32: Kotlin Null Safety Advanced
-
Section 33: Kotlin Testing Deep Dive
-
Section 34: Kotlin Build Tooling Deep Dive
-
Section 35: Kotlin Serialization
-
Section 36: Kotlin Performance Considerations
-
Section 37: Kotlin Native Overview
-
Section 38: Kotlin for Data and Scripting
-
Section 39: More Coroutines Practice
-
Section 40: More Android-Adjacent Patterns
-
Section 41: More Practical Projects
-
Section 42: More Design and Architecture Practice
-
Section 43: Kotlin Language Evolution
-
Section 44: More Interview and Review
-
Section 45: Kotlin Delegation Patterns Deep Dive
-
Section 46: Kotlin Annotations Deep Dive
-
Section 47: Kotlin for Gradle Plugin Development
-
Section 48: Kotlin Concurrency Beyond Coroutines
-
Section 49: Kotlin Compiler Internals
-
Section 50: Real-World Kotlin Case Studies
-
Section 51: Final Practice Projects
-
Section 52: Kotlin for Server-Side Reactive Programming
-
Section 53: More Practice and Drills
-
Section 54: Kotlin Security Practices
178: Kotlin Notebook Basics
I've spent far too many hours of my career creating "TemporaryProject1", "Temp2", and "TestProject_Final" just to check if a specific library function works the way I think it does. It's a slog. You have to set up the Gradle build, wait for the index, write a main function, and run the whole JVM just to test five lines of code. This is exactly why I started using Kotlin Notebooks.
Getting out of the "Main" function rut
Let's say I'm trying to build a small utility that calculates a "Readability Score" for a piece of text based on sentence length. In a standard project, I'd be writing a class and a wrapper. Here, I'm just going to open a .ipynb file in IntelliJ and toss this in a cell:
fun calculateScore(text: String): Double {
val sentences = text.split(Regex("[.!?]")).filter { it.isNotBlank() }
val words = text.split(Regex("\\s+")).filter { it.isNotBlank() }
return words.size.toDouble() / sentences.size
}
I hit Shift+Enter. Nothing happened? Well, actually, it did. The cell executed, the function is now defined in the notebook's memory, and I didn't have to write fun main(). I can just create a second cell and call it immediately:
val sampleText = "Kotlin is great. I love notebooks! Do you?"
calculateScore(sampleText)
The output prints right below the cell. It's an interactive REPL on steroids. The most important thing to realize here is that the notebook maintains state. The calculateScore function lives on in the background until I restart the kernel.
The "Where is my library?" moment
Now, I want to do something a bit more complex. I want to use the kotlinx-datetime library to timestamp when these scores are calculated. I'll try to use Clock.System.now() in a new cell:
val now = Clock.System.now()
println("Calculated at $now")
And... it fails. Red squiggles everywhere. The notebook doesn't magically know every library in existence; it only knows the Kotlin standard library by default. In a regular project, I'd go to build.gradle.kts, add the implementation line, and sync. But that ruins the "quick experiment" vibe. Instead, I'll use the @file:DependsOn annotation at the very top of my notebook:
@file:DependsOn("org.jetbrains.kotlinx:kotlinx-datetime:0.4.0")
import kotlinx.datetime.*
I run that cell, and suddenly the IDE recognizes the types. I love this because I can keep my dependencies documented right inside the notebook without leaving the editor.
Tuning the logic on the fly
Here is where the real power kicks in. I realize my calculateScore is too simple—it's not handling empty strings well. In a traditional IDE workflow, I'd change the function, re-compile, and re-run the whole app. Here, I just go back to the first cell, tweak the code, and run just that cell again:
fun calculateScore(text: String): Double {
if (text.isBlank()) return 0.0
val sentences = text.split(Regex("[.!?]")).filter { it.isNotBlank() }
if (sentences.isEmpty()) return 0.0
val words = text.split(Regex("\\s+")).filter { it.isNotBlank() }
return words.size.toDouble() / sentences.size
}
Now, when I go back to my test cell and run it again, it uses the updated logic. I'm essentially iterating on a live object. It feels less like "software engineering" and more like "sketching," which is exactly what you want when you're in the exploration phase of a feature.
📋 Practical Task
Build a Weather Data Transformation Sandbox
Your goal is to use a Kotlin Notebook to prototype a data cleaner. Instead of a full project, create a notebook that does the following:
- Use
@file:DependsOnto include theorg.jetbrains.kotlinx:kotlinx-datetime:0.4.0library. - In one cell, define a data class
WeatherReading(val temp: Double, val city: String, val timestamp: Instant). - In a second cell, create a list of
WeatherReadingobjects with some dummy data (include at least one reading with a temperature that seems like an error, e.g., 500.0 degrees). - In a third cell, write and test a function
filterAnomalies(readings: List<WeatherReading>)that removes any readings where the temperature is outside the range of -100.0 to 60.0. - Verify that your filter works by printing the size of the list before and after the function call in a final cell.
There are no comments for now.