Forem: Bala K

The Cursor Effect: How GitHub Copilot is Responding to Peer Pressure

Bala K — Sat, 19 Apr 2025 04:08:10 +0000

Intent

The AI Coding Assistant arena is heating up. In recent months, excitement around Cursor IDE has sparked curiosity among developers. Rightfully so—Cursor’s entry into the IDE space with a deeply integrated AI experience turned heads. It hasn’t just plugged in AI; it’s trying to reshape the entire development experience around it, from agentic workflows to seamless chat-first coding.

Naturally, this raises a question for me: Is GitHub Copilot keeping up?

Before we think about shifting direction or adopting a Multi-IDE working model, we need a shared understanding of what’s already available to us—especially within the latest VS Code + Copilot ecosystem. Otherwise, we risk comparing tools unfairly, based on outdated versions or impressions shaped by trend cycles rather than facts. It's crucial that we evaluate them fairly—not against past memories, but against their most current, full-featured releases.

Let’s take a step back and look at what GitHub Copilot now brings to the table—especially the capabilities rolled out in recent months that may go unnoticed if your IDE isn’t up to date.

Along the way, in this post, I will briefly unpack some of the recent concepts shaping AI-assisted development workflows—like Modes of working with Code AI, Next Edit Suggestions (NES), Model Selection, and AI Rules.

This post is about clarity—not conclusions.

Model Awareness & Flexibility

In the past, GitHub Copilot was synonymous with “the OpenAI model behind the curtain.” But that’s no longer the case. Copilot has evolved into a model-flexible platform, supporting a wide range of top-tier models—empowering developers to tailor their experience based on speed, reasoning depth, task complexity, or preference.

🧩 Multi-Model Support

Copilot now gives you the flexibility to choose, switch, and experiment with models—especially useful when balancing latency, reasoning depth, or creative freedom. This shift is critical: just as developers choose libraries or frameworks, selecting the right model for the task is now part of the modern development flow.

Feel free to experiment with different models for various use cases—and share your observations as a post in our dev blog space!

Each model is known for certain strengths:

OpenAI GPT-4.1 (OpenAI)[April 14, 2025] – Great at instruction following, frontend development, and long-context reasoning
OpenAI GPT-4.5 (OpenAI) – Latest Copilot model (Apr ’25), tuned for enterprise use
OpenAI o3-mini (OpenAI) [April 16, 2025] – Low-latency, fast reasoning for rapid iteration loops
OpenAI o1 models (OpenAI) – Early GPT-4 family models with fallback support
Claude 3.7 Sonnet (Anthropic)[April 16, 2025] – Strong in structured code reasoning, SWE-bench performance, and agentic flows
Claude 3.5 Sonnet (Anthropic) – Reliable for day-to-day coding support and quick iterations
Google Gemini 2.5 Pro (Google)[April 16, 2025] – Excels in deep reasoning across code, math, and science (Apr ’25)
Gemini 2.0 Flash (Google) – Fast and multimodal, ideal for lightweight tasks and conversational coding

Cursor’s perspective on Models: Cursor started strong with default high-quality models (GPT-4, Claude) built-in, focused on experience over configuration. While model selection was not always visible, recent updates now allow model switching. Small nitpick—model switching requires resetting the conversation, unlike Copilot’s in-chat model toggle.

Copilot gives you granular control per session—ideal for experimenting with speed vs depth vs creativity. Cursor simplifies the experience with optimized defaults. Both are converging toward flexible model fluency.

When I first tried Cursor and Copilot, this was before enabling the new models in Copilot. The response styles were noticeably different—not just in tone but also in how they reasoned through problems. Now, when I switch to Claude in Copilot, I can feel the difference. The responses are more thoughtful and structured, and it’s clear: the model you choose affects the outcome.

With more model options available in Copilot, it’s finally possible to do an apples-to-apples comparison. It also made me realize that some past comparisons were closer to apples vs. oranges—comparing tools without matching the models beneath them.

Let’s now turn our attention to another hot topic in the Cursor world—Agent Mode.

Modes of Working with Code AI

As AI assistants mature, it’s no longer just about inline completions or answering a question in chat. The real leap is in how we collaborate with AI across different phases of the coding workflow—whether you’re asking a question, refactoring code, or letting an agent handle multi-step tasks.

Both Cursor and Copilot recognize this shift.

While Cursor had a head start, GitHub Copilot has rapidly caught up by releasing new capabilities—and in some areas, I’ve noticed Cursor’s also getting influenced.

Cursor’s tab-based workflows set the bar early, but Copilot now matches it with an elegant, integrated UX. Interestingly, Cursor has since updated its interface to align more closely with Copilot’s mode-based structure—a sign of mutual influence and convergence.

If you walk through the features chronologically (I skimmed through the release logs for both), you’ll notice it’s not just Copilot learning from Cursor—it’s Cursor learning from Copilot too. They’re clearly watching each other closely, and what we’re witnessing is a convergence in the capability SKUs across both tools.

🤖 Agent Mode

Copilot’s Agent Mode was introduced as experimental in response to Cursor autonomy workflow and **is now generally available in **VS Code Stable. It enables multi-step, semi-autonomous workflows, including:

Editing files across the workspace
Running terminal commands with user approval (My guess is it follows a human-in-the-loop principle when executing commands autonomously—mainly from a security standpoint)
Fetching and inserting web content with #fetch
GitHub MCP Server support
Available Context for Agent in GitHub Copilot got increased dramatically in last two months (see the screenshot below)
Switch modes mid-conversation (Ask → Edit → Agent) without losing context

The available context list is growing on both sides—as each learns from the other.

✏️ Edit Mode

Targeted edits across one or more files—Edit Mode lets you describe a change (e.g., “Convert this to use async/await”), and Copilot will propose updates in diff format, complete with undo, keep, or refine controls. Known as the Copilot Editor, it’s optimized for structured code transformation.

Describe a change in plain English
See proposed edits across one or multiple files
Accept or undo changes granularly with the updated diff UX
Supports notebooks, comments, and image context

Recent updates:

Unified editing experience inside the chat panel (March ’25)
Edit Mode support extended to JetBrains IDEs (March ’25)
Multi-file preview for edits (Feb ’25)
Image context for vision models (Feb–Mar ’25)

Cursor introduced intuitive multi-file edits early on. Copilot now delivers that—and expands it across both VS Code and JetBrains IDEs.

If I had to nitpick on Copilot, Cursor’s refactor revert UX is more flexible: it treats refactors as checkpoints you can roll forward and backward. In Copilot, you can undo changes, but there’s no native “revert the revert” capability just yet.

🔍 Ask Mode

Designed for exploration, explanation, and problem-solving. In Ask Mode, you can:

Query your codebase (e.g., “Where is this class used?”)
Get explanations or quick-start snippets
Explore unfamiliar repos with help from chat participants like @workspace or #codebase

Recent enhancements include (GitHub Copilot):

GitHub URL pasting as context — GitHub issues, discussions, and PRs [April 9, 2025]
Instant semantic indexing of the currently working repo (March ’25)

Cursor’s has various ways to build context for question - one of them is linking to Git PRs, Commits; GitHub copilot’s URL pasting context can help achieve the similar behaviour.

All three modes—Ask, Edit, and Agent—now live in a unified Chat view in VS Code (starting v1.99 - April 4, 2025), allowing you to switch fluidly without losing context.

(I’ll park the discussion on the quality of these capabilities for another time, we will expreiment more to judge the quality)

