One topic I always keep coming back to when it comes to DevOps is shift-left testing. What is shift left testing? The term was initially coined by Larry Smith in 2001 in an article in Dr. Dobbs Journal and refers to how we, by testing as early as possible, may deliver both faster and with higher quality. What if we instead of postponing testing until the sprint is over and we’ve delivered a new increment to QA were to test all the time; together?

During the last 12 months, I’ve been doing a lot of public speaking, both as an instructor and as a conference/meetup speaker. If I count, I end up at: 6 classes 7 conference or meetup talks 1 podcast episode (in swedish, available here) While being truly grateful for this opportunity, this also means a lot of really hard work and a whole bunch of rejections. Probably about 9 or 10 times the amount of accepts.

Finding the root cause As I often state when I do talks or courses on the topic of DevOps, I’m a firm believer that DevOps has very little to do with technology, and a whole lot to do with culture. We, as developers, are often very good at performing root cause analysis and present a conclusion whenever things go south. Usually, we’re also as good at pinning that mistake onto someone, whether it’s a colleague or ourselves.

As those who know me or have seen me speak at a conference know, I’m a big fan of DevOps practices. I’m also a big fan of automation. After spending a couple of years digging into the topic, practicing it and talking about it with people from all around the world, I thought I’d share some of my own thoughts and experiences on the topic. The big sell If you’re at a shop that’s been around for a while, have successful software in production and by every meaningful measure is doing great, then you’ll probably have quite a hard time convincing anyone of the need to pivot towards DevOps practices.

Test automation Test automation is the practice of taking tests that traditionally have been executed manually and instead implement them programmatically. By making your tests part of the code you also allow yourself to run the tests continuously every time you make a change in the code while adding little to no additional cost. A high amount of relevant, high-quality and automated tests is one of the most important factors in maintaining high software quality while keeping the cost of change as low as possible.

It’s that time a year again. The time when all the nerds, myself included, get forced out of the office for some well-deserved RNR — just like when we were kids and our parents told us we had to go outside and play to “catch some fresh air”. Jokes aside, I really love my summer vacay. It gives me plenty of time to travel, read books and reflect on the past year.

In this part, we’ll set up a react app with redux and make it work with some simple actions. As I’m a big advocate of typescript and its superior readability; we’ll go ahead and use that as well. Creating the app So let’s get started by creating a react app using the typescript template. If you dont have the create-react-app cli already, start with installing it: $ npm install -g create-react-app Then create a react app with the typescript template.

Before we dive into redux and sagas, it might be nice to get some background. What is Redux? To quote the readme available over at https://redux.js.org/: Redux is a predictable state container for JavaScript apps. It helps you write applications that behave consistently, run in different environments (client, server, and native), and are easy to test.

I confess, besides being a comic buff I’m also an avid reader of business and tech literature. Usually, my summer routine consists of piling up on books, novels, and comics that I never get around reading during the more hectic part of the year. I strongly believe that this habit is a huge factor as to why I steadily feel like I keep growing as a professional, leader and knowledge worker while avoiding the feeling of plateauing.