Hi there!

  Welcome to my professional blog! Or at least to an attempt of one. I've never written anything serious so please be forgiving :) Lately I've accumulated some experiences and things I'd love to share with other Java developers. I am a Poland based Lead Java Dev and Architect with more than 10 years of experience and I felt it would be nice to try something fresh and to start this blog. You can find me on LinkedIn and GitHub . Let's see where this new adventure will take me. I'm Writing this blog in english because english is a de-facto standard for any Java developer and I hope to gain more audience that way. I will try to make regular contributions to the blog, but I won't write something just for the sake of writing. I'll create stuff when I have something to share and, more importantly, when I have time to do it, so please be patient. Ok, that's that. Again - welcome to Kode Krunch. I hope you'll find something of interest here. P.S. T

TDD: How to test something that doesn't exist

Introduction   Hello and welcome to the article that will focus on one of the most divisive and controversial methodologies in the Programmer's too box - Test Driven Development. This topic was sort of covered by me in my Scope Management in Java Architecture article. I'm returning to it however, because it is, from the looks of it, a wildly misunderstood technique, and it deserves its own article. Background In the beginning years of my professional career I wasn't writing any automated Tests.  I didn't know how to do it and, more importantly, I didn't know I was supposed to. I was under the impression that I should be wary of everything that's going on in my code base to the point that I would be able to make changes and refactor things without introducing bugs. I was very efficient in manually testing my Applications just by 'clicking through them' and I was certain that this was the right way to develop Software. I know now how naive I was, but I mu

ORM Tips: Separating Business Logic and Data Logic

 Introduction Welcome to another one of my database-centric articles. This time, although all examples will be written in Java, the topic at hand is so generic and universal, it can be applied to any programming language that utilizes any Database Abstraction library that can be called an ORM .  Be it Java with Hibernate, PHP with its Doctrine or Ruby with Active Record.  Modern Application Architecture has drifted away from layered Monoliths to more flexible and manageable micro-services that utilize Hexagonal approach. Even if you didn't jump into the micro-services train, the focus these days tends to be on good modularization, vertical slicing and defining proper Bounded Contexts and Aggregate Roots within the Business Domain of the developed Product. But does it mean, that a Service or a Module can just be a bag of poorly structured, interconnected Classes with no proper, repeatable and meaningful naming, packaging and responsibilities? Can we, even when using DDD, CQRS and/or

Tech Aside: Architects Suck! Architecture Rocks!

 Introduction Welcome to another installment of "Tech Aside" series, where I focus on non-technical areas that are a part of Software Developers' world. Were you drawn here by a somewhat provocative title of the article? I've chosen it in small part because it is kinda clickbaity, but for the most part because during 2019 Devoxx Conference there was this great lecture performed by James Birnie , and it had the exact same title. I strongly encourage you to watch it (no actual engineering knowledge required), as it's a great talk and it will give you some context to what I'm about to share here.   This article may very well turn out to the most personal entry on this Blog, so if you're not that interested in a bit of my story, thoughts and reflections, feel free to skip it :) Who was I? When I've entered the IT Job Market back in 2010, things were very different from what they are today. I came from a small town in Poland and graduated not-so-prestigious

Tech Aside: What does it mean to be 'Agile' to me?

 Introduction Welcome to the first installment of the new series called 'Tech Aside'. It will group all articles where I focus on various non-technical aspects of my work.    I hope you'll agree that the key to a successful career in Software Development  is not only having  sound technical and analytical skills, but also possessing strong soft skills. We need to be able to work in a team, to organize our work, to communicate with team members, users and all the other people around us. To express our fears, our goals, our approach to solving problems. To be able to provide feedback, to explain technical aspects to non-technical folks, to defend our estimates and decisions against the deadline pressure. Our work is not placed in a vacuum. Deep understanding of the business context we're in and the ability to work collectively are fundamental to our success as Software Developers and/or Engineers. In the end, we need to be able to deliver and not antagonize everyone aroun

Hibernate Tips: Fluent JPA Native Query Builder

 Introduction  Hibernate offers a convenient abstraction layer over most of the common CRUD SQL operations. Combining it further with Spring Data JPA makes us feel that we have this huge and important part of our development covered by simple Interfaces and APIs. Sooner or later however we will be faced with a requirement that will force us to dig deeper into the SQL handbook and come up with a Query that is not supported by JPA/Hibernate. We then will be thrown into the not so pleasant world of calling Native SQL. Convenient until it's not JPA's support for calling Native Queries is not friendly at all. You are required to abandon all of your Java abstraction layers and naming conventions, and simply provide a Native SQL Query in a String. Anyone who needed to code anything using Strings knows how fun it is, even with IDE's support. Let's set a realistic example to work with. Suppose we have an online book store and we keep our book entries using the following simple E

Hibernate Traps: Merge versus Update

 Introduction Welcome to another installment of Hibernate Traps. This time we will take a closer look at one of the most basic and commonly used features - updating Database state with a detached Entity. This time the title is also kinda stretched, because this Trap belongs more to the general JPA realm, than to Hibernate. However because Hibernate is the most commonly used implementation of JPA, and I'm not entirely sure whether all implementations of JPA behave the same way as Hibernate in regard to merging , I will again carry on with the title as it is. What JPA is not telling You... Merging a detached Entity is one of the most common operations in any Database-driven application. Any time we get a REST Request that updates data in our application, it is very likely we will use merge operation and expect Hibernate to generate one or more Update SQL statements. This may not be the case if we need to find Entities using some search criteria prior to updating them, because then we