Abdur Rahman — Writing

You’re Using Claude. Here’s How to Make It More Useful in Your Daily Work.

riyad.abdur@gmail.com (Abdur Rahman) — Sun, 25 Oct 2026 00:00:00 GMT

You ask Claude to fix a bug. It makes a reasonable change.

Then comes the follow-up:

“Use pnpm.”

“Don’t include those unrelated files.”

“Check how we handle this elsewhere.”

“Run the formatter.”

Each instruction is small. Together, they leave you supervising details you’ve already explained.

Claude has features that help with this, but the names can be confusing. Skills. Hooks. Subagents. MCP. Cowork. It takes a little work to understand where each one fits.

The useful question is: what problem would I actually use this for?

Let’s work through that using situations developers recognize: investigating a bug, committing changes, preparing release notes, and checking a spreadsheet against a CRM.

The configurations are examples you can adapt. The sample findings and results are illustrative, so you know what to look for when trying them yourself.

Start by giving Claude a task it can investigate

Imagine a customer enquiry appears in a spreadsheet but never reaches your CRM.

You could ask:

Fix the missing leads.

But “missing” leaves a lot open. Did the webhook arrive? Did the queue job run? Was a contact created without a lead? Did the lead enter another pipeline?

A more useful request would be:

Investigate why submission TEST-002 did not appear in the CRM.

Trace the webhook handler, queue job, and CRM creation request.
Check whether it failed, was skipped, or created a lead elsewhere.

Show the relevant files and evidence before proposing changes.
An existing contact does not necessarily mean a lead exists.

You’ve given Claude an identifier, an investigation path, and a business rule that affects the answer.

For a substantial change, Claude Code’s Plan mode lets it investigate and propose an approach before implementation. Ask for the smallest proposed fix and how it would be verified.

This also makes the response easier to assess. “The retry logic is broken” is a hypothesis. A specific condition in a specific handler gives you something to examine.

The project facts you keep repeating belong in `CLAUDE.md`

You explain that the repository uses pnpm. Later, Claude suggests npm.

You explain that controllers should stay thin. Another session puts business logic in a controller.

Claude Code loads project guidance from CLAUDE.md. You can run /init to generate a starting version, then edit it to reflect how your team actually works.

For a NestJS project, it might contain:

# Working in this repository

- Use pnpm.
- Keep controllers thin; business logic belongs in services.
- Validate webhook payloads before enqueueing jobs.
- Use source submission IDs for duplicate detection.
- Database changes require migrations.
- Run relevant checks and report their actual results.

Now consider the next request:

Add duplicate protection to the lead-import handler.

Claude has a starting point for deciding where the logic belongs and which identifier matters.

That doesn’t guarantee a correct implementation. It makes your expectations explicit and available across sessions.

Keep this file focused on facts that change decisions. “Write clean code” gives little direction. “Use the source submission ID for duplicate detection” can prevent a particular mistake.

Also, maintain it. An instruction describing an old queue system can send Claude in the wrong direction long after your code has changed.

A skill saves a procedure you want to reuse

Project conventions don’t fully describe how you want a particular task completed.

Committing changes is a good example. You may want Claude to inspect the diff, exclude unrelated work, stage carefully, and write a message in your preferred format.

Create:

.claude/skills/commit/SKILL.md

Add:

---
name: commit
description: Review and commit changes belonging to the current task.
disable-model-invocation: true
---

Inspect git status, unstaged changes, and staged changes.

Identify changes belonging to the current task.
Ask if unrelated changes cannot be separated confidently.

Stage only the intended files or hunks.
Review the staged diff before committing.

Write a concise Conventional Commit message explaining
the behavior changed.

Create the commit and report its hash and message.
Report which checks ran and which did not.
Do not push or amend unless requested.

Then type:

/commit

Suppose the working tree contains:

M src/leads/lead-import.service.ts
M src/leads/lead-import.service.spec.ts
M docs/pricing-notes.md

The current task concerns importing leads. The pricing notes belong to something else.

A useful result would identify that distinction, commit the relevant changes, and tell you what remains uncommitted. The message might be:

fix(leads): prevent duplicate imports for the same submission

The frontmatter controls how the skill is discovered and invoked. The body describes the procedure.

Here, disable-model-invocation: true means you explicitly trigger the skill. Without that restriction, Claude can select relevant skills based on their descriptions. Invoking a skill does not bypass tool permissions.

The benefit is consistency. You can review and improve the procedure once, then reuse it.

Skills also help with the work after coding

Think about release notes.

A developer-facing change might say:

Add a unique constraint on source_submission_id and handle conflicts.

A customer-facing note could say:

Fixed an issue where repeated form submissions could create
duplicate leads.

That translation is another good skill:

---
name: release-notes
description: Draft customer-facing release notes from a supplied diff or commit range.
---

Identify changes users will notice.

Group them under Added, Improved, and Fixed.
Explain observable behavior in plain language.
Exclude internal refactoring unless it affects users.
Do not invent benefits or claim unreleased changes are live.

Return a draft for review.

Save it as .claude/skills/release-notes/SKILL.md, then ask:

/release-notes Use the changes between v1.8.0 and v1.9.0.

