just solved the Birthday Kata with Arrow, if anyon...

# arrow

[stojan]

just solved the Birthday Kata with Arrow, if anyone has the time to take a look, any feedback is appreciated, thanks -> https://github.com/LordRaydenMK/BirthdayKata

[simon.vergauwen]

Hey Stojan, just checked it out. Looks awesome!

[simon.vergauwen]

I think the ServiceLogger could be improved tho

[simon.vergauwen]

logError(::logError) { “Error reading employees from repo” }

Looks here you’re calling logError on IO concretely and then passing a lambda there from LoggingService. It looks like it can be encoded in just a single method within LoggingService.

[stojan]

the outer logError is an extension function on IO

fun <A> IO<A>.logError(log: (Throwable, () -> String?) -> IO<Unit>, msg: () -> String? = { null }): IO<A> =
    handleErrorWith { log(it, msg).followedBy(IO.raiseError(it)) }

the logError method reference comes from LoggingService

[simon.vergauwen]

This could be an alternative encoding

Untitled

[simon.vergauwen]

Yes, I realise but it can be fused into a single method which could also be easily refactored to F later this way 😉

[stojan]

thanks, will give it a try

[simon.vergauwen]

This removes all impl details / complexity from the call site

[stojan]

I am too used to Timber.d without caring about IO and stuff 😂

[simon.vergauwen]

Haha 😄 Well this is what I’d do for analytics rather than development debugging

[simon.vergauwen]

But I personally prefer to keep Timder.d out of git since most people have their own preferences/styles of doing debugging/logging.

[stojan]

so you would not use IO for logging?

[simon.vergauwen]

Well I don’t leave logging in code is what I am saying ;D

[simon.vergauwen]

I remove it before I push

[simon.vergauwen]

You use Timber.d for stuff like Opened Settings Activity etc, right?

[simon.vergauwen]

Which is not relevant to business or users. If it gets messy (or buggy) it’s a headache for devs rather than anyone else

[simon.vergauwen]

So that would completely depend on your policy for dev logging which I prefer to keep out of the code. So I should write a lint rule or something to not allow Timber 😄

[stojan]

got it, thanks 😉

[stojan]

Based on your suggestion I came up with

interface LoggingService {

    fun logError(t: Throwable, msg: () -> String?): IO<Unit>

    fun <A> IO<A>.logError(msg: (Throwable) -> String?) =
        handleErrorWith { logError(it) { msg(it) }.followedBy(IO.raiseError(it)) }
}

I love this pattern, a simple operation and then deriving a more complex one based on it

[jimn]

is logging part of the kata spec?

[jimn]

i tend to minimize logging libraries right up to the point where im debugging asyncronous crypto transactions and too much magic exists for debugging. then i paper every possible relevant line with an assertion based logger that requires -ea to be not removed from the jvm

[stojan]

Nope, not a part of the spec, but I wanted to try it out 😁

[stojan]

Maybe removing it now makes sense, so it doesn't add noise