Friday, January 12, 2018

OOP is not dead: Elegant Objects

Recently I have observed a growing wave of what I describe as kind of anti-design movement. Experienced people find out they have been doing it wrong. One say: TDD is dead, other: we do not need interfaces. Script kiddies Dynamic language programmers claim strongly typed languages are broken. It comes even to a very last discovery that short methods are pure evil!
I've just spoken to a programmer, who had nearly 20 years of experience with Java, yet trying to convince me that interfaces are useless, just because for that long time he had never written an alternative implementation of method. In same conversation however, he praised ORMs for possibility of painless exchanging of DB engine!
The leitmotiv of this new heresy is that we can easily cut off the effort introduced by OOP, design patterns, TDD, DDD or any other, until now considered a good practice and focus on delivering just what matters - the `business value` itself. So that we can successfully bill the client and go to the next project. This sounds good. That may make sense. If your project is not going to be maintained for years, please feel free to skip paradigms. Use spaghetti architecture. Use mixed javascript, php, perl and have fun with testing on production. Building a prototype is a kind of development. Write once and dispose the code soon. But in project that is planned for more than three months this approach is just as wrong like murdering your client with an axe and taking their money. Just like Vikings did.


It is all about maintainability. If you use dynamic typing but do not cover your app with test, expect your work will get broken by colleagues siting next to you and following your discipline. If you do not use interfaces - I expect I know already how your tests look like. Like `null`. If you prefer not to extract method I know how lightweight your code is. I have seen java class source code that had over 1 megabyte! Imagine how fast you can deliver business value in such a project. If you think design is a waste - yeah... I was there, I have seen important application presenting different results on each subpage, thanks to `if` pyramid of doom, copied, pasted and happily living its own life. It does cost. Believe me. Technical debt is not something that will disappear by just forgetting the matter.


Elegant Objects by Yegor Bugayenko gives you some kind of framework. By following author's 23 pieces of advice you can learn how to use Object Oriented Paradigm in real language like Java. Yegor conducts personalized object (Mr. Object) through journey of life. The very similar way as we personalize actors using eg. Akka and follow some important rules - not forced by language itself. This concept seems to be core of author's approach to improve maintainability of software we create. When we interact with a person, we stick to some polite way of communication, assuming we are not talking to an idiot. Same holds for our objects.

There are some other helpful tricks and lot of strong opinions on using some code constructs and patterns/antipatterns. The book gives number of easy to remember code examples. Explains or recall you why constructor injection is the only right way and why `static` is not welcomed (even if we do now FP in Java). If you are more interested in the content of the book - I can recommend Tomek's review and page of Yegor Bugayenko.

Some of author's rules I think may be a bit controversial and exaggerated - at least in context of my last project. The only point I really didn't like was actually Yegor's approach to C++, a bit unfair as this language can be as object oriented as Java is.

I am not imposing that there is only one way to create maintainable software. Whether you will use header files to separate contract from implementation or will you use java interfaces or maybe free monads that define program separated from its interpretation. It is up to you. But please, take some set of rules, and keep to them in consistent manner. That is what your client pays you for.

Friday, December 8, 2017

Always say "Junk fix", never "quick fix"

software development area - names are almost only context that can be added to a computation. By using common vocabulary we build shared understanding of how things work and what is their meaning. When we communicate with outside world using our language we also put a corner stone under the how eg. business people will be able to visualize system we are responsible for.

One of the greatest examples of metaphor used to explain the nature of projects to stakeholders is a term coined by Ward Cunningham - technical debt. In very illustrative way it mimics well known figure of a financial debt to explain the costs or possible impact that unmaintained software brings to owners. In the opposite pole I can see a term used so often, while bringing so much confusion and leading to misunderstandings and even conflicts in many organisations. I mean the "quick fix". Quick and dirty, when we tend often to forget how dirty it was, leaving it in our software just to make it rot. Please keep in mind each time you say "quick fix" what you really communicate is "cheap fix". Is it what you meant? Will it be that quick in the final picture? Or it is just half done, ad hoc patch that will not consist solution, but maybe bring counter productive impact to changed process?



About the false velocity of quick fixes
Recently I have watched Netflix "Cooked" series of four, visually elaborated stories about food and eating. It was about the real food, that brings value to our life, as opposed to what is often offered to us, mass product of industry, optimized for price only, washed from nearly everything our body needs. The junk food.

I find this being a perfect metaphor to what is often offered as a "quick fix". This word junk explains exactly nature of the fix without giving a false assumption that anything cheap is being discussed. Let's be clear about it.
It is a "junk fix", not "quick fix".

Sunday, November 12, 2017

Stand IT up!

Recently I had a pleasure to join a presentation on how sitting at work is degrading ones health. IT industry is at highest risk. What unhealthy position does to us has serious, even fatal consequences in long term.



Our way of living is far away from what is natural living that human bodies are created for. This has so many aspects and long term factors that cannot be neutral for our health.

What we do to our bodies is what we call technical debt. Unfortunately, this project has very limited time dedicated for refactoring. Medicine is now clear about it. Sitting at work can take YEARS from our lifetime. 

IT is a fantastic community. We exchange knowledge to improve our skills. We are professionals willing to deliver our best to our business partners and apply best practices we know. We are able to suppress all practices regarding our job, that we considered harmful.

Why not apply this approach to ourselves? Stop unhealthy practices that damage the only thing which really belongs to us - our body? There are scientific, medical, cultural and moral reasons for standing up at work. Changing small habits seems an easy way to live much happier, healthy life. I am convinced!