The review still matters. If the draft claims “faster imports,” there should be evidence for that claim. A refactoring commit alone doesn’t establish a performance improvement.

Build skills around procedures you genuinely repeat: API reviews, migration planning, incident summaries, or onboarding notes. A small collection of specific skills is easier to maintain than dozens you rarely use.

A hook handles a step you want to happen automatically

Some tasks are mechanical enough to attach directly to an event.

Formatting is one. You probably don’t want to remind Claude to run Prettier after every edit.

Claude Code hooks can run commands at defined points in its workflow. PreToolUse happens before a tool executes; PostToolUse happens after a tool succeeds.

For a project with Bash, jq, and locally installed Prettier, create .claude/hooks/format.sh:

#!/usr/bin/env bash
set -euo pipefail

edited_file=$(jq -er '.tool_input.file_path')
cd "$CLAUDE_PROJECT_DIR"

./node_modules/.bin/prettier \
  --write \
  --ignore-unknown \
  "$edited_file"

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/format.sh\""
          }
        ]
      }
    ]
  }
}

Merge this with your existing settings.

When Claude successfully uses Edit or Write, the hook receives the event data, extracts the file path, and runs Prettier on that file.

Run /hooks to inspect the configuration. Then ask Claude to make a small edit in a disposable file and check whether the formatting follows your project configuration.

This example has clear boundaries. It doesn’t catch files rewritten through Bash. It requires its dependencies to be installed. And because it runs afterward, it cannot prevent the original edit.

For checks that should apply to every developer and every commit, keep Git hooks or CI involved too.

A smaller hook can save you from watching the terminal

You start an investigation, switch windows, and discover later that Claude has been waiting for input.

On macOS, a Notification hook can display a desktop notification. Add this event inside your existing "hooks" object:

"Notification": [
  {
    "matcher": "",
    "hooks": [
      {
        "type": "command",
        "command": "osascript -e 'display notification \"Claude needs your attention\" with title \"Claude Code\"'"
      }
    ]
  }
]

This runs when Claude Code emits a matching notification event. macOS notification permissions must allow the notification to appear.

It’s a modest improvement, but it makes longer tasks easier to leave running while you work elsewhere.

A subagent can investigate one question without overwhelming the main conversation

Back to duplicate leads.

The investigation might involve a webhook handler, a queue worker, a CRM client, and database constraints. You need the findings, but you don’t necessarily need every intermediate file read in the main conversation.

Create .claude/agents/lead-investigator.md:

---
name: lead-investigator
description: Investigates missing or duplicate leads across webhook, queue, database, and CRM code.
tools: Read, Grep, Glob
model: inherit
---

Investigate the supplied issue without changing files.

Trace the relevant processing flow.
Separate confirmed evidence from hypotheses.
Cite files and functions supporting each finding.

Return:
- Likely cause
- Evidence
- Unresolved questions
- A suggested way to verify the finding

Then ask:

Use lead-investigator to check whether two workers could
create leads for the same submission.

A hypothetical report might say:

Finding:
Both workers can pass the duplicate lookup before either
records the submission as processed.

Evidence:
The lookup and insert are separate operations, and the schema
has no unique constraint on the submission identifier.

Verification:
Process two jobs concurrently with the same submission ID.

The main Claude session now has a specific hypothesis to examine.

You can ask it to check the evidence and propose a fix. A local database constraint might protect local records, while preventing duplicate remote CRM requests also requires attention to retries and when external IDs are stored.

A custom subagent has its own context and configurable tools. The main session must pass the details needed for the task. In this example, the tool list limits the worker to reading and searching.

Subagents consume usage and add overhead. They’re useful for substantial, focused investigations. A one-line change rarely needs several workers.

Separate context also doesn’t automatically mean separate files. Agents with editing tools may affect the same checkout unless you arrange filesystem isolation.

MCP gives Claude a way to reach your actual tools

Reading the repository shows what the application intends to do. Sometimes you need to inspect what actually happened in the CRM.

MCP stands for Model Context Protocol. It provides a standard interface for exposing tools and data to AI applications. A connector can make operations backed by your own services available to Claude.

For example, you could implement:

findLeadBySubmissionId(submissionId)
getLeadNotes(leadId)
createLead(input)

These are illustrative custom tools, not built-in Kommo commands.

A tool request could look like:

{
  "tool": "findLeadBySubmissionId",
  "arguments": {
    "submissionId": "TEST-002"
  }
}

Your server responds:

{
  "matches": [],
  "searchComplete": true
}

Claude can use that result to propose creating the missing lead.

But consider a different response:

{
  "error": "CRM request timed out",
  "searchComplete": false
}

That is not evidence that the lead is missing.

This is why tool design matters. An empty result and a failed search need different representations. Otherwise, a temporary API failure could become a duplicate record.

For an API integration, your server stores the credentials. Claude requests an operation; your backend validates the request, checks authorization, calls the provider, and returns the result.

Cowork can handle the operational side of the same problem

Claude Code helps you investigate and change the integration.

Cowork brings agent capabilities to work involving documents, spreadsheets, connected applications, and browser tasks. What it can do depends on the tools and access available in your setup.

Our project has an operational problem as well as an engineering problem.

The engineer needs to fix duplicate handling. The operations team needs to identify which enquiries were missed.

