Comparing web services for output equality

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”

Design patterns in the real world: Strategy

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”

5 easy ways to write hard to test code

 

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”

Design patterns in the real world: Flyweight

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”

Programming interviews – observations, tips

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”

Java 8 HashMaps, Keys and the Comparable interface

/**
* This post is intended to be a 101 quickie for the less experienced.
* It does not provide new or innovative ways of solving a certain problem,
* just summarizes a topic the way I see it.
*
**/

OONO1YLNOY

Java 8 is coming with a lot of improvements/enhancements compared to the previous version. There are pretty many classes that have been updated, HashMap -as one of the most used data structure – is no exception. In this post, we are going to discover a new, important feature that Java 8 brings to us in case of hash collisions.

Continue reading “Java 8 HashMaps, Keys and the Comparable interface”

Writing integration tests for RabbitMQ-based components

I’m writing this post after days of misery, reverse-engineering, github browsing and finding (sort of) clever ways to get yet one step closer to the goal mentioned in the title.

Before we dive into the topic, let me clarify a few things. RabbitMQ, an AMQP (advanced message queueing protocol)  compatible message oriented middleware, (in my understanding) has no in-memory message broker implementation. ActiveMQ, another AMQP compatible implementation, on the other hand does provide such a component – easy to configure and use. The problem is that ActiveMQ implements version 1.0 of the protocol, while RabbitMQ is on version 0.9.1, and the two versions, of course, are not compatible. That is the main reason one might need QPID, a third MOM implementation that comes with an in-memory message broker and is able to “speak” multiple versions of the protocol.

Continue reading “Writing integration tests for RabbitMQ-based components”