To my dismay, there are still a lot of teams that keep aside capacity in their teams to “do QA” after a story is marked development complete.
By that it usually means that there are some people in the team whose sole responsibility is to manually test every story post code-changes.
This is terribly inefficient, and must be changed. This is the premise of this post.
In most cases, the testing methodology being manual means that it is
These are fairly solid reasons to…
I often found teams convincing themselves that they don’t do flow control using exceptions, because they don’t do constructs like a
ResultException as described in Ward Cunningham’s wiki.
Things may not be that bad in most of these teams.
But I’ve seem exceptions being used in ways that are very close to flow-control, especially when the presence of said exceptions is used to trigger complex business scenarios.
You might have also seen that this indeed an oft-used method, so what is so bad about doing using exceptions this way?
From my earlier posts, it might become evident that I am a fan of trunk-based development within small teams, if circumstances were to allow for it.
However, as many of you might have seen through your careers, those circumstances aren’t always available. A well known, common and (dare I say) battle tested alternative is the pull-request model.
The pull-request model gets a lot of hate in certain communities, and it is not without merit, I might add. Some of the frequently leveled accusations against the working model are
I had a couple of stints at teams that did not do estimations, and I then began to realize how much of our time we waste under the guise of “estimation sessions”
The management or your client absolutely requires to know the delivery date of a piece of software, which is a very fair ask, I might add.
For this, team usually does the story-point estimation game. They come up with a point-based estimate that corresponds to the complexity of a task. The client/business has a total number of such points that the team are known to do within a…
This post will reference only the -original- 1993 movie. The sequels were unnecessary cash-grabs, and I will pretend they do not exist.
And don’t even get me started on the current trilogy.
Now that we got that rant out of the way, Jurassic Park having lessons for software development (or technology, rather) is pretty unsurprising, considering the movie was based off a novel by Micheal Crichton, who frequently used plots around technological advancements going wrong.
These are 5 things I personally picked up from the movie I believe applies to our careers as software engineers.
Ian Malcolm, a character in…
In this article, we are going to talk about PACT tests, which is a form of Consumer-Contract-Driven-Testing. For more information on what PACT is, please visit this link
A frequent question that came up in a couple of client engagements where we had used PACT testing was regarding the scope of the Provider verification test: just how much of the application gets tested as a part of such a test?
If you were to follow the official documentation and suggestions provided there, I’d say the options are really wide open for you and your team to choose:
I happened to see this type being returned from long function call today, that set me down a rabbit hole
But first, what is a
It is a construct from the Arrow library, which is used to wrap the result of an operation to be either a value (if the operation was successful) or an Exception, if the operation raised an exception. Have a look at the documentation here for more information.
All good, but what caught my eyes was the fact that the
Try was wrapping a nullable, and the
Try object was itself nullable.
It is fairly easy to convert callback based code into Kotlin coroutine based code, bringing with it advantages of having asynchronous code that looks very much like synchronous code, promising easier readability.
Here is some code where we make a call to an API using the OkHttp library, with a callback to handle the response:
To test if this method works, we write a test method that look like the snippet below. Considering that there is a callback, I have had to use the awaitly library.
Coroutines can make this look better, I promise. Let’s get started.
Quite recently, when we changed some of our code to use
CouroutineScope.async() instead of
When doing this, we came across an interesting exception that was thrown.
This was the offending code, simplified for the sake of demonstration:
thatCallsTheLastFunction() throws the exception above.
If you were to have a cursory look at the stack-trace in the exception, you might guess
logback might be the culprit.
And it indeed is: https://jira.qos.ch/browse/LOGBACK-102 7.
What is happening is that logback will not be able to print out an exception, if it were to have a
suppressedException that is a circular reference…
Our team uses Jetbrains/Exposed for all database interactions in our Vert-X based Kotlin project. Over time, we wanted to migrate away from an ORM and use vietj/reactive-postgres-client instead.
All database related code in our project was encapsulated within repository classes. As such, we merely need to swap them out with new versions of repository classes that used the reactive-pg-client driver, push changes to production, and end the day with a pint.
Pretty simple. A win for layered architecture and SRP, I might add.
However, such a simple switch over, I think, could come with some issues:
Learning to be a better developer everyday.