Try a small experiment with fictional data:

Submission	In the sheet?	In the CRM?
TEST-001	Yes	Yes
TEST-002	Yes	No
TEST-003	Yes	No

Give Claude this assignment:

Compare these three submissions with the CRM.

Match by submission ID and include matching lead links.
An existing contact alone does not prove a lead exists.

Report Existing, Missing, or Uncertain.
Prepare the proposed additions for review.

The expected result is one existing lead and two missing leads.

After checking the comparison, authorize the two creations and ask Claude to record their URLs in the sheet. Then repeat the comparison.

The second run should find three existing leads and create nothing.

That repeat run tells you something valuable. A workflow that succeeds once but duplicates records on retry needs more work.

For browser-based experiments, start small enough that you can inspect every action and result.

Having access and having approval are different things

A CRM token may allow your application to create thousands of records. Your task may authorize creating two.

Your application should enforce that smaller scope.

For custom tools, check the authenticated customer, permitted account, allowed pipeline, and approved actions in backend code.

A tool call containing approved: true is not proof that a human approved anything. That decision needs to come from trusted application state.

Similarly, “never delete records” in a prompt is useful guidance, but removing deletion capability provides a stronger restriction.

Claude Code’s Auto mode concerns permission handling for tool actions. It doesn’t establish that Claude understood the requirements or that a code change is correct.

Review the result with the same questions you would ask another developer: what changed, why, and what evidence supports it?

Sometimes a scheduled job is still the right answer

While learning about agents, I kept coming back to this question:

“I can already build this with NestJS. Why would I need an agent?”

Suppose the rule is to read new rows every morning and create missing CRM records. A scheduled backend job may be the simplest implementation.

The sequence is known. Retries, duplicate protection, and failure handling can be explicit.

An agent becomes useful when the next step depends on interpreting what it discovers.

One customer asks about delivery, so it retrieves the delivery policy. Another asks to be contacted next month, so it proposes a reminder. A third already received an answer, so it skips another follow-up.

The sequence changes because the information changes.

You can also combine ordinary software with a bounded AI step. Let code control eligibility, scheduling, and sending while a model drafts the message. That can be useful without handing the entire process to an agent.

Start with one instruction you’re tired of repeating

You don’t need to configure every feature before your next task.

Maybe you keep explaining how commits should be written. Maybe you keep asking Claude to run the formatter. Maybe a long investigation leaves the main conversation full of details you no longer need.

Give that problem a home: project instructions, a skill, a hook, or a focused subagent. Then see whether you need to intervene less often without losing confidence in the result.

The next time you catch yourself typing “I already told you this,” you have somewhere useful to put that instruction.

Why the Best Manufacturer in the Category Is Invisible on Google

riyad.abdur@gmail.com (Abdur Rahman) — Sat, 24 Oct 2026 00:00:00 GMT

A manufacturer with a twenty-year reputation asked me why two brands nobody had heard of were beating them in search. It wasn’t a trick. It was a sentence they had never written.

This kind of email turns up more often than you would think.

This one came from the owner of a company that makes industrial storage systems. Heavy-duty racking and mezzanines, the kind of steel you bolt into a warehouse floor and then forget about for a decade. They had been in business for twenty years, held every certification that mattered in their market, and had customers who had been with them since the start.

He had typed a question into Google that any of his buyers might type: average cost of a pallet racking system for a 10,000 square foot warehouse.

The results were full of two brands he had barely heard of, young companies three or four years old that import most of their product. His sales team had started hearing their names on calls. “They are not serious players,” he wrote. “So what are they doing to skew the results? Whatever it is, it’s working. We need to study that and copy it.”

It is a familiar question. The assumption is that there is a trick. There almost never is. What there usually is, is a sentence that one company wrote down and the other company didn’t.

This is a story about finding that sentence, and about why the companies with the most to say are so often the ones saying nothing.

Read the result page like a document

I ran his query and read the whole result page, top to bottom, instead of skimming the first few links.

The first thing on the page was not a website. It was a row of product cards with photos and prices. A 10-bay starter system at $4,200, a 20-bay package at $7,900, a heavy-duty run at $12,500. Five sellers and five prices before a single blue link.

Then came the articles. A regional installer suggesting a budget of $15 to $40 per pallet position. A trade magazine piece from three years ago. A marketplace listing. And then, from one of the two upstarts, a guide published in 2022 with a sentence that stopped me.

For a standard warehouse, plan on roughly $8 to $12 per square foot for selective racking, installed.

There was the mystery, solved in one line. A four-year-old sentence with a dollar sign in it, sitting on a page with a question for a headline, had become Google’s answer to “what does this cost.” Every time a buyer asked, the upstart answered, and it would keep answering until someone wrote a better sentence.

I went back to my client’s website and searched it for the word “price,” then “cost,” then the dollar sign. Nothing. Thirty pages, a detailed FAQ, downloadable load tables, a warranty far better than the competition’s, and not one number a buyer could anchor to.

The search engine wasn’t skewed. It was answering the question that was asked. My client had never entered the conversation.

A good company, described badly

A closer look at my client’s own site confirmed something that is common with manufacturers. The business was far better than the website said it was.

