DEV Community: Nithin

The best AI workbench is not an IDE

Nithin — Sat, 21 Mar 2026 21:31:28 +0000

There is a common beginner mistake in AI-assisted development: picking a single tool and asking it to do everything.

That is how people end up defending editors as if they were operating systems.

An editor is not a strategy. It is a window.

What matters is the execution surface behind the window: authentication, tool access, agent reliability, MCP support, and whether team knowledge can survive a change of shell.

After using Cursor, Cursor CLI, IntelliJ IDEA with AI Assistant wired to external providers, IntelliJ with Kilo Code, and Codex CLI, I arrived at a conclusion that is not fashionable but is practical:

IntelliJ should remain the workbench. Codex should become the primary agent. Cursor should be mined for what it does well, mostly skills and rules. Kilo Code should be demoted to utility work such as autocomplete and commit message generation.

This is not a benchmark of clever demos. It is a benchmark of operational friction.

This is also a personal conclusion, not a team mandate. The point is not to move the team to a new stack. The point is to build a personal workbench that works best for me while still adapting cleanly to the team's existing Cursor-based conventions.

Short verdict

If the goal is a practical daily setup rather than a vendor bet, the cleanest arrangement is:

IntelliJ IDEA for editing, navigation, refactoring, and inspections.
Codex CLI as the primary agent runtime.
Cursor rules and skills preserved through AGENTS.md.
Kilo Code used narrowly for autocomplete and commit-message assistance.

That conclusion is not based on abstract model preference. It is based on where authentication, MCP access, and team workflow actually held up under daily use.

Cursor is strongest when you stay inside Cursor

Cursor has one undeniable advantage: if your team has already invested in Cursor rules and skills, the product rewards conformity.

That matters.

Institutional knowledge beats raw model quality surprisingly often. A mediocre prompt with strong team conventions can outperform a brilliant model used in a vacuum.

Cursor authentication also keeps you inside the ecosystem where those skills are first-class citizens. If the team works through Cursor-native skills, Cursor the IDE feels coherent. The tool, the auth model, and the team workflow all point in the same direction.

But this coherence has a price: it is local to Cursor.

The moment you try to separate the agent from the IDE, the promise weakens.

Cursor's own CLI documentation says MCP in the CLI uses the same configuration as the editor and that configured servers should work in both surfaces. In theory, that is elegant. In practice, the theory leaks. In a Cursor forum thread from January 21, 2026, a team member explicitly acknowledged a known issue: cursor-agent could not handle OAuth correctly for remote MCP servers such as Figma, even though the IDE could. The same thread was still receiving reports on March 18, 2026.¹ ²

For workflows that depend on remote OAuth-backed MCPs, that limitation is enough to keep Cursor CLI out of the primary slot.

That matters because an increasing amount of useful agent work now sits behind authenticated remote tools rather than local prompts alone.

The real test is OAuth, not chat quality

The market is still pretending that model selection is the hard problem.

It is not.

The hard problem is whether the agent can reach the systems that matter without turning your desk into a museum of half-working clients.

Figma is the cleanest example.

Figma's remote MCP server requires OAuth. Their official documentation says so directly and includes a Codex CLI flow that prompts for authentication after codex mcp add figma --url https://mcp.figma.com/mcp.³

There is also no useful escape hatch through personal access tokens. In a Figma community thread opened on November 18, 2025, a user asked for PAT-based auth for the remote MCP endpoint. A quoted reply from Figma Support said the remote MCP server does not support authentication using personal access tokens and that this cannot be enabled; OAuth is the recommended path.⁴

That closes the usual loophole.

If a client does not handle OAuth correctly, the integration is not merely inconvenient. It is functionally unavailable.

This is why Cursor CLI is disqualified for my primary workflow today.

Not because Cursor is weak.

Because Figma is unforgiving.

Notion belongs in the same category. Remote MCP access is valuable only when the client can complete the auth dance cleanly and repeatably. A tool that supports MCP on a slide but fails during OAuth is doing theater, not engineering.

IntelliJ is still the best room in the house

IntelliJ IDEA remains the best physical workspace.

It is still the superior editor for large codebases, code navigation, inspections, refactors, and plain old concentration. I do not want to keep both Cursor IDE and IntelliJ open just to preserve one niche capability from each.

That setup is not power-user sophistication. It is a tax.

JetBrains has moved aggressively on AI Assistant and MCP. Their current documentation shows AI Assistant can connect to MCP servers over STDIO, Streamable HTTP, and SSE.⁵ JetBrains also allows third-party providers and OpenAI-compatible endpoints, but this path is explicitly API-key driven, and feature coverage varies by provider.⁶

That distinction matters.

An IDE feature that can consume a model is not automatically equivalent to a first-class agent runtime. The former is a panel. The latter is an operating surface.

Figma's own remote MCP installation page is a useful reality check here. As of March 22, 2026, it provides setup documentation for Claude Code, Codex by OpenAI, Cursor, and VS Code. IntelliJ is not listed among the supported client setup guides.⁷

That does not prove IntelliJ can never be made to work with remote MCP. It does show where official support and documentation currently concentrate.

In my setup, IntelliJ AI Assistant wired to external providers did not become the stable answer for OAuth-backed remote MCP workflows. The practical result was still inferior to using a dedicated agent client that treats authentication and tool invocation as primary concerns rather than attached features.

So IntelliJ stays.

But it stays as the cockpit, not as the pilot.

Codex CLI solves the right problem

Codex CLI succeeded where the supposedly more "native" combinations became awkward.

The decisive point was simple: OAuth-backed MCP worked.

Figma remote MCP worked properly. Notion MCP worked properly. The boring but essential part of the stack, sign-in, token flow, callback handling, tool availability, simply held together.

