DEV Community: Burak Boduroğlu

Free stuck TCP ports in one command — without memorizing `lsof`, `fuser`, and `kill` pipelines

Burak Boduroğlu — Sun, 22 Mar 2026 10:45:04 +0000

`.portkill`

Free stuck TCP ports in one command — without memorizing lsof, fuser, and kill pipelines.

The name reads like .portkill — a small, local dev utility (think .env-style prefix). The CLI binary is still portkill.

Published on npm: @burakboduroglu/portkill — install with npm i -g @burakboduroglu/portkill or npx @burakboduroglu/portkill (see Install).

When Node or another stack prints EADDRINUSE, .portkill shows who owns the port, lets you preview (--dry-run), then stops only what you intend — or opens a calm local web UI on loopback.

Why `.portkill`

Instead of…	You get…
Copy-pasting `lsof` / `xargs` / `kill -9`	One tool, clear output, safe defaults
Guessing PIDs	Process name + PID per port
Accidentally nuking the wrong thing	`--dry-run` first; `--gui` with browser confirm
Another Electron app	Node only; `--gui` is a tiny HTTP server on 127.0.0.1 / ::1

Install

Registry page: npmjs.com/package/@burakboduroglu/portkill.

npm i -g @burakboduroglu/portkill
portkill --version

No global install:

npx @burakboduroglu/portkill --list

From source

git clone https://github.com/burakboduroglu/portkill.git && cd portkill
npm install && npm run build
npm link   # optional: puts `portkill` on PATH

Quick start

# What is listening everywhere?
portkill --list

# See what would happen (no signals sent)
portkill 3000 8080 --dry-run

# Stop listeners on those ports (prompts unless --force)
portkill 3000 8080

# Range (inclusive, max 4096 ports per range token)
portkill 9000-9002

# Optional local UI — same logic as the CLI
portkill --gui

Press Ctrl+C to stop the GUI server. The printed URL is loopback-only.

GUI walkthrough (video)

CLI flags (short)

Flag	Meaning
`-n`, `--dry-run`	Show targets only; do not send signals
`-f`, `--force`	Skip the terminal confirmation
`-s`, `--signal`	Signal to send (default `SIGTERM`)
`-l`, `--list`	List all TCP listeners
`--gui`	Open the local web UI
`-v`, `--verbose`	More detail on stderr

Full reference: CLI reference · Exit codes and outcomes: same doc.

Requirements

Node.js ≥ 18
macOS or Linux — uses lsof (Linux may use fuser as fallback where applicable)

Docs & product spec

Doc	What it is
PRD	Product requirements, roadmap
Implementation	Architecture & data flow
Data dictionary	Types, GUI API shapes
Security notes	GUI scope, `npm audit`, reporting
Release	`npm publish` (2FA), tags, GitHub Release

Development

npm run build
npm test
npm run test:coverage
npm run lint

Terminal colors use chalk; set NO_COLOR=1 to disable (no-color.org).

npm vs GitHub README

This file is the npm package readme for @burakboduroglu/portkill (included via package.json "files"). Distribution is npm only (npm i -g / npx). Full source, docs/, and the PRD are on GitHub; in-repo links use GitHub URLs so they work from the npm package page too.

License

MIT — see LICENSE.

Check out this post and drop your thoughts! Let’s brainstorm some new ideas and learn together.

Burak Boduroğlu — Fri, 20 Mar 2026 10:02:52 +0000

Agentic Coding: Rules, skills, subagents, and reflection—how we steer models so multi-step work stays coherent.

Burak Boduroğlu ・ Mar 20

#ai #cursor #agents #llm

Agentic Coding: Rules, skills, subagents, and reflection—how we steer models so multi-step work stays coherent.

Burak Boduroğlu — Fri, 20 Mar 2026 10:00:36 +0000

Agentic coding here means treating the LLM as part of a system: you supply constraints (rules), reusable procedures (skills), and split responsibilities (subagents), then merge and review (reflection) instead of hoping one giant prompt does it all. This repository is a small, concrete rehearsal of that pattern.

The runnable piece is a User Analytics dashboard—enough UI and mock data to force real decisions about structure and state. The artifact matters less than the orchestration layer you see below: the same ideas written as code-shaped docs you can skim like a technical post, not a pile of file links.

The thesis (one glance)

┌─────────────────────────────────────────────────────────────┐
│  Runnable app  ≈  ~25% of what you optimize for             │
│  Agentic layer (rules, skills, subagents, reflection) ≈ rest │
│                                                             │
│  Goal: repeatable, inspectable workflows—not one-off prompts │
└─────────────────────────────────────────────────────────────┘

Rules: project manifest

Rules are non-negotiables: what kind of product this is allowed to be. Think of this block as the spirit of AGENTS.md—the constitution in miniature.

# agents.manifest — frontend-only dashboard sandbox

constraints:
  backend: none          # never pretend a real service exists
  database: none
  data_source: simulated # APIs are mocked; responses are structured

principles:
  - Always simulate API responses (shape, timing, errors)
  - Use mock data generators with internal consistency
  - State and metrics must feel like one snapshot, not random literals
  - UX realism > technical pedantry when they disagree

deliverables_expectation:
  - Clean React components, modular layout
  - Reusable hooks for async-shaped flows
  - Dummy data that could fool a demo audience briefly

workflow_outline:
  - Understand the feature
  - Split: UI + state + data (+ polish)
  - Delegate to roles (see subagents)
  - Validate consistency
  - Reflect and refine UX

Skills: when to reach for which playbook

Skills are not philosophy; they are repeatable procedures for recurring jobs. Each entry is short on purpose—it is muscle memory, not a tutorial.

# .agents/skills — local playbooks