Other Mentions

Some features in Copilot may not make the headlines but are quietly reshaping how we work with code. Here are a few worth highlighting:

Next Edit Suggestions (NES)

Copilot’s NES predicts the next edit you're likely to make and suggests it proactively—right where it matters in the code.

Shows edit suggestions inline, with contextual cues
Now generally available with collapsed view and keyboard navigation
Designed for low-friction productivity during focused work sessions

NES is trying to bring Cursor’s equivalent predictive editing experience.

AI Rules (Personalization Layer)

With .github/copilot-instructions.md and prompt files (*.prompt.md), you can:

Define team-wide or project-specific guidance
Customize response behavior, code style, and structure
Scope prompts by file type, pattern, or directory

Cursor introduced a similar feature much earlier via .cursor/rules, allowing project-wide instructions. Copilot is not trying to match this with GitHub-native configurations.

Final Word: The Gap Is Closing

This isn’t just a feature race—it’s a shift in how we build software.

Cursor showed industry what’s possible. Copilot has responded with recent rollouts - multi-models, agentic workflows, flexible context, and seamless IDE integration.

The development experience in VS Code can now be shaped around these capabilities, offering countless combinations to build effective and adaptive developer workflows.

Now that we have a clearer view of what’s available, we can begin experimenting—shaping our daily developer workflows and development phases to better reflect how we actually code, debug, and ship.

As I mentioned earlier, the intent of this post is to bring clarity on what Copilot is capable of today—not to decide which tool is better, or which one might win tomorrow. No sides. No hype.

I’m deliberately parking the discussion on the quality of these capabilities for another time. We will explore case by case. For now, I hope this post helps set a strong, objective starting point—a grounded view to help you make informed comparisons and decisions.

**P.S.* Keep your IDE updated regularly to stay in sync with the rapid pace at which new capabilities and features are being rolled out.*

Power of Emergent Behaviour in a Complex System

Bala K — Sun, 25 Jul 2021 09:42:35 +0000

This blog is about understanding how we can tap into the potential of emergent behaviour in a Complex System and what we (IT Org) can learn from Ant Colony

The ultimate purpose of enterprise architecture is not to design systems; it is to help an enterprise reach specific business goals and solve the enterprise’s core problems, and the designing system is a part of it.

Ok…If designing a system is part of it, what else the EA is as a whole?

Before I try to answer that, let me give a tour of complex systems and the emergent behaviour.

Complex System

The common assumption is that one person can fully understand the complex interactions among all the elements that make up a modern enterprise. Though we wanted that to be true, we all know the reality.

In general, the first step in approaching or solving a problem is acknowledging that there is a problem and understanding what the problem is. The problem: even a reasonably large collection of systems interacts in ways that no one person can fully understand all details or accurately predict — there is a name for this system: “Complex System”.

Enterprise is a complex system; There are many studies and researches to characterize complex systems. One of the influential studies is ‘emergent behaviour’ in a complex adaptive system. Let’s briefly see what CAS is.

Complex Adaptive System (CAS)

“The complex adaptive system is a collection of independent entities where the individual elements each behave according to their own rules and interests, but when viewed as a whole, this collection of elements functions as a collaborative group whose behaviours benefit the entire group and rapidly adapt to changing environmental conditions as if they were centrally coordinated.”

Ok…I got it, I think…But, what are we saying again?

A simple example of a complex adaptive system is a flock of birds. Moving from one place to another, turning in midflight, climbing, and diving all appear to be under the control of one — No single flock leader is instructing every step here.

Are we saying, ‘we don’t need a leader ?’

No, that is not what it means; it means — Let me give another example to make the notion apparent in the context of emergent behaviour.

Emergent Behaviour

“Usually, the individual elements of a complex adaptive system are relatively simple and operate according to a set of similarly simple rules. But when these simple elements are combined into a system, the system exhibits complex behaviours that are not readily predictable by examining the behaviours of the individual pieces. The system as a whole is greater than the sum of its parts and behaves differently.”

This phenomenon is known as emergent behaviour and is one of the critical characteristics of a CAS.

Put more simply, emergent behaviours result from each element of a system pursuing its own interest. Tapping into emergent behaviour is a compelling way to strengthening an organization. We can use the insight developed from CAS system research to improve enterprise architecture practice.

Ant Colony & IT Org

An ant colony is an example of something scientists call a superorganism.

“A superorganism emerges when individuals of the same species become so highly specialized that they cannot survive without being part of a larger group composed of many individuals with complementary specializations.”

I know what you are thinking; Yes, the powerful IT organization sounds a lot like a superorganism.

The key attributes of the superorganism, “complementary specializations” and “moving towards a common goal”, are what makes an Organization powerful. What else can we learn from superorganisms? Let’s walk back to the ant colony.

The ant colony does many complex tasks, including forage for food, maintaining the nest, caring for eggs and young ants, fighting off predators, and many others tasks. For example, when one ant finds a food source, the ants will collectively find the shortest path to the source.

Here is how it happens; worker ants leave the colony each day to forage for food. They initially set out without a specific destination, and each wanders the area until it finds a food source. Several ants may find the same food source simultaneously from different routes, and each of the ants will return to the nest independently. On this return journey, the ant releases pheromones, a chemical trail that helps other ants find the source. Those ants that return most quickly will inspire more ants to follow their trail. Over time, the worker ants converge on the shortest routes, and the longer tracks are abandoned. Voilà!

Let’s dissect and understand what just happened here.

The goal of the ant colony is not just to find food. Instead, the colony’s goal is to maintain its health and propagate the species; finding food is just one of the tasks necessary to reach that goal. They have to be back in the nest sooner to protect the colony. This is one of the constraints that create the instinct to bring food back more quickly. It makes finding the shortest path as emergent behaviour.

Let’s Conclude (for now)…

The leaders/enterprise architects can focus on the following aspects to yield results through emergent behaviours; making the common goals apparent and help make the complex system move towards that through defining a development framework, process, guidelines, and constraints. Instead of focusing more on laying out very detailed instructions for doing everything, take advantage of the CAS system by recognizing the importance of the emergent behaviours that come from these systems. Everything about an enterprise architecture effort should contribute to reaching the enterprise’s goals; tasks that do not support the enterprise’s goals are a waste of resources.

In short, Building an efficient system requires both top-down (clear vision, goals, guidelines & constraints ) and bottom-up approaches (room for exploration, adaptiveness, autonomy on implementing low-level details).

Foot Note: Characteristics of CAS systems and their relevance to system design have been recognized for many years. This blog is a summary of my learning in this field of study. In part two of this article, I will expand more on what we concluded in this post. Stay tuned.

Multidimensional Scalability Model for Application

Bala K — Mon, 05 Jul 2021 05:50:20 +0000

This blog is about how to observe scaling problems in a multidimensional way. Scale cube is an influential and straightforward concept that can be a vehicle to focus on scalability-related discussions, approaches, and implementations. Let’s start by going over the different ways of scaling an application, including its benefits and drawbacks. In the end, I will use one of my applications as a case study to demonstrate these dimensions to draw a picture of how they fit in the real world.

Scale Cube

The cube model defines three ways to scale our applications: X, Y, and Z. Progress on each axis solve different scalability problems; to bring the right scalability balance for our application, we will move the needle to varying lengths on these three axes.

X-axis Scaling: Horizontal Duplication