The Google Business Profile had dozens of five-star reviews. Customers wrote about engineers who drove out to re-measure a site for free. The steel was rolled domestically, the powder coat was applied in-house, and the design team held seismic certifications the imports could not match. This is a company with a story worth telling.

The website told almost none of it in a way a search engine could read. A few examples.

It never used the buyer’s words. Every page said “storage solutions.” Buyers type “pallet racking,” “warehouse shelving,” “mezzanine floor.” The phrase “pallet racking” appeared on two pages out of thirty. Google is good at synonyms and still prefers the page that uses the words people type.

It named its products after itself. The systems were called things like “Series 400” and “ProLine HD.” Fine names for a catalog. Almost nobody searches for them. Every page title was a model name followed by the company name, which is the digital equivalent of a shop sign that says only the owner’s surname.

It told the machines the wrong address. Buried in the page code was a structured-data block, the kind search engines and AI assistants read to understand who a company is. It listed the headquarters correctly, then declared the country as somewhere the company had once had a distributor. The phone number in that block did not match the one in the footer. A sister site for another market claimed the same address with no link back. From a machine’s point of view, there were two companies, one of them possibly foreign.

Every page had two headlines. A newsletter box in the footer had been built as a top-level heading, so every page on the site announced two subjects, one of which was “Join our mailing list.”

The best content was hidden. The FAQ answered forty real questions about load ratings, floor requirements, lead times and installation. Real expertise, clearly written by people who had answered these questions on the phone a thousand times. None of it was marked up so a search engine could use it, none of it appeared on the product pages, and none of it touched price.

None of these are hard to fix, which is what made the email hard to answer. The client assumed he was losing to a sophisticated opponent. He was mostly losing to a template setting and a missing page.

What the upstarts were actually doing

I spent some time on the two competitors’ sites, looking for the trick my client was sure existed.

I didn’t find one. Neither site had structured data worth mentioning. One had a copy-paste error on its main product page that referred to a completely different product. Their content was thin. Their backlinks, as far as I could tell, were ordinary.

What they had was three habits.

They wrote the number down. One had published four separate cost guides, each with a table that gave a figure for a small warehouse, a mid-size one, and installation on top. Every section heading was a question a buyer would type. The newest one had the year in its title and a date two weeks old. The other brand put a “From $X” on every product listing.

They put the products where the shopping results look. Both had product feeds in Google Merchant Center, which is why their systems appeared as priced cards above the organic results. One also sold through a big-box marketplace, and the marketplace listings carried exact dimensions in the title. My client’s buyers who “kept mentioning” that brand were seeing it on a marketplace shelf, not Google’s.

They claimed geography. One brand had a page for every state it shipped to. When I searched for my client’s own company name plus his city, that competitor’s state page ranked above him. Above his own name. Not through any manipulation. My client simply had no page about his home state at all, despite having a factory there.

That was the whole secret. Publish prices, feed the shopping results, say where you are. The two brands weren’t gaming the system. They were the only ones in the category doing the obvious things, and the obvious things add up.

Five decisions, not a checklist

The full audit ran to about forty items. But the conversation that mattered was about five decisions, and each one was uncomfortable in its own way.

1. Publish a price range, and accept that it will be wrong for someone. Custom manufacturers hate this. Every project is different, and a range feels like a promise. But a buyer who sees “$X to $Y for a typical 10,000 square foot layout” and then gets a quote inside that range trusts you more, not less. The buyer who never sees a number goes to the competitor who printed one.

2. Put standard configurations in the shopping results. The company already stocked common packages. Free listings in Merchant Center cost nothing beyond the setup time. A handful of products with real prices, photographed well, is enough to get the brand into a carousel that until now belonged entirely to competitors. Of the five, this is the quickest to act on and needs the least writing.

3. Rename the pages for the buyer, not the catalog. “Series 400” became “Heavy-Duty Selective Pallet Racking.” The model number stayed in the subtitle. Nothing about the product changed, only who could find it.

4. Tell the machines who you are, once, consistently. One company name, one address, one phone number, and one account of where the steel is rolled and the coating is applied. Write it on an About page (the site didn’t have one), repeat it in structured data that names the right country, and link the sister site properly so Google can tell it is the same company speaking another language rather than a rival.

5. Claim the ground you already stand on. A page for the home state and the factory. Pages for the seismic certifications that matter in certain regions. The company had earned each of these. It had just never said so anywhere a search engine would look.

None of this requires a bigger budget. It requires deciding that the website is a salesperson who should answer the question it was asked.

The gap in one picture

[Image: Infographic comparing an established manufacturer with no prices online against two young brands with priced cards, cost guides and state pages]

Side by side: an established manufacturer with no price on its site, and two young brands with priced product cards, dated cost guides and state pages. The established company has more to say and says less of it where search engines look.

The takeaway

Search engines and AI assistants can’t test a product. They go with the clearest answer they can find. The competitors here didn’t outspend or outsmart anyone. They just answered the question.

The established company doesn’t need to copy them. It has more to say than they do. It only needs to say it where buyers are looking.

Why Lumen Failed: The Rise and Fall of Laravel’s Micro-Framework

riyad.abdur@gmail.com (Abdur Rahman) — Sun, 20 Apr 2025 00:00:00 GMT