component-generation:
  when: building or extending UI pieces
  good_finish:
    - Clear purpose and props contract
    - Structure before ornament
    - Styles and patterns reusable across the dashboard

dashboard-design:
  when: composing a screen, not a single widget
  good_finish:
    - Cards, KPIs, chart, clear hierarchy
    - Layout breathes; density feels intentional

mock-data:
  when: anything the UI will render as “facts”
  good_finish:
    - IDs, timestamps, plausible variation
    - No lazy filler that breaks suspension of disbelief

state-patterns:
  when: async UX (even when nothing hits the network)
  good_finish:
    - loading → success → error paths read as one story
    - Retry and optimism where they make sense for the scenario

Subagents: who owns what

Splitting work is a feature. The orchestrator holds intent and merges; specialists own slices. Reflection is a mandatory last pass—not a bonus round.

ORCHESTRATOR (.agents/orchestrator.md)
──────────────────────────────────────
  • Parse intent
  • Decompose into sub-tasks
  • Assign → merge
  • Guard cross-cutting consistency

DELEGATION MAP (orchestrator → specialist)
──────────────────────────────────────────
  UI work      →  UI Builder
  State / async →  State Manager
  Data / API   →  Mock API Generator
  Polish       →  UX Enhancer

# specialists — one job each

ui_builder:
  focus: React surfaces, hooks, composition
  avoid: hardcoded data where props or hooks should feed the tree

state_manager:
  focus: loading, errors, fake delays, optimistic updates
  goal: async that feels real without a wire

mock_api:
  focus: JSON shape, latency, failure modes
  rule: always structured enough to drive real UI branches

ux_enhancer:
  focus: skeletons, motion, empty states, layout polish
  goal: demo-credible, not merely functional

# reflection — “does it still feel like one app?”

reflection_pass:
  consistency:
    - KPIs and time series agree (e.g. same snapshot / generatedAt story)
  ux_realism:
    - Latency + occasional errors + Retry exercise the real flow
  polish:
    - Dark analytics read, skeletons, accessible error region
  persistence_story:
    - Tracked accounts: actions survive refresh (e.g. localStorage) without contradictions

End-to-end flow

The loop is simple; agentic coding pays off when you run it every time—not only on “big” tasks.

flowchart LR
  userReq[UserRequest]
  orch[Orchestrator]
  ui[UIBuilder]
  state[StateManager]
  api[MockAPI]
  ux[UXEnhancer]
  merge[MergeOutputs]
  refl[Reflection]
  out[Deliverable]

  userReq --> orch
  orch --> ui
  orch --> state
  orch --> api
  orch --> ux
  ui --> merge
  state --> merge
  api --> merge
  ux --> merge
  merge --> refl
  refl --> out

Plan → Execute → Review → Refine
        ↑___________________|
        (reflection closes the loop)

Steal this shape for your own repo

You only need a thin stack: one manifest-style rules doc, a few skill stubs, subagent one-pagers, and a reflection checklist. If you use Cursor, wire that layer into your session before the editor fills with components—for example, a Plan Mode block that pulls in the same manifest, skill names, and subagent paths so the model loads constraints first.

<!--
  Example session preamble (trim to taste)

  CONTEXT:
  - Frontend-only; no real API or DB.
  - Follow the project manifest (rules): simulated data, consistent state, UX realism.
  - Use skills: component-generation, dashboard-design, mock-data, state-patterns.
  - Delegate mentally or explicitly: UI Builder, State Manager, Mock API, UX Enhancer.
  - Finish with reflection: consistency, believable errors/retry, polish, persistence.

  OUTPUT:
  - Components + hooks + mock API shapes + UX notes in one coherent story.
-->

Where this lives in the tree

Everything above is documented in-repo; this block is just a map.

agentic-coding.md              # this essay (agentic layer walkthrough)
AGENTS.md                      # rules (constitution)
.agents/orchestrator.md        # coordinator + delegation
.agents/subagents/*.md         # UI, state, mock API, UX
.agents/reflection.md          # last-pass checklist + project specifics
.agents/skills/*/SKILL.md      # playbooks
README.md                      # runbook + Plan Mode prompt example

Small app on purpose: a sandbox where agentic coding—rules, skills, subagents, reflection—stays visible and easy to copy into your own projects.

Note: This project isn’t exactly the one discussed here, but it works on a similar idea. You can check out the details and source code on GitHub:

GitHub Agentic Coding Project

What is Agile?

Burak Boduroğlu — Mon, 13 Oct 2025 12:43:10 +0000

Agile, which literally means "nimble" or "quick," is a project management and product development philosophy. In contrast to traditional, rigid, and long-term planning methods in software development (like Waterfall), it centers on flexibility, continuous improvement, team collaboration, and customer feedback.

The fundamental goal of Agile is to break down a project into small, manageable parts (often called "sprints" or "iterations") and, at the end of each part, to deliver a working product that adds value for the customer. This eliminates the necessity of knowing all requirements at the very beginning of the project and allows for quick adaptation to changing needs throughout the process. In short, Agile is about moving forward step by step, but with confidence, on a path full of uncertainties.

The Agile Manifesto: 4 Core Values

The Agile philosophy was formalized in 2001 with the publication of the "Manifesto for Agile Software Development" by a group of 17 software developers. This manifesto lays out the four core values that form the spirit of Agile.

Here are those four core values:

Individuals and interactions over processes and tools: It's people who carry out projects. Direct communication and collaboration within the team and with the customer are far more valuable than complex processes and tools. Problems are solved fastest by talking.

Working software over comprehensive documentation: Instead of preparing detailed documents that take weeks or months, the priority is to produce a working product that the customer can use. A working product is the clearest evidence of a project's progress.

Customer collaboration over contract negotiation: Seeing the customer as part of the project and maintaining constant communication with them throughout the process is more important than adhering to rigid contract clauses. The goal is to develop the product the customer truly wants, together.

