Static Factory Methods known from Java have their place also in Kotlin, although they look and behave a bit different because there is no static word in Kotlin. Here I’ll try to show how to use companion object for Static Factory Methods and more. PS: This whole post was supposed to be about Factory Method with just a short mention about static factory methods, but the topic becomes more interesting than I thought :)
Importance of Code Review I sure do hope that I don’t need to convince anyone how important is the process of code review. If you need some guidelines on how to do it well I can recommend this Yelp blog post Here I’d just like to perform a retrospective of my own code review experiences. A bit of history When I started my developer career in a rather small company - we were not doing code reviews.
Mr Hyde Text you are reading is available on Jekyll blog hosted on GitHub, with the use of free Github Pages. Long story short: Jekyll is a template engine changing markdown documents on static HTML webpages, that you can then host anywyere, because you don’t need databases or server that has PHP or Python. Usual process Normally process of adding new post looks like this: I write markdown document with setting parameters like title, date and tags when I’m happy with what I wrote (never), I commit changes and push it to repository on GitHub.
My setup looks like this: I have Windows PC with Linux installed on a separate drive, also I have 2 MacBooks for work, and rarely used Linux ThinkPad. Keeping my IntelliJ settings in sync at all of those machines wasn’t really possible. If I find some setting that improves my workflow at my office machine, and after some time I want to work on a pet project on my own PC - I get this itch of not having this setting I had on MacBook… so I can export my settings and then import it.
Why Recently I had to do some tasks that required me to fallowing a strict checklist. It wasn’t anything complex, no creativity required - just do as list tells you to do. I was also one of the creators of the checklist. I had to do it a few times, almost regularly, sometimes in short notice but nothing extreme. So obviously I made errors because I knew the checklist so well I wasn’t paying attention.
It seems great Write code once use it many times. Creating smaller pieces of code forces developers to write encapsulated software that follows single responsibility principle and is easy to test. Such code piece (AKA module) can be then published as a versioned artifact - a private library, that can be reused in more than one project. We are getting quality and reusability, how cool is that! Well that’s the theory.
This is third part in series of articles about Android build configuration, all parts will be linked right below. [#1 Build basics]({% post_url 2018-07-23-android-build-hacks %}) [#2 Build time optimization]({% post_url 2018-09-16-android-build-hacks-2 %}) [#3 Documentation with Dokka]({% post_url 2018-11-05-android-build-hacks-3 %}) Homework Wait what? You’ve wrote beautiful self-documenting code and someone tells you to create DOCUMENTATION for it? It’s already there! Well named methods and variables, design patterns used. If anyone wants to know how it works, he just needs to read through it - well named method by well named method…