DEV Community: Boris

What time to workout as a programmer?

Boris — Tue, 31 Jan 2023 19:26:58 +0000

Programming is a good way to stretch the synapses between your brain cells but usually comes with a price to pay. As everything in life is Ying-Yang and requires some balance.

We, humans, are made for work. By work, I mean physical work. If you go a couple of thousands of years into the past you would see that men would fight for food and territory and women would collect berries as well. In other words "You have to deserve your food on the table". Those days are way behind us, but our bodies aren't.

If you exercise on the daily basis, let's say 15 minutes of stretching or some calisthenics you will achieve a tremendous amount of motivation for other stuff in life. A cure for laziness would be a daily workout. Treat it as a daily stand-up meeting with your team.
Slap that favorite podcast, do some exercises, and thank me later.

Often decision-fatigue kick in after your busy working hours and you depleted your if-else blocks in your brain. Usually, those logical blocks would re-fill after a good sleep.

If you are not familiar with decision fatigue you can read more here.

Technical details:

15 minutes are less than 2% of your day.
better mood
good drive to start the day
keeping your heart happy

What type of workouts are good:

running (yes, try run 15 minutes with regular pace)
stretching / yoga
HIIT(high interval intensity training)
Tabata
Jump rope
Calisthenics circuit training

Anyway, I suggest that kind of workout be done either fasted as first thing in the morning or first thing after your breakfast. That way you can kickstart your day, get that adrenaline + dopamine booster and you'll be ready to battle the day. Otherwise, decision fatigue will take over especially after long working day.

Peace

Early return patterns

Boris — Mon, 30 Jan 2023 16:57:56 +0000

"First write the code for people, then for the machine."
I don't know who originally said this but it's legitasf.

How many times you saw some piece of code and like what!? What is this supposed to do?

One good tip that I accepted from a senior developer in my team is to use that early return statement which is my favorite thing if I have small to medium business logic inside my functions.

You have a function that does something bigger, and it does it well but not too well.

fun getListOfArticles(hasInternet: Boolean): List<Article> {
    if (hasInternet) {
    //big piece of code. Maybe some data manipulation before 
     //returning the list of Articles from the API.
    } else {
       return emptyList()
    }
 }

This is OK, but if you want to make life easier for somebody else that will read your code in half a year we can use that early return pattern which comes in handy sometimes and it looks like this:

fun getListOfArticles(hasInternet: Boolean): List<Article> {
    if(!hasInternet) return emptyList()

    //Big piece of code here for manipulating the data
    return articles
 }

This way is more intuitive to read "if there is no internet, just return an empty list of articles" or do whatever you need in your app. Just return early as possible and you will make your program fail fast.
That means:

Easier to read
Easier to spot code smell
Easier to debug.

Here's one more interesting example using a happy path design

"The happy path for a function would be where none of the validation rules raise an error, thus letting execution continue successfully to the end, generating a positive response."

fun logIn(argument1: String?, argument2: String?, argument3: 
 String?) {
  if(argument1 != null || argument2 != null || argument3 != 
   null) {
  //do something and log in the user
    } else {
  // throw exception
  }
}

Now happy path applied:

fun logIn(argument1: String?, argument2: String?, argument3: String?) {
 if(argument1 == null) throw Exception() //maybe throw different exceptions
 if(argument2 == null) throw Exception()
 if(argument3 == null) throw Exception()

  //do the happy path of the function here

}

Some patterns that are considered as early return:

You have your own style of writing software but be aware that this is popular for a reason and it has a lot of benefits inside the codebase. It will force you to think more with that "TDD" mindset.

Composition over Inheritance

Boris — Sun, 09 Oct 2022 21:33:11 +0000

We should be careful how we construct and design our classes in OOP world. If we have simple application or we are building MVP project I wouldn't even bother with this topic at all since code should be short and workable. But we will leave that for other blog post. Now let's define what are these two concepts.

Starting with Inheritance

Inheritance is a concept in OOP which one child class(subclass) inherit everything from the parent class(superclass). When we say everything it means, properties and functions of that superclass. The best is to present with the good old example:

open class Animal {
 fun eat() {
    println("Njam njam")
  }
}

class Dog: Animal() {
  fun bark() {
    println("Woof!")
  }
  fun run() {
    println("Running..")
  }
}

class Cat: Animal() {
  fun meow() {
    println("Meow!")
  }
  fun jump() {
    println("Jumping..")
  }
}