Here the method of scaling is by cloning or replicating. It is one of the popular ways to scale an application. It involves running multiple application instances doing the same task. The load balancer distributes requests among the N identical instances of the application, and each instance works 1/N of the load.
The x-axis approach is easy to implement in most cases. You take the same code that existed in a single instance implementation and put it on as multiple instances. If your application is “stateless,” you simply load balance all of the inbound requests to any of the N systems. If your application is “stateful,” the implementation is slightly more complex. Making your application cluster-friendly is the demanded effort before cloning.
This approach is an excellent way of improving the capacity and availability of an application. On the downside, x-axis implementations are limited by the growth of a monolithic application, and they do not scale well with increases in data or application size. Further, they do not allow engineering teams to scale well, as the code base is monolithic, and it can become comparatively complex over time.

Y-axis Scaling: Functional Decomposition

Y-axis scaling splits your application into multiple services by the separation of work responsibility. Travelling in Y-axis is a journey towards a pure microservices architecture. The common challenge with the idea of microservices architecture is with the term micro. Instead of debating on “What should we define as the size of micro?”, it is better to see this scaling as a functional decomposition to give the application multiple deployable modules. Application complexity and business capability can help decide the modules.
Y-axis scaling has a blind spot. What I mean by this is, at a very high level, it is often possible to implement a y-axis split in production without actually breaking the codebase itself. However, a clean separation at the codebase is needed to get the most benefits of this approach.
“There is only one codebase per app…” — 12factor app.
The Y-axis scaling tends to be more costly to implement for the brownfield application than the X-axis scaling. Still, it solves different kinds of issues than availability issues addressed by X-axis scaling. In addition to handling matters related to increasing development and application complexity, Y-axis splits support creating fault-isolative architectural structures.
Of course, this approach comes with its own set of new challenges to handle. It should be considered while making a trade-off — the number of distinct sub-applications increases the complexity around operations and shared-data management.
In general, when Engineering teams start to lose development velocity, that indicates an opportunity to scale further in the Y-axis. If the application is too large for any developer to understand fully, that is also a signal for decomposition.

Z-axis Scaling: Partitioning by Attribute

Z-axis scaling is about scale by splitting similar things based on a “looked up” value, a.k.a attribute. This scaling also runs multiple instances of the application, but unlike X-axis scaling, each instance is responsible for only a subset of the data or the workload. In the later section, we will see this with an example.
Very often, this approach offers a first-class scaling at the fine grain. An increase in fault isolation and scaling at the partition level are the key benefits of this approach. This approach can be combined with x-axis scaling to bring availability along with partition level fault isolation.
Though we may not be creating multiple instances in the z-axis right away, it is best to keep this as a vision or end goal while making significant design decisions for your application. It is very well possible that different customers have a different level of priority and weightage to a different partition of your application. For example, if I have to scale one partition much higher than the other partitions to serve customer-specific usage patterns better, designing application architecture to support z- scaling is essential.
An interesting observation is that: Z-axis is a little easy from a design perspective for a greenfield project. But, this scaling tends to be the most costly for brownfield applications.
(Each scaling axis solution should handle caching strategy differently to get even more out of these approaches. This is another topic for another time)

Case Study

This section will demonstrate how the scalability cube perspective helped boost my application scalability needs; let’s call this app App-X (intentionally, I am skipping the business use case here to keep it simple).

Y-axis

When the application development team started with a two-pizza size (group small enough to be fed with two pizzas), App-X as one application is a good starting point. When the App-X was relatively small, monolithic architecture had many benefits: simple to develop, easy to make radical changes to the application, and straightforward to deploy. In an initial couple of years, the application went through constant changes to the data model as the requirements start to grow; monolithic made it easy for the high-velocity agility.
However, over time, to manage the growing complexity, decomposition is a necessary step. Functionally decomposing extensive application into multiple independently deployable modules is an ongoing process for any application. The App-X now has numerous components for various work modules — one for computing-unit, one for UI, one for input-extraction, one for calculator services, one for the reuseable internal library, and one for downstream services orchestrator and so on. Even the clear separation at the codebase level is what we achieved.

X-axis

The significant benefit of this scaling is to provide high availability. Hence, we started with a user-facing component of App-X. This application is not a simple stateless application. So, it has to go through the pre-step of making the app cluster-friendly. Then, this component has been containerized and enhanced to work with active-active mode. However, for the computation component of App-X, it could use more than this one-dimensional scaling. Y- and Z- axis scaling can be much more beneficial to this component.

Z-axis

Similar to how x-axis scaling requires your application to be stateless or cluster-friendly, z-axis scaling also needs pre-step if the application is designed in a traditional N-tier layered architecture with centralized execution control. That was a case in App-X.
To enable the z-axis capability, the computational component should be stripped independently based on the attribute (in App-X, it was partitioned by business attribute); this needs a redesign of the computational-unit-driver to move to hexagonal architecture style from layered architecture style. In that context, a small scale spike was done to make the sub-component of the computation unit to be independently launchable. The idea is to create configurable swim lanes. We will go over this in detail, maybe in another blog. For now, let's see splitting by attribute as just an example to demonstrate how the z-axis scaling will look like.
This approach will enable us to scale computational-unit-internal workload in isolation and on-demand. And, This will provide much more control over the execution of work units and pave a step towards a configurable concurrent model.

Let’s Conclude…

The cube model is not something new; in fact, this was first published a decade back in ‘The Art of Scalability’ book. However, it is worth rehashing these concepts when tackle scalability needs.

For a greenfield project, it is vital to architect your application to support scalability in a multidimensional way, even if you will not launch the n-instances of your app on day one. Because bringing these capabilities later is very costly. So, make it cluster-friendly, make it as modular as possible, make it independently launchable and deployable units by design.
For a brownfield project, deciding when-to scale, what-direction-to scale, how many splits to create is not straightforward. It is both science and art. However, using incident and production issues history analysis to spot the scale bottlenecks could be a good starting point to figure out the scalability directions.

Continuous Inspection: 3 Steps to Manage Complexity

Bala K — Tue, 18 May 2021 13:29:04 +0000

The objective of this blog is

To briefly discuss - What is Continuous Inspection and What are the deadly sins of a developer?
To throw some insight into how SonarQube computes Code Complexity. It is pretty different from the traditional metric we all are well aware of – Cyclomatic Complexity.
To emphasize some of the Programming Principles and Refactoring Idioms, which are directly linked with code complexity.
To share my favourite mind maps related to Continuous Inspection.

Continuous Inspection

What is it? It is a widespread inspection of software to provide early warning of maintainability and other code quality issues.

"Continuous Inspection is a process designed to make internal code quality an integral part of the software development life cycle. The key concept in Continuous Inspection is finding problems early–when fixing them is still cheap and easy. Under this model, automated code audits are performed daily and made available within an organization." - SonarQube Whitepaper.

There are ten principles of Continuous Inspection defined by SonarQube. Here are my three favourites;

Software Quality must be part of the development process, meaning that meeting quality standards is one of the demanding requirements to declare development complete.
Software Quality data must be up to date
All new issues and existing critical issues must be assigned a clear path and timeline for resolution.

Let's quickly skim through what we call as deadly sins before we see three steps of managing them.

The Deadly Sins

Sonar defines the following seven technical axes, which the Sonar team prefers to call them: "The seven deadly sins of a developer."

Coding standards: respect coding standards and follow best practices
Potential bugs: eliminate code violations to prevent vulnerabilities
Documentation and comments: provide documentation especially for the Public API, the source code
Duplicated code: isolates and refines duplication, Don't Repeat Yourself
Complexity: equalizes disproportionately distributed complexity among components; eliminates complexity if possible.
Test coverage: writes unit tests, especially for complex parts of the software.
Design and architecture: minimize dependencies