Responding to change over following a plan: It is natural for a plan made at the beginning of a project to lose its validity in the face of changing market conditions, technology, or customer demands. Agile sees these changes not as obstacles, but as opportunities to create a better product, and it encourages adapting to change rather than strictly following a plan.

The 12 Principles of the Agile Manifesto

Behind these four core values are 12 principles that explain the Agile approach in more detail. These principles provide guidance on how to apply the values in practice:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Product increments that add value should be delivered to the customer at regular intervals throughout the process, not just at the end.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. The door is always open to the changing demands of the market and the customer.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. It is essential to manage the project as a series of short, fast runs (sprints) rather than a long-term marathon.
Business people and developers must work together daily throughout the project. There must be a constant and direct channel of communication between the customer or business unit and the development team.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Trusting the team, giving them responsibility, and avoiding micromanagement increases creativity and productivity.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Talking directly, rather than using emails or long reports, ensures that problems are solved more quickly and ideas are understood more clearly.
Working software is the primary measure of progress. The best way to understand a project's progress is not the completed documentation or hours spent, but the working product that has been created.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Instead of exhausting the team to the point of burnout, the goal is a stable working pace that everyone can maintain in the long run.
Continuous attention to technical excellence and good design enhances agility. "Being fast" does not mean compromising on quality. On the contrary, clean code and a solid architecture make it easier to adapt to future changes.
Simplicity—the art of maximizing the amount of work not done—is essential. It is important to avoid unnecessary complexity and features, focusing only on the work that adds the most value at that moment.
The best architectures, requirements, and designs emerge from self-organizing teams. Allowing the team to create their own solutions by giving them goals, rather than telling them what to do and how to do it, leads to more innovative and effective results.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Continuous learning and self-improvement are essential. Teams regularly review their processes in "retrospective" meetings to identify areas for improvement.

In this article, we have covered the definition, core values, and 12 principles of Agile. In our next article, we will take a closer look at the Scrum framework, which is one of the Agile approaches.

5 Golden Rules to Improve Code Quality in Java: SOLID Principles

Burak Boduroğlu — Wed, 26 Mar 2025 15:17:50 +0000

SOLID refers to five fundamental principles used in software design. These principles ensure that software is more flexible, maintainable, and testable.

The SOLID principles are as follows:

S: Single Responsibility Principle (SRP): A class should have only one responsibility. It ensures that classes are more understandable and manageable.

public class UserService {
  private final UserRepository userRepository;

  public UserService(UserRepository userRepository) {
    this.userRepository = userRepository;
  }

  public void createUser(String name) {
    userRepository.save(name);
  }
}

O: Open/Closed Principle (OCP): Classes should be open for extension but closed for modification. It allows you to add new functionality without changing existing code.

public interface Shape {
  double area();
}

public class Circle implements Shape {
  private final double radius;

  public Circle(double radius) {
    this.radius = radius;
  }

  @Override
  public double area() {
    return Math.PI * radius * radius;
  }
}

public class Rectangle implements Shape {
  private final double width;
  private final double height;

  public Rectangle(double width, double height) {
    this.width = width;
    this.height = height;
  }

  @Override
  public double area() {
    return width * height;
  }
}

L: Liskov Substitution Principle (LSP): Derived classes should be substitutable for their base classes. It ensures that objects can be used interchangeably.

abstract class FlyingBird{
  abstract void fly();
}

abstract class NonFlyingBird{
  abstract void doSomething();
}

class Eagle extends FlyingBird {
  @Override
  public void fly() {
  // implement something
  }
}

class Ostrich extends NonFlyingBird {
  @Override
  public void doSomething() {
  // implement something
  }
}

I: Interface Segregation Principle (ISP): Users should not be forced to depend on interfaces they do not use. It ensures that interfaces are more specific and understandable.

interface IAreaCalculator {
  double calculateArea();
}

interface IVolumeCalculator {
  double calculateVolume();
}

class Square implements IAreaCalculator {
  @Override
  public double calculateArea() {
   // calculate the area
  }
}

class Cube implements IAreaCalculator, IVolumeCalculator {
  @Override
  public double calculateArea() {
   // calculate the area
  }

  @Override
  public double calculateVolume() {
   // calculate the volume
  }
}

D: Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions. This reduces dependencies and increases testability.

class UserService {
   private final UserRepository userRepository;

   public UserService(UserRepository userRepository) {
     this.userRepository = userRepository;
   }

   public void createUser(String name) {
     userRepository.save(name);
   }
 }

class CourseService {
   private final UserService userService;

   public CourseService(UserService userService) {
     this.userService = userService;
   }

   public void createCourse(String name) {
     // implementation
   }
 }

Keyword	Description
Coupling	The degree of interdependence between software modules. Low coupling is preferred for modularity and maintainability.
Cohesion	The degree to which the elements of a module belong together. High cohesion is desired for clarity and focus.
Single Responsibility Principle (SRP)	A class should have only one responsibility. It ensures that classes are more understandable and manageable.
Open/Closed Principle (OCP)	Classes should be open for extension but closed for modification. It allows adding new functionality without changing existing code.
Liskov Substitution Principle (LSP)	Derived classes should be substitutable for their base classes. It ensures objects can be used interchangeably.
Interface Segregation Principle (ISP)	Users should not be forced to depend on interfaces they do not use. It ensures interfaces are more specific and understandable.
Dependency Inversion Principle (DIP)	High-level modules should not depend on low-level modules. Both should depend on abstractions. This reduces dependencies and increases testability.

Thank you for your interest in the SOLID principles! For more insights and resources, feel free to check out https://dub.sh/burakboduroglu.

Diamond Problem in Java? How to fix it?