[Image: Timeline of the rise and fall of Laravel Lumen from its 2015 launch to Laravel absorbing its use cases in 2023]

In 2015, Laravel introduced Lumen, a microframework designed for blazing-fast APIs and microservices. It promised a lighter, speedier alternative to Laravel, ideal for stateless services. However, a decade later, Lumen has largely faded from the spotlight. Even Laravel’s creator, Taylor Otwell, no longer recommends it, favoring Laravel Octane instead.

So, what led to Lumen’s decline? Let’s delve into the key factors behind its downfall and explore similar cases in the tech world.

1. The Promise of Lumen: Speed and Simplicity

Lumen was marketed as a faster, leaner version of Laravel, designed specifically for microservices and high-performance APIs. Key selling points included:

Blazing Fast Performance: Benchmarks showed Lumen was outperforming Laravel in raw speed.
Minimalist Architecture: Stripped-down features like no sessions, cookies, or Blade templating made it ideal for stateless APIs.
Easy Upgrade Path: Since Lumen shared Laravel’s core components, developers could transition to Laravel if their project outgrew Lumen.

For a while, companies like Trivago, Uber, and ZipRecruiter used Lumen for backend APIs, leveraging its efficiency for high-throughput services.

Why Lumen Ultimately Failed

Despite its early promise, Lumen struggled to justify its existence as a separate framework. Here’s why:

A. Laravel’s Performance Improvements

Over time, Laravel optimized its core, reducing the performance gap. Features like:

Route caching
OPcache integration
Improved middleware handling

Together, these made Laravel nearly as fast as Lumen for most API use cases.

B. Feature Limitations Outweighed Speed Gains

Lumen lacked critical Laravel features, forcing developers to reintegrate them manually:

No built-in authentication (e.g., Sanctum/Passport)
Limited database & queue support
No Blade templating or frontend tooling

This meant that as projects grew, developers often had to either:

Patch Lumen with Laravel components (defeating the purpose of a “lightweight” framework).
Migrate to Laravel entirely (which many did).

C. Maintenance Overhead for the Laravel Team

Maintaining two separate frameworks (Laravel & Lumen) became redundant. By 2021, Taylor Otwell (Laravel’s creator) announced that Lumen would no longer be actively maintained, recommending Laravel for APIs instead.

D. The Rise of Serverless & API-First Laravel

With tools like:

Laravel Sanctum (for API auth)
Laravel Octane (for performance boosts)
Improved API resource handling

Laravel itself became a better choice for APIs, making Lumen obsolete.

When Did Lumen Make Sense? (And When Did It Not?)

Good for

Ultra-low-latency microservices (where every millisecond counts).
Legacy projects already on Lumen.
Tiny APIs with no need for Laravel’s full feature set.

Bad for

Apps requiring robust authentication (e.g., OAuth2).
Teams that later realized they needed Laravel’s features.

The Final Nail in the Coffin: Laravel’s Dominance

By 2023, Laravel had:

Matched Lumen’s speed in real-world API scenarios.
Integrated better API tooling (e.g., API resources, rate limiting).
Made Lumen redundant for most use cases.

Even benchmarks showed that in real-world apps (with DB queries, caching, etc.), the performance difference was negligible.

Conclusion: Why Lumen Failed

Lumen was a good idea in theory but failed because:

Laravel caught up in speed and API capabilities.
Feature limitations made it impractical for growing projects.
Maintaining two frameworks was inefficient for the Laravel ecosystem.

Today, Laravel is the better choice for APIs, while Lumen remains a relic of an era when micro-frameworks seemed essential. For most developers, Laravel + Octane or plain Laravel APIs are the way forward.

Final Thought

Lumen’s demise teaches us that optimizing for raw speed alone isn’t enough — flexibility, maintainability, and ecosystem support matter just as much.

References

Unlock Free AI-Powered Coding Assistance with DeepSeek-Coder-V2 and Ollama: Your Local, Lightweight Code Companion

riyad.abdur@gmail.com (Abdur Rahman) — Wed, 19 Feb 2025 00:00:00 GMT

Introduction

In today’s fast-paced development world, AI tools are transforming how we write code. DeepSeek-Coder-V2, a nice open-source LLM (Large Language Model), paired with Ollama, offers an exceptional local coding assistant — all for free. With Ollama, you can run DeepSeek-Coder-V2 efficiently on your machine, eliminating the need for cloud APIs.

This guide walks you through the process of installing and using DeepSeek-Coder-V2 with Ollama, integrating it with VS Code’s CodeGPT extension for AI-driven autocompletion, and comparing its performance with other models available in Ollama.

Why DeepSeek-Coder-V2 with Ollama is a Game-Changer for Developers

Here’s why this setup should be on your radar:

Free & Open Source — No subscription needed. Run it locally without incurring cloud fees.

Optimized for Code — Trained on a wide range of programming languages, DeepSeek-Coder-V2 is a solid alternative to proprietary models.

Lightweight & Efficient — Despite having 236B parameters in its original form, the Ollama-optimized version is just ~8.9GB, meaning it can run smoothly on most modern machines.

Seamless Integration with VS Code — Unlock the power of AI-assisted code autocompletions with the CodeGPT VS Code extension, boosting your productivity.

How to Install and Run DeepSeek-Coder-V2 with Ollama