Violations/Code Smells

Code-Smells is always my most-liked topic. I did create some mind-map long ago based on few resources on code smells taxonomy; a good shared vocabulary comes very handily while doing code/design review. This picture conveys a lot more than a thousand words – 37264 words to be precise! Check Jeff's blog and Journal of Empirical Software Engineering to get a summary of what each smell means.

It will be a fun exercise to match the code smell name with its corresponding picture representation. Here is the clue: I used the same colour code for each group, narrowing down the selection.

The newer version of SonarQube started showing bad practice as Code Smells (previously called Violations). It is an excellent strategy to call it smell; The term 'code smell' puts psychological pressure on the code developers. No one wants the results of their work to be "smelly". SonarQube can identify a good amount of Code Smells that are easy to find by the machine. However, the remaining tricky code smells need to code/design reviewers' nose to spot them.

Continuous Inspection: Step 1

Bring and keep the code smells to zero
Most of the code smell should be identified in the development and the code review phase even before it goes to the mainline (master branch)

Test Case Coverage

A quick note on the code coverage is in order. Code coverage is how much code of the application on the test is being exercised by giving a test read. That number may not mean a lot in itself, but it can be interesting to watch the trend. If coverage decreases regularly, you should look into why that is happening. To keep the coverage constant, the number of test cases should correlate with the Cyclomatic Complexity (we will see this later). As you add more complexity, you should also add more test cases (although in TDD, you should add the test cases first).

Continuous Inspection: Step 2

Watch out for the code coverage trend: Bench-marking code coverage of the project at the start and end of the sprint is an excellent way to do it.

What could be the Next Steps?
We all know that, Step 1 and Step 2 should be religiously followed. So, let's introduce Step 3 -- Code Complexity.

Understanding Code Complexity

Code Complexity is intended to identify the software modules that will be difficult to test or maintain. In other words, it provides the quantitative measure of the Clean Code. Two famous complexity metrics are widely accepted. Let's compare and contrast.

Cyclomatic Complexity
Cognitive Complexity

Cyclomatic Complexity

McCabe's Cyclomatic Complexity is an old and established measurement of the software complexity. It has been the de-facto standard for measuring the complexity of a method's control flow for a long time.

Cyclomatic Complexity Algo:

The minimum possible Cyclomatic complexity is one because there's always going to be one path. To measure the complexity of a given block of code, start with one and add one every time you find the keywords such as if, else, case, for, for each, do, while, catch.

Though the Cyclomatic Complexity accurately calculates the minimum number of test cases required to cover a method fully, it is not an adequate measure of understandability. Let's see why,

The mathematical model underlying Cyclomatic Complexity gives these two methods equal weight. However, the control flow of the sum of primes is more challenging to understand than that of getWords. The standard Cyclomatic Complexity algorithm penalizes switch/when statements quite heavily. And also, It doesn't include modern language structures like try/catch and lambdas.

Cognitive Complexity

Cognitive Complexity breaks from the practice of using mathematical models to assess software maintainability. It starts from the precedents set by Cyclomatic Complexity but uses human judgment to determine how structures should be counted.

Cognitive Complexity Algo:
The score is assessed according to three basic rules:

Ignore structures that allow multiple statements to be readably shorthanded into one, 2. Increment (add one) for each break in the linear flow of the code, 3. Increment when flow-breaking structures are nested

Additionally, a complexity score is made up of four different types of increments:

Nesting - assessed for nesting control flow structures inside each other, Structural - considered on control flow structures that are subject to a nesting increment, and that increase the nesting count, Fundamental - assessed on statements not subject to a nesting increment, Hybrid - considered on control flow structures that are not subject to a nesting increment, but which do increase the nesting count.

The Cognitive Complexity algorithm gives these two methods markedly different scores that are far more reflective of their relative understandability. More details on how it computes the Cognitive number can be found at SonarQube Documentation.

Continuous Inspection Step 3:

Use build plugins to check Code complexity whenever we add new class, methods or components and refactor it to see if we can reduce the complexity.
The number can be tracked at the project level similar to the code coverage to watch the trend. But, the number makes more sense at the individual component level.

However, we can compute like the project's complexity = project complexity/project lines of code(LOC)

In this way, we should compare the complexity between two major releases by nullifying the increase in LOC.

Stay Clean

These are my best-loved books when it comes to Continuous Inspection. The wisdom from these books are like helpline to get clean and stay sober.

I just want to end the blog with the summary of code-smells and the summary of refactoring technique and how to put them together to get what we want.

Why Kotlin: A Note From a Java Developer

Bala K — Mon, 26 Apr 2021 16:01:43 +0000

This blog is about sharing my experience and what I love about Kotlin. I worked with two applications that are entirely written in Kotlin in a year. I had exposure to two ways of using Kotlin in our applications: Writing a new application from scratch and migrating the existing legacy Java app to Kotlin.

Let's start with what we love about Kotlin.

Why Kotlin (and why do we use it)?

One of the tangible and essential things is that Kotlin language came from the industry, not academia – It was developed "to solve programmers' difficulties" and operational challenges. We wanted to pay special attention to Kotlin features that Java does not have (at the time of this exercise) to evaluate if it will help the projects. The result is, we could fill an entire book about the things we like about Kotlin. Here is a run-down of highlights.

How does It Change the Way We Code (compare to Java)?

Kotlin is really "Java's best practices" put into a language. It solves problems faced by working programmers today.

Kotlin costs nothing to adopt in two aspects!
- It's Open-Source.
- One-click Java to Kotlin converter tool, and a strong focus on Java binary compatibility.
Lean Syntax: Kotlin focuses on readable, at the same time, concise syntax, which makes code-reviews/understanding-the-code painless.
Complete Interoperability with Java: Kotlin is 100% interoperable with Java, having many similarities in the structuring and functionalities.
Ease of interchangeability: The shift from Java to Kotlin is smooth and swift. One can have Kotlin and Java both alongside each other in the same project.
Improved Code Maintainability: Being a concise language, Kotlin drastically reduces the boilerplate code required, enhancing productivity and reducing error. Less code makes easy learning.
Lower Instances of Application Crashes: Kotlin is designed on the concept of fail-fast.

Kotlin brings a myriad of language features. It is worth noting that most of the features are meant to bring best practice to the coding (comparable to how frameworks guide developers in the right direction)—listing down the top the fifteen features, which will make a huge difference compared to how we code in Java.

1. Null Safety: Kotlin as a whole has a much bigger emphasis on overall null safety.
2. Arrays in Kotlin are invariant: Arrays in Kotlin are not built on native types but are instead based on a Java array, which means that an array of a specific type cannot be assigned to an array of its parent type. It is not possible to set Array<Integer> to Array<Any>. 
3. Extension Functions: Ability to extend a class with new functionalities without modifying it
4. No checked exceptions: In Java, exception handling is tedious and controlled by strict rules. Whenever we are dealing with checked exceptions, we can either handle exceptions in try…catch blocks or be declared to be thrown. In this case, the code is repeated. 
5. Data Class: Unlike in Java, where, when creating classes only meant to hold data (models or POJOs to be specific), we are required to write all of the fields, setters, getters as well as a constructor; In Kotlin, we can define all of these things on a single line.
6. Default Arguments: Removes a lot of the need for overloaded methods with the introduction of default arguments
7. Named Arguments: Avoids Client confusion in passing Parameters to Method or Constructor calls. It improves the readability of the code.
8. Delegation: Provides native support for the delegation pattern
9. When Expression: Provides the better version of Switch Statement 
10. Function Literals: Provides the concise version of Function Interfaces
11. Operator Overloading: This allows you to simulate a DSL
12. Immutability: Native support for making things immutable
13. Type Aliases: Improves readability and makes code succinct
14. String Interpolation: Easier way to concatenate a string together without excessive syntax
15. Better Generics & Coroutines

