For the past months I’ve been researching what characteristics an Agile Leader needs in companies of different sizes, for my MSc thesis. I’ve now reached the data collection phase. If you are working in an Agile team, please fill out the following survey to help my work. It will not take more than 10 minutes.
In return, I promise to make the results available here on this site, as soon as I finish writing.
The link is here: https://goo.gl/forms/361nss6U5snIpJpn2
Thank you in advance!
I’ve been building a little home project for the past couple of months, just to experiment with programming languages and frameworks. During this time I managed to put together a simple continuous delivery pipeline, completely automated and free of charge. In the following paragraphs I’ll describe how I, in my next home project should connect those pieces of puzzles together. Maybe it will be useful for others as well. Continue reading “Notes to myself: free CD pipeline for home projects”
The other day I had to figure out a way to compare two different web services to see whether a subset of their output are equal or not. One of these services (let’s call it the legacy service) is capable of emitting XML as a response, while the other one (a completely new service that is intended to be a replacement for the legacy code) uses JSON. Unfortunately, the output of these two are only similar in a conceptual way; their structure differs a lot, they use very different ways of structuring data. I checked out some common frameworks for testing web services, and though all of them were useful for parts of my task, they proved to be hard to use for my complete work. Of course, all these frameworks all all too general purpose, while my problem is, I guess, not that of a common use case. At this time I started experimenting with REST Assured – a framework that finally saved me a lot of time and effort. In the below short post I will describe how easy it was to get my job done in a relatively short time, with this cool framework.
Continue reading “Comparing web services for output equality”
Quite some software engineers think that design patterns are some overly complicated, mythical, abstract things that bring no practical value to software development. This is unfortunate. In order to prove they are indeed something real, in this (and some upcoming) post(s) we are going to take a look on a few examples on how real software products implement some of the GoF design patterns. Today, we are going to visit Strategy, from HotSpot’s point of view. (See the previous post about Flyweight here).
Continue reading “Design patterns in the real world: Strategy”
Once I heard a talk, where the presenter asked the audience how would they write hard to test code on purpose. People in the room were a bit shocked, as nobody would write bad code intentionally. As far as I remember, they couldn’t even come up with very good answers to this question.
Of course, the purpose of this question was not to educate people on how to code in a way that makes their colleagues’ lives harder. Knowing what makes code hard to test can help avoiding some serious problems. Here’s my list of answers to the above poll (of course it’s really subjective, almost everyone has a different set of smells that they hate most).
Continue reading “5 easy ways to write hard to test code”
Quite some software engineers think that design patterns are some overly complicated, mythical, abstract things that bring no practical value to software development. This is unfortunate. In order to prove they are indeed something real, in this (and some upcoming) post(s) we are going to take a look on a few examples on how real software products implement some of the GoF design patterns. The first one to be examined is Flyweight.
Continue reading “Design patterns in the real world: Flyweight”
For the past 2+ years, I’ve interviewed more than 150 people for different Java positions, from junior to senior+ levels. During these technical discussions, I’ve observed a number of strange patterns repeating over and over again. Some of these are really counter-intuitive, maybe I’ll be talking about these in a different post.
All these interviews were really, really different, but one thing is constant: people get scared once they have to solve a programming puzzle at the whiteboard. I remember how I hated these kinds of tests when I applied to my current company. My reaction was not any different from most of the candidates’ I talk with. The whole thing went like this: I told the interviewer how I hated these exercises, I mentioned how the problems were not realistic and finally, at the end of the exercise I complained about how I missed good old JUnit. As I mentioned, nowadays’ candidates are not very different and I usually understand them. I really thought the puzzle part had to be done to torture people, who already happen to be freaked out as hell, with their pulse above 180, and can’t even stop sweating.
Continue reading “Programming interviews – observations, tips”