Step 1: Install Ollama

Ollama is an intuitive tool for running language models locally. To get started:

macOS and Linux: run the following command in your terminal:

curl -fsSL https://ollama.com/install.sh | sh

Windows: download and install Ollama from ollama.com.

Step 2: Download DeepSeek-Coder-V2

Once Ollama is installed, pull the DeepSeek-Coder-V2 model:

ollama pull deepseek-coder-v2

The quantized version is only ~8.9GB, much smaller than its original form.

To test if it’s working, run:

ollama run deepseek-coder-v2

This will start an interactive session where you can ask coding-related queries.

Integrating DeepSeek-Coder-V2 with VS Code and CodeGPT

VS Code, combined with CodeGPT, provides smooth AI-powered code autocompletion.

Step 1: Install the CodeGPT Extension

Open VS Code and go to the Extensions panel (Ctrl + Shift + X).
Search for CodeGPT and install it.

[Image: VS Code Extensions Marketplace search for CodeGPT, with the CodeGPT: Chat & AI Agents extension highlighted]

Step 2: Configure CodeGPT to Use Ollama

Open the CodeGPT menu and select the autocomplete setting.

[Image: CodeGPT Chat panel in VS Code with the autocomplete settings icon highlighted in the toolbar]

Select the deepseek-coder-v2 model, save the settings and restart VS Code.

[Image: CodeGPT AI code auto-completion dialog with deepseek-coder-v2 (Ollama) selected from the model list]

Step 3: Try AI Autocompletion

Open any code file, start typing a function, and see how DeepSeek-Coder-V2 suggests autocompletions based on the context.

For example, if you write a comment like:

// write a program in Go that prints "Hello, World!"

It will generate:

[Image: Editor showing a Go Hello, World program generated from a one-line comment prompt]

Conclusion

Running DeepSeek-Coder-V2 locally via Ollama is a great way to get AI-assisted coding — free, efficient, and easy to use. Pairing it with VS Code’s CodeGPT extension brings even more productivity boosts, all without the hassle of cloud costs.

If you’re searching for a free and powerful alternative to GitHub Copilot, give this setup a try.

Next Steps: Test it yourself and share your experience!

3 Essential Tips for Secure JWT Management and Preventing Token Theft

riyad.abdur@gmail.com (Abdur Rahman) — Fri, 29 Nov 2024 00:00:00 GMT

[Image: Pyramid diagram of JWT security layers: secure storage at the base, short lifespan, and regular rotation at the top]

JSON Web Tokens (JWTs) are a popular way to manage user authentication in web applications. However, handling JWTs securely requires a thoughtful approach to mitigate common threats like Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and token theft. Here are three key strategies for securely storing and managing JWTs.

1. Prioritize Cookies Over Local Storage

When it comes to storing JWTs on the frontend, many developers opt for localStorage or sessionStorage due to their simplicity. However, these storage mechanisms are vulnerable to XSS attacks. If an attacker manages to inject JavaScript into your application, they could easily access sensitive data stored in localStorage.

Why Cookies Are Better

Cookies, on the other hand, can be configured with security features that significantly reduce this risk:

HttpOnly flag: By marking the cookie as HttpOnly, you prevent JavaScript from accessing it, thus mitigating the risk of XSS attacks. Even if an attacker gains access to the frontend code, they won’t be able to steal the token.
Secure flag: The Secure flag ensures that cookies are only transmitted over HTTPS connections. This prevents man-in-the-middle (MITM) attacks where the token could be intercepted over an insecure HTTP connection.
SameSite=Strict: This attribute ensures that the cookie is only sent with same-origin requests, limiting the risk of CSRF attacks. CSRF can occur when an attacker tricks a user’s browser into sending a request to your site with the user’s credentials or token, potentially executing malicious actions.

By using cookies with these flags, you can safely store JWTs and prevent common security vulnerabilities.

2. Implement Token Rotation with Short-Lived Access Tokens

One of the main security concerns with JWTs is that if a token is compromised, it could be used indefinitely. To reduce this risk, it’s crucial to implement token rotation with short-lived access tokens.

How Token Rotation Works

Access Tokens: Set access tokens to expire quickly (e.g., 15 minutes or 1 hour). Since these tokens provide access to protected resources, their expiration limits the time an attacker can use a stolen token.
Refresh Tokens: Use refresh tokens to allow users to obtain new access tokens without reauthenticating. However, refresh tokens should be securely stored in HttpOnly cookies to prevent JavaScript access and mitigate the risk of XSS attacks.
Rotation Mechanism: Implement a system where, each time an access token is refreshed, a new access token and refresh token are issued. Additionally, invalidate the old refresh token immediately to prevent replay attacks (where an attacker tries to reuse a stolen refresh token).

Why Token Rotation Enhances Security

Token rotation significantly reduces the impact of token theft. Even if an attacker manages to steal an access token, they will only have a short window to use it. The refresh token, securely stored in cookies, can only be used to obtain a new access token when it’s valid, and rotating refresh tokens ensures that stale or stolen tokens won’t be accepted.

3. Split Large JWTs Across Multiple Cookies

