# Code Ahoy - Articles Essays on software engineering and leadership by Umer Mansoor. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Semantic Search - Word Embeddings with OpenAI DevFeed: [Semantic Search - Word Embeddings with OpenAI]() Original publisher: [Read original article]() Author: umer Published: 2023-03-28T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [AI search](), [Natural language processing](), [Databases](), [sentence-transformers](), [Computer science]() Tags: [databases](), [embeddings](), [nlp](), [openai](), [search](), [techniques](), [vector](), [word-embeddings]() ### AI overview This introductory tutorial contrasts semantic search with lexical search, explaining how semantic search uses query context and intent to improve result relevance. It also introduces NLP, embeddings, and vector databases as implementation components. ### Source excerpt According to Wikipedia, Semantic Search denotes search with meaning, as distinguished from lexical search where the search engine looks for literal matches of the query words or variants of them, without understanding the overall meaning of the query. For example a user is searching for the term "jaguar." A traditional keyword-based search engine might return results about the car manufacturer, the animal, or even the Jacksonville Jaguars football team. However, semantic search would analyze the context and intent behind the user's query, such as whether they are interested in cars or wildlife, and then prioritize results accordingly. In this blog post, we will explore the underlying principles of semantic search, discuss its advantages over other types of search, and examine real-world applications that are transforming the way we access and consume information. Lexical Search Engines Lexical (Traditional) search engines have served us well using keyword-based search methods, looking for matching exact words or phrases in users' queries with those in documents/database. For example, if we search for the term "computer science intro" in a lexical / traditional search engine, it will return results that match one or more of my search terms. As you can imagine, the keyword matching approach often falls short when it comes to understanding what the user actually meant, often producing less accurate results. Semantic Search Enter semantic search -- a context-aware search technology that aims to improve search results by focusing on understanding the meaning and context behind queries. When a user inputs the query "computer science intro" in a semantic search engine, it would first attempt to understand the intent behind the query. In this case, the user is likely looking for introductory resources related to computer science. Based on this understanding, the search engine would prioritize search results such as introductory computer science courses or textbooks or other ## Programmatic SEO - Adding Millions of New Visits DevFeed: [Programmatic SEO - Adding Millions of New Visits]() Original publisher: [Read original article]() Author: umer Published: 2022-07-15T00:00:00Z Content type: opinion Language: en Sources: [Code Ahoy - Articles]() Topics: [Search engine optimization (SEO)](), [Back end](), [Website](), [Google](), [WordPress]() Tags: [backend](), [engineering](), [google](), [growth](), [infrastructure](), [seo](), [wordpress]() ### AI overview The article argues that an engineering team responsible for organic growth was focused mainly on SEO infrastructure and maintenance rather than measurable traffic growth. It describes redirecting the team toward customer outcomes, an owned traffic goal, and meaningful wins, while noting that much existing search traffic was branded. ### Source excerpt I was a senior engineering manager once at a company that helps job seekers, and one of my teams owned organic growth. It was a (relatively) small team team of very capable engineers front and backend engineers responsible for driving 'organic growth' and traffic. On paper that meant getting more people to the site from Google. But in reality, the team wasn't doing that. They were doing SEO infrastructure and maintenance. Generating sitemaps; keeping the services behind them running. Updating headings and title tags. Reviewing internal links. Owning the 'header' and 'footer'. Owning some low value sections of the website that weren't important to users (or the company). Inheriting work that other teams didn't want e.g. keeping legacy WordPress servers running that were important all but once a year when the company ran its annual awards and increased the traffic many folds. None of it was bad work - and somebody had to do all of it. But they weren't driving anything. There was no number they owned, no goal they were chasing, and nothing coming up that anyone was excited about. The team was a long way from the customer and even further from any outcome they could point at and say we did that. Getting the team closer to the outcome I wanted to change what the team was pointed at. Not their skills, not their headcount, and not how hard they worked. Just what they were aimed at. That meant three things: Get them closer to the customer Get them closer to the outcome, with a number that they actually owned Get them some wins, because a team that hasn't shipped anything meaningful in a while stops believing it can So I went to the VP who owned organic growth and asked a simple question: what are we actually trying to achieve here? Not what tickets need closing. Or how many sitemaps are indexed. What's the goal? The answer was traffic. Real traffic. We looked at the roadmap together and realized that most of the upcoming work was slotted for regular maintenace, SEO infrastr ## Brief Overview of Caching and Cache Invalidation DevFeed: [Brief Overview of Caching and Cache Invalidation]() Original publisher: [Read original article]() Author: umer Published: 2022-04-03T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [Caching](), [Cache](), [systems](), [Redis]() Tags: [cache](), [caching](), [data](), [performance](), [speed]() ### AI overview This overview explains caching as temporary fast storage for a subset of data. It describes how caches reduce expensive computation and speed up retrieval, and gives examples across hardware, operating systems, databases, APIs, HTTP, DNS, browsers, and microservices. ### Source excerpt Caches are present everywhere: from the lowest to highest levels: There are hardware caches inside your processor cores (L1, L2, L3), Page/Disk cache that our Operating Systems Caches for databases such as using MemCached, Redis or DAX for DynamoDB API caches Layer-7 (Application layer) HTTP caches like Edge level caching in CDNs DNS caching Cache in your browser Microservices can have internal caches to improve their performance for complex and time consuming operations You are reading this post thanks to many intermediary caches I can keep going but you get the point: Caching is ubiquitous. Which begs the question, why do we need caching? Before you scroll down for the answer, take a few seconds to think about the answer. What is a Cache? A cache is a fast data storage layer for storing a subset of data on a temporary basis for a duration of time. Caches are faster than original sources of data so they speed up future data retrievals by accessing the data in cache as opposed to fetching it from the actual storage location. Caches also make data retrievals efficient by avoiding complex or resource intensive operations to compute the data. When the application needs data, it first checks if it exists in the cache. It if does, the data is read directly from the cache. If the data is not in cache, it is read from primary data store or generated by services. Once the data is fetched, it is stored in the cache so for future requests, it can be fetched from the cache. Why do we need Caching? Typically, there are two main reasons for caching data: We cache things when the cost of generating some information is high (resource intensive) and we don't need fresh information each time. We can calculate the information once, and then store it for a period of time and return the cached version to the users. Arguably the top reason why we use caching is to speed up data retrieval. Caches are faster than original sources of data and cached information can be retrieved quickly res ## Code Reviews During Emergencies DevFeed: [Code Reviews During Emergencies]() Original publisher: [Read original article]() Author: umer Published: 2022-01-01T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [Code review](), [Pull Request](), [Development](), [Security]() Tags: [code-review](), [code-reviews](), [pull-request](), [security](), [slack]() ### AI overview This article explains how to distinguish genuine emergencies from ordinary release pressure and how to adapt code review during emergencies. It argues that changes should still be reviewed when addressing production bugs, major security issues, urgent legal concerns, or major release blockers. ### Source excerpt It's 3:40pm on a fine Friday afternoon. You are about to wrap up the main logic for a feature you've been working on for a couple of days when you notice you have unread Slack notifications. One catches your eye in particular: "Hey! Emergency. Need approval on my PR. I have tested everything on dev so if you can quickly approve, I can merge it before the weekend." Emergency. Alright, they have your attention. You could stop what you are doing and do a superficial code review on their pull request (PR) because after all, it's an emergency. But you are curious and fire back seeking to understand the context: "Sure, I can take a look right now. What's the emergency? Is it a bug in production or does the legal team want something updated ASAP?" They reply back right away: "No, I want to merge this code that does because I'm OOO on Monday and want to get this released today" Urgent? Perhaps. But does this constitute an emergency? Definitely not. In this post, we'll discuss how to review code during emergencies. Let's first begin by establishing an understanding of what constitutes a real emergency. Emergencies An emergency is a critical bug in production that's affecting users, a major security issue, an urgent legal concern or something that's blocking a major feature release that has a significant impact on KPIs. I think it's easier to understand if we look at a few examples of what is not an emergency: Not Emergencies The following examples are not emergencies. The author has been working very hard and long hours on the feature and wants to get it out ASAP. It's 30-minutes to the weekend code-freeze deadline so it'll be nice to get it merged. The author's manager told them that it'd be great if they can release the feature this week. The author will be away for the next couple of days. These could relate to urgent situations or special circumstances that could definitely be important. Delaying a release may not be ideal, but it's not usual ## Burnout in Software Development - Survey Results 2021 DevFeed: [Burnout in Software Development - Survey Results 2021]() Original publisher: [Read original article]() Author: umer Published: 2021-10-01T00:00:00Z Content type: article Language: en Sources: [Code Ahoy - Articles]() Topics: [Development](), [software-development](), [Software Engineering]() Tags: [article](), [covid-19](), [developer](), [developer-burnout](), [development](), [remote-work](), [software-development](), [stress](), [survey](), [work]() ### AI overview This article presents results from a developer survey examining whether the shift to remote work during COVID-19 worsened burnout. It also explains burnout, its symptoms, and common workplace causes such as excessive workloads, unclear expectations, and insufficient support. ### Source excerpt Burnout is very common in software development. Intense mental focus, heavy workloads, never ending roadmaps, under-staffed teams, unclear targets, and many other factors lead to developer burnout. I have experienced burnout in my career, perhaps twice. Early on, I had mild symptoms and my manager recognized it and helped me manage it. Later, after a very long stretch of working very long hours, 7 days a week on some super unrealistic goals with very little support, I ended up getting a bad case of burnout. It took me weeks to recover from it. When COVID-19 forced remote work shift began in companies, it was a step in the right direction by giving developers the flexibility to work from anywhere. However, I started hearing more and more about burnout. In this article, I will share results of a developer survey we did to explore if COVID-19 is somehow making the burnout situation worse. What is burnout? Burnout is a form of exhaustion caused by constantly feeling swamped. It's a result of excessive and prolonged emotional, physical, and mental stress. In many cases, burnout is related to one's job. Burnout happens when you're overwhelmed, emotionally drained, and unable to keep up with life's incessant demands. If it sounds very broad, it actually is. Burnout doesn't have a test that your doctor can prescribe and be certain whether you are suffering from it or not. Regardless, if it's not identified and addressed, it will continue to grow until it grinds you down and become the new normal. When that happens, it is not easy to pull yourself back out. It might take many months or even years to shake it off. Here are some of the common symptoms of burnout: You stop enjoying working on things you used to enjoy and lose motivation for weeks. You feel exhausted or fatigued all or most of the time. You have low energy at work and at home. You struggle to sleep and wake up feeling tired. You don't feel a sense of accomplishment or feel sort of hopeless about results. (The sy ## How to use Feature Flags in Node.js DevFeed: [How to use Feature Flags in Node.js]() Original publisher: [Read original article]() Author: umer Published: 2021-09-12T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [feature flags](), [Node.js](), [Code](), [Open Source]() Tags: [code](), [feature-flags](), [how-to](), [node-js](), [open-source]() ### AI overview A tutorial on using feature flags in a Node.js application. It explains how to place a feature behind a flag, configure targeting rules, distribute a feature to a percentage of users, and evaluate the flag with a Node.js SDK. The referenced Unlaunch service has since shut down. ### Source excerpt Note: Unlaunch, the feature flagging service referenced in this post, has been shut down. Links to it have been removed. Feature flags (or feature toggles) is a powerful technique used by modern software teams to control the behavior of their code and features in production. Feature flags are used for: rolling new features out gradually branch by abstraction experimentation and testing migrations geographic restrictions permissions or kill switch testing in production In this article, I'll show you how to use feature flag in Node.js. For this example, let's assume we have an e-commerce store and we're implementing a new feature to change the sort order of the items because in our hypothetical example, the marketing team thinks changing the sort order will lead to more revenue. I'll be using an open-source Node project called Crate which is an eCommerce subscription service for trendy clothes and accessories. 1. Put your feature behind feature flag in code First, you'll need to define the new feature in such a way it can be shown or hidden easily. if featureFlag == "on" then // show the new feature: new sort order else // show the old feature: old sort order Once you have wrapped your code (new and old features) in a feature flag, you can easily control the behavior by changing the state of the feature flag or its targeting rules. If the flag is enabled ("on" variation,) we show the new feature. Otherwise, we don't. 2. Create a feature flag Next, create a new feature flag in Unlaunch (Link Removed) that will control the feature you're building. You can call it the "default-sort-order" or "crate-products". Targeting Users A user is any object such as an email address, unique user id, a hash etc. to represent a unique user for which a feature flag is evaluated. Let's define an internal user (engineering, QA or product team member) by email address to always show the "on" variation so they always get the new feature. Targeting Rules The rules that define which variation ## How to Toggle Features in C# with Feature Flags DevFeed: [How to Toggle Features in C# with Feature Flags]() Original publisher: [Read original article]() Author: umer Published: 2021-08-26T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [feature flags](), [.NET](), [Development](), [web applications]() Tags: [c-sharp](), [feature-flagging](), [feature-flags](), [net](), [tutorial](), [web]() ### AI overview This tutorial explains how to use feature flags to toggle functionality in .NET Core web applications. It covers controlling feature visibility independently of deployment, testing features in production, rolling back changes, and gradually releasing features to users. ### Source excerpt Note: Unlaunch, the feature flagging service referenced in this post, has been shut down. Links to it have been removed. This blog post was contributed by Tuan Nguyen, Software Developer at Getty Images. Using feature flags to release new features to customers is a powerful technique. I have been using feature flags for many years to release features or changes to production safely and with the peace of mind. The releases are done without any ceremony, and the features aren't visible to customers until we turn the feature flag on. Using feature flags to toggle functionality in .NET Core apps is easily achievable using a feature flag management platform. In this tutorial, I'll show you how to toggle features on demand in a simple web application using Unlaunch (Link Removed) to create and manage feature flags. We'll also see how to show or hide our features with a click of a button, without merging branches, rollbacks or deploys. Feature Flags Feature flags allow developers to control who sees new features irrespective of code deployment. For example, developers can deploy a new feature to production environment and keep it hidden from all users (except themselves.) This way, they can do testing on real systems, and when the management is ready to release the feature, they can turn on the feature flag to let the users in on it. To me, here are some of the benefits of using feature flags: Developers eliminate some of the risk knowing they can roll things back instantly if things go wrong. On a few occasions, I rolled back features because of negative impact to KPI we didn't consider before or one of the underlying system wasn't quite ready. Developers can launch the feature on production behind feature flag and show it to product or marketing team for their feedback. QA in production. This doesn't mean that we skipped testing on the 'Dev' environment, but rather launching the feature on production just for the development team give extra boost of confidence. It also a ## Feature Flags: Concepts and a Google Sign-In Example DevFeed: [Feature Flags: Concepts and a Google Sign-In Example]() Original publisher: [Read original article]() Author: umer Published: 2021-02-27T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [feature flags](), [Code](), [Development](), [OAuth](), [Google]() Tags: [code](), [development](), [feature-flags](), [git](), [guide](), [oauth]() ### AI overview This tutorial explains feature flags as a way to change software behavior in production without modifying or redeploying code. It describes use cases such as gradual rollouts, production testing, canary launches, and experimentation, then uses Google sign-in approval delays to illustrate staged feature release. ### Source excerpt Note: Unlaunch, the feature flagging service referenced in this post, has been shut down. Links to it have been removed. The term feature flags refers to a set of techniques that allow software developers and teams to change the behavior of their system in production without modifying or even deploying code. Because of their ability to modify system behavior on the fly, feature flags are very powerful and versatile. They facilitate many use cases that boost developer productivity and make the user experience better and faster: gradually rolling out new features to users vs big-bang releases, testing in production, canary launches, experimentation and many more. We'll explore feature flag use cases later. But first, let's examine feature flags in depth and see how they work. What is a feature flag? At the core of this amazing concept, lies a dead simple and basic foundation that uses conditional code (if statement) to determine whether to perform an action or not. This is best explained with an example. I'll use a real one that I worked on not too long ago. We wanted to allow our users to sign-in to our site using their Google account. To do this, you first create a developer account with Google and get the OAuth code. The application must be approved by Google before you can use it on your site. Until then, it can only be used in test mode. Traditionally, the code for Google sign-in will be kept in a separate Git branch. When the application is approved by Google, the branch can be merged into develop or main (aka master) so it can be released to users. The challenge was that the verification process may take several weeks. I tested everything locally to make sure it was all working. But I couldn't release it yet, even for internal users. If I merged into develop to deploy the feature on the development environment, it would also release it to production (since release branches were automatically cut off of develop.) To summarize the issue: I wanted to release an un ## Tutorial on using Feature Flags in Java \[Complete Example\] DevFeed: [Tutorial on using Feature Flags in Java \[Complete Example\]]() Original publisher: [Read original article]() Author: umer Published: 2020-11-22T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [feature flags](), [Java](), [Spring Boot](), [Tutorial](), [Back end](), [API](), [Databases]() Tags: [agile](), [api](), [backend](), [database](), [development](), [feature-flags](), [java](), [software-development](), [spring](), [spring-boot](), [tutorial]() ### AI overview This tutorial explains how feature flags let software teams control feature visibility, gradually roll out changes, test changes in production, and roll back without redeploying. It demonstrates using feature flags in Java with Spring Boot through a backend API example. ### Source excerpt Note: Unlaunch, the feature flagging service referenced in this post, has been shut down. Links to it have been removed. Feature flags (or feature toggles) is a powerful technique used by modern software teams to manage the behavior of their code in production. Gone are the days when production releases happened occasionally and were a big event. These days, agile teams deliver changes to production continuously, sometimes releasing changes several times a day without any fanfare. Feature flags let teams release their changes to production and stay in full control over who gets to see the changes and when. Using feature flags, you can: deploy changes to production but keep them hidden from everyone but internal users. gradually roll out features to build confidence. if things don't look good (you discover errors), roll back instantly without any code changes to redeploys. test your changes into production. I've been using feature flags for the last 5 years and find them very useful in shipping changes quickly and confidently to millions of users, from infrastructure changes like DB upgrades to UI changes. In this post, we'll see how to use feature flags in Java using Spring Boot. Let's get started. Challenge Suppose you're a software developer working on a backend service: User Profile. There is an API that returns user information from the database, combining it with information retrieved from some other services and sources. One day, you were reviewing the performance of the API and noticed it is very slow and takes up to a second to return response. After some investigation and find the root cause. The delay is being introduced due to the way the service calls other services to get user's status, open orders and pending cancelations: the calls are being made sequentially, that is, one after the other. You think you can improve the performance by parallelizing the calls. In traditional software development, you'd create a new feature branch e.g. feature/JIRA-101-a ## Tech Debt Developer Survey Results 2020 - Impact on Retention DevFeed: [Tech Debt Developer Survey Results 2020 - Impact on Retention]() Original publisher: [Read original article]() Author: umer Published: 2020-02-17T00:00:00Z Content type: article Language: en Sources: [Code Ahoy - Articles]() Topics: [Tech Debt](), [Software](), [coding]() Tags: [developer](), [engineering](), [management](), [retention](), [survey](), [tech-debt]() ### AI overview This article reports results from a February 2020 survey of 117 software developers about technical debt. It states that 68% worked on products with high or very high technical debt, while 50% were likely or very likely to leave their jobs because of it. The article also describes the survey sample and asks whether management was aware of and addressing technical debt. ### Source excerpt Last month, I wrote a blog post called Technical Debt is Soul-crushing. In it, I discussed the effects of tech debt on software developers and how it makes them unhappy. I wrote it because, being in management for several years now, I have seen how people discuss tech debt as a product or engineering problem. They completely overlook or ignore its impact on people. For software developers, it is very frustrating to work on a codebase that has a high amount of tech debt. They feel unproductive and handicapped. This creates an atmosphere where people start thinking about leaving and they do soon as they find a better option. Because the blog post was getting good amount of traffic (10k views in a week), I decided to add a survey. The survey is closed and the results are in. 68% of Developers Said They Work on Products with High or Very High Amounts of Tech Debt No large software is tech debt free. At least, I haven't come across one in my life. Some have more, others have less. Not a single person said that their product contains 'No tech debt'. 50% of Developers Are Likely or 'Very Likely' to Leave Their Jobs Because of Tech Debt 27% percent indicated that they think about it, but aren't sure. Question: Is Your Management Aware of Tech Debt and Are They Taking Action to Pay It Off? I asked this question to see if there's a correlation between developer dissatisfaction and management or leadership being aware of the problem and taking action to pay it off. Here are the results. Question: How Long Have You Been Working on the Product with Tech Debt? Here are the results. Survey Methodology 117 software developers from all over the world took the survey. The majority were from the USA, followed by Canada, Australia, Germany, India, Russia , UK and other European countries. The survey ran in February 2020. 91 software developers took the web survey. 26 respondents were from my personal contacts. Senior or Lead software developers mainly from the USA and Canada who use Ja ## Technical Debt: Why Shortcuts Increase Complexity and Developer Frustration DevFeed: [Technical Debt: Why Shortcuts Increase Complexity and Developer Frustration]() Original publisher: [Read original article]() Author: umer Published: 2020-01-25T00:00:00Z Content type: article Language: en Sources: [Code Ahoy - Articles]() Topics: [Tech Debt](), [Software](), [Programming]() Tags: [complexity](), [engineering](), [programming](), [software](), [tech-debt]() ### AI overview The article explains that technical debt results from shortcuts taken to ship features quickly, often increasing system complexity and future maintenance costs. It notes that technical debt can be an intentional trade-off under time or business pressure, but accumulated debt can make development and troubleshooting difficult and demoralizing for developers. ### Source excerpt Technical debt is incurred when the software or system designers take shortcuts to ship a feature faster, increasing the overall complexity of the system. The goal is to optimize the present rather than the future. In other words, it's the easier path that takes us to the end-goal faster, but the resulting code (or design) is messy and complicated. It will require extra time in the future to add new features or to fix bugs. The most common reason why companies take on technical debt is to meet the time to market demands. "We must release this feature by February, or our revenue will take a big hit. Just hack it for now, and we'll fix it later." Other reasons for incurring tech debt include lousy design choices, poor programming, changing requirements, or the presence of outdated libraries or frameworks that made sense in the past but have become a liability now. Technical debt is not always a bad thing. It can help companies ship a critical feature fast and acquire users more quickly than its competition. My first job was at a startup. We intentionally took on tech debt because a) what we were doing was risky, b) we had a tight deadline to meet or the company would run out of money - no point in writing perfect code if it wasn't going to be ever released. Our tech debt wasn't the opposite of over-engineering. It was an intentional compromise to get the product out of the door on time. We understood that we'd have to pay the debt off or it will make it difficult to maintain and grow the system in the future. Tech Debt is Demoralizing for Software Developers The problem starts when companies forget to pay off the debt and let it creep and pile up for an extended period. The past comes to haunt the present. For good software developers, it is totally demoralizing to work on products that have high tech debt. This aspect isn't often talked about, but its effects are very real. Simple things like changing a title tag of a webpage page take up a whole day because the logi ## GraphQL - A Practical Overview and Hands-On Tutorial DevFeed: [GraphQL - A Practical Overview and Hands-On Tutorial]() Original publisher: [Read original article]() Author: umer Published: 2019-10-13T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [GraphQL](), [API](), [REST API](), [Tutorial](), [data]() Tags: [api](), [apis](), [article](), [data](), [graphql](), [rest](), [rest-api](), [tutorial]() ### AI overview A hands-on introduction to GraphQL, explaining how it lets clients query a single API endpoint for precisely the data they need. The article contrasts this approach with the rigidity and over-fetching risks of traditional REST APIs and uses practical examples for beginners. ### Source excerpt GraphQL is a Query Language for APIs. It provides a fresh and modern approach to fetching (and manipulating) data from APIs when compared to traditional methods such as REST. Its power comes from the ability to let clients talk to a single endpoint and specify precisely what data they need. That's very powerful indeed. This blog post is a hands-on introduction to GraphQL and its important features. When I first encountered GraphQL (we're switching public REST APIs to GraphQL,) coming from REST background, I was baffled. 'Where's the list of API end-points?', 'Is the list of fields documented somewhere?' So I decided to write this article not as a comprehensive overview that deep-dives into internals, but rather to give an understanding of what GraphQL is and how to use it using real examples. It assumes no previous knowledge of GraphQL. Let's get started. GraphQL - An Overview GraphQL - or more specifically - the data query language specification and the runtime for it - was developed by Facebook. It was opened sourced it in 2015, after a few years of internal use at Facebook. What inspired the need for GraphQL? Here's an excerpt from the Facebook engineering blog: As we transitioned to natively implemented models and views, we found ourselves for the first time needing an API data version of News Feed -- which up until that point had only been delivered as HTML. We evaluated our options for delivering News Feed data to our mobile apps, including RESTful server resources ... We were frustrated with the differences between the data we wanted to use in our apps and the server queries they required. Once you build and expose a REST API, it's pretty rigid. For example, suppose we have built a News Feed RESTful API which is returning 10 attributes for each item in the news feed. Down the road, you are building a mobile app for low-tier devices that don't have the screen real-estate to show the news feed in all its glory. So instead of showing all 10 attributes for each news ## How Docker Works? Under the Hood Look at How Containers Work on Linux DevFeed: [How Docker Works? Under the Hood Look at How Containers Work on Linux]() Original publisher: [Read original article]() Author: umer Published: 2019-04-12T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [Docker](), [Containers](), [Linux](), [Node.js](), [Processes](), [virtual machines]() Tags: [containers](), [docker](), [linux](), [node-js](), [processes](), [virtual-machines]() ### AI overview This tutorial explains how Docker uses containerization on Linux to isolate processes and provide applications with customized views of operating-system resources. It contrasts containers with virtual machines, which require separate guest operating systems, and uses applications with different Node.js version requirements as an example. ### Source excerpt Docker is awesome. It enables software developers to package, ship and run their applications anywhere without having to worry about setup or dependencies. Combined with Kubernetes, it becomes even more powerful for streamlining cluster deployments and management. I digress. Back to Docker. Docker is loved by software developers and its adoption rate has been remarkable. In this post, we'll look at how Docker works under the hood. Docker uses a technology called "Containerization" to do its magic and that's what we are going to explore next. Why Do We Need Containers? Let's say you want to run a software Foo on your computer. Foo requires Node.js version 10 (assume Foo is incompatible with newer Node.js versions), so you install Node 10 on your machine. Later, you want to run another software, Bar, which requires Node.js version 15. This has created a problem. (Assume we can't use nvm to switch between Node versions easily.) One way we could solve this problem is by using Virtual Machines or VMs to create isolated environments for running Foo and Bar. You can create one VM with Foo and Node 10 and another with Bar and Node 15. Voila, we are back in business. However, there's an issue with this approach: it's very inefficient. Each VM requires its own operating system. We are now running two separate guest operating systems on our computer just to run two different processes. What if there was a way to run Foo and Bar and your machine without running two extra operating systems? Let's review the interaction between processes and operating system. Whenever a process wants to do anything, it asks the operating system. Processes like Foo and Bar would ask the OS questions like, "which Node version do you have installed?" or "how much memory is available to me?" or "what other processes are running?" What if we could intercept and control the communication between processes and operating systems and send customized responses to processes to control their behavior? For ex ## Avoiding Overengineering: Choose Architecture and Databases for the Job DevFeed: [Avoiding Overengineering: Choose Architecture and Databases for the Job]() Original publisher: [Read original article]() Author: umer Published: 2017-08-19T00:00:00Z Content type: opinion Language: en Sources: [Code Ahoy - Articles]() Topics: [Databases](), [Architecture & Design](), [MySQL](), [NoSQL](), [Microservice](), [Apache Cassandra]() Tags: [architecture](), [cassandra](), [databases](), [microservices-architecture](), [mysql](), [nosql]() ### AI overview The author reflects on choosing technologies based on actual needs rather than hype. They describe replacing a monolith and MySQL with service-oriented architecture and Cassandra, concluding that the resulting system was too complex for a small startup team to maintain. ### Source excerpt It was April. Year was probably was 2010. The cold, snowy winter was finally coming to an end and the spring was almost in the air. I was preparing for my final exams. The review lectures were going on for the RDBMS course that I was enrolled in at my university. Around the same time, I had started hearing and reading about the shiny, new technology that was going to change the way we use databases. The NoSQL movement was gaining momentum. I was reading blogs about how MongoDB is big time outperforming ancient, non web scale relational databases. After the lecture, I asked my professor: Me: So, between RDBMS and NoSQL databases, which one do you think is the best? Professor: Well, it depends. Me: Depends on what? Professor: Depends on what you are trying to achieve. Both have their pros and cons. You pick the right tool for the job. Me: But MySQL can't really scale. Professor: How do you think we got this far? Send me an email and I'll send you some papers and practical uses in the industry. SQL was hard for my brain, especially the joins. I loved NoSQL. Simple key->value model without any joins! RDBMS systems that were designed in 1960's were simply not enough to keep up with modern demands. I had lost all interest in RDBMS and predicted they'll just fade off in the next few years. It's 2012. We're redesigning my employer's flagship product. The first version was a monolith that used the boring MySQL. Spending too much time reading blogs and Hacker News comments section, we convinced ourselves that we need to go big and modern: Break monolith into service-oriented architecture, aka, the SOA. Replace MySQL with Cassandra (MySQL to Redis to Cassandra) And we built it. There was nothing wrong with the new system... except one major flaw. It was too complex for a small startup team to maintain. We had built a Formula One race car, that makes frequent pit-stops and requires very specialized maintenance, when we needed a Toyota Corolla that goes on for years and years on j ## Caching Strategies and How to Choose the Right One DevFeed: [Caching Strategies and How to Choose the Right One]() Original publisher: [Read original article]() Author: umer Published: 2017-08-11T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [Caching](), [Cache](), [Databases](), [Redis](), [systems]() Tags: [cache](), [caching](), [caching-strategies](), [database](), [how-to](), [performance](), [redis](), [strategy](), [systems]() ### AI overview This tutorial explains how caching strategies should be chosen based on data access patterns, including write frequency, read frequency, and whether returned data is unique. It describes cache-aside caching, including cache hits, cache misses, database fallback, and the use of Redis and Memcached. ### Source excerpt 👉 Read First: A Brief Overview of Caching Caching is one of the easiest ways to increase system performance. Databases can be slow (yes even the NoSQL ones) and as you already know, speed is the name of the game. If done right, caches can reduce response times, decrease load on database, and save costs. There are several strategies and choosing the right one can make a big difference. Your caching strategy depends on the data and data access patterns. In other words, how the data is written and read. For example: is the system write heavy and reads less frequently? (e.g. time based logs) is data written once and read multiple times? (e.g. User Profile) is data returned always unique? (e.g. search queries) A caching strategy for Top-10 leaderboard system for mobile games will be very different than a service which aggregates and returns user profiles. Choosing the right caching strategy is the key to improving performance. Let's take a quick look at various caching strategies. Cache-Aside This is perhaps the most commonly used caching approach, at least in the projects that I worked on. The cache sits on the side and the application directly talks to both the cache and the database. There is no connection between the cache and the primary database. All operations to cache and the database are handled by the application. This is shown in the figure below. Here's what's happening: The application first checks the cache. If the data is found in cache, we've cache hit. The data is read and returned to the client. If the data is not found in cache, we've cache miss. The application has to do some extra work. It queries the database to read the data, returns it to the client and stores the data in cache so the subsequent reads for the same data results in a cache hit. Use Cases, Pros and Cons Cache-aside caches are usually general purpose and work best for read-heavy workloads. Memcached and Redis are widely used. Systems using cache-aside are resilient to cache failures. ## Basics of Java Garbage Collection DevFeed: [Basics of Java Garbage Collection]() Original publisher: [Read original article]() Author: umer Published: 2017-08-06T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [Java](), [Algorithms](), [Concurrency](), [real-time]() Tags: [garbage-collection](), [garbage-collectors](), [gc](), [hotspot](), [java](), [jvm](), [latency](), [low-latency](), [memory](), [performance](), [real-time](), [threads](), [troubleshooting]() ### AI overview This tutorial provides a high-level overview of Java garbage collection, including collector algorithms, stop-the-world pauses, throughput and low-latency tradeoffs, JVM heap generations, and troubleshooting performance issues. ### Source excerpt Knock, knock. Who's there? ...long GC pause... Java. It's an old joke from the time when Java was new and slow compared to other languages. Over time, Java became a lot faster. Today it powers many real-time applications with hundreds of thousands of concurrent users. These days, the biggest impact on Java's performance comes from its garbage collection. Fortunately, in many cases, it can be tweaked and optimized to improve performance. For most applications, the default settings of the JVM work fine. But when you start noticing performance issues caused by garbage collection and giving more heap memory isn't possible, you need to tune and optimize the garbage collection. For most developers, it's a chore. It requires patience, good knowledge of how garbage collection works and an understanding of application's behavior. This post is a high-level overview of Java's garbage collection with some examples of troubleshooting performance issues. Let's get started. Java ships with several garbage collectors. More specifically, these are different algorithms that run in their own threads. Each works differently and has pros and cons. The most important thing to keep in mind is that all garbage collectors stop the world. That is, your application is put on hold or paused, as the garbage is collected and taken out. The main difference among the algorithms is how they stop the world. Some algorithms sit completely idle until the garbage collection is absolutely needed and then pause your application for a long period while others do most of their work concurrently with your application and thus need a shorter pause during stop the world phase. The best algorithm depends on your goals: are your optimizing for throughput where long pauses every now and then are tolerable or you are optimizing for low latency by spreading it out and having short pauses all along. To enhance the garbage collection process, Java (HotSpot JVM, more accurately) divides up the heap memory into two genera ## Message Batching to Increase Throughput and Reduce Costs DevFeed: [Message Batching to Increase Throughput and Reduce Costs]() Original publisher: [Read original article]() Author: umer Published: 2017-08-03T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [Amazon Simple Queue Service (SQS)](), [Back end](), [Amazon Web Services](), [Latency](), [Concurrency]() Tags: [advice](), [amazon-sqs](), [asynchronous](), [aws](), [backend](), [batching](), [best-practices](), [concurrent](), [latency](), [performance](), [queue](), [services]() ### AI overview The article describes using batching and buffering with Amazon SQS to group messages before sending them. In the author's system, batches of up to 15 messages or 50 milliseconds increased throughput, reduced SQS costs, and had little effect on latency, while retries can mitigate message loss after a crash. ### Source excerpt A while ago, I was working on a backend system on the AWS cloud. Individual services in the system communicated by exchanging asynchronous messages with each other using Amazon SQS. During early stages of development, we ran small load tests and found that CPU use was high and we would need more servers to handle the load. (Estimated peak load was 50,000 requests per second.) Services were generating lots of small messages every second and the profiler showed that threads responsible for handling and sending messages to SQS, one message at a time, were using CPU more than they should. This was affecting performance and throughput. To overcome this challenge, we took a page from Amazon's best practices advice, and introduced batching and buffering on senders to group multiple messages and send as one batch. This simple fix increased the throughput, cut down SQS costs (SQS pricing is by number of messages), and had very little impact on latency. Win, win, win. The custom batching algorithm was simple: batch up to 15 messages or wait up to a maximum of 50 milliseconds. If either 15 messages arrive quickly to form a batch or 50 milliseconds elapse, the batch is sent out. These figures (batch size and maximum time) were established after trial and error, tuned for the best throughput and latency. The application was multi-threaded with hundreds of active threads, so the system allowed multiple concurrent batches to be active at the same time to reduce thread blocking. The only downside is that if the application crashes after retrieving batch from the queue but before processing messages in it, we can lose some or all of the messages. To deal with complete message loss, the system can implement retries and resend messages upon timeout. Clients will see 2x response times, but at least get their response back. If you are building applications which generate and exchange a lot of messages in short periods, batching can increase throughput, performance and in the case of SQS ## Amazon DynamoDB Auto Scaling DevFeed: [Amazon DynamoDB Auto Scaling]() Original publisher: [Read original article]() Author: umer Published: 2017-07-29T00:00:00Z Content type: article Language: en Sources: [Code Ahoy - Articles]() Topics: [DynamoDB](), [amazon](), [Provisioning](), [Availability]() Tags: [amazon](), [amazon-dynamodb](), [availability](), [dynamodb](), [high-availability](), [pricing](), [provisioning]() ### AI overview The article explains how Amazon DynamoDB Auto Scaling adjusts provisioned read and write capacity for tables and global secondary indexes in response to traffic. It contrasts automatic scaling with fixed provisioning, describing how scaling can help address throttling during demand spikes and reduce payment for unused capacity during lower traffic. ### Source excerpt Amazon DynamoDB supports Auto Scaling which is a fantastic feature. When enabled, Auto Scaling adjusts read and write capacities of DynamoDB tables (and global secondary indexes) automatically based on the demand. If you haven't used DynamoDB before, you might be wondering why is this important? Before Auto Scaling, the users were required to provide fixed capacities for their tables. These capacities were static and didn't respond to traffic demands. This was problematic because: The application performance and high-availability was compromised whenever the utilization exceeded the provisioned throughput. When this happened, DynamoDB throttled requests, which resulted in loss of data or poor user experience. Cost control was poor at best. DynamoDB charges you by how much you provision. You end up paying the full cost by provisioned amounts, even if you use less than what you provisioned. In other words, if you overprovision for peak load, you'll pay extra during the non-peak hours, when the capacity isn't being full utilized. On the other hand, if you underprovision, the performance of your application will suffer due to throttling when the load exceeds the provisioned capacity. Many real-world use cases are difficult to predict in advance and fluctuations are common. Speaking of traffic fluctuations, they are prevalent and hard to deal with. In mobile gaming, the traffic can increase suddenly if Apple or Google features the game, or the publisher runs a massive ad campaign. A website can suddenly see a large number of visitors if an article is picked up by a major newspaper or news aggregator site. What is DynamoDB Auto Scaling? Historical Perspective Auto Scale Target Utilization DynamoDB Auto Scaling Pricing DynamoDB Auto Scaling vs On Demand When to use Auto Scaling vs On Demand? DynamoDB and DAX What is DynamoDB Auto Scaling? DynamoDB Auto Scaling feature lets you automatically manage throughput in response to your traffic patterns without throttling your user ## AI Is Not Magic. How Neural Networks Learn DevFeed: [AI Is Not Magic. How Neural Networks Learn]() Original publisher: [Read original article]() Author: umer Published: 2017-07-28T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [Neural Network](), [Algorithm](), [App](), [Image]() Tags: [algorithm](), [app](), [images](), [neural-networks]() ### AI overview A high-level tutorial explains how neural networks learn to recognize images. Using a hypothetical hot-dog classifier, it introduces labeled training data, artificial neurons, weights, biases, and the role of layered neurons in image recognition. ### Source excerpt In my previous blog post, I claimed that "AI is not magic." In this post, my goal is to discuss how neural networks learn, and show that AI isn't a crystal ball or magic, just science and some very slick mathematics. I'll keep this very high level. Let's start with a hypothetical scenario. Suppose we are building an app to identify hot dogs. Take a picture and the app will tell you if it's a hotdog or not. Total App Store domination. To recognize images, we choose to implement a popular machine learning algorithm called the neural network. (In this hypothetical scenario) This decision was made after reading an online article which talked about how neural networks can learn to recognize objects by training on lots of labelled examples. Once trained, it can start identifying images it has never seen before. We go ahead and obtain a training set of 6000 images gathered from online sources. 1000 images of different types of hotdogs: New York vs Chicago, ketchup, no ketchup, hotdogs on a grill, etc. The other 5000 images are of various non-hotdog objects: shoes, hamburgers, burrito, human legs. Now all that remains is to build our neural network. To understand neural networks, we must first understand its elementary building block: the artificial neuron. An artificial neuron takes one ore more inputs and produces a single output. Looks familiar? It looks a lot like logic gates, which are elementary building blocks of digital circuits. The similarity ends there. Unlike logic gates, neurons can have several inputs and can change output for the same input values. This is possible because neurons have weights associated with each input, which is multiplied with the input value. These weights allow neurons to rate how important each input is. E.g. if the second input to a neuron isn't very important, neuron can assign it a weight close to 0 essentially cancelling it out. Neurons also have biases which controls how easy it is to get neuron to output or fire. If the bias is hug ## Tweaking TCP for Real-time Applications: Nagle's Algorithm and Delayed Acknowledgment DevFeed: [Tweaking TCP for Real-time Applications: Nagle's Algorithm and Delayed Acknowledgment]() Original publisher: [Read original article]() Author: umer Published: 2017-03-19T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [TCP/IP](), [real-time](), [Protocol (disambiguation)](), [Algorithm]() Tags: [algorithm](), [data-transmission](), [protocol](), [real-time](), [tcp-ip]() ### AI overview This tutorial explains how TCP buffering techniques affect real-time applications that send small messages. It focuses on Nagle's algorithm, which combines small messages to reduce packet overhead, and introduces TCP delayed acknowledgment. The article notes that Nagle's algorithm can create performance issues for multiplayer gaming servers. ### Source excerpt TCP is a complex protocol. Don't get me wrong. It is a marvelous piece of engineering that gives us the reliable data transmission guarantee that other protocols don't provide. Reliable data transmission between two devices on the internet is no walk in the park and TCP uses a lot of magic under the hood to make things happen. Generally, it does a fine job of abstracting away low level details and its default settings work fine for most general purpose use cases. However, once in a while, things don't go according to plan and we need to pop open the hood and do some tweaking. It is in these situations, that some knowledge of TCP comes in very handy. By default, TCP uses two buffering techniques to optimize and minimize overhead for general purpose applications. However, if you are building applications that require real-time message delivery for small messages (e.g. chat or control messages), you must have some knowledge of these techniques. Nagle's algorithm TCP delayed acknowledgment Let's look at them in more detail. Nagle's Algorithm If there's no congestion, TCP tacks on a header and sends data out as soon as it gets it from the application. If the application is generating a lot of small messages, the headers can add a lot of overhead: TCP/IP headers are 40-byte, so 1-byte of data is sent as 41-byte packet on the network. A computer programmer named John Nagle came up with an algorithm to reduce the overhead by combining many small messages into a single message. Nagle's algorithm, named after its inventor, is a technique to make TCP more efficient by reducing the number of packets that are sent over the network. Here's the pseudo code for the algorithm: if there is new data to send if the window size >= MaximumSegmentSize and available data is >= MaximumSegmentSize send complete MaximumSegmentSize segment now else if there is unconfirmed data still in the pipe enqueue data in the buffer until an acknowledge is received else send data immediately end if end if ## Cluster Analysis Using K-means Explained DevFeed: [Cluster Analysis Using K-means Explained]() Original publisher: [Read original article]() Author: umer Published: 2017-02-19T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [data](), [Machine learning](), [Algorithm](), [datasets]() Tags: [algorithm](), [blog-post](), [clustering](), [data](), [dataset](), [machine-learning]() ### AI overview This tutorial explains clustering and k-means, including how k-means assigns data points to clusters, updates cluster centroids, and repeats the process to minimize the total distance within clusters. It also discusses applications and the importance of choosing a clustering method based on requirements and the dataset. ### Source excerpt Clustering or cluster analysis is the process of dividing data into groups (clusters) in such a way that objects in the same cluster are more similar to each other than those in other clusters. It is used in data mining, machine learning, pattern recognition, data compression and in many other fields. In machine learning, it is often a starting point. In a machine learning application I built couple of years ago, we used clustering to divide six million prepaid subscribers into five clusters and then built a model for each cluster using linear regression. The goal of the application was to predict future recharges by subscribers so operators can make intelligent decisions like whether to grant or deny emergency credit. Another (trivial) application of clustering is for dividing customers into groups based on spending habits or brand loyalty for further analysis or to determine the best promotional strategy. There are various models and techniques for cluster analysis. When I first started, I was mistakenly searching for 'the best clustering model or technique.' I wasn't aware that there is no universal best algorithm and the choice depends on your requirements and the dataset. There are density-based, graph based or centroid based clustering models. We finally settled on a clustering technique called k-means. This blog post is a brain-dump of everything I've learned about clustering and k-means so far. K-means K-means is a very simple and widely used clustering technique. It divides a dataset into 'k' clusters. The 'k' must be supplied by the users, hence the name k-means. It is general purpose and the algorithm is straight-forward: We call the process k-means clustering because we assume that there are k clusters, and each cluster is defined by its center point -- its mean. To find these clusters, we use Lloyd's Algorithm: we start out with k random centroids. A centroid is simply a datapoint around which we form a cluster. For each centroid, we find the datapoints ## Certificate Authorities - Do You Know Who You Trust? DevFeed: [Certificate Authorities - Do You Know Who You Trust?]() Original publisher: [Read original article]() Author: umer Published: 2017-02-18T00:00:00Z Content type: article Language: en Sources: [Code Ahoy - Articles]() Topics: [TLS (Transport Layer Security)](), [Security](), [HTTP](), [browsers](), [Vulnerabilities](), [Microsoft]() Tags: [breach](), [browsers](), [certificates](), [http](), [microsoft](), [passwords](), [private-key](), [security](), [tls](), [trust](), [vulnerabilities](), [wifi]() ### AI overview This article explains how certificate authorities and root certificates affect trust in HTTPS and TLS. It examines Lenovo's Superfish adware incident, in which a shared private key exposed encrypted user communications, and discusses certificate misissuance involving Google domains. ### Source excerpt HTTPS (aka HTTP over the secure TLS protocol) provide a secure communication channel between web browsers and servers to guard against man-in-the-middle attacks. Although researchers have identified and reported a few vulnerabilities, TLS is still the best option out there and all websites should be using it. Arguably, the most famous TLS fiasco was not a vulnerability but an enormously miscalculated and incompetent attempt to increase ad revenues by a top selling laptop manufacturer. "Lenovo incident / scandal" got its start when Lenovo thought it would be a brilliant idea to pre-install an adware (Superfish) on their laptops to inject ads on webpages, both encrypted and non-encrypted. To allow Superfish to view and alter encrypted traffic, they pre-loaded its self-signed, root certificate on their laptops. By doing this, Lenovo let Superfish become man-in-the-middle and allowed it to view and alter traffic without the user ever knowing. If that was the end of the story, it might not have been all that terrible. However, by installing the self-signed root certificate, which used the same private key on all laptops, Lenovo exposed sensitive and confidential communication of their users to attackers or eavesdroppers connected to the same WiFi. Communication including emails, bank transactions, messages, and passwords were all exposed. After users complained and there was public outcry, Lenovo finally acknowledged that it "messed up" and apologized to users for betraying their trust. It quickly dumped Superfish. Microsoft stepped in and provided an update of Windows Defender to remove Superfish. As someone who purchased a Y50 around the same time (2014), I'm happy to report that Superfish is dead. (So long, and no-thanks for the fish.) It is not always the incompetence of laptop vendors - user trust has been violated intentionally for malicious purposes as well: a Chinese certificate authority issued valid security certificates for a number of domains, including Googl ## Testers Make Software Teams Highly Productive DevFeed: [Testers Make Software Teams Highly Productive]() Original publisher: [Read original article]() Author: umer Published: 2017-02-17T00:00:00Z Content type: opinion Language: en Sources: [Code Ahoy - Articles]() Topics: [Testing](), [bug](), [DevOps](), [Exception](), [Software](), [API](), [Database](), [payload](), [Network](), [XML]() Tags: [api](), [app](), [automated](), [bug](), [database](), [developer](), [devops](), [exception](), [exceptions](), [payload](), [quality-assurance](), [software](), [testing](), [xml]() ### AI overview This opinion argues that skilled testers and quality assurance engineers can make software teams more effective by finding bugs, identifying root causes, and suggesting improvements that developers or automated tests may miss. It uses examples involving API timeouts, database initialization, exceptions, XML payloads, and input validation. ### Source excerpt To put it mildly, developers are not great at testing their own products. Bias, pride, wrong assumptions, lack of time, switching contexts, all play a role in making developers ineffective at testing their code. Most companies, especially startups, don't fully understand the role of a tester. Very early on in my career, we made the mistake of hiring people to be testers who applied for a software developer position but weren't good enough programmers. We paid for it in terms of software quality and over-worked team. It wasn't until I worked with some great testers that I realized how effective and productive software teams become when they have great testers on board. The best testers or quality assurance engineers I've ever worked with weren't developers. One was a DevOps guy and the other was a Network Engineer. They became testers coincidentally because they were very smart and tremendously effective at finding bugs, even when they tested the system as a black-box. They treated the whole exercise like puzzle solving. Here's an example bug report from them: "Found an issue with API to retrieve all widgets right after registering as a new user. Requests kept timing out. Upon digging further, I discovered that the system is throwing NullPointerExceptions. This is happens because the xyz counter in the database wasn't properly initialized in the previous step. Initialize the counter in the previous step and also catch all un-handled exceptions and return an error to the user." Or this one. "Found an issue. The system throws exception when the user selects option 5. I checked the logs and found nothing. I ran wireshark to look at the request and response and found the issue to be caused by developers sending a unicode character in the request. Don't send unicode characters and log error reasons which is field_10 in the XML payload." These bug reports not only clearly identified the issue, but also the root cause and suggested a better course of action, thus refining t ## What Is Yak Shaving? Advice for Software Developers on Staying Focused DevFeed: [What Is Yak Shaving? Advice for Software Developers on Staying Focused]() Original publisher: [Read original article]() Author: umer Published: 2017-02-13T00:00:00Z Content type: opinion Language: en Sources: [Code Ahoy - Articles]() Topics: [Development](), [Software Engineering]() Tags: [advice](), [developers](), [software](), [software-developer](), [software-development]() ### AI overview The article explains "yak shaving," a chain of distracting prerequisite tasks that pulls developers away from their original goal. Using a fictional software-development example, it advises finishing the initial task, then separately evaluating and prioritizing related improvements such as upgrading Hibernate. ### Source excerpt Yak shaving is defined as: what you are doing when you're doing some stupid, fiddly little task that bears no obvious relationship to what you're supposed to be working on, but yet a chain of twelve causal relations links what you're doing to the original meta-task. Fun-fact about the origin of the term 'yak shaving': The term was coined at the MIT AI Lab in the 90s. Its scientists got inspiration from an episode of the Ren and Stimpy show called "Yak Shaving Day". A picture is worth a thousand words. A video, perhaps billions. A well-known sitcom scene captures it perfectly: a man sets out to change a lightbulb, and one prerequisite errand leads to another until he is doing something entirely unrelated. To understand it more clearly, suppose you are required to perform a task. We'll call it task A. As you start working on task A, it leads you to another task, e.g. task B. Task B leads you to Task C, and so on. Before you know it, you are working on Task Z, completely distracted from your original goal of completing task A. Here's an example dialog in the world of software development. Manager: "Did you fix the issue where we had to update the column name in our code because someone changed it in the DB? " Software Developer: "Ah, not yet. I'm still working on it." Manager: "What happened? It was a one-line change." Software Developer: "As I looked into the code, I realized we were using a really old version of Hibernate. I tried to upgrade it but there were some breaking changes in the new version. They recommended switching to the Repository pattern so I refactored a few classes but now the DB is throwing errors. I'm debugging." In this fictional scenario, the developer 'went down a rabbit hole,' which had nothing to do with the original task of changing the column name in code. The key is staying focused and not letting distractions pull you away from the main goal. Assuming the developer was right that the code needed to be upgraded, he mixed the two unrelated t [Next page]()