That is what maturity looks like in agent tooling: fewer broken rituals between intention and execution.

Once Codex handled remote MCP cleanly, the rest of the architecture became obvious.

Use IntelliJ as the IDE.

Use Codex as the primary agent runtime.

Keep Cursor knowledge without keeping Cursor as the center of gravity.

The bridge matters more than the model

The most expensive part of switching tools is not the subscription.

It is the loss of team memory.

That is why the AGENTS.md bridge is the most important piece of this workbench.

By teaching Codex to treat .cursor/rules/*.mdc and .cursor/skills/**/SKILL.md as source-of-truth instructions, the setup stops being ideological and becomes mechanical. Cursor skills remain usable. Cursor rules remain usable. Team conventions survive. My workbench changes; the shared operating doctrine does not.

This is the right way to personalize AI tooling inside a team without forcing the team to follow.

Do not rewrite every rule because a vendor changed.

Do not ask the team to learn a second set of rituals.

Move the execution engine locally. Preserve the doctrine globally.

That is exactly why Codex is a better primary workflow than Cursor IDE in this setup: it can inherit the team's Cursor knowledge while also handling the remote MCP reality that Cursor CLI still fumbles.

The bug that weakens trust

There is another reason not to make Cursor IDE the center of the system: reliability debt.

I have seen occasional cases where agent changes do not appear correctly in the Git changelist inside Cursor. There are workarounds, restarts, and folklore. I have not found a permanent fix worth trusting a primary workflow to.

Intermittent bugs are how tools slowly lose authority. A development surface must be boring when it comes to source control visibility. If the user has to wonder whether a file changed or merely failed to appear, the editor has ceased to be infrastructure and has become weather.

Comparison in practice

Setup	What worked	What broke or stayed weak	Verdict
Cursor IDE	Cursor-native rules and skills, coherent in-product workflow	Git changelist visibility sometimes unreliable, requires staying in Cursor to get the full benefit	Useful, but not my center of gravity
Cursor CLI	Reuses Cursor MCP configuration and team skills in principle	Remote MCP OAuth remained unreliable for the workflows that mattered most	Not suitable as primary runtime
IntelliJ + AI Assistant with external providers	Excellent IDE, strong editing and refactoring environment, growing MCP support	Not listed in Figma's official remote MCP client setup docs; also did not become the most reliable home for remote OAuth-backed MCP workflows in my setup	Best editor, not best agent runtime
Codex CLI	Remote MCP with OAuth worked cleanly for Figma and Notion; agent workflow felt dependable	Less value from Cursor-native ecosystem unless bridged deliberately	Best primary runtime
Kilo Code	Helpful for lightweight assistance	Not the tool I would trust for heavy MCP-centric workflows	Keep it narrow

The resulting workbench

The final arrangement is not elegant in the way marketing teams prefer. It is elegant in the way a good wrench is elegant.

The workbench is:

IntelliJ IDEA for editing, navigation, refactoring, and staying in flow.
Codex CLI as the primary agent for serious work, especially when remote MCP with OAuth is involved.
Cursor CLI as a secondary utility when team-specific Cursor workflows are still useful, but not as the foundation.
Kilo Code for lightweight assistance such as autocomplete and commit message generation through OpenAI auth.

This division of labor is healthy.

Each tool is forced to do only the job it is actually good at.

That is rare in modern AI tooling, where every vendor wants to be your editor, shell, browser, memory layer, and therapist at the same time.

Conclusion

The winning setup is not Cursor versus Codex versus IntelliJ.

That framing is too small.

The real contest is between two philosophies.

One philosophy wants a single branded surface to own the whole experience.

The other treats the development environment as a federation: one editor, one primary agent runtime, a few specialized helpers, and a thin compatibility layer to preserve team knowledge.

The second philosophy wins because it respects reality better.

Today, that means IntelliJ IDEA as the room, Codex CLI as the worker, Cursor rules and skills as inherited doctrine, and Kilo Code as a useful but limited assistant.

The best AI workbench is not the one with the most features.

It is the one that authenticates, executes, and gets out of the way.

Sources

Cursor CLI MCP docs: https://docs.cursor.com/cli/mcp
Cursor forum, "Cursor CLI - Figma support," January 21, 2026: https://forum.cursor.com/t/cursor-cli-figma-support/149491
Figma MCP remote server docs: https://developers.figma.com/docs/figma-mcp-server/remote-server-installation/
Figma forum, PAT auth request for remote MCP, November 18, 2025: https://forum.figma.com/ask-the-community-7/support-for-pat-personal-access-token-based-auth-in-figma-remote-mcp-47465
JetBrains AI Assistant MCP docs: https://www.jetbrains.com/help/ai-assistant/mcp.html
JetBrains AI Assistant custom model docs: https://www.jetbrains.com/help/ai-assistant/use-custom-models.html

Cursor documentation says the CLI shares MCP configuration with the editor and exposes cursor-agent mcp login for authentication. ↩
Cursor staff acknowledged on January 21-22, 2026 that cursor-agent had a known OAuth issue for remote MCP servers such as Figma and GitHub, with additional user reports still appearing on March 18, 2026. ↩
Figma's remote MCP documentation says the remote server requires OAuth and includes a Codex CLI setup path that prompts for authentication. ↩
This relies on a quoted support reply in the Figma community thread, so treat it as support guidance surfaced through the forum rather than a standalone product-spec page. ↩
JetBrains AI Assistant documentation currently lists STDIO, Streamable HTTP, and SSE as supported transports for MCP servers. ↩
JetBrains documents third-party provider integration through API keys and notes that some feature availability depends on provider and model support. ↩
On March 22, 2026, Figma's remote MCP installation page listed setup guides for Claude Code, Codex by OpenAI, Cursor, and VS Code, but not IntelliJ. ↩