JWTs are typically small and concise, but in some cases, they can grow large if they contain extensive claims, permissions, or user data. Browsers impose a size limit on cookies (usually around 4KB), which means that storing a large JWT in a single cookie could exceed this limit and result in errors.

Solution for Large Tokens

If your JWT is too large, split it into multiple parts and store them across multiple cookies. For example, you can break the JWT into:

Header: Store the header part of the JWT in one cookie.
Payload: Store the payload part in another cookie.
Signature: Store the signature part in a third cookie (if needed).

Once the JWT is split and stored, the backend will need to reassemble the parts before validating the token. By managing the token this way, you ensure that each cookie stays within the size limits while still securely storing the JWT.

Why This Works

Splitting the JWT ensures that your application remains within browser constraints while leveraging cookies’ security benefits. This method allows you to keep large JWTs while avoiding potential issues with localStorage or trying to store oversized tokens in a single cookie.

Journey from Pokhara to Khumai Danda: A Beginner’s Himalayan Trek

riyad.abdur@gmail.com (Abdur Rahman) — Tue, 29 Oct 2024 00:00:00 GMT

Nepal is a land of awe-inspiring landscapes, towering peaks, and pristine mountain trails. For me, trekking from Pokhara to Khumai Danda was more than just a journey; it was an experience filled with physical challenges, natural beauty, and cultural encounters. Our trek introduced us to the iconic Annapurna and Machapuchare Himalayan mountains, bringing us closer to nature than ever before. Here’s a detailed look at the journey, complete with photos that capture the essence of this unforgettable trek.

[Image: Route map of the trek with stops from Tushey through Saripakha, Chichimley, Deurali and Lupruchi to Khumai Danda]

Day 1: Starting the Adventure

Our adventure began at a lakeside hotel near Phewa Lake in Pokhara, from where we took a taxi to the trekking checkpoint. After some formalities — such as logging our entry details — we set off on foot. The path was inviting, with the morning sun casting a golden hue on the surrounding mountains.

[Image: Snow-covered Machapuchare peak rising above village houses, seen from inside a taxi]

Our first stop came after about an hour of walking, at a cozy rest house where we refueled with a hearty breakfast of chana, boiled eggs, and black tea with a distinctive aroma. The scenery was inspiring, and the journey, initially planned to be a single-day trek, was extended to two days with another day for the descent. With the help of the rest house owner, we arranged for a night’s stay in Chichimley, our stopover for the day.

Reaching Chichimley: The Uphill Climb

[Image: Trekkers having tea at an outdoor table by a stone rest house with snowy Himalayan peaks behind]

After a short break, we began our ascent towards Khumai Danda. The trail quickly became challenging, with steep uphill paths that demanded focus and stamina. After two hours of rigorous climbing, we found another small teahouse where we stopped for some hot tea and enjoyed the sight of the Himalayas inching closer with every step.

With renewed energy, we pushed on, passing by waterfalls where we made our own tea from the hot water we’d carried. These mini-breaks provided the perfect moments for photos, snacks, and the sheer joy of being surrounded by untouched nature.

[Image: Group of trekkers resting with cups on stone steps beside a forest stream]

After a long and challenging walk, we finally reached Chichimley, only to find out that due to a booking miscommunication, there was no room available. The hotel owner graciously set up a tent for us outside. Though the space was tight, the tent became our refuge in the biting cold of the night, amidst an atmosphere that truly felt like wilderness.

[Image: Blue and orange tent pitched on a grassy ledge beneath large trees]

Night at Chichimley: Cold, Campfire, and Community

Despite the cold, the night had its warm moments. After dinner, we gathered around a campfire under the stars, sharing stories and laughter with other trekkers. We dined on dal chawal (lentil rice) and vegetables, a comforting meal after a long day of hiking. The night was chilly, but the warmth of camaraderie kept us comfortable enough to rest and recharge.

[Image: Trekkers around a campfire at night, one playing a flute as sparks rise]

Day 2: Ascending to the Peak of Khumai Danda

Early the next morning, we resumed our journey, heading towards Khumai Danda’s peak to witness the grandeur of Annapurna and Machapuchare. The trail became even steeper and more precarious. After a few hours, we reached the rest house at Khumai Danda, where we enjoyed some tea and refilled our water. With our next hotel booked at the core viewpoint, we were eager to make our way to the top.

[Image: Trekker with a pole on a steep stone-step trail along a grassy ridge with mountains beyond]

Our trek was soon interrupted by a dramatic moment: a fellow hiker had slipped, injuring her foot. We helped her with our first-aid supplies and continued, humbled by the reminder of nature’s unpredictability. Finally, we reached the summit, surrounded by a 360-degree view of towering Himalayan mountains and lush valleys.

[Image: Trekker sitting on a grassy summit looking out over layers of misty blue mountain ridges]

As we celebrated reaching the peak, we discovered one of our friends had accidentally left his jacket at the last rest stop — a tough situation given the cold and proximity to freezing temperatures. After some deliberation, we chose to forgo the core viewpoint hike, accepting the breathtaking views we already had.

[Image: Four trekkers in jackets posing with thumbs up in front of a snow-capped peak]

Night at Khumai Danda: Friends, Music, and Memories

