It appears to me that Pair Programming is, next to TDD, one of the most controversial of XP practices. It also appears to me that most people criticising Pair Programming have never done it or, if they did, don't have too much experience with it. Where the critique comes from? Why should you give Pair Programming a try? How to get yourself into Pair Programming?
Let's just say, hypothetically, that you have just started working for a new company. Finally a perfect job you have always dreamt about... or at least what it seemed to be until you haven't taken a first look at THE CODE. That's when first crisis comes along...
A tear appears in my eye. My beauty! My child! I've just spent 3 fantastic, productive pomodoros developing this feature! Maybe I'll just leave it. The end users will have a choice! More features! Yes! But.. I'm a programmer. YAGNI, KISS... I can't just leave this complexity in there, just in case someone prefers double deployment, just to be able to review posts via pull request. My heartbeat goes crazy. And then it woke up...
I can't name exact sources, but I feel like ever since I started learning how to program, I was reading tales and legends about "reusable" components, modules and so on. It was not until recently, that something clicked in my head and I found this concept pretty basic. In this text, I'll try to shed some light on creating components and making them reusable. Obviously, it won't be any close to complete, rather an inspiration to explore further.
Imagine you're assigned to work with an old codebase without a reasonable component structure or any structure at all. A big ball of mud! What now?! How do you get from there to nice, reusable components you'd enjoy working with?
For proper understanding of this article I'd like you to close your eyes and imagine something. But since having closed eyes and reading at the same time is not an option, we'll skip the "close your eyes" part and jump straight into "imagine".
Among the discomfort of being sick over the weekend, I also had the pleasure to do some reading - Kent Beck's TDD by Example in this case[^1]. This inspired me to write something about TDD - a topic that polarizes people a lot. Reading different opinions about TDD, I found that most TDD opponents don't know what it really means and haven't even partially mastered it. Here's my first attempt to stop this trend a little bit.
Michael Tharrington from DZone crew recently suggested to me that I could write about mistakes that I make. Well, the moment couldn't be better - my team just went live with a critical application and everything that could go wrong.. went wrong! Of course, none of the solutions was written solely by me - some of it was created when we were pair programming and all of it went through rigorous code review process, which makes it even more ridiculous.
I recently had a chance to play with Spring Boot 1.4 at work. Part of the application I was implementing involved communicating with REST services. I wrote some simple code and I liked it so much, that I decided to share it with you. Since I don't want to bore you with lot's of code and little comment, I made up a story to make things more plausible.
Hey boy, are you doing microservices? Sure you are. Everybody does. Have you moved to 4-tier architecture already? Are your applications cloud-native? Have you containero-dockerized yourself? All of it?
One of the keys to being a good programmer is working in an organized way. You pick a small, easy problem, solve it and move to the next small, easy one. One after another, step by step, something greater emerges. Our brains have limited capacity and processing speed. We can't do everything at once, we can't solve multiple complicated problems at the same time. Knowing this we can conciously limit our current "context" to something simple enough to chew at once.
I've already expressed my concerns about meetings, but I think there's more to say in terms of agile processes. Putting these things into practice is essential to being a good software developer. I've worked in Scrum and Scrum-like environments for a while and I have a feeling that we lack something - continuity.
Recently, I came to work, took a task from the agile board and started working. Some semi-interesting monitoring stuff. As it turned out, summing a few numbers in Grafana is not as easy as I expected. Then it began.
It's been some time since I started blogging and I see a lot of room for improvement. I was looking for a way to deliver more value with my posts, especially in terms of good examples. It's not possible to write a big enough example application for every single post and I can't use any of my work projects for obvious reasons. Taking all this into account, I decided to create something open source that will produce real value and act as an example in my posts. Here it comes, yet another blogging platform!
Packaging is one of the underrated features of Java. We use common sense to put things here and there, after some time everybody knows where certain things go and nobody cares any more. Well, as long as it doesn't slow you down, it doesn't shock newcomers and everybody on the team is fine with it, you should be just fine. Nothing wrong will happen. In the end, IDEs are so smart that it only takes a few clicks to reorganize the whole project. But we can do better! We can really benefit from a good package structure.
Recently, I noticed lack of inspiration for writing. None of the topics I've listed down on my to-write list seems worthwhile. All of these things are already written down somewhere by someone and I just don't feel like repeating them. One more article about SOLID, Design Patterns or Clean Code? Not today.
In this post, I will try to share with you some of the Clojure's (Lisp for the JVM) beauty. Note: I'm still learning the language, so I might be oversimplifying things. If you're a seasoned Clojure programmer, you risk a heart attack reading this :)
Recently, I've been working on a new project using Spring. It's been a great chance to try out new things, gather all the best practices and see what comes out of it. One of the things that struck me was how confusing Spring naming is when trying to go the right way.
Spring has become extremely popular among Java developers. After all, it's a great project with tons of useful features. I decided to share with you a list of practices I use to work effectively on Spring applications, avoid unnecessary framework coupling and achieve a tidy application architecture. The whole set of practices was too long for one article so I divided it into smaller parts. In this one, I will focus on services.
Persistence is a part of almost every Java enterprise application. Unfortunately, persisting domain objects is a non-trivial task. On the contrary, it generates a lot of problems, especially when we're using a relational database [^1]. Let's see different approaches to the problem.
Spring has become extremely popular among Java developers. After all, it's a great project with tons of useful features. I decided to share with you a list of practices I use to work effectively on Spring applications, avoid unnecessary framework coupling and achieve a tidy application architecture. The whole set of practices was too long for one article so I divided it into smaller parts. In this one, I will focus on effective handling of configuration properties.
Spring has become extremely popular among Java developers. After all, it's a great project with tons of useful features. I decided to share with you a list of practices I use to work effectively on Spring applications, avoid unnecessary framework coupling and achieve a tidy application architecture. The whole set of practices was too long for one article so I divided it into smaller parts. In this one, I will focus on things related to starting a new Spring application.
Tidy guide on how to create a Living Documentation in your (not only) Java projects.
Begineer guide to using the power of Dependency Inversion with examples in Java.
Are you using frameworks the right way? Are you using frameworks for business purposes or the other way around? Are your business classes dependent on frameworks? Can I press delete button on your Spring, Guice, Hibernate, JPA dependencies and still be able to test and use your business features? If not, you might have a huge problem - high framework coupling.