I know what you're thinking at this moment; "Wait! this is just a bunch of key distinctive features, and anything new gives something like that. Still, why Kotlin? You can't just sell it by showing a fancy list of features ".

I will tell you this, "There is a way to look beyond just features."

Let's change the scenery now and go to defensive programming valley, then it will be evident 'Why Kotlin'.

Defensive Programming

Think of defensive programming as analogous to "defensive driving", which would help if the term is not very familiar.

When you drive defensively, you assume that the other drivers are not careful. You must be cautious yourself: you must give yourself extra room on the road to make emergency manoeuvres. You assume other drivers may ignore red lights and stop signs; therefore, you look both ways and are ready to stop when you approach intersections. You anticipate problem areas up ahead – dense traffic, impaired visibility, and other potential impediments. In any case, you devote a lot of time, energy, and resources to the infrequent and unlikely event that you will encounter a dangerous situation.

"Okay, I got it". "Adding NULL checks and other checks is Defensive programming"

"No! Please stop that thought – we are not giving enough credit to the art of defensive programming if we are thinking that way".

"Okay, then, what is defensive programming?"

As I said, it is an art. what I believe to be the motto of defensive programming is:

"If you have to defend, you already had lost the battle."

For example, adding Null-Checks is Defensive-Coding; instead, coding so that you do not need to check for null is the real art. This comparison is just one example to illustrate defensive programming; there are many – we can have an exclusive blog for visiting that valley later. Let's get back to Kotlin Valley now.

When we use Kotlin, without the developer being aware, they use many defensive programming styles naturally. It is by design as a default setting; e.g. all classes are final unless stated otherwise, the default behaviour of type is non-nullable…etc…

Dev Journal

In 2018, We worked on a Greenfield project, which allowed us to take a step back to question popular thinking a few years back.

When we think of developing an application, Java is one of the top programming languages that come to mind for various reasons, including its robust and secure nature and the independence of its platform. Kotlin is designed to be interoperable with Java, meaning Kotlin can seamlessly co-exist with Java. We can add Kotlin to our existing applications, and we can use Java-based frameworks for application development. With this bi-directional use of Kotlin, we can invoke Java constructs from Kotlin or Kotlin constructs from Java.

Although Java and Kotlin are both JVM-based languages used for application development, there are several differences between them, as covered in an earlier section. Kotlin has addressed some of the limitations previously associated with Java. The more we learn about the things Kotlin support, our pressing question of why-kotlin turned into why-not-kotlin.

We had exposure to two ways of using Kotlin in our applications:

Moving legacy Java written project to Kotlin language
Project development on Kotlin from scratch While developing a new application, in general, when time-limit holds the gun to the head, we tend to copy over the setup from an existing application; sometimes, we don't realize that we are reproducing some legacy stuff along with it. For these projects, we tried not to do that.

"Is there any impact on the way we test or write the test? "

"Yes, very positive one. The two applications built in this stack have around 80+ and 90+ as unit test coverage."

"Did we notice any significant performance degrade?"

Though we have not tested the performance of the Kotlin in an experimental condition like implementing the application both in Kotlin & Java and bench-marking it, however, we did compare the performance with legacy (now dead) wherever applicable. The performance was at par, and sometimes it was even better.

"What is the learning curve (and how did we learn)?"

There are many ways you can build new tech skill; most of us followed the below.

Step 1: 4Hrs Video Training to start the cold engine to enter into the Kotlin Valley
There are a lot of courses available on Pluralsight & Udemy; we started with Pluralsight: kotlin-fundamentals. At that time, when we began learning Kotlin. Pluralsight course was open for Free. Lucky Us.
Step 2: Kotlin Koans to get familiar with Kotlin by doing small exercises. Kotlin Documentation is good to look back at any time.
Step 3 & 4: Then, Code & Write Unit Tests (have a printout of Quick Reference Card while coding)

What is the Maintainance overhead post-production ?
These two applications are running well in production over the last 3+ years without any technical or maintenance issues related to the stack being Kotlin; thus, we see high stability in these two applications.

We enjoyed learning something new (in 2018). From a Java developer perspective, the learning curve to Code in Kotlin is close to flat. Once the integration of the stack was ready to provide a skeleton for the project, we managed to gain speed in Kotlin within a week and write more idiomatic code within a couple of weeks. If you find it interesting, learn about best practices and go for it to fit your application nature.

Summing-up

Kotlin, "You Had Me at Hello" (here, the Hello means "to solve programmers' difficulties"). Overall, it was a positive experience.

P.S: This is a page from my devjournal 2018. And, I feel this is still relevant.

Reliability Engineering: Two Mistakes High

Bala K — Sat, 24 Apr 2021 03:22:25 +0000

This blog is about — What Is "Two Mistakes High"? and How is it relevant to our IT industry?

What does it mean?
Why TWO mistakes?
Is it relevant to us?
How do we apply in an application?

I stumbled on this expression a couple of years back while reading a tech book. When I read it, it sounded OK; nothing too exciting or remarkable about that. Later, I noticed something; it was a seed that started to root stronger. Now I can't get it out; every time I make some decision about reliability/stability, regardless of whether it is for work or for fixing something at home (be it electrical/plumping/carpentry/IoT project), I almost hear someone whispering in my ear "are yooou flying two mistakes high?"
Hold on ✋, before you call this paranoia, let's see what does it mean to "Flying Two Mistakes High"?

What does it mean?

This expression is used while kids are learning to fly remote control aeroplanes.

When you learn to fly, you will be doing some manoeuvres and learning acrobatics. Of course, you will try out a stunt of some sort. And, quickly, you will learn this lesson: If you make a mistake, your plane will naturally lose some altitude.
And, you will see, mistakes equate to altitude.

So, keeping your plane "two mistakes high" means keeping it high enough that you have enough altitude to recover from two independent mistakes.

Why TWO mistakes?

While you are recovering from the first mistake — and you are now already lower in altitude — what happens if you make another slip-up? If your plane isn't high enough to recover from the second mistake, well, it's terrible news. And, if you lose too much altitude, you know what happens — broken toy at worst.

In that event, you always want to stay high enough to recover from a mistake, even while you are still recovering from the first mistake. As a result, you don't crash, no matter what goes wrong.

Is it relevant to us (IT)?

We saw where the expression came from. And, this is a good analogy for maintaining availability in our most critical applications.
In our critical modern applications, It means that even when something is going wrong with our application, we want to keep our application running reliably enough so that we can afford for something else to go wrong while we are still recovering from the main problem. Think about it: during our recovery process, we are typically stressed and perhaps in a tricky situation doing potentially ad-hoc things — just the type of situation that can cause us to make another mistake.

While I was researching more on this topic (just a glorified way of saying "I googled it"), I was able to find only a handful of info that relates this philosophy with the IT field — most of them are about how it can be connected to availability.
But, to me, it is more than that. It applies to many more scenarios.