fun main() {
  val goofy = Dog()
  println("Goofy wants to eat ${goofy.eat()}")

  val dizzie = Cat()
  println("Dizzie wants to eat ${dizzie.eat()}")
}

We have Animal class as a parent class to the Dog and Cat subclasses. And this is great, we inherited eat() method from the Animal class.

Now the requirements in the project has changed and somebody wants a robot dog which needs to clean around the house and another robot that play some music!
Ah great... Okay, let's define the same thing as above using inheritance.

open class Robot {
  fun stop() {
    println("Stopping")
  }

  fun move() {
    println("Moving")
  }
}

class DogRobot : Robot() {
  fun bark() {
    println("Woof!")
   }
  fun clean() {
    println("Cleaning around the house")
  }
}

class MusicRobot: Robot() {
  fun playMusic() {
    println("LalaLalLa")
  }
}

fun main() {
 val goofyRobot = DogRobot()
  println("Robot is ${goofyRobot.clean()}")
  println("Robot is ${goofyRobot.move()}")

  val musicRobot = MusicRobot()
  println("Robot playing ${musicRobot.playMusic()}")
  println("Stopping robot... ${musicRobot.stop()}")
}

We have our design now. Everything looks cool and suddenly, guess what? Requirements changed again.
Client asks for a robot that can bark, play games, play music, cook, clean around the house. 🙈

Composition to the rescue.

Composition is concept which we are constructing object "from the outside" and we don't inherit anything from other classes instead we are composing it. Let's see the example:

class SuperRobot(
  private val dogRobot: DogRobot,
  private val musicalRobot: MusicRobot
) {
  fun playMusic() {
    println("Super robot will play some old school music: ${musicalRobot.playMusic()}")
  }
  fun bark() {
    println("Barking around the house ${dogRobot.bark()}")
  }
  fun clean() {
    println("Cleaning the house... ${dogRobot.clean()}")
  }
 }

fun main() {
  val superRobot = SuperRobot(
   dogRobot = DogRobot(),
   musicalRobot = MusicRobot()
 )
  println("Playing music: ${superRobot.playMusic()}")
  println("Barking: ${superRobot.bark()}")
  println("Cleaning: ${superRobot.clean()}")
}

To achieve this in Kotlin with the inheritance concept is not possible since Kotlin does not support multiple inheritance.

The downsides of the inheritance are:

we can only extend one class
we are setting contract for the subclasses which should be respected
we take everything from the parent class

Pros of using Composition over Inheritance:

composition is more secure because we don't depend on the class implementation at all, only on the external observables.
with composition we are more flexible, when we inherit, we take everything, but when we are composing then we can choose what we need for constructing.
unit testing with composition is easier because we already know from which classes some methods are used.

Summary

General rule in the OOP is using composition over inheritance. Use inheritance only when you must and if you need strict contract which subclasses should respect. In any other case strive for composition.
Easier to remember is like this:

use inheritance when a class "is"
use composition when class "has"

Happy coding :)

3 Android Studio plugins for productive development

Boris — Sun, 02 Oct 2022 20:06:59 +0000

Rainbow brackets

The codebase usually gets bigger and bigger and you should take care of nested for loops or some other nested function scopes. This plugin will color every scope you have with the different brackets color so you can easily track in which scope you are working. Read more about this plugin.

WakaTime

This is my favourite one. It tracks how much time you spent on your project, on which classes and which lines of code. There is free and paid version so you can choose which features you want. I am currently using free version and it's great! If you want to know how much time you spent daily on some tasks or you should log your time if you are working in a company which requires logging, then just try it.
Read more here

Json to Kotlin

Another great plugin that helps you generate Kotlin classes out of nothing 🧐. Just kiddin'. If you provide any JSON string/JSONSchema or any URLs that returns a JSON string/JSONSchema as a response you can generate the classes. It saves so much time. But anyway, sometimes you should refactor a bit if you have too much repeating data classes which are redundant. Read more here

Key promoter X

Title said three, but you get to fourth one. Bonus plugin for the long term investment in learning the AS shortcuts.
If you want to be more productive, you should learn to use shortcuts in Android Studio. This plugin will alert you everytime you open something in AS if there is a shortcut for that action. You can, of course, disable alerts but the more you have it, the more you learn. If there are no shortcuts for some action, the Key promoter X will provide option for your custom shortcut.
Read more here

Happy coding!

You can follow me on:

Reduce cognitive load with Kotlin Extension functions.

Boris — Sun, 25 Sep 2022 13:05:44 +0000