System Design Docs for Flutter Mobile Teams: A Brutal Guide

Nithin — Thu, 25 Sep 2025 10:40:52 +0000

"If you can't explain it simply, you don't understand it well enough."

— Albert Einstein

Why Most System Design Docs Are Useless

You’re a Flutter developer. You want to ship features, not write novels. Yet, your team drowns in system design docs nobody reads. Why? Because most are written for the writer, not the reader. They’re verbose, vague, and quickly outdated. The result: confusion, blame, and wasted time.

When to Write a System Design Doc

Don’t write a system design doc if:

The change is trivial (icon swap, label tweak).
The feature is isolated (debug screen, theme toggle).
You’re prototyping (speed > perfection).

If you can explain it in a Slack message, you don’t need a doc. Just code.

Do write a system design doc if:

You’re touching core system architecture (auth, state, backend).
Other teams are involved (backend, QA, PM).
You’re introducing new architectural patterns (custom BLoC, new dependency).
There are risks (security, compliance, performance).
The feature is controversial (if two devs argue, document it).

If you’re afraid of being blamed later, write the doc now.

The Anatomy of a Brutal System Design Doc

A good system design doc is short, sharp, and actionable. It answers three questions:

What are we building?
Why are we building it this way?
How will we know it works?

Example: Core System Change

# User Authentication System

## Problem
We need secure, fast login. Passwordless preferred.

## Solution
- Use Firebase Auth
- Email/password fallback
- Biometric auth on supported devices

## Architecture
- Stateless backend
- JWT tokens for session
- Secure storage on device

## Risks
- JWT tokens expire in 24h
- Password hashing with bcrypt

## Success Criteria
- Login < 2s
- <5% auth failure

Example: Cross-Team System Feature

# Payment System Integration

## Teams
- Mobile (Frontend)
- Backend (APIs)
- QA (Testing)

## Architecture
- RESTful API for payments
- Secure token exchange
- Error handling strategy

## Timeline
- API Spec: 2025-09-15
- Frontend: 2025-09-20
- QA: 2025-09-25

The Only System Design Doc Structure You Need

Your system design docs should fit in a single directory:

FlutterSystemDocs/
├── Architecture/
│   ├── ADRs/
│   ├── StateManagement.md
│   └── AppStructure.png
├── Features/
│   ├── [Feature]/
│   │   ├── SystemSpec.md
│   │   └── SequenceDiagram.png
├── UI-Kit/
│   ├── WidgetCatalog.md
│   └── Theming.md
├── Platform/
│   ├── iOS.md
│   ├── Android.md
└── RELEASE.md

Anything more is waste.

What to Document

Architecture Decisions: One file per decision. Why Riverpod, not Bloc? Why go_router?
System Flows: Sequence diagrams, data flow, error handling.
Feature Specs: Problem, solution, edge cases, metrics.
Widget Catalog: Screenshot, code, props, usage.
Platform Differences: Only if iOS/Android diverge.

What NOT to Document

Obvious Flutter practices (Scaffold, Container).
Temporary hacks (use code comments).
Every small decision (only long-term impact).

How to Maintain System Design Docs

Update docs in the same PR as code.
Delete outdated docs—don’t mark as deprecated.
Review docs in code reviews. Bad docs block merges.

Why This Works

Focused: Only what matters.
Cross-Platform: Handles iOS/Android differences.
Composable: Widget catalog = design system.
Lightweight: Docs don’t become a project.

The Hard Truth

If your system design docs are a burden, you’re doing it wrong. Good docs:

Are faster to update than to ignore.
Answer common questions before they’re asked.
Help onboard new devs in days, not weeks.

If not, delete and start over.

Final Words

A system design doc is not for you. It’s for the next developer—maybe you in six months. No doc? Own the chaos. Doc? Make it short, brutal, and actionable. No fluff. No "maybe." Decide.

Now stop documenting. Go build something useful.

Finagle’s Fourth Law and BDD

Nithin — Thu, 14 Aug 2025 02:27:42 +0000

You think you’re fixing your app. You’re not. You’re just moving the bugs around. This is not a curse. It’s a feature. The sooner you accept it, the sooner you’ll stop pretending you’re smarter than entropy.

Finagle’s Fourth Law: Once a job is fouled up, anything done to improve it makes it worse.

1. The Law You Break Every Day

Fred Brooks said adding people to a late project makes it later. Finagle said any “improvement” to a broken thing creates new failure modes. You know this. You’ve seen it. You patch a leak, water comes out of the ceiling. You refactor your Flutter state management, and now the UI is stale. Welcome to reality.

2. Bug-Driven Development: The Only Honest Method

Forget “Test-Driven Development.” Forget “Clean Architecture.” Here’s the only process that works:

Fix the bug that hurts the most.
Accept that your fix will create new bugs.
Use those new bugs as clues.
Repeat.

You don’t need a perfect rewrite. You need controlled chaos. Perfection is a myth sold by consultants.

3. Stop Worshipping Patterns

Most teams treat Finagle’s Law as a warning: “Be careful!” They freeze. They design Bloc event/state machines that look like a PhD thesis. They map JSON:API to RFC 9457 with factories and adapters and mappers. They do nothing. BDD says: break things, but break them on purpose.

4. Controlled Breakage: JSON:API vs RFC 9457

If you’ve ever mapped API errors, you know the trap:

// JSON:API
{ "errors": [{ "status": "404", "detail": "Not found" }] }

// RFC 9457
{ "status": 404, "title": "Not Found" }

You want to support both error formats. You will fail. Here’s what you do:

Unify parsing for the format you use most.
When a bug appears in the other format, fix only that branch.
Notice the shared logic. Refactor only when you see it.

Stop pretending you can do everything at once.

5. Responsive Design: The Domino Effect

You scale your UI for tablets. Now buttons are billboards, labels overlap, tap targets are huge. BDD says:

Fix the chart label density.
When small phones get too few labels, extract breakpoint logic.
Let bugs show you where the real problems are.

6. Discipline or Disaster

Finagle + BDD is dangerous. You need discipline:

Keep fixes small. Roll back often.
Test critical paths: prices, rendering, error handling.
Avoid “quick fixes” with global variables and hidden timers.

Without discipline, you’re just firefighting. The goal is to let bugs guide you, not to live in chaos.

7. When Big Bang Rewrites Are Allowed

Sometimes, you need a big rewrite. Rarely.

Modules are isolated.
Technical debt blocks all progress.
Requirements change drastically.
You have strong tests.
The team is ready.

Example: Your monolithic Flutter app can’t handle dynamic modules. You migrate to plugins, write tests, isolate the migration. This is justified. Most rewrites are not.

8. The Final Rules

Small, surgical fixes. Big Bang rewrites are for gamblers.
Bugs are GPS markers. Follow them.
Architect last, refactor always.
Measure every fix. If things get worse, revert.

9. Why No Big Bang?

Big Bang rewrites break everything. Controlled fixes isolate issues, measure impact, and let you revert. Shrink the blast radius. Don’t gamble the system.

10. What Is a Fouled Up Job?

A job is “fouled up” when any change is risky. Complexity, technical debt, workarounds. In these cases, even good intentions create new bugs. BDD with Finagle’s Law accepts this. Bugs are signposts. Clean up in small, reversible steps.

Examples:

Integrating APIs: Add a small adapter for the new format. Keep the old one. Fix only what breaks.
Domain Layer Mess: Extract business logic for one feature. Use bugs to guide the next extraction.
Global State: Replace it in the worst widget first. Use new bugs to find the next target.

Bottom line:

Finagle’s Fourth Law is not a curse. It’s reality. Bug-Driven Development uses it as a compass. Don’t avoid making things worse. Make them worse in controlled ways, so you can make them better.

In Flutter, this means smaller migrations, isolated logic, and never believing a pattern will save you.

Entropy wins. You can only play along.

Stop Lying in Daily Standups

Nithin — Thu, 31 Jul 2025 18:18:47 +0000

Daily standups are a theater. Every developer knows it. You stare at Slack, try to remember what you did, lie a little, and type something vague like “worked on the dashboard bug.” Rinse. Repeat.

I stopped doing that. Now my commits tell the truth. I wrote a Shell script. It reads my Git logs, filters by my email, and generates my standup notes. That’s it. No Jira. No Notion. No retrospection gymnastics. Just Git, Terminal, and Copilot.

And yes, it saves me time. But more importantly, it eliminates human memory from the equation. Memory lies. Commits don’t.

The Stack (If You Care)

VSCode (because Emacs is dead)
Git (the only real source of truth)
GitHub Copilot (to type what I don’t want to)
Google Sheets (don’t ask)
Slack (optional, unfortunately)

How It Works

I write code.
I commit often, with Copilot writing the messages.
At the end of the day, I run a script.
The script reads recent commits based on time of day.
The output becomes my standup report.
I paste it where the team expects me to.

That’s it. No plugin. No integration. Just plain text.

The Script That Does My Job

#!/bin/bash

REPO1_PATH="/path/to/project-one"
REPO2_PATH="/path/to/project-two"
AUTHOR="your.email@example.com"

if [[ "$OSTYPE" == "linux-gnu"* ]]; then
    alias date="date --date"
fi

HOUR=$(date +%H)
if [[ "$OSTYPE" == "linux-gnu"* ]]; then
    if [ "$HOUR" -lt 12 ]; then
        START_DATE=$(date -d "yesterday" "+%Y-%m-%d")
    else
        START_DATE=$(date "+%Y-%m-%d")
    fi
    DAY_OF_WEEK=$(date -d "$START_DATE" "+%u")
else
    if [ "$HOUR" -lt 12 ]; then
        START_DATE=$(date -v -1d "+%Y-%m-%d")
    else
        START_DATE=$(date "+%Y-%m-%d")
    fi
    DAY_OF_WEEK=$(date -j -f "%Y-%m-%d" "$START_DATE" "+%u")
fi

if [ "$DAY_OF_WEEK" -eq 6 ] || [ "$DAY_OF_WEEK" -eq 7 ]; then
    START_DATE=$(date -v -Fri "+%Y-%m-%d")
fi

START="${START_DATE}T00:00:00"
END="${START_DATE}T23:59:59"

echo "What we did on ${START_DATE}"
echo "==========================================="

{
    git -C "$REPO1_PATH" log --author="$AUTHOR" --since="$START" --until="$END"         --pretty=format:"- %s" --abbrev-commit --no-merges
    git -C "$REPO2_PATH" log --author="$AUTHOR" --since="$START" --until="$END"         --pretty=format:"- %s" --abbrev-commit --no-merges
} | sort | uniq

echo "==========================================="
echo "End of Update"

Output That Doesn’t Embarrass Me

What we did on 2025-07-23
===========================================
- Refactor: Adjust padding in Combined OI screen
- Add: Support for toggle between chart and table views
- Fix: Crash on missing data in open interest API
- Chore: Remove unused debug logs from dashboard
- Update: Improve spacing in TopBanner layout
===========================================
End of Update

Google Sheets: My Personal Logbook

Each row is a day. Each cell is a commit log. Meetings, code reviews, discussions—those get manually added. I don’t mind. It’s five lines. I don’t write novels.

