Resilience is the ability to recover from or adjust easily to adversity or change.
Generally speaking in software engineering, resilience means that your system/application is able to withstand a failure in one of its components, work nevertheless, and eventually recover in a reasonable manner and acceptable duration.
Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production. wikipedia
Ok.., that does not add much to our understanding:
What does experimenting on a system mean? How do we experiment?
With every day more new people learning to code, and new developers starting a blog and with Blogging being so important for your professional growth and your personal brand, I decided to share some tips I realized to be a winning strategy over many years of blogging.
Here it goes, hope it helps:
Whenever I tell this to my kids and come back 5 minutes later, I go crazy because the floor is still covered by socks, pencils and basically any other toy which is not a Lego.
What did I say? Tidy up your room! Why didn´t you pick up all that mess?!?
I guess right now you imagine the answer, even though you don´t have kids:
You didn’t say that! You told us to just pick up the Legos!
As a father, tech lead, and developer I am always surprised and upset when after “giving an instruction” the outcome is not what I expected.
I immediately start to wonder where I failed in my communication. …
“Don’t expect to be motivated every day to get out there and make things happen. You won’t be. Don’t count on motivation. Count on Discipline.”
I love this quote, and I think about it everytime I feel lazy or tired and I don´t want to wake up early, workout, finish that course on Udemy, wash the dishes or whatever.
I love climbing and I would climb every day, but the sweating, screaming and going through the sore muscles of a full workout, well that sucks! But it´s important! …
Jinx or Cassandra? What’s the difference?
Well… Cassandra was right! **
I found this quote in a book I read this summer. ( The hungry and the fat — from Timur Vermes) and it reminded me immediately about the endless discussions “Be Positive!” vs “I am just realistic!”.
I bet you all know Murphy’s law. In all of its variations and corollaries:
If you are implementing a RESTful API, it is very likely that you need to validate the request parameters or the request body.
This can be done in multiple ways.
The first approach is having parsing and validation methods in your handler:
If not, return an error for an invalid request.
You can imagine that depending on the size of the payload and its constraints it is a lot of boilerplate code to run even before you got to the juice of your handler. …
Many years ago, I started working on a project, the code base was huge, developed by about 25 different developers over a span of 3 years.
The most recent parts were using a Dependency Injection framework, the older parts ( basically 70% of the entire code) were not.
One day, after I had finished my ticket in advance, I was so pissed I had to waste so much time to achieve something trivial, that I decided to create a branch and refactor the entire thing to use that framework.
It took me overall 2 or 3 days of work, split over many days of spare time ( whenever I had time after other tickets). Then I submitted the merge request to my Lead. …
I am pretty sure it happened to you many times to not agree on a comment you received in your Merge/Pull Request.
Cmon, this comment is just about style. The code is working. why should I change it?
…and by the way. I like my style best.
When something like that happens, and we try and manage to let it happen very rarely (over time we all grew similar coding habit and styles — and many time we don’t consider code style so important to block a ticket from being blocked by minor details), we normally stop the discussion and start a quick poll on slack. …
A couple of years ago when we started working with AWS, just a couple of weeks after we deployed our very first lambda + API Gateway, we received a message on Slack from one of our DevOps asking what the heck we where doing with our application, since it was quite contributing to the bill, despite the low usages.
The app was mostly internal and wasn’t doing much, still, Cloudwatch logs were growing huge and huge.
What was wrong? Well, first of all, the app had been deployed to production with all logging enabled, and more importantly, we were logging the entire result of the lambda before returning it — and that result was a JSON file. …
Monday afternoon, you are working on your ticket which was planned for about a week (I know that with T-shirt sizes there is not direct reference to hours/days — or should not be — but… when you have a pile of things to do, who does not convert the effort in the time it will take?)
Let’s say the estimate has been quite loose, accomodating, the task seemed quite easy to everyone but there were some unknowns, so some buffer was added and the highest number on the poker cards was approved.
The sprint will end on Wednesday and you will be surely done tomorrow. Or not. …