Burak Boduroğlu — Sat, 22 Mar 2025 09:48:41 +0000

In Java, the Diamond Problem is an issue that arises due to multiple inheritance. When a class inherits the same method from two different superclasses, it becomes unclear which method should be used. However, Java does not directly support multiple inheritance for classes (a class can only inherit from a single class). The Diamond Problem typically occurs with interfaces when default methods are involved.

What is the Diamond Problem?

Scenario: How the Diamond Problem Arises

When a class inherits a default method with the same name from two different interfaces, ambiguity arises. Let’s illustrate this with a diagram:

       Interface A
       /       \
      /         \
Interface B   Interface C
      \         /
       \       /
        Class D

Explanation:
- Interface A has a default method, let’s say methodX().
- Interface B and Interface C implement Interface A and may either override methodX() or define their own default methodX() implementations.
- Class D implements both Interface B and Interface C.
- Now, when methodX() is called in Class D, it’s unclear which methodX() should be used. This is the Diamond Problem.

Solution to the Diamond Problem in Java

Java provides several mechanisms to solve the Diamond Problem. Let's explain them with diagrams:

Solution 1: Overriding the Default Method

By explicitly overriding methodX() in Class D, you resolve the ambiguity.

       Interface A
       /       \
      /         \
Interface B   Interface C
      \         /
       \       /
        Class D
         |
    Override methodX()

Explanation:
- Class D defines methodX() within itself and specifies the desired behavior.
- This way, instead of using the default methods from Interface B or Interface C, Class D's own implementation is used.

Solution 2: Calling by Specifying the Super Interface

In Java, a class can explicitly specify which interface's default method it wants to use.

       Interface A
       /       \
      /         \
Interface B   Interface C
      \         /
       \       /
        Class D
         |
    methodX() -> Interface B.methodX()

Explanation:
- While defining methodX() in Class D, for example, methodX() from Interface B can be called.
- Alternatively, methodX() from Interface C can be used.

Solution 3: Establishing a Hierarchy Among Interfaces

Sometimes, the Diamond Problem can be avoided by creating a hierarchy among interfaces.

Interface A
   |
Interface B
   |
Interface C
   |
 Class D

Explanation:
- If Interface C inherits from Interface B, and Interface B inherits from Interface A, a chained structure is formed.
- This way, Class D only implements Interface C, eliminating ambiguity.

Thanks for reading.

Burak Boduroglu

Interface vs Abstract Class?

Burak Boduroğlu — Sat, 22 Mar 2025 09:41:06 +0000

Interface:

An interface is a structure that defines only the signatures (method signatures) of the methods a class must implement. In other words, it does not contain the method bodies (implementation), only specifying what needs to be done.
A class can implement one or more interfaces.
A class that implements an interface must implement all the methods defined in that interface.
It is used to solve the problem of multiple inheritance.

Abstract Class:

An abstract class is a class that can contain both abstract and concrete methods. This means some methods may be bodiless (abstract), while others may be implemented.
A class can inherit from only one abstract class (single inheritance).
Abstract classes cannot be directly instantiated (no instances can be created), but they can be extended by subclasses.
They can contain both abstract and regular methods.
Variables can be defined with any access modifier (public, private, protected).
Subclasses are required to implement the abstract methods.
Inheritance from multiple abstract classes is not possible.

Differences Between Interface and Abstract Class:

Criterion	Interface	Abstract Class
Method Type	Generally only method signatures (except default/static methods after Java 8).	Can have both abstract and concrete methods.
Inheritance	Multiple interfaces can be implemented.	Only one abstract class can be inherited.
Variables	Only `public static final` (constants).	Variables of any type can be defined.
Constructor	Cannot have a constructor.	Can have a constructor.
Access Modifier	All methods are `public` by default.	Methods can have different access modifiers.
Purpose	Provides a fully abstract structure, typically used to define a set of behaviors.	Provides partial implementation, ideal for sharing common code.

When Should We Use Which Structure?

Use an Interface:
- When you want to define a common behavior across multiple classes.
- When you want to achieve full abstraction between classes.
- When multiple inheritance is needed.
- Example: General behaviors like Comparable, Runnable.
Use an Abstract Class:
- When you want to share common code (e.g., if some methods will have the same implementation).
- When you want to create a hierarchy between classes.
- When you need to use variables or concrete methods.

Thanks for reading.

Burak Boduroglu

How to Dockerize Your Next.js App: A Step-by-Step Guide

Burak Boduroğlu — Thu, 23 Jan 2025 15:45:09 +0000

In this blog post, I'll show you how to Dockerize a Next.js app using Docker and Docker Compose. We'll cover creating a Dockerfile, setting up a .dockerignore file, and configuring compose.yml to streamline development and deployment. This guide will help you containerize your Next.js app efficiently for a consistent environment across all stages.

Step 1: Create Your Next.js App

Start by creating a new Next.js application using the following command:

npx create-next-app@latest "your_app_name"

This will generate a Next.js project with the default setup.

Step 2: Initialize Docker

Once your Next.js app is set up, navigate to the project folder and run the following command to initialize Docker:

docker init

This command will generate essential Docker configuration files such as Dockerfile, compose.yaml, .dockerignore and README.Docker.md providing a solid starting point for containerizing your application.

After these steps, your project should look like this:

Step 3: Configure Next.js for Standalone Output

To optimize the Next.js app for production and make it easier to run in a Docker container, update the next.config.ts file by adding the following configuration:

import type { NextConfig } from 'next'


const nextConfig: NextConfig = {
  output: 'standalone',
}

export default nextConfig

This setting allows Next.js to generate a self-contained build, making deployment simpler with fewer dependencies.

Step 4: Configure the Dockerfile

Open the Dockerfile in the root of your project and replace its content with the following setup or your setup:

FROM node:20-alpine

WORKDIR /app
COPY package*.json /.
RUN npm install

COPY . .
EXPOSE 3000
CMD npm run dev

This Dockerfile uses a single-stage build process, simplifying the setup while still Dockerizing the Next.js application for development and production use.

Step 5: Configure compose.yaml

Update the docker-compose.yml file in the root of your project with the following content:

services:
  app:
    build:
      context: .
    image: host
    ports:
      - '3000:3000'
    environment:
      NODE_ENV: development

This configuration defines a service called app, which:

Builds the image from the current directory (context: .).
Tags the image as host.
Maps port 3000 on your local machine to port 3000 inside the container.
Sets the environment variable NODE_ENV to development.

Now, you can run your app with Docker Compose using the command:

docker-compose up

Conclusion
In this guide, we have covered the steps to Dockerize a Next.js application, making it easier to manage and deploy consistently across different environments. By following these steps:

Created a Next.js app using create-next-app.
Initialized Docker to generate the necessary configuration files.
Configured Next.js for a standalone build by modifying next.config.ts.
Set up a simple Dockerfile to build and run the Next.js app.
Configured docker-compose.yml to streamline building and running the application with ease.

With Docker and Docker Compose, you can now easily deploy your Next.js application in a controlled and reproducible environment. This approach simplifies development, testing, and production setups, ensuring that your application works the same across different machines and stages of deployment.

Let's take a quick look at Drizzle ORM

Burak Boduroğlu — Tue, 14 Jan 2025 11:48:07 +0000

Drizzle ORM Crash Course

Burak Boduroğlu ・ Jan 14 '25

#javascript #sql #programming #beginners

Drizzle ORM Crash Course

Burak Boduroğlu — Tue, 14 Jan 2025 11:46:32 +0000

Introduction

Drizzle ORM is a simple, lightwiegt ORM for TypeScript. It is designed to be simple to use and easy to understand. It is designed to be used with MySQL databases, but can be easily extended to work with other databases.

Get Started

Drizzle ORM supports PostgreSQL, MySQL, and SQLite. This guide will focus on MySQL, but the concepts are the same for all databases.
You can reach out more details on Drizzle ORM

Installation

To install Drizzle ORM, you need to install the package from npm.

npm i drizzle-orm pg dotenv
npm i -D drizzle-kit tsx @types/pg

npm i drizzle-orm pg dotenv - This command installs the Drizzle ORM package, the pg package, and the dotenv package. The pg package is required for PostgreSQL support, but it is not required for MySQL or SQLite.

npm i -D drizzle-kit tsx @types/pg - This command installs the Drizzle Kit package, the tsx package, and the @types/pg package. The Drizzle Kit package is required for Drizzle ORM to work with TypeScript.

Configuration

To configure Drizzle ORM, you need to create a .env file in the root of your project. This file should contain the following information:

DATABASE_URL=your-database-url

Replace your-database-url with the URL of your database. For example, if you are using MySQL, the URL should look like this:

DATABASE_URL=mysql://username:password@localhost:3306/database

Setup drizzle config in your drizzle.config.ts file.

import 'dotenv/config';
import { defineConfig } from 'drizzle-kit';

export default defineConfig({
  out: './drizzle',
  schema: './src/db/schema.ts',
  dialect: 'postgresql',
  dbCredentials: {
    url: process.env.DATABASE_URL!,
  },
});

Create a Table

To create a table in your database, you need to define a schema in a file called schema.ts. This file should contain the following information:

import { pgTable, unique, integer, varchar } from 'drizzle-orm/pg-core';
import { sql } from 'drizzle-orm';

export const users = pgTable(
  'users',
  {
    id: integer().primaryKey().generatedAlwaysAsIdentity({
      name: 'users_id_seq',
      startWith: 1,
      increment: 1,
      minValue: 1,
      maxValue: 2147483647,
      cache: 1,
    }),
    name: varchar({ length: 255 }).notNull(),
    age: integer().notNull(),
    email: varchar({ length: 255 }).notNull(),
  },
  (table) => {
    return {
      usersEmailUnique: unique('users_email_unique').on(table.email),
    };
  }
);

We define a table called users with four columns: id, name, age, and email. The id column is an auto-incrementing primary key, and the name, age, and email columns are required.

Connect to the Database

Create a index.ts file in the src/db directory and initialize the connection to the database.

import 'dotenv/config';
import { drizzle } from 'drizzle-orm/node-postgres';

const db = drizzle(process.env.DATABASE_URL!);

We have already define the DATABASE_URL in the .env file. We are using the drizzle function to connect to the database.

Insert Data

To insert data into the users table, you can use the insert method on the db object.

import { users } from './schema';

const user = await db.insert(users).values({
  name: 'John Doe',
  age: 30,
  email: '
});

We are using the insert method on the db object to insert a new user into the users table. We are passing an object with the name, age, and email properties to the values method.

Query Data

To query data from the users table, you can use the select method on the db object.

import { users } from './schema';

const user = await db.select(users).where(users.id.eq(1)).execute();

We are using the select method on the db object to query a user from the users table. We are using the where method to filter the results based on the id column.

Update Data

To update data in the users table, you can use the update method on the db object.

import { users } from './schema';

const user = await db.update(users).set({ age: 31 }).where(users.id.eq(1)).execute();

We are using the update method on the db object to update a user in the users table. We are using the set method to set the age column to 31, and the where method to filter the results based on the id column.

Delete Data

To delete data from the users table, you can use the delete method on the db object.

import { users } from './schema';

const user = await db.delete(users).where(users.id.eq(1)).execute();

We are using the delete method on the db object to delete a user from the users table. We are using the where method to filter the results based on the id column.

Conclusion