TLDR; quit sitting, it kills.

Friday, July 7, 2017

I want my Rhino back! Switching to Nashornless.

In JDK 8 default scripting engine had been changed. Nashorn replaced Rhino. I understand all positives of this change and how good the use of InvokeDynamic is, etc.
But this change may be also seen as a breaking change. Which is quite normal in world of JavaScript btw :D And do not expect compile time errors! It is almost like node experience...

Ok, your old Rhino-specific code will not run with Nashorn. However, I have been using it for years, and truly speaking missing it a lot. I wrote test tooling scripted by Rhino, glue code that connects ETL to Java or dynamic backend of application, allowing website maintenance with no redeployment. Still, it is possible to go back to old good JavaScript implementation. So let's make our Rhino great again!

We could, of course, use it like we did it before JDK 6: add just a lib to our project and evaluate script by means delivered by specific Mozilla implementation.

If we are more familiar with Java scripting in JSR-223 style we would need extra code that is Sun specific part, already removed from recent Java. But fortunately someone already did the job for us and provided alternative JSR-223 wrapper that uses original Rhino and provides all extra classes that are required by standardized engines.
Let's just add dependency to pom.xml file:
    <dependency>
        <groupId>org.mozilla</groupId>
        <artifactId>rhino</artifactId>
        <version>1.7.7.1</version>
    </dependency>
    <dependency>
        <groupId>cat.inspiracio</groupId>
        <artifactId>rhino-js-engine</artifactId>
        <version>1.7.7.1</version>
    </dependency>

And yes, now we can use old, good, nashornless Rhino again! Just one more thing to remember is to use right scripting engine instead of "javascript".

new ScriptEngineManager().getEngineByName("rhino");


Thursday, June 8, 2017

No pride, no prejudice: Effective Java

While reading programmers' blogs you can be exposed not only to shiny technical stuff, as well you can meet author's private opinion. It's positive, as human being we want to share our opinions with others. But some opinions seem weired - and only possibility is to get used to that. One blogger dissed proggrammers' meetups, other advocated abortion, another one prefered null checks over Optional, million others actively hate statically typed languages. Not mentioning Emacs fans...

Some time ago I read a blog post in which author rejected idea of reading "Effective Java". Blogger had explained that book must be clearly outdated as 2nd edition was released in 2008 and he is not going to loose time for reading things like string concatenation vs using StringBuilder.
Well...

Fortunately this classical book is easy to defend, even for not such-a-proficient-blogger like me.
Well recognized Java bestseller is not really about outdated micro-optimations on low layer (which btw may also be a good topic to know). It is not about what is different from C in Java.

This book introduces readers into variety of interesting topics.
After reading you will (not only) be more aware of why immutability is important in contemporary software, how to structure data better, or how to use compiler to ensure type safety to work for your benefit. It will encourage you to use language constructs that support safe coding (eg. using enums), name things correctly (like use static factory methods) and depict constructs that are problematic (eg. clone). And explain variance in generics... :D


My personal observation is that Bloch's book was for some Java guys a first step into typed functional programming with Scala or even Haskell. I have seen lot of smart who followed this path. They could of course years ago assume that their knowledge of Java and enterprise technologies was good enough and they do not need to read one more book on `efficiency`.
I think that they had a very good and respectable attitude to their own knowledge.
Be like them. Do not believe you already know everything, rather as a software engineer you must be open to learn, read and try new things out. And sometimes read 10 years (or even more) old books.

Wednesday, March 1, 2017

Generating model with inheritance from swagger specification

The post on generating java model with inheritance from swagger specification is on Zooplus company blog.




BTW I must admit I like more code formatting options on ghost platform than what I have here with blogger.

Saturday, January 21, 2017

The great red dragon and the novice programmer

As a novice software developer at some point of time you will find enlightenment. You will understand what is the source of Power. Power of perfect code development. Power of ideal expression ideas to text. SOLID and clean, intentional and free of any accidental complexity.

You will desire that Power. Like the Pilgrim admired the power of The Great Red Dragon. But still you need a transformation. Pilgrim needed his victims to see his beauty, as he himself admired the Red Dragon. You will instead look at code you work with. The real code. Ugly. Legacy. Half year old code written on 2 releases backward Spring version. You will show your vict... sorry, colleagues that bad code. And yourself as a powerful Red Dragon. But... You're not yet him.

You need your transformation. I was there too. Now I know. Please keep in mind one thing. Consult your more experienced colleagues before you start making that code better. Example from my transformation. I spent some time years ago to refactor piece of code using collection to keep objects of various classes. Then cascade of instanceOf... This was looking for me as an unacceptable implementation. Unfortunately, my employer would have been more happy if I had focused on my tasks instead of refactoring code that was correctly working since years. From his perspective my hard work was not considered as productive. Now I know I just was not able to recognize which part of system needs what kind of refactoring.

Here I must refer to Procent's excellent talk with Jarek Palka (in Polish). You can find out a lot of important hints regarding working with legacy code. Which is code you have just commited. One of hints is why compulsive refactoring may affect your projects and may cause inability to deliver.

After years I learnt that system I was working with was actually quite good thanks to good design and correct, efficient, event driven architecture. As a young developer, influenced by Clean-Code evangelism, I was focused on local parts, not on wider scope. Lot of implementation details were given to novice programmers and far from ideal. They SHOULD be better, but system was good enough to resist local code ugliness. Please try to learn what is important in your system first, before you start assuming that whoever wrote some piece of code was an ignorant or does not even know the programming language. Remember you have not yet transformed into The Great Red Dragon.