Performance Reviews Without Anxiety

When the cycle begins, I open the sheet. I trim the log into a focused summary—no digging, just filtering.

It’s unemotional. And it’s honest. Try doing that with Jira.

For Teams

Want your team to stop pretending they were “looking into a few things”?

Let them run the same script with their email. Keep it local. Keep it personal. If you want, post it in a shared thread. But don’t centralize it. Autonomy matters.

Want to Try?

Save the script as update_scrum.sh
Run chmod +x update_scrum.sh
Replace the paths and author email
Run it: ./update_scrum.sh
Pipe output to file (optional): ./update_scrum.sh > daily_log_2025-07-23.md

Final Thought

Most standups are lies. This one isn’t.

Write code. Commit often. Let Git speak for you.

Dart and Exception Handling: No Guardrails, Only Discipline

Nithin — Thu, 31 Jul 2025 17:13:30 +0000

Have you ever relied on Dart’s throw and thought, “Great—now my callers are forced to handle this”? Think again. In Java and its cousins, exception chaining is a first-class citizen: you catch, chain, and let the compiler enforce your discipline. In Dart (and by extension Flutter), you’re on your own.

Exception Chaining in Java: A Quick Recap

Java’s checked exceptions bite when they must. If a method declares throws IOException, every caller up the chain either handles it or propagates it. And when you rethrow, you do it right:

try {
  riskyOperation();
} catch (IOException e) {
  throw new MyAppException("failed to do the thing", e);
}

That little , e preserves the stack trace and makes debugging a dream. Learn more on exception chaining Wikipedia.

Dart’s “Freedom” Feels a Lot Like No Guardrails

Dart’s type system doesn’t distinguish between checked and unchecked exceptions—all are unchecked. You can write:

void doSomethingRisky() {
  throw StateError('something went terribly wrong');
}

…and your callers aren’t even reminded to catch it. There’s no compiler error, no warning—nothing. You have to remember, by convention, that doSomethingRisky() might explode.

Even `Result<T>` Patterns Don’t Save You

“Okay,” you say, “I’ll wrap everything in a Result<T> so that forgetting to handle it is impossible.” Not quite. In Dart:

final result = await getUser();

There’s… nothing stopping you from parking result in a corner, ignoring its .isSuccess, and then accessing .value. At runtime? Boom—a throw you forgot to anticipate. You traded one potential uncaught exception for another.

Catching Errors (If You Care)

A good rule of thumb is “catch if you can, otherwise let it bubble”—but since Dart never forces you to catch in the first place, the habit rarely forms. Consider these behaviors:

Dart	Effect
No catch	Bubbles up silently—no compile-time reminder
`catch (e) { rethrow; }`	Bubbles up with original stack trace
`catch (e) { throw e; }`	Bubbles up losing original stack trace

Nullable Responses: The Invisibility Cloak

Returning T? or Future<T?> might seem like a gentle way to sidestep exceptions:

Future<User?> fetchUser() async {
  try {
    return await api.getUser();
  } catch (e) {
    log(e);
    return null;
  }
}

But now, instead of an explicit error, all you have is a silent null. The real crime? You’ve lost the ability to bubble up the original error. The stack trace, the exception type, the context—all vanished in the void. Without that, diagnosing failures becomes a wild goose chase.

A Pragmatic Prescription

Be deliberate. Whether you throw or return null (or wrap in Result), pick a convention and document it.
Catch at the edges. Localize unchecked exceptions at boundaries—UI layer, service layer—where you can log and recover.
Preserve your traces. If you catch and rethrow, use rethrow so the original stack isn’t lost.
Enforce via tooling. Automate linting to flag un-caught futures or raw throw without surrounding try/catch.
Educate your team. Habits form from code reviews: make error-handling expectations crystal clear.

Dart may not force error handling—but with discipline, conventions, and the right practices, you can. Catch if you can; otherwise, be ready to bear the pain.

Creating a Line Chart with Secondary Y-Axis in Flutter

Nithin — Fri, 06 Dec 2024 09:25:37 +0000

In this guide, we’ll explore how to create a line chart in Flutter with a secondary Y-axis for datasets that have different scales. By using fl_chart, we’ll develop a flexible charting solution that works for any generic data.

Why a Secondary Y-Axis?

Sometimes, two datasets that share an X-axis (e.g., timestamps) but have different Y-axis scales need to be visualized together. For example:

Primary Y-Axis: Represents Dataset A.
Secondary Y-Axis: Represents Dataset B (on a different scale).

Above image displays the need for secondary y-axis in certain scenarios. Sample 1 represents single y axis. Sample 2 represents dual y-axis with scaling

Step 1: Define the Data for the Chart

First, define two datasets that will be plotted on the chart. In our example, these datasets will represent different measurements that we wish to compare over time.

List<double> primaryData = [10, 20, 15, 30, 25];  // Dataset A
List<double> secondaryData = [50, 100, 75, 200, 150];  // Dataset B
List<String> xAxisLabels = ["Jan", "Feb", "Mar", "Apr", "May"];  // X-Axis labels (time, categories, etc.)

Step 2: Create the Widget for the Chart

Now, create a new Flutter widget that will display the chart. We will use the LineChart widget from fl_chart.

2.1 Define the Widget Class