Drizzle ORM is a simple, lightweight ORM for TypeScript. It is designed to be simple to use and easy to understand. It is designed to be used with MySQL databases, but can be easily extended to work with other databases. You can reach out more details on Drizzle ORM

Thank You

Thank you for reading this guide. I hope you found it helpful. If you have any questions or feedback, please feel free to reach out to me. I would love to hear from you.

SOLID Design Principles and Design Patterns with Examples

Burak Boduroğlu — Wed, 07 Aug 2024 18:09:34 +0000

Today we will talk about SOLID principles and design patterns. These are the most important concepts in software development. They help us to write clean, maintainable, and scalable code. Let's start with the SOLID principles.

SOLID Principles

SOLID is an acronym for five principles that help software developers design maintainable and scalable code. These principles were introduced by Robert C. Martin in the early 2000s. The five principles are:

Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)

Let's discuss each of these principles in detail.

Single Responsibility Principle (SRP)

Single Responsibility Principle states that a class should have only one reason to change. In other words, a class should have only one responsibility. If a class has more than one responsibility, it becomes harder to maintain and test. It's better to split the class into smaller classes, each with its own responsibility. However most of time we call interface or abstract class as single responsibility principle.
It's a quick example with .NET code:

public interface IEmailService
{
    void SendEmail(string to, string subject, string body);
}

public class EmailService : IEmailService
{
    public void SendEmail(string to, string subject, string body)
    {
        // Send email
    }
}

In this example, we have an IEmailService interface and an EmailService class that implements this interface. The EmailService class has a single responsibility, which is to send emails. If we need to change the way emails are sent, we only need to modify the EmailService class.

Open/Closed Principle (OCP)

Open/Closed Principle states that a class should be open for extension but closed for modification. In other words, we should be able to extend a class's behavior without modifying it. This can be achieved by using inheritance and interfaces. It's a quick example with .NET code:

public interface IShape
{
    double Area();
}

public class Circle : IShape
{
    public double Radius { get; set; }

    public double Area()
    {
        return Math.PI * Radius * Radius;
    }
}

public class Rectangle : IShape
{
    public double Width { get; set; }
    public double Height { get; set; }

    public double Area()
    {
        return Width * Height;
    }
}

In this example, we have an IShape interface and two classes Circle and Rectangle that implement this interface. If we need to add a new shape, we can create a new class that implements the IShape interface without modifying the existing classes.

Liskov Substitution Principle (LSP)

Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. In other words, a subclass should be able to replace its superclass without any
issues. It's a quick example with .NET code:

public class Rectangle
{
    public virtual double Width { get; set; }
    public virtual double Height { get; set; }

    public double Area()
    {
        return Width * Height;
    }
}

public class Square : Rectangle
{
    public override double Width
    {
        get => base.Width;
        set
        {
            base.Width = value;
            base.Height = value;
        }
    }

    public override double Height
    {
        get => base.Height;
        set
        {
            base.Width = value;
            base.Height = value;
        }
    }
}

In this example, we have a Rectangle class and a Square class that inherits from the Rectangle class. The Square class overrides the Width and Height properties to ensure that they are always equal. This allows us to use a Square object wherever a Rectangle object is expected.

Interface Segregation Principle (ISP)

Interface Segregation Principle states that a client should not be forced to implement an interface that it doesn't use. In other words, we should split large interfaces into smaller, more specific interfaces so that clients only need to implement the methods they are interested in. It's a quick example with .NET code:

public interface IShape
{
    double Area();
    double Perimeter();
}

public class Circle : IShape
{
    public double Radius { get; set; }

    public double Area()
    {
        return Math.PI * Radius * Radius;
    }

    public double Perimeter()
    {
        return 2 * Math.PI * Radius;
    }
}

public class Rectangle : IShape
{
    public double Width { get; set; }
    public double Height { get; set; }

    public double Area()
    {
        return Width * Height;
    }

    public double Perimeter()
    {
        return 2 * (Width + Height);
    }
}

In this example, we have an IShape interface that defines two methods Area and Perimeter. The Circle and Rectangle classes implement this interface and provide their own implementations for these methods.

Dependency Inversion Principle (DIP)

Dependency Inversion Principle states that high-level modules should not depend on low-level modules. Both should depend on abstractions. In other words, classes should depend on interfaces or abstract classes rather than concrete classes. This allows us to decouple classes and make them easier to test and maintain. It's a quick example with .NET code:

public interface ILogger
{
    void Log(string message);
}

public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

public class EmailLogger : ILogger
{
    public void Log(string message)
    {
        // Send email
    }
}

public class Logger
{
    private readonly ILogger _logger;

    public Logger(ILogger logger)
    {
        _logger = logger;
    }

    public void Log(string message)
    {
        _logger.Log(message);
    }
}

In this example, we have an ILogger interface and two classes ConsoleLogger and EmailLogger that implement this interface. The Logger class depends on the ILogger interface rather than concrete classes. This allows us to easily switch between different loggers without modifying the Logger class.

Design Patterns

Design patterns are reusable solutions to common problems in software design. They help us write clean, maintainable, and scalable code. There are three categories of design patterns:

Creational Patterns
Structural Patterns
Behavioral Patterns

Let's discuss each of these categories in detail.

Creational Patterns

Creational patterns are concerned with object creation mechanisms. They help us create objects in a way that is flexible and decoupled from the client code. Some common creational patterns are:

Factory Method
Abstract Factory
Builder
Prototype
Singleton

Structural Patterns

Structural patterns are concerned with object composition. They help us define how objects are composed to form larger structures. Some common structural patterns are:

Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Module

Behavioral Patterns

Behavioral patterns are concerned with object interaction. They help us define how objects communicate with each other. Some common behavioral patterns are:

Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor

Let's discuss each of these patterns in detail with examples.

Repository Pattern

