Let’s face it, writing software is hard. And frankly we humans suck at it. We need all the help we can get. Our industry has developed many tools and techniques over the years to provide “safety rails”, from the invention of the macro assembler through to sophisticated integration and automated testing frameworks. But somewhere along the way the idea of static analysis went out of favour.
I’m here to convince you that static analysis tools still have a place in modern software engineering.
This was my first DevOpsDays event, I had only recently started looking into the world of Ops. I was unsure how much I could get out of the two days, or what exactly I was getting into.
DevOpsDays is a rapidly growing, annual conference acutely focused on Developer Operations and Delivery Engineering. So what is DevOps? Nobody really knows yet, not even the engineers supposedly belonging to this group can concisely explain what it is. The scope of the word has grown unwieldy, despite its state of infancy. In fact, the crowd seem to hate the very use of the word. Everyone pauses and takes time to punctuate each mention of the phrase DevOps with a facetious “air-quotes” gesture. Continue reading
I sometimes get the feeling that Google is watching me.
I don’t mean the way it emails me three hours before I have to catch a plane, or how it recommends news articles I actually would like to read, or how it does that thing where ads follow me all around the internet. That’s not paranoia. We all know they’re watching us for that stuff.
No, I’m talking about REA Hack Day projects.
Co-authored: Daniel Stankevich
TL;DR: React is better if you use Flux…
Our Journey with React
Having recently decided to embrace React.js for some of our front end applications we soon reached the limitations of simply wiring components together. When you start with a simple React application you will create many components. At some point a change in one of these components will need to update another component. eg. If you change a Price text field, you need to change the page title to reflect that. Continue reading
Most Agile retrospectives are about how the team is feeling e.g. happy, sad, confused etc. We then try and understand the cause of the problem so that we can fix it, in the same way that we try to debug an issue with a software program. This approach makes sense when dealing with complicated problems, such as software, which have direct cause effect relationships. However, when working with team dynamics, people interactions and feelings, we are working with, and within, a complex system that doesn’t have a direct cause and effect relationships.
Trying to understand the root cause of something in a complex system can take a lot of time, and isn’t necessarily helpful in finding the desired solution. In complex systems, there is no direct relationship between a problem and the desired solution – this is one of the things that defines a complex system
Solutions-focused approaches to change have shown that a more direct approach for complex systems is to investigate for clues of where evidence of the solution you want is happening already and do more of it. In addition you can also identify small actions to take, like mini-experiments, to see if these actions nudge the complex system in the direction of the desired solution.
One of the things you lose when you start using docker is the caching systems implemented in our package managers.
Take the following Dockerfile for example:
ADD Gemfile /project/Gemfile
ADD Gemfile.lock /project/Gemfile
RUN cd /project && bundle install
ADD . /project
This is great in that we don’t have to wait for our bundle if we haven’t changed the gemfile. But if we change just one dependency we have to wait for the whole bundle install.
This gets annoying after a while.