class DualAxisLineChart extends StatelessWidget {
  const DualAxisLineChart({
    super.key,
    required this.primaryData,
    required this.secondaryData,
    required this.xAxisLabels,
    required this.primaryColor,
    required this.secondaryColor,
    required this.scaleSecondaryData,
  });

2.2 Define Chart Properties

primaryData and secondaryData: Lists of values for the primary and secondary data lines.
xAxisLabels: A list of X-axis labels (e.g., months or categories).
primaryColor and secondaryColor: Colors for the primary and secondary data lines.
scaleSecondaryData: A function to scale the secondary data to fit within the primary Y-axis.

2.3 Build the LineChart Widget

@override
Widget build(BuildContext context) {
  return Padding(
    padding: const EdgeInsets.all(16.0),
    child: LineChart(
      LineChartData(
        gridData: _buildGridData(),
        titlesData: _buildTitlesData(),
        lineBarsData: _buildLineBarsData(),
        borderData: FlBorderData(show: true),
      ),
    ),
  );
}

2.4 Define Grid Data

Configure the grid lines using FlGridData. This section will make the chart's background grid visible. Modify as per requirement.

FlGridData _buildGridData() {
  return FlGridData(
    drawVerticalLine: false,
    getDrawingHorizontalLine: (_) => FlLine(
      color: Colors.grey[300]!,
      strokeWidth: 0.5,
    ),
  );
}

2.5 Define Titles Data

Use FlTitlesData to configure the axis titles. You will define both left (primary Y-axis), right (secondary Y-axis), and bottom (X-axis) titles.

FlTitlesData _buildTitlesData() {
  return FlTitlesData(
    /// display underlying price on right side. utilise scaling to emulate second y-axis.
      rightTitles: AxisTitles(
          sideTitles: SideTitles(
              showTitles: true,
              getTitlesWidget: (double value, TitleMeta meta) {
                final int tentativeIndex =
                    ((meta.axisPosition / meta.parentAxisSize) * secondaryData.length)
                        .toInt();
                final int index = tentativeIndex.clamp(0, secondaryData.length - 1);
                return Text(
                  text: // TODO: format text and set,
                );
              })),
    /// empty top axis
    topTitles: const AxisTitles(),
    // TODO: define other title here similarly
  );
}

2.6 Define Line Data for Both Axes

The lineBarsData section defines the lines for both datasets. We will use LineChartBarData to create a line for each dataset. Utilise FlDotData to specify points on the graph to draw the line through.

List<LineChartBarData> _buildLineBarsData() {
  return [
      LineChartBarData(
        color: primaryColor,
        barWidth: barWidth.r,
        dotData: const FlDotData(show: false),
        spots: primaryData.mapIndexed((int index, double value) {
          return FlSpot(index.toDouble(), value);
        }).toList(),
      ),
      LineChartBarData(
        color: secondaryColor,
        barWidth: barWidth.r,
        dotData: const FlDotData(show: false),
        spots: secondaryData.mapIndexed((int index, double value) {
          return FlSpot(index.toDouble(), scaleSecondaryData(value));
        }).toList(),
        dashArray: <int>[5, 5],
      )
  ];
}

For each dataset, the LineChartBarData defines how the line is drawn.
scaleSecondaryData: A function that scales the data to fit the chart’s axis.
dashArray: this will render the secondary line as dashed specifying width and gap.

Step 3: Define a Scaling Function for the Secondary Data

To ensure the secondary dataset fits within the scale of the primary Y-axis, we need to create a scaling function. This function will adjust the secondary data to match the range of the primary data.

double scaleSecondaryData(double value) {
  double primaryMin = 10;
  double primaryMax = 30;
  double secondaryMin = 50;
  double secondaryMax = 200;

  double primaryRange = primaryMax - primaryMin;
  double secondaryRange = secondaryMax - secondaryMin;

  return primaryMin + (value - secondaryMin) * (primaryRange / secondaryRange);
}

Step 4: Create the Widget to Display the Chart

Now, we will create a MaterialApp widget and add the chart widget to the screen.

void main() {
  runApp(MaterialApp(
    home: Scaffold(
      appBar: AppBar(title: Text("Dual Axis Line Chart")),
      body: DualAxisLineChart(
        primaryData: [10, 20, 15, 30, 25], // Example Dataset A
        secondaryData: [50, 100, 75, 200, 150], // Example Dataset B
        xAxisLabels: ["Jan", "Feb", "Mar", "Apr", "May"], // Example X-axis
        primaryColor: Colors.blue,
        secondaryColor: Colors.red,
        scaleSecondaryData: scaleSecondaryData,
      ),
    ),
  ));
}

Step 5: Run the Application

After implementing the above code, run your Flutter app, and you should see a line chart with two Y-axes. The primary data will be on the left Y-axis, while the secondary data will be scaled to fit the primary Y-axis and shown on the right.

Conclusion

You have now successfully created a line chart in Flutter with a secondary Y-axis! This approach can be used to compare two datasets with different ranges, such as temperatures and rainfall, stock prices and trading volume, or any other comparable metrics.

Feel free to adjust the styling, scaling, and data to suit your specific use case. The fl_chart package provides a lot of flexibility to customize your chart to your needs.

Links

fl_chart widgets
Pub Package

Testing Dependent Events in Flutter Bloc: Seeding State & Handling Multiple Events

Nithin — Tue, 30 Jul 2024 10:55:02 +0000

In Flutter Bloc testing, there are two main approaches to test the dependent Event in scenarios where the Event in test depends on the outcome of a previous event: seeding the state or calling a pre-event with skip. Both methods have their own advantages and disadvantages.

Seeding State

Advantages

Direct Control: You can directly set the Bloc's state to a desired state without having to dispatch any events. This provides a precise starting point for your tests.
Simplicity: Seeding is straightforward and easy to understand, as it eliminates the need for additional event handling and state transitions.

Disadvantages

Unrealistic Testing: Directly seeding a state might not accurately reflect the real-world usage of your Bloc, where states are typically reached through event dispatching and state transitions.
Initialization Complexity: Creating and passing the correct initial state can be complex, especially when the state has multiple parameters or requires specific configurations.
Limited Coverage: This approach may not cover all the transitions and side effects that occur when events are dispatched, potentially missing bugs in event handling logic.

Calling Pre-Event with Skip

Advantages

Realistic Testing: By dispatching events to reach a desired state, you mimic the actual behavior of your application, ensuring that all transitions and side effects are covered.
Efficient Event Handling: Often, setting up the initial state by dispatching a pre-event is straightforward and may be simpler than manually constructing a complex state.
Thorough Coverage: This approach tests the entire flow, from event dispatch to state transition, providing a more comprehensive test of your Bloc's logic.

Disadvantages

Event Dependency: If your tests require many pre-events to reach a desired state, it can make the test setup more verbose, although each individual pre-event is typically simple to add.
Performance: Dispatching multiple events to reach the desired state can slow down your tests, especially if there are many intermediate states. However, this is usually a minor issue for most test cases.

Example in Flutter Bloc Test

Seeding State

blocTest(
  'CounterBloc emits [10] when seeded with 9',
  build: () => CounterBloc(),
  seed: () => 9,
  act: (bloc) => bloc.add(CounterEvent.increment),
  expect: () => [10],
);

Calling Pre-Event with Skip

blocTest<MyBloc, MyBlocState>(
  'emits [MyBlocState] when SearchItemEvent is added',
  build: () => MyBloc(),
  act: (bloc) {
    bloc.add(ListItemsEvent()); // Start with loading the list
    bloc.add(SearchItemEvent(item: 'Apple')); // Start searching loaded list
  },
  skip: 2, // Skip emissions for intermediate states if not needed
  expect: () => [
    MyBlocState(filteredList: ['Green Apple', 'Red Apple'])
  ],
);

Summary

Use Seeding State When: You need to quickly set up a simple initial state, or when you are testing scenarios where event-driven transitions are either not needed or not practical like in above example.

Avoid Seeding State When: Your focus is on understanding how your Bloc reacts to sequences of events, how it transitions between states, or when you want to ensure that all parts of the Bloc’s behavior are tested as they would occur in a live application.

In practice, a combination of both methods might be useful depending on the scenario. Seeding can be a useful tool, but it’s important to ensure that it aligns with the objectives of your tests and does not bypass critical event-driven logic.

Feel free to share your thoughts and experiences in the comments below!

How to Write BLoC Tests to Improve Code Quality

Nithin — Sun, 28 Jul 2024 09:23:41 +0000

// Detect dark theme var iframe = document.getElementById('tweet-1213571513439399936-113'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1213571513439399936&theme=dark" }

In the world of Flutter development, testing is paramount to ensuring robust and maintainable applications. Among the various testing strategies, BLoC (Business Logic Component) testing stands out for its ability to convert events into states, whether synchronously or asynchronously. Writing BLoC tests can significantly enhance code quality, uncover hidden issues, and ensure that your state management logic is sound. In this article, we'll explore how to write effective BLoC tests using the bloc_test library and provide practical pseudocode examples.

What is the BLoC Pattern?

The BLoC pattern is a state management solution that separates business logic from UI components. It uses streams to handle the flow of data, allowing events to trigger state changes in a predictable and testable way. The BLoC pattern is widely adopted in Flutter applications for its scalability and maintainability.

Why Write BLoC Tests?

Improving Code Quality

The primary goal of BLoC testing is to improve code quality. By thoroughly testing all events and state transitions, you can:

Uncover Hidden Events: Identify events that aren’t triggered from the UI.
Avoid Spaghetti Code: Prevent complex and tangled state transitions.
Simplify State Management: Ensure that most events only emit one or two states (usually loading and success/failure).
Adhere to SOLID Principles: Identify and remove unnecessary data and business logic from repository methods.

// Detect dark theme var iframe = document.getElementById('tweet-1596031809229565952-449'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1596031809229565952&theme=dark" }

Getting Started with BLoC Testing

1. Set Up Your Test Environment

Add the bloc_test library to your pubspec.yaml:

dev_dependencies:
  bloc_test: ^8.0.0

2. Create Test Repositories

Implement two versions of your abstract repository class: one for success and one for failure. Use real JSON samples from the API or create samples using AI tools like Gemini or Copilot.

class SuccessTestRepository extends AbstractRepository {
  @override
  Future<Response> fetchData() async {
    return Response(successJson);
  }
}

class FailureTestRepository extends AbstractRepository {
  @override
  Future<Response> fetchData() async {
    throw Exception('Failed to fetch data');
  }
}

3. Set Up BLoC Instances

Create instances of your BLoC in the main testing function, one with the success repository and one with the failure repository.

void main() {
  group('BLoC Tests', () {
    late MyBloc successBloc;
    late MyBloc failureBloc;

    setUp(() {
      successBloc = MyBloc(SuccessTestRepository());
      failureBloc = MyBloc(FailureTestRepository());
    });

    tearDown(() {
      successBloc.close();
      failureBloc.close();
    });

    // Add tests here
  });
}

4. Write Tests Using blocTest

For each event, write a test that describes the expected behavior. Use the blocTest function to test the BLoC instance, adding events and asserting the resulting states.

blocTest<MyBloc, MyState>(
  'emits [Loading, Success] for FetchDataEvent - success',
  build: () => successBloc,
  act: (bloc) => bloc.add(FetchDataEvent()),
  expect: () => [
    isA<LoadingState>(),
    isA<SuccessState>().having((state) => state.data.isNotEmpty, 'data list not empty', true),
  ],
);

blocTest<MyBloc, MyState>(
  'emits [Loading, Failure] for FetchDataEvent - failure',
  build: () => failureBloc,
  act: (bloc) => bloc.add(FetchDataEvent()),
  expect: () => [
    isA<LoadingState>(),
    isA<FailureState>().having((state) => state.error, 'error', isNotEmpty),
  ],
);

5. Handle Edge Scenarios

For edge scenarios where certain states depend on previous events, add the list of events in the act method. Use the skip method to isolate the test.


blocTest<MyBloc, MyState>(
  'emits [Loading, Success] after pre-event',
  build: () => successBloc,
  act: (bloc) {
    bloc.add(PreEvent()); // previous event
    bloc.add(FetchDataEvent()); // the dependant event
  },
  skip: 2, // skip states produced by one or more preceding events
  expect: () => [
    isA<LoadingState>(),
    isA<SuccessState>(),
  ],
);

6. Document Edge Case Tests

Make sure to document edge case tests with comments and keep them simple. This practice helps in understanding the context and reasoning behind certain tests, especially when dealing with complex scenarios.

7. Run Tests with Coverage

Ensure comprehensive test coverage by running tests with coverage reporting. Use the following command to generate coverage reports:

flutter test --coverage
genhtml coverage/lcov.info -o coverage/html

Using `isA` and `having` Matchers

The isA and having functions are powerful tools in Dart's testing framework, allowing for granular and precise state validation. Using these matchers, you can ensure that the emitted states not only belong to a certain type but also contain specific values or properties.

Example:

Consider a BLoC that fetches user data. You want to test that the SuccessState contains the correct user data.

blocTest<MyBloc, MyState>(
  'emits [Loading, Success] with correct user data',
  build: () => successBloc,
  act: (bloc) => bloc.add(FetchUserEvent()),
  expect: () => [
    isA<LoadingState>(),
    isA<SuccessState>().having((state) => state.user.id, 'id', equals(1))
                        .having((state) => state.user.name, 'name', equals('John Doe')),
  ],
);

In this example, isA<SuccessState>() verifies the state type, while having checks the specific properties of the state.

Benefits of Nested Matchers

Precision: Ensure that the state not only matches a type but also contains expected values.
Readability: Provide clear, readable assertions about the expected state.
Debugging: Easier to debug when tests fail, as the error messages specify which part of the state did not meet the expectations.

Best Practices for BLoC Testing

Write Descriptive Test Names: Ensure that your test names clearly describe the scenario being tested.
Test One Thing at a Time: Focus on testing a single event or state transition in each test.
Keep Tests Independent: Ensure that tests do not depend on the outcome of other tests.
Use Realistic Data: Use real API data or realistic mock data to make your tests more robust.
Review and Refactor: Regularly review and refactor your tests to improve readability and maintainability.

Community Resources

Conclusion

Writing BLoC tests is a rewarding endeavor that significantly improves code quality. By converting events into states and testing these transitions, you can uncover hidden issues, simplify state management, and adhere to best practices. With tools like the bloc_test library and matchers like isA and having, writing these tests becomes a structured and systematic process. Happy testing!

DEV Community: Nithin

The best AI workbench is not an IDE

Short verdict

Cursor is strongest when you stay inside Cursor

The real test is OAuth, not chat quality

IntelliJ is still the best room in the house

Codex CLI solves the right problem

The bridge matters more than the model

The bug that weakens trust

Comparison in practice

The resulting workbench

Conclusion

Sources

System Design Docs for Flutter Mobile Teams: A Brutal Guide

Why Most System Design Docs Are Useless

When to Write a System Design Doc

The Anatomy of a Brutal System Design Doc

Example: Core System Change

Example: Cross-Team System Feature

The Only System Design Doc Structure You Need

What to Document

What NOT to Document

How to Maintain System Design Docs

Why This Works

The Hard Truth

Final Words

Finagle’s Fourth Law and BDD

1. The Law You Break Every Day

2. Bug-Driven Development: The Only Honest Method

3. Stop Worshipping Patterns

4. Controlled Breakage: JSON:API vs RFC 9457

5. Responsive Design: The Domino Effect

6. Discipline or Disaster

7. When Big Bang Rewrites Are Allowed

8. The Final Rules

9. Why No Big Bang?

10. What Is a Fouled Up Job?

Stop Lying in Daily Standups

The Stack (If You Care)

How It Works

The Script That Does My Job

Output That Doesn’t Embarrass Me

Google Sheets: My Personal Logbook

Performance Reviews Without Anxiety

For Teams

Want to Try?

Final Thought

Dart and Exception Handling: No Guardrails, Only Discipline

Exception Chaining in Java: A Quick Recap

Dart’s “Freedom” Feels a Lot Like No Guardrails

Even Result<T> Patterns Don’t Save You

Catching Errors (If You Care)

Nullable Responses: The Invisibility Cloak

A Pragmatic Prescription

Creating a Line Chart with Secondary Y-Axis in Flutter

Why a Secondary Y-Axis?

Step 1: Define the Data for the Chart

Step 2: Create the Widget for the Chart

2.1 Define the Widget Class

2.2 Define Chart Properties

2.3 Build the LineChart Widget

2.4 Define Grid Data

2.5 Define Titles Data

2.6 Define Line Data for Both Axes

Step 3: Define a Scaling Function for the Secondary Data

Step 4: Create the Widget to Display the Chart

Step 5: Run the Application

Conclusion

Links

Testing Dependent Events in Flutter Bloc: Seeding State & Handling Multiple Events

Seeding State

Advantages

Disadvantages

Calling Pre-Event with Skip

Advantages

Disadvantages

Example in Flutter Bloc Test

Seeding State

Calling Pre-Event with Skip

Summary

Even `Result<T>` Patterns Don’t Save You

Using `isA` and `having` Matchers