The Repository pattern is a design pattern that abstracts the data access logic from the rest of the application. It provides a way to access data without directly querying the database. This makes the application more maintainable and testable. It's a quick example with .NET code:

public interface IRepository<T>
{
    T GetById(int id);
    IEnumerable<T> GetAll();
    void Add(T entity);
    void Update(T entity);
    void Delete(T entity);
}

public class Repository<T> : IRepository<T>
{
    private readonly DbContext _context;

    public Repository(DbContext context)
    {
        _context = context;
    }

    public T GetById(int id)
    {
        return _context.Set<T>().Find(id);
    }

    public IEnumerable<T> GetAll()
    {
        return _context.Set<T>().ToList();
    }

    public void Add(T entity)
    {
        _context.Set<T>().Add(entity);
        _context.SaveChanges();
    }

    public void Update(T entity)
    {
        _context.Entry(entity).State = EntityState.Modified;
        _context.SaveChanges();
    }

    public void Delete(T entity)
    {
        _context.Set<T>().Remove(entity);
        _context.SaveChanges();
    }
}

In this example, we have an IRepository interface and a Repository class that implements this interface. The Repository class provides methods to interact with the database without directly querying it. This allows us to easily switch between different data access technologies without modifying the client code.

Factory Method Pattern

The Factory Method pattern is a design pattern that provides an interface for creating objects in a superclass but allows subclasses to alter the type of objects that will be created. It's a quick example with .NET code:

public interface IShapeFactory
{
    IShape CreateShape();
}

public class CircleFactory : IShapeFactory
{
    public IShape CreateShape()
    {
        return new Circle();
    }
}

public class RectangleFactory : IShapeFactory
{
    public IShape CreateShape()
    {
        return new Rectangle();
    }
}

In this example, we have an IShapeFactory interface and two classes CircleFactory and RectangleFactory that implement this interface. The CircleFactory class creates Circle objects, and the RectangleFactory class creates Rectangle objects. This allows us to easily switch between different types of shapes without modifying the client code.

Singleton Pattern

The Singleton pattern is a design pattern that ensures a class has only one instance and provides a global point of access to it. It's a quick example with .NET code:

public class Logger
{
    private static Logger _instance;
    private static readonly object _lock = new object();

    private Logger()
    {
    }

    public static Logger Instance
    {
        get
        {
            lock (_lock)
            {
                if (_instance == null)
                {
                    _instance = new Logger();
                }
                return _instance;
            }
        }
    }

    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

In this example, we have a Logger class with a private constructor and a static Instance property that returns the singleton instance of the class. The Instance property uses a double-checked locking mechanism to ensure that only one instance of the class is created.

Adapter Pattern

The Adapter pattern is a design pattern that allows objects with incompatible interfaces to work together. It acts as a bridge between two incompatible interfaces. It's a quick example with .NET code:

public interface ITarget
{
    void Request();
}

public class Adaptee
{
    public void SpecificRequest()
    {
        Console.WriteLine("Specific request");
    }
}

public class Adapter : ITarget
{
    private readonly Adaptee _adaptee;

    public Adapter(Adaptee adaptee)
    {
        _adaptee = adaptee;
    }

    public void Request()
    {
        _adaptee.SpecificRequest();
    }
}

In this example, we have an ITarget interface and an Adapter class that implements this interface. The Adapter class uses the Adaptee class to adapt the SpecificRequest method to the Request method. This allows objects that expect an ITarget interface to work with the Adaptee class.

Builder Pattern

The Builder pattern is a design pattern that separates the construction of a complex object from its representation. It allows us to create an object step by step and produce different types and representations of an object using the same construction process. It's a quick example with .NET code:

public class Product
{
    public string Part1 { get; set; }
    public string Part2 { get; set; }
}

public interface IBuilder
{
    void BuildPart1();
    void BuildPart2();
    Product GetProduct();
}

public class ConcreteBuilder : IBuilder
{
    private readonly Product _product = new Product();

    public void BuildPart1()
    {
        _product.Part1 = "Part 1";
    }

    public void BuildPart2()
    {
        _product.Part2 = "Part 2";
    }

    public Product GetProduct()
    {
        return _product;
    }
}

public class Director
{
    private readonly IBuilder _builder;

    public Director(IBuilder builder)
    {
        _builder = builder;
    }

    public void Construct()
    {
        _builder.BuildPart1();
        _builder.BuildPart2();
    }
}

In this example, we have a Product class that represents a complex object with two parts. We have an IBuilder interface and a ConcreteBuilder class that implements this interface. The Director class uses the ConcreteBuilder class to construct a Product object step by step.

Conclusion

In this article, we discussed the SOLID principles and design patterns. These are the most important concepts in software development. They help us write clean, maintainable, and scalable code. By following these principles and patterns, we can build high-quality software that is easy to maintain and extend. I hope you found this article helpful. Thank you for reading!

References

React Query Crash Post

Burak Boduroğlu — Thu, 04 Jul 2024 09:28:47 +0000

React Query is a library that provides a way to fetch, cache and update data in your React applications. It is a great library that can help you manage your data fetching in a more efficient way. In this post, we will take a look at how to use React Query to fetch data from an API and display it in a React component.

Installation

To get started with React Query, you need to install it in your project. You can do this by running the following command:

npm install react-query

yarn add react-query

After installing React Query, you should provide the QueryClientProvider at the root of your application. This will allow you to use the useQuery hook in your components. Here is an example of how you can set up the QueryClientProvider in your application:

import { QueryClient, QueryClientProvider } from "react-query";

const queryClient = new QueryClient();

const App = () => (
  <QueryClientProvider client={queryClient}>
    <div>{/* Your application components */}</div>
  </QueryClientProvider>
);

export default App;

GET Data

Once you have installed React Query, you can start fetching data from an API. To do this, you need to create a query using the useQuery hook. Here is an example of how you can fetch data from an API using React Query:

import { useQuery } from "react-query";

const fetchPosts = async () => {
  const response = await fetch("https://jsonplaceholder.typicode.com/posts");
  const data = await response.json();
  return data;
};

const Posts = () => {
  const { data, isLoading, error } = useQuery("posts", fetchPosts);

  if (isLoading) {
    return <div>Loading...</div>;
  }

  if (error) {
    return <div>Error: {error.message}</div>;
  }

  return (
    <div>
      {data.map((post) => (
        <div key={post.id}>{post.title}</div>
      ))}
    </div>
  );
};

export default Posts;

POST Data

React Query also provides a way to update data in your application. You can use the useMutation hook to send a POST request to an API. Here is an example of how you can update data using React Query:

import { useMutation } from "react-query";

const createPost = async (newPost) => {
  const response = await fetch("https://jsonplaceholder.typicode.com/posts", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify(newPost),
  });
  const data = await response.json();
  return data;
};

