A service overload happens when a service receives more incoming requests than it can reasonably respond to. There are many reasons that service can get overloaded. A few examples are a sudden surge in traffic, a change in the service configuration, attacks by malign actors, and more. In the event of a service overload, the service starts to behave differently. It starts returning HTTP error codes, responds…
Leave a CommentCategory: Software
Welcome to the Software Development section of the blog. A place for both the strategic thinker and the technical enthusiast. Here, we go over realm of software development, embracing both the overarching methods and the occasional deep dive into the world of coding.
In this space, we’ll venture through various terrains:
Tech Trends: Keep your finger on the pulse of the latest advancements and shifts in the software industry, from AI breakthroughs to cloud computing.
Development Strategies: From ideation to launch, explore frameworks and methodologies that streamline the development process and enhance product quality.
Code Insights: While the focus is on the bigger picture, we won’t shy away from dissecting a piece of code or two, demystifying the magic behind the machines.
Project Management: Delve into the art and science of managing software projects, ensuring they are delivered on time, within scope, and up to standards.
Opinion Pieces: Engage with thought-provoking commentary on where the industry is heading and what it means for developers, businesses, and end-users alike.
In each article I share my understanding. I want to spark conversation, whether you’re a seasoned developer, a project manager, or simply tech-curious. Join me in this collaborative exploration of software development, where theory and practice meet to drive innovation forward.
Incidents are used for the negative consequences of an action. The incident comes from an action that fails to result in the expected outcome. For instance, deploying a code to production to add a new feature to improve performance. It then takes down the whole service. This is an unexpected outcome. The incident learning is the part where we uncover underlying problems that lead to the incident.…
Leave a CommentThroughout the years I have worked on many software projects. In most of them, the code header included the author’s name. At first, it seemed natural to have the author’s name. In time I realized having a code author in the header is irrelevant, discouraging, and often negative. In many projects, the header file is dictated by the coding style for the company or the project itself.…
Leave a CommentOver the years I conducted many interviews and recently I have interviewed with a couple of companies. While preparing for interviews, I solved a bunch of leetcode problems including hard ones. Practicing makes it easier to solve problems and reading the solutions of other people improves the perspective. Hard problems require combining multiple approaches such as dynamic programming, sorting, and searching. At a first glance, there’s a…
Leave a CommentRecently, I was working on a project and I missed a case in unit tests. I didn’t want to verify each argument but rather wanted to check if an object has a certain attribute set. In the older versions of mockito, this wasn’t doable. Since mockito 2.1, you can now do argument verification through argThat. Let’s see an example of this in action. @Test public void testWritesWithAttributes(){…
Leave a Comment