As evening settled, we bonded with fellow trekkers from Nepal who shared our profession in technology. With music echoing through the air, we sang Nepali and Bengali songs, forging unforgettable friendships. The temperature dropped even further, forcing us to stay close together and savor the warmth of the rest house as we enjoyed the night’s last meal.

[Image: Steel plate of dal bhat: rice with papad, lentil soup, vegetable curry, greens and pickle]

Day 3: Sunrise and Snowfall — The Journey Back

Our last morning at Khumai Danda was nothing short of magical. We woke up early to witness the sunrise painting the mountains in shades of pink and red. As if that wasn’t enough, light snowfall began — a dream moment for me, seeing snow fall against the Himalayan backdrop.

[Image: Blue and white tent on a grassy field with the sharp snowy summit of Machapuchare towering behind]

With our hearts full and bags packed with memories, we began our descent back to Pokhara. On the way, we recovered the forgotten jacket — a small victory that felt symbolic of a journey completed. Tired but fulfilled, we returned to Pokhara after hours of trekking and a brief jeep ride, carrying memories and a deeper respect for the mountains.

[Image: Trekkers with poles descending steep stone steps through tall grass on a hillside]

Reflections: A Trekking Journey to Remember

For a beginner, the trek from Pokhara to Khumai Danda is the perfect introduction to Himalayan trekking. It’s challenging but accessible, offering a balance of adventure, cultural experiences, and natural wonders. This trek has etched itself in my heart as a highlight of my Nepal journey, and I hope to return, ready for an even more ambitious adventure.

Discovering Nagarkot: A Work-from-the-Hills Adventure

riyad.abdur@gmail.com (Abdur Rahman) — Tue, 15 Oct 2024 00:00:00 GMT

Sometimes, a change of pace is exactly what’s needed to clear the mind. That shift came for me during a trip to Nagarkot, a peaceful hill station just a short distance from the bustling streets of Thamel, Kathmandu. With a laptop in my bag and a curiosity for both adventure and tranquility, I set off for a quick getaway that turned out to be one of the most memorable experiences I’ve had in Nepal.

The Journey: From Thamel to Nagarkot

Leaving Thamel behind in the early morning, I headed out for what was supposed to be a peaceful work trip. What I didn’t expect was how breathtaking the journey itself would be. As the car snaked its way through hilly roads, we passed by villages that looked frozen in time, perched on terraced slopes. The further we went, the more the air changed. It got cooler, fresher, and suddenly it felt like I was worlds away from the city.

[Image: Long suspension bridge crowded with people stretching across a forested valley]

There was a point when we crossed a huge suspension bridge, and just below it, there was a waterfall that seemed to appear out of nowhere. The mist rising from the water created this otherworldly atmosphere — it felt like I had stumbled into a scene from a travel documentary. Another waterfall showed up a little later, reminding me how much beauty Nepal packs into its landscapes.

[Image: Waterfall rushing over dark rocks and boulders surrounded by green foliage]

Finding a Work-Life Balance: Coffee with a View

Once I arrived in Nagarkot, I discovered the perfect place to work — a cozy coffee shop with a terrace that looks out over the hills. Imagine sitting outside with a cup of fresh coffee, typing on your laptop while taking in the beautiful hilly view. If the sky is clear and you’re lucky, you might even see Mount Everest in the distance. It’s the kind of spot that inspires you, whether you’re focused on work or just soaking in the beauty around you.

[Image: Laptop, breakfast plate and coffee on a cafe table by a window overlooking hills and clouds]

The coffee shop had all the essentials — good WiFi, warm drinks, and the kind of quiet you need to really focus. And with that view, even work felt a little less like work. It was the ideal blend of productivity and peace. Honestly, if I could do all my remote work from here, I’d never leave.

Sunset Points and Everest Views

Nagarkot is famous for its sunset points, so after wrapping up my work, I made sure to catch one. Watching the sun dip behind the rolling hills, casting a golden glow over the valley, was a moment I won’t soon forget.

[Image: Orange sunset sky over layered silhouetted hills seen from a balcony]

But the highlight came the next morning. I woke up early, hoping for a clear sky, and headed to the Nagarkot Watch Tower. As the clouds began to lift, there it was — Mount Everest, peeking through the horizon. It was one of those rare, perfect moments where nature gives you exactly what you’re hoping for.

[Image: Snow-capped Himalayan peaks on the horizon above treetops under a hazy blue sky]

Dining with a View

One evening, I enjoyed dinner at a hilltop restaurant that offered an amazing view. The food was great, but what really stood out was the scenery. From my table, I looked out at the villages below, and as night fell, the valley lit up with twinkling lights, creating a beautiful and peaceful atmosphere.

[Image: Rooftop restaurant terrace at night with string lights, tire stools and distant valley lights]

The houses started lighting up one by one, and before long, the entire hillside was twinkling with lights. It was a perfect end to an already perfect day.

[Image: Old blue van converted into a lit-up seating nook with prayer flags, parked at night]

Nagarkot is more than just a hill station — it’s a place where you can truly unwind while staying productive. The fresh air, the breathtaking landscapes, and the peaceful vibe make it an ideal destination for remote workers looking for a change of pace. Whether you’re there to work, hike, or simply take in the sunsets, Nagarkot will leave you feeling refreshed and inspired.

And if you’re lucky, you just might catch Everest watching over you.