const NewPost = () => {
  const { mutate, isLoading, error } = useMutation(createPost);

  const handleSubmit = (event) => {
    event.preventDefault();
    const newPost = {
      title: event.target.title.value,
      body: event.target.body.value,
    };
    mutate(newPost);
  };

  return (
    <form onSubmit={handleSubmit}>
      <input type="text" name="title" placeholder="Title" />
      <textarea name="body" placeholder="Body" />
      <button type="submit" disabled={isLoading}>
        {isLoading ? "Loading..." : "Submit"}
      </button>
      {error && <div>Error: {error.message}</div>}
    </form>
  );
};

export default NewPost;

React Query vs useEffect

React Query is a great library that can help you manage your data fetching in a more efficient way. It provides a way to fetch, cache and update data in your React applications. With React Query, you can easily fetch data from an API and display it in your components. It also provides a way to update data in your application using the useMutation hook. If you are using useEffect to fetch data in your React application, you should consider using React Query instead. It can help you manage your data fetching in a more efficient way and provide a better user experience.

Same Example with useEffect

Here is an example of how you can fetch data from an API using useEffect:

import { useEffect, useState } from "react";

const Posts = () => {
  const [posts, setPosts] = useState([]);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchPosts = async () => {
      try {
        const response = await fetch(
          "https://jsonplaceholder.typicode.com/posts"
        );
        const data = await response.json();
        setPosts(data);
        setIsLoading(false);
      } catch (error) {
        setError(error);
        setIsLoading(false);
      }
    };

    fetchPosts();
  }, []);

  if (isLoading) {
    return <div>Loading...</div>;
  }

  if (error) {
    return <div>Error: {error.message}</div>;
  }

  return (
    <div>
      {posts.map((post) => (
        <div key={post.id}>{post.title}</div>
      ))}
    </div>
  );
};

export default Posts;

Summary

useQuery hook is used to fetch data from an API.
useMutation hook is used to update data in your application.
enable option in useQuery hook is used to control when the query should be fetched.

Thank You

Thank you for reading this post. I hope you found it helpful. If you have any questions or feedback, please feel free to leave a comment below.

DEV Community: Burak Boduroğlu

Free stuck TCP ports in one command — without memorizing `lsof`, `fuser`, and `kill` pipelines

.portkill

Why .portkill

Install

Quick start

GUI walkthrough (video)

CLI flags (short)

Requirements

Docs & product spec

Development

npm vs GitHub README

License

Check out this post and drop your thoughts! Let’s brainstorm some new ideas and learn together.

Agentic Coding: Rules, skills, subagents, and reflection—how we steer models so multi-step work stays coherent.

Burak Boduroğlu ・ Mar 20

Agentic Coding: Rules, skills, subagents, and reflection—how we steer models so multi-step work stays coherent.

The thesis (one glance)

Rules: project manifest

Skills: when to reach for which playbook

Subagents: who owns what

End-to-end flow

Steal this shape for your own repo

Where this lives in the tree

What is Agile?

The Agile Manifesto: 4 Core Values

The 12 Principles of the Agile Manifesto

5 Golden Rules to Improve Code Quality in Java: SOLID Principles

Diamond Problem in Java? How to fix it?

What is the Diamond Problem?

Scenario: How the Diamond Problem Arises

Solution to the Diamond Problem in Java

Solution 1: Overriding the Default Method

Solution 2: Calling by Specifying the Super Interface

Solution 3: Establishing a Hierarchy Among Interfaces

Interface vs Abstract Class?

Interface:

Abstract Class:

Differences Between Interface and Abstract Class:

When Should We Use Which Structure?

How to Dockerize Your Next.js App: A Step-by-Step Guide

Step 1: Create Your Next.js App

Step 2: Initialize Docker

Step 3: Configure Next.js for Standalone Output

Step 4: Configure the Dockerfile

Step 5: Configure compose.yaml

Let's take a quick look at Drizzle ORM

Drizzle ORM Crash Course

Burak Boduroğlu ・ Jan 14 '25

Drizzle ORM Crash Course

Introduction

Get Started

Installation

Configuration

Create a Table

Connect to the Database

Insert Data

Query Data

Update Data

Delete Data

Conclusion

Thank You

SOLID Design Principles and Design Patterns with Examples

SOLID Principles

Single Responsibility Principle (SRP)

Open/Closed Principle (OCP)

Liskov Substitution Principle (LSP)

Interface Segregation Principle (ISP)

Dependency Inversion Principle (DIP)

Design Patterns

Creational Patterns

Structural Patterns

Behavioral Patterns

Repository Pattern

Factory Method Pattern

Singleton Pattern

Adapter Pattern

Builder Pattern

Conclusion

References

`.portkill`

Why `.portkill`