I believe, inherently, most of us are risk-takers, and we would like to push the envelope now and then test our limit (in this case, try our application limit — keeping the error budget in mind). I consider the R/C plane analogy as a meta-thinking tool. It makes you take calculated risks in any given situation.

It is a lesson about redundancy, and it's a lesson about resiliency, and it is a lesson about …you get the idea. It effectively applies to modern application development, change management, operation. It even applies in many other aspects: from dealing with hardware failures to data redundancy, capacity planning, performing retries in your service calls, reducing toil, risk management, and disaster planning.

For those curious minds who might ask, "Why stop at two? Why not three or more mistakes high?"

Short answer: To keep it simple, I don't want to go Inception experience here to avoid Limbo. To start with, two sounds reasonable enough.

How do we apply in an application?

For starters, when we identify the failure scenarios that we anticipate, we should walk through the ramifications of those scenarios and our recovery plan for them. We make sure the recovery plan itself does not have the potential for mistakes or other shortcomings built into it — in short, we check that the recovery plan can work, and it has backup for shortcomings.
Sounds simple, right?…. Big No, it is easier said than done. But we can practice wherever/whenever we should to make it a habit.

Conclusion

A few years back, when one of the applications was facing relatively high stability issues, my mentor gave me the advice to bring things under control. This is the gist of what he said: "Hey Bala, it is ALL about asking the right questions, and there is no need to get overwhelmed".

I can firmly say, "are you flying two mistakes high?" comes under that list of right-questions-to-ask.

For site reliability engineering, the word "mindset" is critical. Being an effective SRE is as much about how you think as it is about your technical skills.
— Kevin Casey

tmux: 13 Cool Tweaks to Make It Personal and Powerful

Bala K — Tue, 20 Apr 2021 18:07:20 +0000

Intended Audience: tmux users (beginner) or who read the part one of my "Command Line Happiness" post or looking for best tips & tricks.

Why do you want to tweak the default setup ?

Keyboard shortcuts in tmux are a bit of a stretch, both physically and sometimes mentally
tmux has a lot of less-than-stellar default setting
Moreover, the configuration is fun, especially when you personalize it to suit your needs; after all, that's what it's for!

In general, I prefer using the default setting with any tech/tools that I use as long as it serves its purpose well. However, tmux is different. It is designed to be customizable. On top of that, these are my reasons why you should tweak it.

Follow along, and let's make your tmux friendly. Along the way, do not forget to put more comments in your configuration file; they'll jog your memory later. Treat your tmux config as a living document; Learn, practice, and update.

Here is your ready-to-use valuable tmux tips-&-tweaks. Try these to improve your day-to-day development while using tmux. Let's start with the biggie ! [prefix]

1. Prefix Should be Simple

By default, all key bindings will demand a "prefix" key before they are active. It is similar to a [leader] key in vim. The default is Ctrl-b.

The default is a little hard to trigger as the keyboard button is pretty far. Most prefer the Ctrl-a as prefix key:

It puts your prefix in the home row.
CapsLock can be remapped with a Ctr key, and A sits just next to it.
If you have already used the GNU screen, Ctrl-a is already the standard key for you.

unbind-key C-b              # free the original bind-key key
set-option -g prefix C-a    # setting the prefix from C-b to C-a
bind-key C-a send-prefix    # ensure that we can send Ctrl-A to other apps or the shell that your interacting

2. Just Reload the Config

Considering you will be doing config tweaks and testing often, it is good to introduce the shortcut here.

By default, there are two ways of reloading

shutting down all tmux sessions and start them
executing 'source-file ~/.tmux.conf' on all the sessions

Who on earth want to follow the above approaches all the time! let's create the shortcut - Ctr+r

bind-key C-r source-file ~/.tmux.conf \; display "Config Reloaded !"

3. This is How I Want to Start

If you do not want to use your default shell and prefer something else, it is easy to set in tmux.

Let me set my default to my fav shell - zsh. Macs now use zsh as the default login shell across the operating system. It is for a reason. Give it a try if you don't already use zsh as your default shell.

set-option -g default-shell /usr/bin/zsh        # login shell for new windows/pane

4. I Can't See Enough !

By default, the message that comes in the status bar disappears in the blink of an eye and the pane number display time also too short to notice. Tweak the time as you wish.
If you feel your default history limit is not good enough for your case, crank that up too.
Lock the session after x mins of inactivity. Sometimes, it is good to protect your screen to make sure other's should not see enough.
Default names given to the window are based on what runs in the pane. Hi tmux, let me name it.

set-option -g display-time 2000            # By default, status msg disappears in the blink of an eye (750ms)
set-option -g display-panes-time 2000      # By default, pane number disappears in 1 s
set-option -g history-limit 50000          # maximum number of lines held in window history - crank it up from 2k default
set-option -g lock-after-time 3600         # lock the session after 60 mins of inactivity. Sometimes, it is good to protect your screen to make sure other's can't see enough.
set-option -wg automatic-rename off        # default names are too vague to see. Let me name it.

5. Count like Human

By default, the windows or panes start with index 0 (silly programmers!). Though tmux is one of those "created by and for programmers", this indexing makes it challenging to do switching windows; window 0 will be all the way to left in the status bar and the 0 in keyboard is all way to the right, then 1 key comes in the left...it messes with you.
Let's imagine you have three windows. If we removed the second window, the default result would be two remaining windows, numbered 1 and 3. but, tmux could automatically renumber the windows to 1 and 2 with the right setting.

Ok, Let's make tmux a human for a bit,

set-option -g base-index 1                # window index will start with 1
set-window-option -g pane-base-index 1    # pane index will start with 1
set-option -g renumber-windows on

6. Kill it with X-Force !

By default, if you press x, tmux will ask if you're sure you want to kill a pane before it does it. That's nice and all, but what if you'd rather just kill it? Let's do that. And, while we’re at it, let’s create a custom key combo for killing the entire session too.

unbind-key x               # unbind-key “x” from it’s current job of “ask and then close”
bind-key x kill-pane       # rebind-key it to just “close”
bind-key X kill-session    # key combo for killing the entire session - <prefix> + shift + x

7. Make Splitting Panes Intuitive

Splitting a window in panes are currently bound to % and ”>, which are hard to remember. It is much easier to remember if you use | for vertical splits and _ for horizontal splits. For now, I will leave the default binding as it is since I don’t have any other use for these weird key commands.

Additionally, you could also mention the directory to open in the new pane when you split.

bind-key | split-window -h -c "#{pane_current_path}" # let's open pane with current directory with -c option
bind-key _ split-window -v -c "#{pane_current_path}"

8. Make Movements Quick

One of the main reasons for using tmux is because it’s keyboard-centric and plays well with Vim, another my favourite keyboard-centric tool. If you use Vim, you’re probably familiar with its use of h, j, k, and l for movement keys. This way, you do not have to take your fingers off the home row to move to anywhere else.

Let's make movements in pane, window, & command prompt much familiar and faster,

# Pane: Vim Style Movements
bind-key -r h select-pane -L              # go left
bind-key -r j select-pane -D              # go down
bind-key -r l select-pane -R              # go right
bind-key -r k select-pane -U              # go up

# Pane: Arrow Movements
bind-key Up select-pane -U
bind-key Down select-pane -D
bind-key Left select-pane -L
bind-key Right select-pane -R

# Window: Movements
bind-key L last-window
bind-key -r C-h select-window -t :-              # cycle through the windows for quick window selection
bind-key -r C-l select-window -t :+