We are 80% reading the code and 20% writing the code. That's why we should take care about cognitive load which our code reproduce. One way is to write intuitive and readable code.

A very useful Kotlin feature are Extensions functions. Let's see what extensions are and how to use it in your code to make it more readable.

"Kotlin provides the ability to extend a class or an interface with new functionality without having to inherit from the class."

If we want to check if some money amount is valid for transaction we can create simple check function that return a Boolean like this

fun isValidAmount(amount: BigDecimal) = amount > ZERO && amount <  PAYMENT_MAX_AMOUNT

or we should disable / enable some view from the screen

fun hide(amountView: View) {
  amountView.visibility = View.GONE
}

fun show(amountView: View) {
  amountView.visibility = View.VISIBLE

}

These two functions are absolutely correct but we can go even further with Kotlin extensions in order to make code a bit more intuitive and readable. Now let's see how these two functions will look like

fun BigDecimal.isValidAmount() = this in ZERO..PAYMENT_MAX_AMOUNT

//and applied in code
val amount = BigDecimal(1000)
if(amount.isValidAmount()) {
// make a payment
} else {
 //show message to the user
}

and hiding the view function will look like this

// Hides the view
fun View.hide() {
  visibility = View.GONE
}

// Shows the view
fun View.show() {
 visibility = View.VISIBLE
}

// Hides or show the view based on the flag
fun shouldShow(show: Boolean) {
  if(show) visibility.VISIBLE else visibility.GONE
}

// when applied 
if(amount.isValidAmount()) {
    amountView.show() 
} else {
    amountView.hide()
}

// or even further with one liner
amountView.shouldShow(amount.isValidAmount())

You can see how this improves readability in our code.

Under the hood there is nothing special. If we decompile the Kotlin bytecode into Java source file we can see nothing but regular methods with passed arguments.
So there is no performance benefit, it's just a pure Kotlin synthetic sugar!

You can play with them and use it everywhere inside the app where you think that is necessary to improve readability. They are excellent for Utility classes where you need a lot of checks and validations.

Write safe code with immutable properties in Kotlin?

Boris — Thu, 22 Sep 2022 17:41:46 +0000

This topic is highly underrated so it's good to know why we should try to use immutable properties.

I would like to point some safety measures when it comes to writing in Kotlin. Kotlin has awesome API's that allows us to write clean, safe and readable code.

One of safety guns in Kotlin is defining immutable properties val or read-write properties var

val num = 10
num = 5 //this is not allowed

The properties in Kotlin are encapsulated by default. That means that even num is read-only property, it can have custom getter or it can hold mutable object like mutableListOf() which you can operate on.

val list = mutableListOf(2,3,4)
list.add(5) //this gives us more flexibility

or even we can specify custom getter:

class Rectangle(val width: Int, val height: Int) {
    val area: Int 
        get() = this.width * this.height
}

With above examples we've seen that Kotlin is protecting us by default if we use val property.

The big question is, why we should use it in our classes which holds state?

Let's see this example:

var num = 0
for(i in 0..1000) {
thread {
 Thread.sleep(10)
num++
  }
}
Thread.sleep(3000)
println(num)

In example above there are high chances that num will not be 1000 because some threads will change value of this property and we will not have consistent app after all.

The same applies with coroutines. The value will be modified as well.

Limiting mutability in Kotlin:

val keyword (we can make custom getter or use delegation)
copy keyword applied on data class objects
mutable collections (mutableMapOf() mutableListOf()...etc)

Prefer object and classes that are immutable over mutable. But if you need to change them, consider making immutable data classes and use a copy to change the state.

data class User(
val name: String,
val surname: String,
val address: String
)

Let's say that user has changed his address in the meantime so we want to change this immutable adress property with copy.

val johny = User(
"John",
"Johnny",
"Beverly Hills 74"
)

val johnyWithNewAdress = johny.copy(adress = "Holywood 12")

Another big mistake when it comes to mutability is down-casting immutable collection. This is huge mistake and please don't do it.

Example:

val list = listOf(1,2,3,4,6)
if (list is MutableList) {
list.add(5) //DON'T DO THIS
}

//Do THIS INSTEAD
val list = listOf(1,2,3,4,6)
val newList = list.toMutableList()
newList.add(5)

Here our list is not modified by outside, instead it creates copy of new list which you can easily modify.

There are some exception to this rules but chose it wisely, sometimes we need object to be fully mutable. Baseline is that we should limit mutability as much as possible.