I'm going to let you in on a secret. I learnt my trade in a traditional software testing consultancy - I'm talking a waterfall approach to test planning, test case definition and test scripting. Over the last 5 years at Infomentum, I've evolved and have worked hard to optimise Infomentum's testing practices to suit our agile development environment.
Recently, I was one of the lucky few that were handpicked to attend Oracle's partner training on Intelligent Bot in London - and that meant I got hands-on experience with the product and witnessed its glory in action! The product is called Intelligent Bot and it would be available as part of the Mobile Cloud Service (MCS) suite as it complements other features of that product - not to mention that it fits the product the most. The aim is to provide an easy way to create Chatbot applications in simple steps, and provide options for Intent Recognition - i.e. understanding what the Chatbot's end user means - and custom entities to be able to take actions and drive the conversation towards whatever developers see fit.
Wait: you need to read part 1 and part 2 first!
You’ll remember that last week I discussed the crucial need for a cultural change in how we dealt with time logging. After the CX team’s thorough research, we were ready to take the findings – and our ideas – to our board of directors.
Hint: you'll need to read part 1 first for this post to make sense.
The CX team got together to discuss the problems and carry out an internal ideation workshop to tackle them. We knew that we had 3 key tasks:
It had been coming for a long time…
At the end of every month, developers scrambled to complete their timesheets, while the operations team were breathing down their necks, threatening them with sticks to get it done - and done right. The developers were left wondering why operations wanted their time logs so desperately. Surely they already knew what they had been working on? The operations team were scratching their heads as to why the developers didn’t do it; they had been reminded at the end of every month like clockwork, yet every month the same story. It was hugely frustrating for both sides, and was approaching boiling point. As soon as the Customer Experience team had a break between projects, we knew this was a top internal issue that had to be solved.
I’ve wanted to write something about Infomentum's scrum board since its inception in late 2012. Now seemed as good a time as any to share the story...
During an end of sprint retrospective, one of our developers Jakub said “I'm bored of the board.” That didn’t surprise me.
In the 'What are microservices (part 3)' we touched different approaches to building a microservices architecture. In this final post of series on microservices, I will discuss those approaches in more details.
Wait! Have you read 'What are microservices' blog posts part 1 and part 2? You need to cover those out before reading on.
When it comes to microservices, the million dollar question is: “How do I decompose my monolith into microservices?”. Well, as you can imagine this can be done in many ways, and here I will be suggesting some guidelines.
I'm an Integration Consultant and part of Infomentum's wider integration team. As well as being a MuleSoft trainer, I'm a certified MuleSoft developer and an Oracle SOA suite specialist.
I’m going to pick up from last week’s post when we discussed the microservices definition, and looked at the alternative approach to microservices, aka the monolith. Make sure you read that before carrying on with this post.
Why is the microservices approach different? Let’s explore the main features one by one.
