How to verify your Kotlin project in a Kotlin way? What linter, code coverage tool and static code analysis plugin to use?! We might know our Java counterparts for this, but what to do when you write your talks in Kotlin?
Kotlin is designed to fully interoperate with Java, mainly provoked by the fact that the JVM version of Kotlin's standard library depends on the Java Class Library. Nevertheless, Kotlin’s standard library has some new tricks which are not supported by Java. Therefore, the Java verification tools might not interpret all the cool new stuff that we’re writing in Kotlin in the right way.
In this talk we’ll go over some plugins (Kover and Detekt) that are specifically designed for the Kotlin language to fully support your Kotlin project!
What would happen if we would bring design, front end, back end etc. all together? How could we improve the user-flows by thinking of alternative, non-happy flows? What would happen to the performance and therefore the user-experience when back end is already involved before the finalised wireframes are handed over?!
That's all nice and dandy. But we do need to deal with some concerns like:
- Knowledge gap: How can the different disciplines with their specialty understand each other and come to conclusions?
- Shared responsibilities: Where do start and where do they end?
- Efficiency: What would it do to the efficiency of the team when they get different tasks?
In this session we’ll dive in together;
- seeing what the pro's and con's are of a multidisciplinaire way of working,
- what tips and tricks can be exchanged,
- and what kind of tools can help in smoothing out the concerns that arise
