Reusable Modules - Its as easy as ABI

A "lightning blog" to accompany a lightning talk I have recently given at Kotlin London. I dig into the importance of visibility modifiers and declaring dependencies.

Reusable Modules - Its as easy as ABI, lightning talk

A brief summary of a lightning talk I gave at Kotlin London on October 10th 2024. I delve into how we can create reusable modules. We look at how visibility modifiers such as `public` and `private` work with Gradle dependency declerations to impact a modules Application Binary Interface.

A brief look at Gradle convention plugins

Gradle is essential for building Android apps, and Convention Plugins can simplify multi-project codebases by enforcing consistent build logic across modules. They help avoid misconfigurations, reduce repetitive code, and make managing changes, like updating Java or Kotlin versions, more efficient. With Convention Plugins, you can streamline configurations like Kotlin compiler options, dependency injection setups, and SDK versions, ensuring consistency and reducing complexity in large projects.

Type II Pain

There are two types of pain: Type I pain: Unwanted, caused by illness, injury, or heartbreak. It's the pain you wish to avoid. Type II pain: Sought-after pain, felt during intense physical effort. It's agonizing in the moment but addictive once it's over.

Windsor Triathlon 2022

Back in 2019 Thais (my girlfriend) and a friend of hers did the Windsor Triathlon. They bought me in as coach and supporter for the day. It was fantastic. I am pretty sure there is no better way to spend a Sunday than wake up at 4:30 and go and watch people do a triathlon.

Practical Modularisation for Android Developers

Modularisation.. You cannot escape it as an Android Developer. As your code base gets larger well modularised code becomes crucial. It can encourage code ownership, increased build speed, better organisation and increased productivity. This post will help you to use the tooling available to you to modularise your codebase.

Learning a lot at Twitter

I recently joined Twitter as an Android Developer. So far, it is unlike anywhere I have ever worked before. In two months I have learned a lot and have been incredibly overwhelmed. I’ve recently felt like I have started to get on top of the learning curve and I can start to reflect a bit on the first two months. To do that, I’m going to make an effort to blog three times a week focusing on a few topics.

Merging multiple files into one with Kotlin

Kotlin lets us write top level functions, this enables us to write code that isn’t necessarily constrained to the concept of classes. It frees us from “util” classes of static methods (but it doesn’t free us from dumping methods or functions in one place).

Experimenting in a legacy code base

I work on what could be called a “legacy code base”. We’ve just crossed the 10 year anniversary of the first commit. Between then and now over 40 developers have contributed. Many features have come and gone, and the platform we develop for has changed beyond recognition and so have our ways of writing code.

To abstract or not to abstract

The longer I’ve written software the more I debate with myself about whether I should be adding an abstraction or not adding an abstraction.

An FTP test retrospective

Yesterday, I did an FTP test -functional threshold power test – on my bike. This is a test to find out how hard you can cycle for one hour. I failed a test back in May and I’ve been nervous about it all week. 

Some thoughts on testing

The first is finding peace of mind. In years gone by I have written some dodgy code that has gone to production, I still think about some of this code to this day. I still write dodgy code, but I’m able to stop it from going to production with a superpower I have gained. That superpower is to write tests for my code and mostly stop that code from being released (crashlytics will sometimes disagree). A good set of tests should be enough to give me confidence that what I have written actually works.