# word separators for automatic word selection
set-window-option -g word-separators ' @"=()[]'  # default => ‘ -_@’.

# tmux adds a short, almost imperceptible delay between the commands that can cause funny behavior when running vim inside tmux.
set-option -s escape-time 0

# Command Prompt Movements:  within the tmux command prompt and the command prompt is accessed using <P>: (in the status line)
set-option -g status-keys vi

9. Resizing Panes

The default key binding are Ctr+ Up/Down/Left/Right for one row movements , Alt + Up/Down/Left/Right for five row movements.

Let's add one more to the set (Vim way)

# Vim Style
bind-key -r H resize-pane -L 2         # resize a pane two rows at a time.
bind-key -r J resize-pane -D 2
bind-key -r K resize-pane -U 2
bind-key -r L resize-pane -R 2

10. Copying and Pasting Text

We will do multiple custom setting here. This tweak can be a real productivity boost if you happen to do a lot of copying and pasting between windows.

We will do these;

Navigating through output in a quick way like vi
Vim Style in Copy-Mode
Setup keys (install xclip if you don't already have it)
- To copy from the current buffer to the sys clipboard Alt+c
- To paste text from sys clipboard into current buffer Alt+v
- To copy to the sys clipboard directly from the selection Ctr+c
- To paste text from sys clipboard into the view Ctr+v
Take a screenshot of the pane and store it with timestamp Alt+s

# To navigating through output in quick way, enable vim navigation keys
set-window-option -g mode-keys vi

# Vim Style in Copy-Mode "<prefix> ["
# Interacting with Paste Buffer
bind-key Escape copy-mode
bind-key -T copy-mode-vi 'v' send-keys -X begin-selection            -N "start visual mode for selection"
bind-key -T copy-mode-vi 'y' send-keys -X copy-selection-and-cancel  -N "yank text into the buffer"
bind-key C-b choose-buffer # view the buffer stack
unbind-key p
bind-key p paste-buffer # default "<prefix> ]"

# Alt+C: To copy from the current buffer to the sys clipboard .
bind-key M-c run "tmux save-buffer - | xclip -i -sel clipboard"

# Alt+V: To paste text from sys clipboard into current buffer
bind-key M-v run "tmux set-buffer \"$(xclip -o -sel clipboard)\""

# Ctr+C: Make it even better -just one step to move from sys->buffer->editor vice versa
bind-key -Tcopy-mode-vi C-c send -X copy-pipe "xclip -i -sel p -f | xclip -i -sel c" \; display-message "copied to system clipboard"

# Ctr+V: To paste text from sys clipboard into the view
bind-key C-v run "tmux set-buffer \"$(xclip -o -sel clipboard)\";tmux paste-buffer"

# To take ASCII screenshots (tmux-resurrect uses C-s for saving, here binding to Alt-s ) .
# create the dir for storing screenshots
bind-key M-s run "tmux capture-pane; tmux save-buffer ~/.mytmux/pane_screenshots/\"$(date +%FT%T)\".screenshots"

11. Visual Styling: Configuring Colors

Once the proper colour mode is set, you'll find it much easier to use Vim, Emacs, and other full-colour programs from within tmux, especially when you are using more complex colour schemes shell or syntax highlighting.

What you can do here is up to your preference. It goes beyond just colour to your eyes. Let me demo with a few of my tricks;

Let's dim out any pane that's not active. It is a lot easier to see the active pane this way than looking for * in the status bar.
Customize pane divider to make it subtle but distinct.
Make the message colour not harmful to your eyes

# Set the default terminal mode to 256color mode
set -g default-terminal "screen-256color"

# Pane divider
set-window-option -g pane-border-style fg=colour11,bg=colour234
set-window-option -g pane-active-border-style fg=colour118,bg=colour234

# Cool trick: Let's dim out any pane that's not active.
set-window-option -g window-style fg=white,bg=colour236
set-window-option -g window-active-style fg=white,bg=colour235

# Command / Message line
set-window-option -g message-style fg=black,bold,bg=colour11

12. Dress Up the Status Line

This is how you tailor up the dress for your status line

Update Status bar colour and window indicator colour
Update What do you want to see on the left side & right side of the status line
Setup soft activity alerts

Instead of going fancy here, I just focused on what can help me during my work and less resource-intensive operation. Below is my status bar config;

# Status Bar
set-option -g status-style fg=white,bg=colour04
set-option -g status-justify centre
set-window-option -g window-status-style fg=colour118,bg=colour04
set-window-option -g window-status-current-style fg=black,bold,bg=colour011
set-window-option -g window-status-last-style fg=black,bold,bg=colour011
set-window-option -g window-status-separator |

# Left Side
# Show my active session, window, pane name or id  
set-option -g status-left-length 50   # default 10
set-option -g status-left "[#[fg=white]S: #S, #[fg=colour11]W #I-#W, #[fg=colour3]P: #P #[fg=white]]"
# set-option -g status-left-style

# Right Side
set-option -g status-right-length 50   # default 50
set-option -g status-right "#[fg=grey,dim,bg=default] uptime: #(uptime | cut -f 4-5 -d\" \" | cut -f 1 -d\",\")"

# Enable Activity Alerts
set-option -g status-interval 60           # Update the status line every 60 seconds (15 is default)
set-window-option -g monitor-activity on   # highlights the window name in the status line

13. Extending tmux with Plugins

There are many tmux plugins available. If I have to choose one, that would be 'tmux-resurrect'.

This plugin restores the tmux environment after system restart. This plugin goes to great lengths to save and restore all the details from your tmux environment. See doc
If you setup resurrect, then the next logical thing to do is set up 'continuum' to make the saving and restoring as an automatic step

Here is the step to setup tmux plugin management;

# List of plugins
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'

# Last saved environment is automatically restored when tmux is started.
set -g @continuum-boot 'on'  

# terminal window will go fullscreen
set -g @continuum-boot-options 'fullscreen' 

# Initialize TMUX plugin manager (keep this line at the very bottom of tmux.conf)
# run-shell "mkdir -p ~/.tmux/plugins/"
# run-shell "git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm"

run '~/.tmux/plugins/tpm/tpm'

# Hit prefix + I to install plugins for the first time. 
# It takes few seconds. So, wait before panic.
# 
# resurrect key bindings:
#   prefix + Ctrl-s - save
#   prefix + Ctrl-r - restore
#

Note: All of these tweaks are tested and working in Ubuntu.20.10 and tmux3.1b

You could access my tmux config here

Productivity Booster: Command Line Happiness with tmux

Bala K — Wed, 14 Apr 2021 16:07:19 +0000

Who Should Read It:

Anyone who uses the command line daily and not yet explored tmux in-depth, this blog is for you.
If you are already using tmux, check out 'beyond basics' section.
Others, check out the 'why should you care' section to see if it can be a valuable addition to your toolbox.

You do not really need this blog to use tmux; If you want a technical guidebook, you could look at the manpage for tmux. However, manpages are seldom adequate to wrap your brain around concepts (why & when); they're there for reference (how-to) sorted alphabetically instead of logically. Here, We will see 'why tmux', some of its practical uses, and how to quickly start using it in your day-to-day workflow.

Why Should You Care

Suppose you are working on many projects or many contexts (DevOps, development, exploring, etc.). In that case, each needs a set of terminals to control various activities, "creating more tabs & windows and using a mouse to organize them" isn't the best solution. This process is typically slow, and the context-switching between different kinds of work is very unproductive (especially if you end up redoing the same setup afresh).

Of course, there are other ways of managing multi-tasking, like using simple bg & fg commands or using the GNU screen. However, Tmux is considered to be the next evolutionary step forward. I am not overstating; even the screen packages have been replaced by tmux in RHEL8.

"T"erminal "mu"ltiple"x"ing

I am writing this in a github-managed .md file from vim running in a pane, inside a window, in a session managed by a tmux server, through a client running in my zsh terminal in Ubuntu VM using VirtualBox that installed in win10.

Tmux is a powerful tool; It is one of those things that at first sounds peculiar, involved and intensive; you can't quite grasp what the heck they do, how they can be valuable or why anybody even wants to use them. Nonetheless, it is one of those things that will turn out to be a fantastic swiss-army-knife when given a chance. Let's give a chance for the below reasons.

Why Tmux?

tmux help solves the weaknesses of standard terminal emulators. The followings are some of the reasons why I became a tmux fan:

It expedites the creation and management of terminal windows and pane
- Once you get familiarized with working within sessions, windows, panes, you are into an excellent developer environment.
It provides the ability to connect to existing local and remote sessions
- It uses a client-server model, which lets you pause and resume your work where everything is exactly how you left it.
- It makes it easy for context-switching between multiple themes of your work
It is totally customizable and gives the ability to automate creating a specific layout
- It comes with the heavy load of built-in commands that let you build your script to automate your dev env
It provides 100% mouse-free control

Overall, it can be an incredible productivity booster once you get the hang of it.

Basics

Ok, Let's break down tmux by its objects, from servers down to panes.

Server is what powering tmux behind the scenes. It is so streamlined, and zero-config needed from you. It runs in the background; you will hardly notice it is there. When you execute a tmux command, a tmux server is launched. Every activity that is launched in the tmux happen within the server. What you see in your shell is merely a client connection. The server holds sessions.
Session is essentially the base unit holding windows. You can have multiple sessions also. e.g., you could have one session for each application your developing or a session for work and a session for your cool side project or exploration.
Window is what you see when tmux is open in front of you. Think of it as a tab in your browser. The window layout is customizable, and tmux has many preset layouts also to arrange panes.
Panes are a terminal in a terminal, or you could call it pseudoterminals. The panes let you divide the screen horizontally and vertically within the same window. A window and a pane are perfect analogies to their real-world counterparts.

Sessions, Windows & Panes: These are good to logically organize multiple activities (totally mouse-free).

I think we got the basic concepts covered. Now, Let's see the general usage of the tool in the context of typical dev workflow.

Typical Workflow

This flow is how tmux-using developers' day looks like. First things first, one grabs a coffee ☕ and bossily command GoogleHome to play Mozart 🎵 on Spotify. Then, let's say that we are starting the work on project A.

Step 1: You can start just by invoking $ tmux . However, I suggest that you always begin by creating a session with a name; it is better than a default session name. The name could be the project or a theme you are working on, so it will be easy to recognize and switch between them.

 $ tmux                 # Launch tmux with defalut session    
 $ tmux new-session –s  # Launch tmux with a named session
*[prefix] X            Closing Session

# By default, all key bindings will require a "prefix" key before they are active. It is like a <leader> key in vim. The default is Ctrl-b; I changed to Ctrl-a. 

* this is a custom key-binding

Step 2: Now, You can create as many panes as needed (typically, the most user go with three panes in a window; one editor in the main terminal and two other terminals for running processes like interacting with git, running tests, a web server, etc.…)

#### Pane Management
*[prefix] _            Split the window into two vertical panes
*[prefix] |            Split the window into two horizontal panes (horizontal )

 [prefix] q            Show the pane number in each pane briefly.
 [prefix] arrow-keys   Switch focus to different pane
 C-d                   Close the pane just like how you will close a terminal

#### Layout Management
[prefix] <space> Rotate through the default layouts
[prefix] <alt>1  Switch to Even Horizontal Layout
[prefix] <alt>2  Switch to Even Vertical Layout
[prefix] <alt>3  Switch to Main Vertical Layout
[prefix] <alt>4  Switch to Main Horizontal Layout
[prefix] <alt>5  Switch to Tiled Layout

### Resizing Panes
[prefix] z             zoom current pane to full window size

[prefix] <ctrl>up      increase the height of this pane by one row
[prefix] <ctrl>down    decrease the height of this pane by one row
[prefix] <ctrl>left    increase the width of this pane by one column
[prefix] <ctrl>right   decrease the width of this pane by one column

*[prefix] H             increase the height of this pane by two row (shift+)
*[prefix] J             decrease the height of this pane by one row
*[prefix] K             increase the width of this pane by one column
*[prefix] L             decrease the width of this pane by one column

[prefix] <alt>up       increase the height of this pane by five rows
[prefix] <alt>down     decrease the height of this pane by five rows
[prefix] <alt>left     increase the width of this pane by five columns
[prefix] <alt>right    decrease the width of this pane by five columns

*this is a custom key-binding

Step 3: Then, you start working, 🎵click-clack clickity-clack🎵, while you'r at it, if a single window can't hold all related terminal works, you can create additional windows as you see fit.

Frequent Use:
 [prefix] c      _C_reate a new window
 [prefix] ,      Rename current window

 [prefix] w      Choose a _w_indow from a menu
 [prefix] 0-9    Switch to window 0-9
 [prefix] p      Cycle to _p_revious window
 [prefix] n      Cycle to _n_ext window
 [prefix] l      Back to the _l_ast window

 [prefix] x      Closing Window

Sporadic Use:
 [prefix] M-p    _p_revious window with activity
 [prefix] M-n    _n_ext window with activity

 [prefix] !      Breaking Window Panes If you have too many panes in a single window.

 $ move-window  –t {target session}         # Move the window from one session to another
 $ link-window –t {target session}          # Link a window between two sessions         
 $ unlink-window                            # Unlink the window from the current session
 $ join-pane -t {session}:{window}          # Join the current pane to a target window

Step 4: Then, you just realized that you need to finish off something for project B; now, you can create a new session for project B and switch out from the first session. You can come back to project A workspace later (maybe tomorrow or next year as long as your tmux server runs).

[prefix] s      Choose from a list of _s_essions
[prefix] (      Switch to previous session
[prefix] )      Switch to next session
[prefix] L      Switch the attached client back to the _L_ast session.
[prefix] $      Rename the session

Step 5: When it is closing time, you could leave the working session open or detach the session. When you detach a session, it becomes a headless entity running in the background and remain active in the server, ready for whenever you want to resume the work. You can even close the terminal that launched it.

 [prefix] d      _d_etach from your current session

Step 6: The next day, when you reconnect, you can start a new terminal and reattach the still-running background session that contains your work in progress. Tada! You just jumped right back in. Now, you can start making your keyboard sing again 🎵.

$ tmux attach-session -t {session-name}   # Start tmux and attach a _t_arget session by name

Beyond Basics: Personalizing Environments & Scripting tmux

With the basics under our belt, let's explore a custom configuration and automation of developer workspace in part two of this blog. It will wrap up with valuable tricks you can use with tmux to improve your day-to-day development. For the Impatient, you could check out my tmux setup here -github

tmux is a versatile addition to your terminal toolbelt. No need to grasp everything in a single sitting; efficiently managing workspace with tmux is a skill acquired over a period. Soon you will find yourself becoming more comfortable with this powerful screen-management tool.

<<à suivre...>>