Boraxpr

Simplify Your Code with Guard Clauses and Logical Expressions.

Boraxpr — Wed, 20 Sep 2023 00:00:00 GMT

When you start learning to code, after your initial "Hello, World!" program, one of the first constructs you encounter is the if-else statement. It's a fundamental part of programming, but it can quickly lead to complex and convoluted code if not used wisely. In this article, we'll explore how to simplify your code by avoiding nested if statements and employing guard clauses and logical expressions.

The Nested If Challenge 😫

is_sunny = True
temperature = 25
is_weekend = False
is_holiday = True
has_garden = False

if is_sunny:
    if temperature > 20:
        if not has_garden:
            print("It's a great day for a picnic!")
        else:
            print("We can't have a picnic today, no garden available.")
    elif is_weekend and is_holiday:
        if not has_garden:
            print("It's a great day for a picnic!")
        else:
            print("We can't have a picnic today, no garden available.")
    else:
        print("We can't have a picnic today, temperature is too low.")
else:
    print("We can't have a picnic today, it's not sunny.")

Admit it, this code is not the easiest to read or maintain.

Guard Clauses: A Cleaner Alternative ✨

To keep your code straightforward and easy to understand, consider using guard clauses. Guard clauses allow you to handle exceptional cases first and return early from a function or method. This eliminates the need for deeply nested if-else blocks.

Don't do these 💀

if (A != null) {
  if (B != null){
    //do1
  }
  else {
    return;
  }
}
else {
  return;
}

Do these 😇

if (A == null) {
  return;
}
if (B = null) {
  return;
}
//do1
//do2

Combining Conditions for Clarity 🔍

After eliminating excessive if-else nesting, consider combining conditions when dealing with multiple variables. This simplifies your code and reduces the need for labyrinthian logic.

Don't do these 💀

if (A){
  //before check B
  if (B){
    //before check C
    if (C){
      //...
      if (D){
        //...
        if (E){
          //do1
        }
        //...
      }
      //...
    }
    //after check C
  }
  //after check B
}

Do these 😇

if (A and B and C and D and E){
    //do1
  }
...

Or, for even more clarity, consider breaking conditions into seperate lines 😇😇😇

if (A){}
if (B){}
if (C){}
//...

Simplifying Conditional Logic in Action 🚀

Now, let's apply these concepts to simplify the code:

is_sunny = True
temperature = 25
is_weekend = False
is_holiday = True
has_garden = False

if is_sunny and (temperature > 20 or (is_weekend and is_holiday)) and not has_garden:
    print("It's a great day for a picnic!")
else:
    print("We can't have a picnic today.")

By implementing guard clauses and simplifying conditional logic, you can make your code more readable, maintainable, and less error-prone. Whether you're a beginner or an experienced developer, these practices will help you produce cleaner and more efficient code.

In summary, code simplicity is not just a preference; it's a best practice that leads to better software development. Embrace these techniques to make your codebase more approachable and enjoyable to work with.

Low code, The code is low until it is not.

Boraxpr — Fri, 22 Sep 2023 00:00:00 GMT

Low code is not as straightforward as it might appear. While it may initially seem like an easy, error-free solution for developers, the reality is quite different. Low code can indeed simplify your life, but only until your project's requirements dictate otherwise.

The Front-End Challenge

Low code platforms allow you to create user interfaces without requiring in-depth knowledge of HTML, CSS, or JavaScript. You can simply drag and drop elements like inputs, forms, buttons, and tables. There are even helper actions to pull data onto the screen and generate tables automatically. These pre-made UI elements promise speed and efficiency, making you feel like you can deliver quickly—assuming your project aligns with the pre-made UI components.

In practice, such alignment with pre-made UIs is rare. Customers and designers often demand customizations that involve CSS adjustments. This is where low code becomes a daunting challenge. Pre-made UIs come with their own pre-existing CSS code, making it challenging to modify them. Finding the right CSS class to edit can be a struggle, and you might end up reinventing the wheel by resorting to vanilla CSS, without the convenience of libraries.

In high-code environments, you have access to reusable React components, which can be more efficient than the low code alternative.

Being Locked in the Environment

While low code platforms may offer some libraries, they may fall short when you need a specific one. Integrating external libraries can be far from straightforward, with limited documentation and poor integration with the low code platform itself.

The Risk of Reinventing the Wheel

When importing well-tested and proven libraries is impossible, and your project requirements exceed the capabilities of your low code platform, you're left with no choice but to write your own code. This can be time-consuming and prone to bugs, whereas high-code environments offer the convenience of utilizing existing libraries to save time and effort.

In summary, low code can simplify development, but it's essential to recognize its limitations. It's "low" until your project's unique demands push you into the complexities of custom CSS, limited library options, and potentially reinventing solutions.

"In essence, low code serves as a higher-level abstraction of high code, but the closed nature of low code platforms frequently necessitates subpar high-code workarounds, ultimately compromising software quality."

Demystifying: CSS The Transition from Vanilla CSS to TailwindCSS

Boraxpr — Fri, 27 Oct 2023 00:00:00 GMT

When I first got into programming during college, I was all about C, Python, and Java. Web development, with CSS and JavaScript, seemed like a whole different world. Fast forward to my new gig at a company, and I've spent months wading through the CSS waters. I want to share what I've learned and why I'm warming up to Cascading Style Sheets.

The HTML Riddle

Fire up your favorite web browser and open a developer console. For me, I'm on Firefox so it's ctrl+shift+I. Now, go to any website and click on the inspector tool. You'll see the HTML code that makes up the page. It's a tree-like structure of tags and content. Like this:

<html>
  <head>
    <title>My Page</title>
  </head>
  <body>
    <h1>My Page</h1>
    <p>My first paragraph</p>
  </body>
</html>

This is the HTML code for a simple page. It has a title, a heading, and a paragraph. The tags are the building blocks of the page. They tell the browser what to display and how to display it. But there's a catch.

The HTML Challenge: It's Not Pretty

HTML is great for structuring content, but it's not so good at making it look good. You can't change the font size, color, or spacing. You can't even make a simple box. That's where CSS comes in.

The CSS Riddle

CSS was a head-scratcher at the beginning. It didn't behave like the familiar programming languages I knew. But as I got into it, I started to decode its mysteries.

With CSS, you can dress up your web content. You make classes with your names and decide how they should look. Like this:

.myFirstClass {
  /* CSS properties */
}

These classes can be imported into your HTML code:

<div class="myFirstClass">
  <!-- HTML content -->
</div>

Everything inside this HTML tag adopts the specified CSS properties. But there's more.

CSS Tricks: Targeting Things

One of CSS's magic tricks is the ability to target nested elements. Let's say you want to style mySecondClass, but only when it's inside a myFirstClass tag. You can do this:

.myFirstClass .mySecondClass {
  /* CSS properties */
}

This is called a descendant selector. It's a powerful tool that allows you to target specific elements in your HTML code.

Borrowing from the Basics

CSS is not just about custom classes. You can also inherit and extend styles from predefined HTML elements. For instance, 'a' tags come with default values:

a {
  color: blue;
  text-decoration: underline;
  cursor: auto;
}

This means that when you use an anchor tag:

<a href="www.yourlink.com">Link Text</a>

It always has an underline, a default cursor, and the default link color. It's like the CSS magic got passed down through the generations.

The CSS Challenge: It Gets Messy

As I got better at CSS, I bumped into a common problem - keeping the old styles while bringing in new ones. It's like a slippery slope. What begins as a simple task can quickly turn into a maze of CSS classes, leading to a mess that's hard to clean up.

Enter TailwindCSS

In my search for a solution, I found TailwindCSS, and it's made my life easier.

TailwindCSS simplifies styling. It gives you a set of ready-made classes, so you don't have to write loads of custom CSS. You style HTML elements by picking and using these classes directly.

It's super convenient. You select and apply TailwindCSS classes for your HTML elements without piling up tons of custom CSS. But there are trade-offs. Your HTML might get longer, and you have to learn TailwindCSS's class names.

Conclusion

CSS might seem confusing at first, but once you get the hang of it, it's a powerful tool. Whether you go for old-school custom CSS or embrace the simplicity of TailwindCSS, the key is to create good-looking and functional web stuff. Happy coding! 🚀

Art of Tailwind CSS

Boraxpr — Wed, 17 Jan 2024 00:00:00 GMT

TailwindCSS is a utility-first CSS framework. It is a set of CSS classes that you can use to style your HTML elements. It is not a UI library like Bootstrap or Material UI. It is a CSS framework that you can use to build your own UI library. Assuming you have a basic understanding of HTML and CSS, you can use TailwindCSS to build your own UI library.

Animate

One of the hardest thing to do is Animation In tailwind.config.js, you can add your own animation. Keyframes are the animation that you want to do. Animation is the name of the animation that you want to do.

module.exports = {
  content: [
    './app/**/*.{js,ts,jsx,tsx,mdx}',
    './components/**/*.{js,ts,jsx,tsx,mdx}'
  ],
  theme: {
    extend: {
      keyframes: {
        shake: {
          '0%, 100%': { transform: 'translate3d(0, 0, 0)' },
          '10%, 30%, 50%, 70%, 90%': { transform: 'translate3d(-10px, 0, 0)' },
          '20%, 40%, 60%, 80%': { transform: 'translate3d(10px, 0, 0)' }
        }
      },
      animation: {
        shake: 'shake 1s ease-in-out'
      }
    }
  },
  plugins: []
}

After that, you can use the animation in your HTML element.

<div className="animate-shake">Shake me!</div>

Arbitrary Values

You can use arbitrary values in TailwindCSS. For example, if you want to set the width of an element to 100px, you can do it like this:

<div className="w-[100px]">My Element</div>

You can also use arbitrary values in the @apply directive. For example, if you want to set the width of an element to 100px, you can do it like this:

@layer base {
  .my-element {
    @apply w-[100px];
  }
}

Then you can use the my-element class like this:

<div className="my-element">My Element</div>

You can't use it for animations though.

Don't make components for default HTML elements

You do not need to make components for default HTML elements to reuse TailwindCSS classes. Things like button, input, p tag, etc. You can override them by using the @apply directive at @layer base.

@layer base on globals.css is the base layer. It is the default style of the HTML elements. You can override the default style by using the @layer base directive. For example, if you want to override the default style of the h1 element, you can do it like this on your globals.css file:

@layer base {
  h1 {
    @apply text-4xl font-bold text-gray-900;
  }
}

Then you can use the h1 element like this:

<h1>My Title</h1>

Even for the button element, you can override the default style like this:

@layer base {
  button {
    @apply px-4 py-2 text-white bg-blue-500 rounded-md;
  }
}

Then you can use the button element like this:

<button>My Button</button>

Then poof!, all your buttons will have the same style.

Reuse : Do make components for custom elements

You can make components for custom elements. For example, if you want to make a card, you can do it like this:

async function handleClick() {
  const { data, error } = await someAPICalls
  redirect('/some-page')
}
;<Card
  customTailwindClasses="bg-red-50 border-red-200 rounded-lg"
  customFunction={() => handleClick}
>
  <span>My Card</span>
  <span>Card detail</span>
</Card>

Then you can make a component for it like this:

// Card.tsx
import React from 'react'

export default function Card({
  children,
  customTailwindClasses,
  customFunction
}: {
  children: React.ReactNode
  customTailwindClasses?: string
  customFunction?: () => void
}) {
  return (
    <div className={`${customTailwindClasses}`} onClick={customFunction}>
      {children}
    </div>
  )
}

Understanding Docker Multi-Stage Builds

Boraxpr — Sun, 25 Feb 2024 00:00:00 GMT

Docker has revolutionized the way we develop, package, and deploy applications. It provides a way to run applications isolated in containers, which are lightweight and include everything needed to run the application. One of the key features of Docker is the ability to build images using a Dockerfile. A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image.

What are Multi-Stage Builds?

In Docker, a multi-stage build is a process where you use multiple FROM statements in your Dockerfile. Each FROM instruction can use a different base, and each of them begins a new stage of the build. You can selectively copy artifacts from one stage to another, leaving behind everything you don’t want in the final image.

The primary reason behind using multi-stage builds is to keep the final images small in size. The smaller the image, the faster it can be transferred and the less disk space it takes up.

Why Use Multi-Stage Builds?

1.Image Size

When building Docker images, size matters. A smaller Docker image will lead to faster deployment times, which is critical in a CI/CD environment. It also reduces the attack surface area and thus improves security.

2.Build-Time Dependencies

There might be some dependencies required during the build time, but not needed in the runtime. With multi-stage builds, you can install these dependencies in the first stage where the building happens and not include them in the final stage.

3. Separation of Build and Run Stages

With multi-stage builds, you can use one base image for building the application and a different image for running the application. This separation can lead to more efficient images. For example, you might need a full-fledged Rust environment to build a Rust application, but you might only need a minimal Fedora image to run it. An Example of Multi-Stage Build

Here’s an example of a Dockerfile for a Rust application using multi-stage builds:

# Use an official Rust runtime as a parent image

FROM rust:1.76 as builder

# Set the working directory in the container to /usr/src/rust_axum_service

WORKDIR /usr/src/rust_service

# Copy the current directory contents into the container at /usr/src/rust_axum_service

COPY . .

# Build the application

RUN cargo build

# Start a new stage. This is for the runtime environment

FROM fedora:41 as runtime

# Install openssl and ca-certificates and other dependencies that will be needed

RUN dnf -y update && dnf -y install openssl-devel ca-certificates && dnf clean all

# Set the working directory in the container to /usr/local/bin

WORKDIR /usr/local/bin

# Copy the binary from builder to this new stage

COPY --from=builder /usr/src/rust_service/target/debug/app /usr/local/bin

# Run the binary executable

CMD ["./app"]

Conclusion

Docker's multi-stage builds feature is a powerful tool for creating efficient Docker images. By separating build and runtime environments and selectively copying artifacts between stages, you can create smaller, more secure Docker images. This leads to faster deployment times and less disk space usage, making it beneficial in a production environment. As always, it's important to understand your application's specific needs and adjust your Dockerfile accordingly.

Beyond CRUD: Architecting Backends with Modern Languages

Boraxpr — Mon, 26 Feb 2024 00:00:00 GMT

Recently, I've stumbled across the newer languages and frameworks that are prevalent and expected by the dev community to be the future of backend. I tried Rust tokio-rs/axum the framework way and also Go minimalistic net/http way. And incorporated best practices in the architecture.

Routing Layer

The routing layer is responsible for defining the URL paths for incoming requests. It acts as the entry point for requests, directing them to the appropriate handler based on the specified path.

Middleware Layer

Middleware functions as a pre-handler, allowing you to run code before passing the request to the handler. This is commonly used for tasks such as validation, authentication, logging, and request processing. Middleware helps to modularize and reuse code across different parts of your application.

Handler/Controller Layer

The handler/controller layer serves as the bridge between the frontend and backend. It receives incoming data from the frontend, processes it, and sends outgoing data back to the frontend. This layer plays a crucial role in handling user requests and orchestrating the flow of data within the application.

Service Layer

The service layer is where complex business logic resides. It abstracts away the logic from the handler/controller layer, keeping it clean and focused. This layer is particularly useful for handling complex operations that would otherwise clutter the handler/controller code.

Data Access/Repository Layer

The data access layer is responsible for interacting with the database and performing data operations. It handles low-level tasks such as SQL queries, data manipulation, and database transactions. Separating this layer from the rest of the application logic helps maintain a clear separation of concerns and improves overall code maintainability.

By understanding and implementing these architectural principles, developers can create robust, scalable, and maintainable backend systems. While the specific technologies and languages may vary, the core concepts remain consistent, making these principles applicable across a range of backend development scenarios.

Cookie-Token based Authentication (Client-To-Server)

Boraxpr — Sat, 02 Mar 2024 00:00:00 GMT

Authentication is one of the hardest thing to do. Even when almost every application that you need to implement nowadays (Client-To-Server), needs an authentication system. Today, I'm going to debunk the myth of the authentication in both front and backend.

The Problem : Front-end

Front-End should not be able to access the cookie. Confusing isn't it ? Exposing a cookie or any token on front-end is just pure WRONG with CAPS because it allows anyone with JavaScript steal your identity. How are we going to implement protected routes ? you might ask.

The Key : Set-Cookie & HttpOnly

Invented back in 2002 by Microsoft Internet Explorer developers, HttpOnly is a flag that you could set inside "Set-Cookie" HTTP response header. How is this important ? Because Set-Cookie header that you send from server-side is automatically captured by the client-side, and every subsequence requests to the server by the same origin will be attached with the cookie without any intervention from the client-side. This way, You prevent all access from client-side and the only way hacker could do you wrong is to mess with the server. Cross-site scripting (XSS) would be the past problem. On top of that, set SameSite Attribute = Strict or Lax helps mitigate Cross-Site Request Forgery(CSRF) attacks.

How-To

The Front-End

Whether you are using Framework like Nuxt, Vue, Next or library like React to do a multi-page app, you are going to have a router. That router, you can do a middleware. Every route changes you need to call the server-side to check session. If True, Allow access. If False, Redirect to Login Page. And that's it for the Front-End.

The Back-End

Back-End is the main actor here. You need /login, /session and some knowledge about JWT. JavaScript Object Notation Web Token. Ok, just ignore that. Basically, JWT is a base64 encoded text.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The JWT

Anyone can decode JWT, sees its content. But Only the one with its pro·gen·i·tor "SECRET" is able to edit, verify and create more JWT cute childlings. Hence, JWTs can provide data integrity, authenticity but lacks confidentiality.

Now, After you know about the JWT secret and their ability to create more childs.

The Back-End & JWT interaction

/login: After successfully verify username and password, response with cookie (Don't forget to use Set-Cookie to make the browser automatically handles the cookie safely) and user info. <br> /session : Will check the cookie from the client (Automatically sent on every subsequences)

Here is more things you need to know. Cookie Expiration controls how long the cookie will be stored and sent by the browser. Once it has expired, the browser will not include it in requests to the server. JWT Expiration controls the validation on the server-side. The secret and the expiry of JWT will be cross checked on parsing and JWT childs that passed their expiry are invalid.

The limitations

This method of cookie-token has one of its downside being when you need multiple domain to call the server apis. If that's the case then you would need "Token based Authentication" which is basically everything Cookie-Token Based Authentication is minus "Set-Cookie". Now you need to send the JWT token via header "Authorization: Bearer [Your token]" (This format is a socially accepted. But it's not enforced by the client because you will need to do it all manually for using Token-based Authentication.) and on the client-side you would need to manually unpack it and store it somewhere (LocalStorage, SessionStorage, Cookie, Application Memory, Web Worker). And then you would need to include the said token on every requests to the apis. And use backend auth middleware implementation to intercept and verify all requests. However, there will be nuances of security issues in this method that requires more effort such as utilizing encryption and hashing algorithms. That is also take a toll on the performance on each token retrieval.

Conclusion

In conclusion, the keywords are JWT secrets (Secret can be used to verify, create more JWT child), Set-Cookie (Let your browser automate cookie management far out of JavaScript reach), Use the server and finally do not trust the client.<br>

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie https://owasp.org/www-community/HttpOnly

Coding is not Going Anywhere: Disagreeing with Jensen Huang

Boraxpr — Mon, 04 Mar 2024 00:00:00 GMT

There has been a significant push from online courses, influencers, and governments promoting the idea that everyone should learn to code. The push is fueled by the booming popularity of online courses promising to help anyone change their careers. Anyone can be a software engineer, software developer, software tester, et cetera.

The Turning Point

Recently, Jensen Huang, CEO of Nvidia, made headlines with his statement: "Don't learn to code." At the World Government Summit in Dubai, he furthered this narrative by suggesting that AI will replace coders, stating, "Everyone is now a programmer."

Firstly, I want to clarify that I'm not opposed to AI. It's helpful, save my time and potentially will remedy the labor shortages due to the aging society in next 20 years but it won't kill programmers.

LLMs : A Limitation

The current approach to AI, particularly with Large Language Models (LLMs), does not embody true "Artificial Intelligence." LLMs lack consciousness, reasoning, logic, and understanding. LLMs excel in processing vast amounts of data and mapping patterns to generate answers. However, problem-solving is not a simple copy-and-paste operation. It requires a deep understanding of the problem itself. Of course, If you insert Leetcode style problems into your LLMs, they will be able to solve because these types of problems are used over and over again. Like University Admissions Exams. There are only few original problems and they only change the wordings. And the solutions are all over the internet.

Here is the 2025 update: After ChatGPT was debunked, attempts were made to patch hallucinations. However, if users provide incorrect information, LLMs will still hallucinate 🤦

<br>Here is an image that I try to make up "King Mantisoraya" asking LLM "who is King Mantisoraya". The LLM replies suggested that Mantisoraya is a character from the anime and manga "Yu-Gi-Oh!". However, after I try to search on Google, I find nothing closely related to the name of the character in Yu-Gi-Oh anime.

LLMs look promising and feel promising because the premise is that all their outcomes are human responses. They have been designed to do so. They might replace your tinder girlfriends. They are best at knowing what you want as a response but worst for the truth-seeking and problem-solving.

LLM lacks true understanding. That’s why they will never be able to guarantee their response correctness based on their internal understanding. Basing on statistics, LLM is bound to always be sound correctful that’s why they will always be hallucinating. At its core, hallucination is LLM core. That alone would put them in a place that is unable to replace human.

A Future Perspective

In the future, there might be new ways to approach AI. It may be programmer replacing AI. But sorry LLMs, it's not today.

Balancing Complexity and Simplicity in Frontend Development

Boraxpr — Sun, 10 Mar 2024 00:00:00 GMT

In the world of frontend development, simplicity is often overlooked in favor of the latest and trendiest technologies. As developers, we're bombarded with new libraries, frameworks, and tools that promise to revolutionize our workflow and deliver unparalleled results. However, this pursuit of innovation can sometimes lead us down a path of over-engineering, where we create solutions that are far more complex than the problems they're meant to solve.

The Allure of New Technologies

It's easy to fall into the trap of over-engineering, especially when faced with the pressure to keep up with the latest trends. Influencers and experts constantly tout new libraries and frameworks as the "must-have" tools for any project, leading to a culture of constant churn and unnecessary complexity.

For example, a simple project that could be completed with a few essential libraries suddenly requires the integration of four or five additional frameworks, all in the name of staying up-to-date with the "META" stack of tooling. This trend is reminiscent of gaming channels on YouTube, where content creators focus on the latest updates and strategies.

The Problem with Over-Engineering

Over-engineering not only adds unnecessary complexity to our projects but also creates new problems in the process. By adopting multiple frameworks and libraries without a clear understanding of their purpose or how they fit into the overall solution, we risk creating bloated and unmaintainable codebases.

Moreover, this approach can be particularly harmful to beginners, who are just starting to learn the basics of programming. Instead of focusing on fundamental concepts and problem-solving skills, they're bombarded with information about the "latest and greatest" tools, which may not always be the best fit for their needs.

Embracing Simplicity and Practicality

It's essential to remember that there is no silver bullet in software development. Stacks and technologies come and go, but the fundamentals remain the same. Rather than blindly following trends, we should focus on understanding the problem at hand and choosing tools that solve that problem effectively and efficiently.

By embracing simplicity and practicality in our development practices, we can avoid the pitfalls of over-engineering and create more maintainable and scalable applications. Let's prioritize understanding the problem, choosing the right tools for the job, and building solutions that stand the test of time.

The Allure of Libraries for Simple Tasks

JavaScript developers are often tempted to use libraries for even the simplest of tasks. Whether it's adding a date picker or creating a modal dialog, there's a library out there that promises to make the job easier. While libraries can indeed save time and effort, they can also introduce unnecessary complexity into a project.

One of the main reasons developers reach for libraries is convenience. It's easier to npm install a package than to write custom code, especially for tasks that seem mundane or repetitive. However, this convenience comes at a cost. Every library added to a project increases its dependency footprint and potential for conflicts or vulnerabilities.

Moreover, the use of libraries can sometimes lead to a lack of understanding of the underlying concepts. When developers rely too heavily on libraries, they may not fully grasp the fundamentals of the task at hand. This can be particularly problematic when troubleshooting issues or trying to optimize performance.

Striking a Balance

While libraries can be incredibly useful, especially for complex tasks or when working under time constraints, it's essential to strike a balance between convenience and necessity. Before reaching for a library, developers should ask themselves if the task truly requires it, or if it can be accomplished with simpler, more lightweight solutions.

By being more selective about the libraries we use and taking the time to understand the problem we're solving, we can avoid over-engineering and create more efficient and maintainable codebases. Let's prioritize simplicity and practicality in our development practices, and choose tools that truly enhance our workflow without adding unnecessary complexity.

Scientific Coding

Boraxpr — Tue, 26 Mar 2024 00:00:00 GMT

Introduction

The how is what you needed most for getting anything done. But in order to connect the dots, you must collectively consider the why. Years of experience often be one of the most gauge when it comes to perceivable effectiveness of devs. However, It's so easy to have 1 years of experience 10 times and call it 10 years experience.

Scientific Coding

It's important to avoid using faith in programming. It always has a cost when all you understand is "it just works". The price is you never grow. Moreover, the memorization over understanding increases the probability of preaching to everyone that it needs to be done that way.

For database, 3-4 years ago it's MongoDB, "we all must use NoSQL because it scales". For frontend, it's React, "we all must use React [insert arguments here]".

In reality, it's all about the why. It's harder to understand why. You must know why before you analytically know what tools should be used to solve the problem.

Why?

Frameworks, Libraries and programming languages , depends on how deep you want to go, have been built upon layers and layers of underlying implementations. The problem is that, while it makes app building easier, it also makes it harder to understand what's going on behind the code. Let's say you started out learning React as your first tool you ever known. While React is a great way to quickly build apps and see instant results. It's important that you also understand core programming concepts. You would never understand why React (in a scientific sense) when you never try vanilla JavaScript, jQuery, other frameworks (Vue, Svelte, Angular, etc.).

Conclusion

Instead of chasing the hype, we should focus on understanding the problems, the tools and the solution. Learning is good but make sure you learn the why.

HOT TAKE: I do not use ORMs - Why it should not be used on production, ever

Boraxpr — Thu, 04 Apr 2024 00:00:00 GMT

Object-Relational Mapping (ORM) is an anti-pattern that should be avoided at all costs.

Reasons to avoid ORMs

Violation of Separation of Concerns: ORMs void the separation of concerns between the database and the application.
N+1 Query Problem: Most ORMs lead to N+1 query problems that you will notice only after it runs on production servers. N+1 query problems refer to N extra number of queries executed instead of a single optimized query.
Complexity and Learning Curve: ORMs require developers to work with unfamiliar APIs to achieve optimal SQL code generation.
Abstraction Overhead: Newer ORMs are marketed as "SQL-Like". If it's SQL-like, Why not just use SQL? Instead of having a giant pile of magic abstraction in data layers.

Reasons to use SQL instead of ORMs

Universality and Simplicity: SQL is the most common programming language used for database management systems. Every university course teaches SQL. Recruiting developers ? It's more likely that they know SQL than your specific ORM library.
Control and Performance: SQL is considered straightforward and essential, especially for complex projects where direct control over database queries is necessary.

Debunk 1 : Use ORM now !!, What would you do when we need to change the database in the future ?

Companies often avoid changing their databases due to compliance concerns, as any modifications can impact compliance requirements significantly. In large organizations, there's a strong emphasis on data tracking and logging to ensure that every action taken on the database is traceable and logged for audit purposes. The cost of changing production databases is high and is not advisable as it might leads to data loss and data corruption. The benefits just do not outweigh the cost.

Debunk 2 : Use ORM now !!, Why use the complex-hard-labourly SQL when you have the Easy-to-Use ORM ?

When it comes to ORM, while suitable for simpler projects or short-term applications, there's a risk of missing out on developing SQL and DBMS skills, which are crucial in the long run for more complex projects. In general, SQL is considered straightforward and essential, once you learn how to use it. You know it forever. Unlike some ORMs, which maintainers may abandon within the next 3 months if they do not generate enough traffic or if the maintainers are simply bored and want to create a new one. For toy projects or short-lived applications, ORM can be a suitable choice if you do not want to develop and grow as a developer.

Conclusion

For simple projects on production, I would still be against using ORMs. Initially, every project starts as a simple CRUD application. Over time, projects inevitably become more complex. For simple projects, using SQL is easier and straightforward as well. The latest ORMs promise no n+1 query problems, SQL-like APIs. But why does it matter? When you can simply learn and use SQL. It's highly valued because it has been researched, battle-tested, and proven to work since 1974 (that's over 50 years ago!). While many languages from that period have faded away, SQL is still widely used and relevant. Let that sink in. SQL is declarative and highly readable, almost like your everyday english. It's even more readable than Python. It's easy to learn and use. That's why it has been used widely for over 50 years and will be used in the future.

Object Oriented Programming as intended by the original creator, Alan Kay

Boraxpr — Sat, 20 Apr 2024 00:00:00 GMT

In object oriented programming, It's widely taught, misunderstood, misused that inheritance is "the basic building block" of OOP by the books.

It's undeniable that most courses, whether it is an online course or university course, placed a lot of emphasis on inheritance making every new programmer think that Object Oriented Programming is about inheritance.

They always give examples like there is Animal then we need to create a Dog, a Cat, etc. That's literally the first example, the first step of learning OOP everywhere.

Visiting any tutorials or textbooks, 99.99% of the time, you will find that they talk about inheritance and they would give you an example similar to this:

class Car {
  private String color;
  private String brand;
  private String model;

  public void drive() {
    System.out.println("Driving");
  }

  public void fillFuel() {
    System.out.println("Filling fuel");
  }
}

class SportsCar extends Car {
  private String engineType;
  public void startEngine() {
    System.out.println("Starting engine");
  }
}

class LuxuryCar extends Car {
  private String engineType;
  public void startEngine() {
    System.out.println("Starting engine");
  }
}

The Problem with Inheritance

The problem with inheritance is, it locks down the code forever. Says, one day there is a new type of car that do not play well with the traditional Car. Like an EV car that requires a whole new way to fill fuel. EV cars need to be charged instead of using Gasoline. That's when inheritance fails. Because it voids the Open/Closed Principle.

a class should be open for extension but closed for modification. The deeper into the class hierarchy, the more difficult it is to add new features. the more difficult it is to change existing features. the more chances it is to introduce new bugs.

Voiding the Open/Closed Principle, it's the best way to create a spaghetti code destroying multiple of normally working classes at once. Now, the base class will be the single point of failure, god object.

The Composition Approach

Inheritance is "is a" and composition is "has a". Instead of fixate on how something is, we create room for composition. Now we design classes based on what they has.


class Car {
  private String color;
  private String brand;
  private String model;
}

interface Driveable{
  default void drive() {
    System.out.println("Driving");
  }
}

interface Fuelable{
  void fillFuel();
  default void startEngine() {
    System.out.println("Starting fuel engine");
  }
}

interface Chargeable{
  void charge();
  default void startEngine() {
    System.out.println("Starting electric engine");
  }
}

class sportsCar extends Car implements Driveable, Fuelable {
}

class EVCar extends Car implements Driveable, Chargeable {
}

Utilizing strategy pattern, we can create classes based on what they has. This design has the advantage of being modular and reusable. However, as you can see, it still uses inheritance. For maximize the flexibility, never tie any cars to the Car class.

class Car {
  private String color;
  private String brand;
  private String model;
}

interface Driveable{
  default void drive(Car car) {
    System.out.println("Driving");
  }
}

interface Fuelable{
  void fillFuel(Car car);
  default void startEngine(Car car) {
    System.out.println("Starting fuel engine");
  }
}

interface Chargeable{
  void charge(Car car);
  default void startEngine(Car car) {
    System.out.println("Starting electric engine");
  }
}

class sportsCar implements Driveable, Fuelable {
}

class EVCar implements Driveable, Chargeable {
}

class HybridCar implements Driveable, Fuelable, Chargeable {
  public void startEngine(Car car) {
    System.out.println("Starting hybrid engine");
  }
}

Another thing that we can do is, we can use generic type to allow interfaces to be more flexible.


class Car {
  private String color;
  private String brand;
  private String model;
}

class Bike {
  private String color;
  private String brand;
  private String model;
}

interface Driveable<T> {
  default void drive(T self) {
    System.out.println("Driving");
  }
}

interface Fuelable<T> {
  void fillFuel(T self);
  default void startEngine(T self) {
    System.out.println("Starting fuel engine");
  }
}

interface Chargeable<T> {
  void charge(T self);
  default void startEngine(T self) {
    System.out.println("Starting electric engine");
  }
}

class sportsCar implements Driveable<Car>, Fuelable<Car> {
}

class roadBike implements Driveable<Bike>, Fuelable<Bike> {
}

Instead of fixing these interfaces to allow just Car, we can use generic type. This opens up new possibilities of implementing by other types. For example, Bike that can also implement Driveable (Not a Car).

Benefits of Composition

Now, any new class can be flexibly created based on what they have without any lockdown that you are going to inherit from a specific class (Never need to modify deep in the class hierarchy ever again).

Composition makes Loose Coupling possible while adhere to Open/Closed Principle.

Inheritance has its place

Inheritance can be used to avoid attribute duplication.

class Machinery {
  private String weight;
  private boolean isWorking; 
  private boolean isAutomata;
}

class Car extends Machinery {
  private String color;
  private String brand;
  private String model;
}

Inheritance should not be used for behavior in object-oriented programming. Doing so leads to tight coupling, a rigid class hierarchy, and spaghetti-unmaintainable code. Many developers mistakenly use inheritance for behavior, considering it as true object-oriented programming. However, in true object-oriented programming, inheritance is used to model relationships between objects. Objects interact with each other through messages and method calls, emphasizing meaningful relationships and interactions over organizing code around data structures and operations.

Let's write the maintainable, reusable, testable code by using OOP as intended by the original creator.

Stop Forcing React to Re-render: Here’s a Better Way

Boraxpr — Thu, 20 Jun 2024 00:00:00 GMT

React, the most popular JavaScript framework for building user interfaces, leverages state management to efficiently update and re-render components. In the early days of web development, developers relied on vanilla JavaScript or libraries like jQuery to perform partial page updates using AJAX. React simplifies this by automatically re-rendering components when the state changes.

Re-rendering with setState

React detects changes and triggers re-renders when the state is updated using the setState method (or the useState hook in functional components). Here’s a simple example:

const [example, setExample] = useState({ Apple: 1, Banana: 8, Orange: 4 })

// Re-render is triggered on set state
setExample({ Apple: 7, Banana: 8, Orange: 4 })

The Problem with Direct State Mutation

A common anti-pattern in React is directly mutating the state and then setting it back. This approach does not trigger a re-render because React uses shallow comparison to detect state changes. If the reference to the state object does not change, React assumes the state has not changed. 🚫

// Get the default value
let tmpExample = example
// Mutate the state
tmpExample[Apple] = 7
// Set it right back
setExample(tmpExample)

What happen is the screen will not be rerendered because the object id has not changed.

Force Re-rendering as an Anti-pattern

To force a re-render, some developers introduce a boolean state variable. This approach can work but is considered an anti-pattern because it complicates the code and can lead to unexpected behaviors. 🚫

const [rerender, setRerender] = useState(false)

// Get the default value
let tmpExample = example
// Mutate the state
tmpExample[Apple] = 7
// Set it right back
setExample(tmpExample)

// Trigger the rerender
setRerender(!rerender)

While this method triggers a re-render, it is not recommended. It adds unnecessary complexity and can be confusing to others maintaining the code.

The Proper Way: Shallow Copy

A better solution is to create a shallow copy of the state object and update the copy. This ensures that the reference changes, triggering React’s re-render mechanism.

const [example, setExample] = useState({ Apple: 1, Banana: 8, Orange: 4 })

// Re-render is triggered on set state
setExample({ Apple: 7, ...example })

In this example, the spread operator (...example) creates a shallow copy of the example object. The Apple property is updated, and the new object is passed to setExample, ensuring that React detects the change and re-renders the component.

Conclusion

Using the spread operator to create a shallow copy of the state object is a best practice in React. It avoids the pitfalls of direct state mutation and force re-rendering, leading to more predictable and maintainable code. Remember, immutability is key to effectively managing state in React applications.

RESTful and why it matters

Boraxpr — Thu, 20 Jun 2024 00:00:00 GMT

In modern web development, creating clear and manageable paths for your APIs and frontend routes is crucial. Take a look at these examples:

/api/create-a-new-post-in-the-database
/myPage/Product/Product-List/Product-Details/Edit-Product&id=1

These paths are undeniably more complex than they need to be. They are not only difficult to read but also harder to maintain. Imagine the app growing in complexity, and you have to keep track of all these paths. This is where RESTful design comes into play, promoting simplicity and modularity.

Why RESTful Design ?

RESTful design is an architectural style that uses HTTP requests to access and manipulate data. It is based on a set of principles that ensure your API is easy to understand, scalable, and maintainable. Here’s why it matters:

Modularity and Reusability: RESTful APIs are built around resources and use standard HTTP methods (GET, POST, PUT, DELETE) to perform operations on these resources. This modular approach allows you to reuse and extend your API easily.
Scalability: Since RESTful APIs are stateless, each request from a client to a server must contain all the information the server needs to fulfill that request. This makes it easier to scale your application horizontally, as any server can handle any request independently.
Consistency and Predictability: Using a consistent structure for your endpoints makes your API predictable. Developers can easily understand how to interact with your API without extensive documentation.
Better Performance: RESTful APIs can take advantage of HTTP caching mechanisms, which can reduce the load on the server and improve response times for clients.

Examples of RESTful Paths

Non-RESTful Path

/api/create-a-new-post-in-the-database

RESTful Path

POST /api/posts

Here, /api/posts is the resource, and POST is the HTTP method used to create a new post.

Non-RESTful Path

/myPage/Product/Product-List/Product-Details/Edit-Product&id=1

RESTful Path

GET /api/products/1
PUT /api/products/1

In this example, /api/products is the resource. GET is used to fetch product details, and PUT is used to edit product details for the product with ID 1.

Conclusion

Adopting RESTful principles in your API design ensures that your paths are simple, modular, and maintainable. It enhances the scalability, consistency, and performance of your application, making it easier for developers to understand and use your API. By following RESTful design, you can create an API that is robust, flexible, and future-proof.

So, when designing your next API, remember to keep it RESTful and embrace the benefits of simplicity and modularity.

When DRY Becomes Too Dry: Avoiding Over-Complexification

Boraxpr — Fri, 12 Jul 2024 00:00:00 GMT

The idea of DRY is to avoid repetition. If multiple places use the same code, why should we write it multiple times? Instead, we should write it once and reuse it. This is a good practice and helps in maintaining the codebase. But sometimes, developers take this too far and end up over-complicating the codebase. This is when DRY becomes too dry.

When DRY Becomes Too Dry

1. Abstraction Overload

One of the common pitfalls of overusing DRY is abstraction overload. Developers tend to create unnecessary abstractions to avoid repetition. While abstractions are good, too many of them can make the code hard to understand and maintain. It's essential to strike a balance between DRY and readability.

2. Premature Optimization

Another issue with overusing DRY is premature optimization. Developers try to optimize the code too early, even when it's not needed. This can lead to complex code that is hard to debug and maintain. It's better to keep the code simple and optimize only when necessary.

3. Tight Coupling

Overusing DRY can also lead to tight coupling between different parts of the codebase. When code is too abstracted and reused in multiple places, changing one part can have unintended consequences in other parts. It's essential to keep the code modular and loosely coupled.

4. Maintenance Nightmare

When DRY becomes too dry, it can turn into a maintenance nightmare. Developers spend more time understanding the code than actually fixing bugs or adding features. It's crucial to keep the codebase simple and easy to understand. Sometimes, a little repetition is better than over-complicating things. It's better to have a clear codebase than a DRY one. Let's say there is a new requirement, and you need to change the code. If the code is too abstracted and over-complicated, it can be challenging to make the necessary changes. On the other hand, if the code is simple and straightforward, making changes becomes easier.

Conclusion

DRY is a good principle, but it's essential to use it wisely. Don't over-complicate things in the name of DRY. Sometimes, a little repetition is better than creating a complex codebase. Keep the code simple, modular, and easy to understand. Strike a balance between DRY and readability. Remember, when DRY becomes too dry, it's time to reevaluate your approach.

Being Lazy is the First Step Toward Creating a Maintainable Solution

Boraxpr — Wed, 30 Oct 2024 00:00:00 GMT

Many developers fall into the trap of over-engineering solutions early on, thinking that complexity or a comprehensive feature set equates to a robust system. But in reality, simplicity is king.

When approaching a problem, the first step toward maintainability is being "lazy" This doesn't mean avoiding work—it's about being strategic with your effort. By minimizing unnecessary code, dependencies, and convoluted architecture, you can focus on what's important. Leverage default behaviors, use out-of-the-box solutions where possible, and avoid reinventing the wheel unless you have no other choice.

More code always comes at a cost. More dependencies always come at a cost. This cost is often hidden, and only a few truly notice it at first. A bloated codebase makes every future feature slower to develop, and maintenance becomes a burden. It’s easy to get caught up in adding feature after feature, but with each addition, you risk entangling the system in complexity that will slow down progress in the long run.

More custom, non-default settings mean more things to fix when dependencies upgrade or deprecate. Each customization adds layers of complexity, and when third-party libraries or tools evolve, maintaining these customizations can become a nightmare.

The beauty of a maintainable solution is that it's straightforward, predictable, and easy for others to pick up. If your codebase requires endless explanations or a detailed manual just to onboard someone new, it’s probably too complicated.

Remember: good code is not about showing off complexity; it's about clarity, efficiency, and ease of maintenance. Keep it lazy, keep it simple, and future you (and your colleagues) will thank you for it!

Dev contents in 2024 make no sense

Boraxpr — Thu, 07 Nov 2024 00:00:00 GMT

While I appreciate the content that has helped me grow in the past, I’ve noticed a worrying trend in 2024 that seems to undermine its value. I've always been a big fan of getting new knowledge by watching YouTube, TikTok, and Facebook posts about software development. However, there’s an ongoing trend that I'm not so happy to see: more and more software development content is using fear-mongering tactics to trick us into clicking, preying on our FOMO (Fear of Missing Out).

Many YouTube channels aimed at beginner software developers seem more focused on the profits than on providing real value. I’m not saying this out of bias—these were once my go-to sources for learning. But as time has passed, I feel like the quality has hit rock bottom.

A common pattern in video titles includes phrases like "Don't use Try Catch" or "What you're doing is totally wrong." When you click to watch, the content often reiterates things you already know, followed by a dramatic claim that you're doing something wrong. Then, the video quickly pivots to promoting sponsored products, online courses, or services they're trying to sell.

The knowledge gained from these videos has steadily decreased, to the point where I consider them mostly clickbait. Maybe these videos are aimed at beginners, and I’m past that stage now.

What I think is happening is that some creators focus more on exploiting insecurities than providing valuable insight. They capture our attention, then steer us toward their products, courses, and services that promise to fix our "flaws." This is marketing 101. The substance doesn't match the hype, leaving people feeling less confident and like they're falling short—even though the original concern may not have been that significant. These creators make you feel lesser, implying that you always need their opinions, just to get you to stick around and watch their promotional content, all while gaining a constant flow of revenue.

It’s exhausting to go into a video expecting improvement, only to leave feeling manipulated or sold to. This type of content capitalizes on emotions, making people feel like they need to constantly consume to improve, which can be overwhelming and counterproductive. I hope creators start focusing on delivering real, practical value rather than sensationalizing issues to sell products. In the end, we should strive to build each other up, not profit from each other's insecurities.

React's Evolution: From Higher-Order Components to the Flexibility of Hooks

Boraxpr — Sun, 17 Nov 2024 00:00:00 GMT

In the early days of React, Higher-Order Components (HoCs) were the go-to pattern for reusing logic across components. They offered a way to "wrap" additional behavior into a component, striving to follow the DRY (Don't Repeat Yourself) principle. But as React evolved, so did its patterns—and now, with Hooks, HoCs have become largely outdated.

Example: HoC vs. Hook

Here’s a practical comparison to illustrate the difference.

HoC Approach

function withLogger(WrappedComponent) {
  return function LoggerComponent(props) {
    console.log("Rendered with props:", props);
    return <WrappedComponent {...props} />;
  };
}

const EnhancedComponent = withLogger(MyComponent);

This works but tightly couples the logging logic to the wrapper. Removing or modifying it means touching every instance of withLogger.

Hook Approach

function useLogger(props) {
  useEffect(() => {
    console.log("Rendered with props:", props);
  }, [props]);
}

function MyComponent(props) {
  useLogger(props);
  return <div>{props.text}</div>;
}

With Hooks, the logging logic is decoupled. You can add or remove useLogger in specific components without affecting the others.

Here’s a closer look at why HoCs feel rigid and cumbersome compared to the flexible and composable nature of Hooks.

The Problem with HoCs: "Wrap Everything Forever"

HoCs operate on a simple idea: take a component, wrap it in another component that provides extra functionality, and pass everything down through props. On paper, this sounds great! However, in practice, HoCs have significant downsides:

Rigid and Hard to Manage

Carved in the stone : Once you wrap a component with an HoC, it’s difficult to untangle that behavior or change it. It’s like OOP inheritance—you're locked into the parent-child relationship.
Wrapper Hell : If you have multiple HoCs wrapping the same component, debugging turns into a nightmare, as you deal with "wrapper hell."

Overengineering in the Name of DRY

God Component Trap : HoCs aim to avoid repeating code by centralizing logic, but this can lead to over-abstraction. Logic hidden inside a wrapper might make sense initially, but over time, it becomes harder to trace bugs or customize behavior.
Prone to violate the Open/Close principle : Adding or removing features requires modifying the HoC itself, potentially impacting every component it wraps. It's easy to end up with fragile, tightly coupled code.

Enter Hooks: Reusable Lego Bricks

React Hooks (introduced in version 16.8) revolutionized how we share logic in React apps. Instead of wrapping components, Hooks offer utilities—small, focused, and composable pieces of logic you can use anywhere.

Why Hooks Work Better

Flexibility Over Rigid Abstraction

Hooks don’t force you into a specific structure. They’re just functions. You can freely add, remove, or combine Hooks without altering the component hierarchy.
Need to reuse logic? Create a custom Hook that can be applied wherever needed—no wrappers required.

Readable and Debuggable

With Hooks, the logic is front and center, directly inside the component. This makes it easier to understand what’s happening, less context-switching, and simpler debugging.

More Code, More Freedom

Hooks may lead to some repetition (e.g., multiple components importing the same custom Hook), but this repetition gives you the freedom to customize logic on a case-by-case basis.
It’s a pragmatic trade-off: a bit more typing in exchange for long-term maintainability.

DRY vs. Maintainability

HoCs are a classic case of taking the DRY principle too far. By striving for zero duplication, they end up coupling logic tightly to the wrapper, creating inflexible, monolithic abstractions.

Hooks, on the other hand, embrace composition over inheritance, focusing on building reusable utilities that are easy to add, modify, or remove. While this approach might feel less DRY at first glance, it ensures:

Ease of Debugging: Logic is visible and accessible.
Maintainability: Small, focused pieces of logic are easier to refactor.
Flexibility: Components can evolve without being shackled to a wrapper.

Comparing HoCs and Hooks

Aspect	Higher-Order Components (HoCs)	Hooks
Structure	Forces a wrapping hierarchy	Flat, reusable functions
Debugging	Hard due to wrapper layers	Easier with inline logic
Flexibility	Coupled tightly to wrappers	Decoupled and composable
Readability	Abstracted away in HoCs	Directly visible in components
Maintainability	Harder due to global HoC impact	Localized and focused utilities

The Verdict

HoCs are the result of wanting to be DRY but applying it too rigidly. They over-centralize logic at the expense of flexibility and readability. Hooks, on the other hand, trade a bit of repetition for composability and long-term maintainability.

If you’re starting a new React project or modernizing an old one, Hooks are the way forward. They’re not just a replacement for HoCs—they’re a more intuitive, flexible, and powerful paradigm for sharing logic in React.

So, let’s leave "wrap everything forever" behind and embrace the future with reusable Lego bricks that make our code easier to build and maintain.

E2E Typesafety, tRPC, and T3 Stack: Overhyped Hype or Developer Trap?

Boraxpr — Sun, 24 Nov 2024 00:00:00 GMT

The buzz around "Type-safe end-to-end" is impossible to ignore. With frameworks like the T3 Stack and tRPC, developers are promised seamless integration and foolproof data consistency. But here’s the harsh truth: the reality is far less glamorous. These tools may have their place, but they often fail to deliver on their promises—and sometimes, they make things worse.

Let’s cut through the noise and expose why “E2E typesafety” is more of a mirage—and what you should be focusing on instead to build real, reliable systems.

1. TypeScript: More Hype Than Help for E2E Typesafety

Let’s set the record straight: TypeScript doesn’t deliver “E2E typesafety”—it’s a compile-time tool, and it has limits.

Compile-Time Only: TypeScript guarantees nothing at runtime. Once your app is up and running, it’s on you to handle unvalidated data. Forget about trusting TypeScript alone—it’s not a magic bullet.
JavaScript’s Chaos: TypeScript can’t fix JavaScript’s mess. Dynamic data (like raw JSON) can break your app in ways TypeScript can’t prevent, leaving you with crashes when you least expect them.
False Confidence: Just because TypeScript doesn't throw an error at compile time doesn’t mean you’re safe. In production, a minor type mismatch could lead to catastrophic issues you never saw coming.

Wake Up: TypeScript is great for catching bugs during development, but relying on it for runtime safety is reckless. Without runtime validation, your system is a ticking time bomb.

2. The Database: Your True Data Guardian

Stop chasing the illusion of “E2E typesafety.” The real authority over data integrity is your database schema.

Schemas Do the Heavy Lifting: Your database schema doesn’t ask for permission—it enforces rules at runtime. Constraints, data types, relationships: these are the things that ensure your data stays consistent. TypeScript types? Not even in the same league.
Avoid the ORM Trap: Tools like Prisma are tempting, but they often add layers of complexity you don’t need. A properly structured schema in PostgreSQL or MySQL is the real workhorse behind your app’s integrity.

Bottom Line: TypeScript may help during development, but the real guarantee of data integrity is your database schema. Without it, you’re gambling with your app’s reliability.

3. Validators: The Non-Negotiable Safety Net

If you're skipping runtime validation, you're leaving your app wide open to failure.

Don’t Skip Validation: Libraries like Zod, Joi, or NestJS’s built-in validation tools aren’t optional—they’re required. These libraries ensure the data entering your system is clean, safe, and trustworthy.
Guard Against the Wild West: TypeScript can't protect you from untrusted user input or malicious data. You need a robust runtime validation layer to keep your app stable in the real world.

Pro Tip: Stop pretending TypeScript will handle everything. Add runtime validation to catch errors where they matter most—at runtime.

4. tRPC and T3 Stack: Powerful but Not for the Long Haul

The T3 Stack and tRPC are sold as the answer to your development woes, but here’s why you should be cautious:

Tightly Coupled Systems: tRPC thrives in a one-stack world like Next.js. But try integrating with other tools or scaling beyond that, and you’ll quickly realize you’ve painted yourself into a corner.
Vercel Lock-In: The T3 Stack’s seamless integration with Vercel is fantastic—until it’s not. When you need to scale or move to other platforms like AWS, Azure or GCP, you’re left with an ecosystem that’s difficult to escape. Good luck with that.
API Flexibility? Forget It: Need OpenAPI or GraphQL support? You won’t get it here. tRPC is built for one thing, and it’s not the kind of flexibility that large-scale systems demand.

Takeaway: tRPC and the T3 Stack are great for small projects and rapid prototyping, but they’re a poor fit for scaling. They’re not the long-term solution you’re looking for.

5. Serverless: Not the Silver Bullet

Serverless is all the rage in the T3 Stack, but it’s far from a universal solution. Here’s why it often fails:

Cold Start Hell: Serverless architectures come with cold start latency issues that will slow you down, especially for high-traffic apps or real-time features. If performance matters to you, serverless is a liability.
Scaling Nightmares: Moving away from serverless is a nightmare. If you ever need to migrate to traditional servers or containers, expect a costly and time-consuming refactor. Not exactly a smooth transition.

Be Realistic: Serverless is great for quick, small apps—but for any serious, high-performance project, it’s a poor choice.

A Smarter Approach to Typesafety and Scalability

Stop chasing the “E2E typesafety” dream. Focus on building systems that are robust, flexible, and scalable. Here’s the real formula for success:

Validate at Runtime: TypeScript won’t save you. Use Zod, Joi, or NestJS validation tools to guarantee correctness at runtime.
Trust Your Database Schema: The database schema is the final authority on data integrity. Design it well, and trust it.
Decouple Your Architectures: Don’t lock yourself into a specific frontend or backend stack. Build flexible, decoupled systems that scale as needed.
Take Control of Deployment: Use Docker, Kubernetes, or traditional servers to avoid vendor lock-in and maintain control over your infrastructure.

Final Thoughts: Don’t Be Sucked In by the Hype

The hype around “E2E typesafety” is real, but it’s a trap. While tools like tRPC and the T3 Stack might offer some conveniences, they come with major limitations that could bite you later. Don’t get blinded by the shiny promises—focus on what actually works.

By combining TypeScript for development-time safety, runtime validation for production reliability, and a robust database schema for data integrity, you’ll build systems that are truly scalable and reliable—without falling into the trap of overhyped, one-size-fits-all solutions.

AI Replacing Humans: The Reality of Agentic AI

Boraxpr — Sat, 22 Feb 2025 00:00:00 GMT

Today, I'm going to talk about the recent topic that has been talked about a lot in the job world. Agentic AI. What is it? And why I don't think it's going to replace human anytime soon. Many have discussed this topic, but I’ll offer a real-world, practical take.

The Pricing

Current AI pricing models are token-based. For example, in OpenAI’s model, four characters equal one token. The more complex your prompt, the more it costs, with no guarantee that the AI will complete the task correctly. This means wasted money when the output isn’t useful.

The Productivity

AI agents aren’t as fast as you might think. You can’t just assign a task and expect it to be completed instantly. Processing is slow, and results are often inaccurate. Reports show that when agentic AI was asked to fix a minor text error, it took hours and still failed. In another case, a self-funded startup relied on agentic AI, but due to the founder’s lack of technical expertise, the project ended up with over 30 barely functional Python files.

The Real-World Agentic AI Everyone Talks About - Without the Hype

One of the most well-known agentic AI software engineers, Devin, has a buy-in cost of approximately 15,000 Thai Baht and comes with limited token usage. After the initial free tokens are used, additional tokens must be purchased. Despite being one of the most advanced agentic software engineers currently available, Devin is shockingly slow, turning a simple 3-5 minute task into an hour-long process. A simple configuration change can generate multiple unrelated files. While AI is bound to improve, at this rate, it won’t be replacing humans anytime soon.

An hour clip of Devin in action by ex-Netflix software engineer ThePrimeAgen <iframe width="560" height="315" src="https://www.youtube.com/embed/927W6zzvV-c?si=Rxe8wQUOjKbuGzwT" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

The bottom line

In today’s global economy, where remote work is widely available, hiring a human expert is often more cost-effective than using agentic AI—especially in regions with lower living costs. Humans offer more than just task completion; they provide insights, feedback, accountability, and adaptability. AI lacks these qualities, making it a less reliable alternative.

Conclusion

While agentic AI is evolving, it remains costly, slow, and unreliable compared to human expertise. For now, hiring skilled professionals remains the smarter choice, especially for tasks demanding creativity, accountability, and critical thinking.

Once You See the Patterns, Every Framework Speaks the Same Language

Boraxpr — Sat, 10 May 2025 00:00:00 GMT

TL;DR: I don’t chase frameworks — I trace patterns. I work best when I understand the full system. Once you see the design beneath the syntax, every framework starts to feel familiar. It’s not about how many years you’ve used X — it’s about how quickly you can see how X thinks.

Recently, someone asked me questions like:
"How many years have you used framework X, Y, Z?"
"How long have you been working with language A, and are you comfortable with it?"

It got me thinking — not just about my past experience, but about what actually lets me cut through tools, languages, and stacks with understanding and intent.

The Shift That Started It All

The story begins in 2018. Windows 10 — in its notorious version 1809 update — nuked my personal files. Gone. Coursework, notes, everything. The moment that happened, I made a decision: never again. I wasn’t going to trust an OS that careless with my work. I Googled alternatives. macOS? No thanks. And that’s how I ended up with Linux — by force, not fandom.

Linux didn’t solve everything. But it made things fun. It pulled me into the real world of programming. I got into PyBites code challenges and caught fire — earning two certificates that lit a spark in me I didn’t even know was there. That passion made me curious — not just about Python, but everything around it.

Everything about the developer experience felt better on Linux — once you got past its quirks. Installing tools was dead simple. On Windows, you’re Googling installers, manually adding things to PATH, clicking through wizards. On Linux? It’s a single command: sudo apt install [tool]. Most setups just work, and if they don’t, the logs usually tell you why.

At first, I was stuck in the language war. I thought everything should be written in Python. But once I worked in production with Java, I immediately saw the difference: if we used Python in that environment, the system would’ve caught fire — literally — from runtime errors. That experience taught me the hard way: dynamic typing is harder to write safely than it looks. In fact, strict languages like Java or Go can be easier to build stable systems with, because they fail early — not in production.

Once that realization clicked, I couldn’t stop. At my second workplace, I found myself in a low-code environment where I had to manually wrangle outdated CSS to meet design requirements. I remember thinking: "There has to be a better way than forcing visual changes through this brittle setup." That frustration pushed me toward frontend development — HTML, JS, React, Next, Vue, Nuxt, Svelte. Then I explored Rust. Then Go. Every new stack made me see the same thing more clearly:

They’re all connected.

How I Learn: Systems First, Tools Second

I’ve learned that I can’t truly work on something unless I see the top-down view — the full map. That’s just how I operate. I need to see the universe — how all tools and languages fit together — before I choose the set I’ll use. And once I understand how a system designer thinks, I don’t fight the tool. I follow its grain. I use it the way it was meant to be used — not against its nature.

Some non-tech folks think jumping between frameworks makes you shallow.
And sure — it can, if you're just chasing hype without asking why.
But when you jump because you’re tracing patterns, because you want to understand the shape of things — that’s not shallow. That’s systems thinking.
Suddenly, everything connects. Everything gets sharper.

Frontend frameworks all follow a common architecture. So do backend frameworks.
Each has its trade-offs, its strengths, its limitations.
Some frameworks give you freedom and power — but you pay for it with complexity.
Others are opinionated — and get out of your way, fast.
Community conventions shape the experience more than the syntax does.

Mapping Mental Models Across Stacks

So when I see NestJS, I don’t just see TypeScript sugar — I see Angular’s influence, inversion of control, and dependency injection. In fact, it’s basically Spring Boot with a better developer experience.
When I see Java, I don’t complain about verbosity — I understand why it exists, because I’ve seen what too much freedom in Python can cost.
When I see Go, I don’t see safety like Rust — I see modern ergonomics. Pointers without the pain. Static typing without the ceremony. Simplicity by design, yet packed with just the features you need. It enforces OOP the right way — through composition with structs — unlike Java, where too much flexibility often leads to bloated, misused inheritance trees.
When I see Azure DevOps, I see a managed, easier version of the bare-metal Jenkins and GitLab CI/CD pipelines I once built.
When I see Vue, I see React’s component model — just rendered through templates instead of JSX.
When I see Tailwind, I see modular, utility-first CSS done right — unlike the tangled, manual CSS hierarchies I once had to wrangle in a low-code platform.
When I see Spring Boot, I see echoes of .NET Core — same enterprise scaffolding, different dialect.

Not because I’ve used all of them for years — but because I’ve studied their shape, their model, and their intention.

Because once you’ve seen enough patterns, you realize most frameworks are the same game — just with different dice.

Design Is the Real Fluency

This isn’t about mastering syntax. It’s about recognizing that every serious framework is just a system of assumptions, opinions, and constraints.
And once you see the scaffolding, you can operate in any ecosystem.

You stop asking “How many years have you used this?” and start asking “How does this thing think?”

That’s what lets developers jump stacks with confidence — the ability to see the structure behind the syntax.

I don’t measure fluency by surface familiarity.
I measure it by how fast I can find the edges of a system, where the pain points lie, and — most importantly — knowing what to look for in the documentation to move forward.

Because at a certain point — if you’ve really paid attention — every framework speaks the same language.
And it’s not JavaScript or Python.
It’s design.

I don’t aim to be a god of one specific technology — because stacks come and go.
What stays is the ability to see how systems work at their core. That’s the real future-proofing.
Once you understand the fundamentals, the stack becomes the icing — not the cake.
The real focus should be on design, intention, and what you’re building.

The Cost of a "User-Driven" System with No Filters

Boraxpr — Sat, 17 May 2025 00:00:00 GMT

Database without Primary Key, Foreign Key, Constraint
→ Spreadsheet + GUID cosplay

Project Owner without System Ownership, Product Vision/Direction, Accountability
→ A feature wishlist printer who doesn’t know how the app works

Business Engineer without Decision Confidence, Technical Understanding, Flow Awareness, Prioritization
→ A fear-driven feedback generator

Dev
→ Left customizing code and architecture based on reactive emotional fear

"Here, we do whatever the user wants."
That was the moment I realized: this isn’t product development — this is chaos management.

Here’s what that really means:

No product ownership
No logic gate between wishful thinking and production
No pushback, no filtering, no prioritization
Just BA/BE acting as human forward bots, dumping raw input on devs

What happens next:

The system bends to every fear, every whim, every “what if”
Business logic turns into duct tape
Flow becomes an emotional rollercoaster
And engineers?
→ We become the sanity firewall — rewriting backend code to accommodate feelings, not facts

Reality check:

User-driven ≠ user-ruled.
Building software is not the same as saying yes to everything.
If no one protects the system, it will rot — no matter how many devs you hire.

Posted from the last stage of a glamorous AI project built on a low-code database with no primary key.

What Is Database Pooling — and Why So Many People Get It Wrong

Boraxpr — Fri, 06 Jun 2025 00:00:00 GMT

This issue is rampant in Node.js, Go, and Python — basically anywhere you're not using a meta-framework like Java Spring Boot or Python Django.

In contractor-heavy environments with no real code reviews, things like this slip through. And they quietly burn your system with way more resource usage than necessary.

Take this common anti-pattern:

const sql = require('mssql');

var pool = await sql.connect(config);
var query = "SELECT * FROM TABLE";
var result = await pool.request().query(query);

I’ve seen this copy-pasted into dozens of methods. One connect() call per API. What’s wrong with it?

❌ Why This Is a Problem

Every time you call an endpoint, the app reconnects to the database:

Network call → Authenticate → Allocate new connection → Run query → Return result

Now imagine:

Every API call does this
Dozens or hundreds of users hit the system
You’re running in a limited connection pool

Your database gets hammered not by queries, but by connection spam.

When the pool overflows, the DB has to:

Figure out which connections are idle
Kill those
Start new ones
Authenticate again
Maybe finally run your query

This is silent tech debt. And it scales like a time bomb.

✅ How It’s Done Right

Frameworks like Spring Boot have HikariCP under the hood — a high-performance connection pool you don’t even think about. You just inject DataSource and go.

In Node.js and other minimal stacks? You have to manage it yourself.
At minimum:

// db.js
const sql = require('mssql');
const poolPromise = sql.connect(config);
module.exports = poolPromise;

Then in your services:

// userService.js
const pool = await require('./db');
const result = await pool.request().query("SELECT * FROM Users");

One connection pool. Reused. As it should be.

🧨 TL;DR

Don’t sql.connect() on every API call.
Connect once on app startup.
Reuse that pool. Always.

Otherwise, you're not building a backend — you're building a denial-of-service engine.

[Off-topic] Why I Think Hot Countries Are Generally Less Developed Than Colder Countries

Boraxpr — Sun, 08 Jun 2025 00:00:00 GMT

People often talk about colonialism, politics, or geography when explaining why hotter countries tend to be less developed. But there's a deeper, physics-based reason that often gets overlooked:

Thermodynamics silently shapes civilization.

In an isolated system, entropy tends to increase.
Heat is energy. Entropy is how spread out and disordered that energy becomes.

Hot air = air molecules moving fast
Cold air = air molecules moving slowly

When we add energy to a system, molecules move more freely.
So heating cold air aligns with entropy. It’s the direction nature already wants to go.

Making air colder = fighting entropy

Making air hotter = going with entropy

In layman’s terms:
The natural tendency of a room is to let air molecules move faster (get warmer).
Slowing those molecules down (cooling the room) goes against that tendency and takes continuous effort.

🔧 The Implication

Cooling a room in a tropical country requires:

Active systems : air conditioning, fans, chilled water, insulation
Continuous energy input : to maintain a low-entropy (cool) state
Constant upkeep : heat and humidity wear everything down

Heating a room in a cold climate can be done passively:

Insulation
Body heat
Sunlight
A single bonfire

Once heat is added, it stays. Keeping warm is relatively easy.
But cooling down? That needs machines, electricity, and maintenance or you suffer.

A poor person in Canada can survive winter with blankets and soup.
A poor person in a 40°C slum might die from heatstroke.

🏛️ The Civilization Factor

Humans learned to fight cold the moment we discovered fire.
But we didn’t learn how to fight heat until the 20th century with the invention of modern air conditioning.

In cold climates:
A cup of tea, a wool blanket, a sealed cabin and you're fine.
You decide how hot you want it. Just light the fire.

In hot climates:
Even the rivers are warm. There’s no relief.
It’s thermodynamic hell, and only recently have we had the tools to resist it.

🧠 The Takeaway

This isn't just about comfort. It's about survival, labor efficiency, and civilizational momentum.

Hotter regions:

Require more energy just to function
Suffer faster infrastructure decay
Force people to spend effort just staying alive, not advancing

Heat works against you. Cold simply waits.

Hot countries aren’t behind due to culture or laziness.
They’re behind because the physics of heat and entropy made progress harder from the very beginning.

Code is Not Meant to Be Clever

Boraxpr — Sun, 08 Jun 2025 00:00:00 GMT

Lately, I’ve been reflecting on a growing pattern across the frontend ecosystem:
A push for complexity disguised as innovation.
A tendency to worship cleverness over clarity.

And it worries me.

Clarity Over Cleverness

In serious environments — where software is expected to last, scale, and evolve — clever code ages poorly.

It might feel impressive in the moment, but months later that same cleverness becomes friction:

When requirements change
When teams grow
When someone else has to debug at 2AM

The best code is boring.
It’s predictable. Readable. Maintainable.

“Clever code is for the author. Clear code is for the team.”

TypeScript is Not a Contract

TypeScript helps. But it lies.

It tells you a value is a string — until the API returns null.
It says a field exists — until the database changes and nobody updates the types.

TypeScript is a developer aid, not a runtime guarantee.

Some devs push its type system to extremes.
They build complex type gymnastics that impress nobody outside their GitHub.

But in real systems, correctness doesn’t come from types.

It comes from:

Validating inputs at runtime
Enforcing rules where they actually matter — like in the database
Building flows that are predictable, not fragile

You don’t need wizard types.
You need solid boundaries.

Type safety is a tool. Discipline is the contract.

Abstractions Don’t Make You a Framework Author

There’s a growing culture of building wrappers, bundlers, micro-frameworks — and pitching them as “production-ready.”

But engineering isn’t about abstraction density.

It’s about:

Long-term maintainability
Upgrade paths
Operational trade-offs
Knowing when not to build something

Scaffolding a repo is easy.
Maintaining it across five years of change? That’s the real test.

Code That Lasts

Real software survives:

Major version upgrades
Team turnover
Changing requirements
Regulatory compliance

That kind of resilience doesn’t come from clever syntax or type wizardry.
It comes from boring, solid, predictable engineering.

Final Thought

Engineering is in the thinking — not the typing speed.
Code is communication. Not a performance.

If your goal is to impress future maintainers — not followers —
Write code like it’ll live longer than you expect.

Because it probably will.

[Linux] Fedora 2025: GNOME's Decline, KDE’s Burden, and the Wayland Gamble

Boraxpr — Sat, 14 Jun 2025 00:00:00 GMT

Fedora was one of the go-to distro for people who wanted a clean, minimal setup. It shipped with GNOME as a default desktop environment. Modern, Simple and low-maintenance.

But GNOME has always carried a big red flag on the forehead: the devs love to lock things down, Playing the Apple™ UX game. Their vision is making desktop looks and behave like a cheap tablet.

Thankfully, the open-source community stepped in. GNOME Extensions became the lifeline—bridging the gap between GNOME’s locked-down vision and what users actually wanted. GNOME Extensions are a godsend. They let users take back control—whether that’s adding a proper taskbar, system monitor, or restoring basic functionality GNOME randomly cuts with each release. When GNOME strips features in the name of “design,” the community patches it back in.

Fast forward to 2025, things changed. Fedora still ships with GNOME, but now the extensions are buggy, fragile, and frequently broken by upstream updates. “Just works” turned into “just broke.” Long-time users are fed up. People left. It's clear that people fed up with how GNOME has been pushing breaking changes and people just moved to other desktop environment for good.

At this point, the only sane, usable setup on Fedora is the KDE Spin. It brings back control, flexibility, and a desktop that respects user choice.

But even Fedora KDE Spin still comes with a big caution: Wayland.

Wayland is supposed to be the next-generation replacement for X11—the old display server that’s powered Linux desktops for decades. In theory, Wayland offers a cleaner design, better security, and more efficient rendering. In reality? It has been "THE FUTURE" since 2008. In 2021, I remember wrestling with wayland glitch that cause my desktop total stuck. Today, It’s still not ready for prime time in 2025, especially if you’re a gamer, developer, or anyone who needs reliable desktop tooling.

Yesterday, I launched Stellar Blade on my machine—and the performance was a stuttery mess. I switched to GE-Proton, the go-to custom Proton build for better compatibility. Still stuttered. After troubleshooting, the culprit was obvious: Wayland.

Gaming on Wayland is mostly fine until you hit that single game for me it's Stellar Blade where Frame pacing is inconsistent, and input lag is noticeable. But it’s not just about games—even basic apps like Chrome behave weirdly. UI elements misalign, invisible buttons appear, clicks land in the wrong place, and windows sometimes act like they’re half-rendered. It’s not just inconvenient—it’s disorienting. Sometimes, If It even stuck at sddm. When your daily browser becomes a glitchy experience, that’s a red flag that the desktop stack isn’t production-ready.

After I dig deep, it turns out that some apps or game still based hard on X11. But first I'm going to visualize the "Linux Desktop Stack" and what they are composed of. Unlike windows or mac where it's a blackbox like so.

┌──────────────────────────┐
│       Graphical App      │   ← Chrome, Photoshop, Teams
└────────────┬─────────────┘
             │
┌────────────▼─────────────┐
│     Operating System     │   ← Win32, DWM, Quartz, Audio, Input, GPU stack
│    (monolithic, hidden)  │
└────────────┬─────────────┘
             │
┌────────────▼─────────────┐
│        Hardware          │   ← CPU, GPU, Display, Audio, etc.
└──────────────────────────┘

Modern Linux Desktop Stack:

┌────────────────────────────────────────────────────┐
│                  Graphical Applications            │
│   (Chrome, Firefox, VSCode, Steam, etc.)           │
└────────────────────────────────────────────────────┘
               ▲              ▲             ▲
               │              │             │
┌──────────────┴──────┐ ┌─────┴─────────┐ ┌──┴────────────┐
│  GUI Toolkits       │ │  Wayland/X11  │ │  Audio System │
│ (Qt, GTK, Electron) │ │  Client APIs  │ │ (PipeWire)    │
└────────────┬────────┘ └────┬──────────┘ └────┬──────────┘
             │               │                 │
┌────────────▼────────────┐  │                 │
│  Window Manager /       │  │                 │
│  Compositor (KWin,      │  │                 │
│  Mutter, wlroots, etc.) │  │                 │
└────────────┬────────────┘  │                 │
             │               │                 │
┌────────────▼───────────────▼─────────────────▼────────┐
│              Display Server Protocol (Wayland / X11)  │
└───────────────────────────────────────────────────────┘
                           │
              ┌────────────▼────────────┐
              │       Kernel (DRM/KMS)  │
              │     Input & GPU drivers │
              └────────────┬────────────┘
                           │
              ┌────────────▼────────────┐
              │        Hardware         │
              └─────────────────────────┘

There is no true non-moving part on Linux, you can change anything but it comes with bugs if they are not designed with that specific combination integration.

As for Fedora KDE Spin, the non-moving parts are WM (KWin) + Display Server (Wayland) + NVIDIA PROPRIETARY DRIVER. The problem is that while Fedora pushes Wayland as a hard default, There are multiple apps that are not yet built to use Wayland Client APIs that means they still use X11. Now Wayland solves that problem by providing XWayland APIs aims to support these apps and fall them back on to X11. This makes it's possible to run X11 apps on Wayland without crashing. The point is not crashing does not mean no problems. It introduces mismatch of X11 legacy scaling, rendering, gpu connectivity quirks within the wayland environment itself.

The problem here is Google Chrome on Red Hat Package Manager still ship with X11 as a default while Fedora already moves to Wayland as a default. So when I install google chrome on fedora, It falls back to X11 (XWayland) and causes problem like UI and screen mismatch on Multi-monitor setups. Whenever I click fullscreen, there is 75% chance the UI and the reality are going to be mismatch e.g. the UI show button is there but when i click : actual button is 5px downward.

The Fix

Specifically for Chrome, ~/.local/share/applications/google-chrome.desktop must be modified to be launched with flags to make Chrome uses Wayland as a Backend.

Exec=/usr/bin/google-chrome-stable --ozone-platform=wayland --enable-features=WaylandWindowDecorations %U

The fact that this even works mean Google Chrome already supports Wayland but they don't rollout with Wayland as defaults. This config will be overwritten anytimes there is package update so I must copy and create another launcher for Chrome itself. oh. Fedora experience is almost like Arch Linux in 2025 : I installed Default flavor - Met Unusable Gnome Extensions, buggy even caused multiple crashes. I manually installed KDE - now multiple Desktop managers setup is buggy GNOME conflicts with KDE. I reinstalled anew with KDE Spin. Now I meet Wayland-X11-XWayland-Nvidia messes. Good thing that there are still way out but Fedora in 2025 is not the same 2021 Fedora that it just works.

Now we're in the limbo. KDE+Wayland+NVIDIA GPU = Abysmal performance on some games, Visual Glitches on Google Chrome unless force launch flag to use Wayland, etc. While KDE+X11+NVIDIA GPU = Abysmal Desktop Experience because KWIN Compositor are not playing well with X11 due to de-prioritized and focused on wayland.

Fedora has become the distro where everything is possible — and nothing is guaranteed. If 2021 was the “just works” era, 2025 is the “just fix it yourself” generation. Back to finding way to run Stellar Blade on Wayland without lagging hard.

TL;DR

GNOME on Fedora is now fragile and over-simplified.
KDE Spin is better — but Wayland+NVIDIA still cause random graphical glitches.
Chrome defaults to X11 via XWayland = misaligned UI, broken fullscreen.
Manual .desktop fixes help, but updates overwrite them.
Fedora today is bleeding-edge in the worst way.

AI แทนคนไทยไม่ได้หรอกครับ

Boraxpr — Sat, 01 Nov 2025 00:00:00 GMT

ทุกคนพูดถึง AI กำลังจะทดแทนงานต่างๆ
โอเค มันอาจจะฟังดู make sense ถ้าคุณฟังแต่ feed ตาม social หรือแม้แต่ตาม conference
ในไทยที่ชอบพูดกันว่า “อีกหน่อยหุ่นยนต์จะมาแทนคน”

แต่ถ้าเรานั่งคิดจริงๆ ในเชิงสมการเศรษฐกิจ
**ในบริบทของประเทศไทย มัน make sense เหรอครับ? **

ค่าแรงคนไทยโดยเฉลี่ยวันละหลักร้อย
หุ่นยนต์โดยเฉลี่ยตัวละหลักครึ่งล้าน
คนไทยทำงานทั้งปี ได้แค่แขนหุ่นยนต์ข้างเดียว

ในประเทศพัฒนาแล้วอย่างสหรัฐฯ หรือยุโรป ค่าแรงเฉลี่ยวันละ 5,000 บาทขึ้นไป
หุ่นยนต์หนึ่งตัวราคา 600,000-1,000,000 บาท มันจึงพอคำนวณ ROI ได้ ถ้าใช้งานแทนแรงงาน 24 ชั่วโมงโดยไม่หยุด

แต่ในไทย ค่าแรงเฉลี่ยแค่ 300–400 บาทต่อวัน
แปลว่าหุ่นยนต์หนึ่งตัวต้องทำงานแทนคน เกือบ 10 ปีเต็ม ถึงจะคุ้มทุน
และนั่นยังไม่รวม **ค่า maintenance, ค่าไฟ, ค่าซ่อม, downtime, และค่าเทรนคนให้ใช้มันได้ ** และนี่ยังไม่รวม คุณภาพงาน (quality) ที่เสียไปอีก
อย่างล่าสุด McDonald’s ในตะวันตกที่ลงทุนกับ AI Drive-Thru ก็ต้องพับโปรเจกต์ทิ้ง
หลังลูกค้าร้องเรียนจำนวนมากจากการสั่งผิดพลาด (https://www.bbc.com/news/articles/c722gne7qngo)

AI หรือ automation จึงไม่ใช่ปัญหาสำหรับประเทศที่แรงงานถูก
แต่กลับเป็นปัญหาของประเทศที่แรงงานแพงต่างหาก
เพราะ “ค่าแรงไทย” มันยังถูกเกินกว่าที่เทคโนโลยีจะเข้ามาแทนได้อย่างคุ้มจริง

ในประเทศที่ค่าแรงยังถูก
สิ่งที่ต้องลงทุนไม่ใช่ “หุ่นยนต์”
แต่คือ “สมองที่รู้จักใช้หุ่นยนต์ให้เกิดประโยชน์”

Damage Absorber: One Year of Senior Engineering Under a Non-Tech Power Structure

Boraxpr — Sun, 23 Nov 2025 00:00:00 GMT

When you start your career, you think software engineering is about code.
You chase clean patterns, perfect programming languages, the right framework, the right naming, the right architecture diagrams.
It feels like the quality of the system depends on how good you write code.

Then you get promoted.
You move closer to the decision making layer.
That is the moment you learn the truth.

Code is never the main problem.
The real problem is power.

1. Junior engineers solve technical problems. Senior engineers absorb organizational damage.

As a junior, the hardest thing you face is a tricky bug or a messy module.

As a senior, you start taking hits from every direction.

Last minute business changes
Fake deadlines
Requirement shifts with no context
Scope creep driven by pressure, not logic
Misaligned incentives

You are no longer judged by code quality, but by how well you can protect the team from chaos above you.

2. The real system is not the backend or the frontend. The real system is the hierarchy.

Software architecture in many companies is just a decoration.
The real architecture is the power flow of the organization.

If business holds full power, engineering becomes a service desk.
If architecture has no authority, design becomes optional.
If KPIs reward speed over correctness, technical debt becomes cultural.

And when this happens, seniors turn into firefighters.
Not designers. Not builders.
Just human buffers between unreasonable demands and a collapsing reality.

Being part of an architecture team forced me to move across business, infra, dev, and AI groups.
Seeing how decisions flow between these layers made it clear that the real problems rarely start in the codebase.
They start in the structure above it, long before engineers ever touch a keyboard.

3. Speed-driven cultures destroy their best engineers first.

I was officially promoted only two months ago, but I had already been working at the senior level for almost a year.
That gap between responsibility and title is common in non-tech organizations, and it shapes how you see the system.
You learn the role long before anyone calls it by name.

When every project is “urgent”, nothing has value anymore.

You see smart engineers slowly losing their edge.

They stop thinking long term
They stop pushing back
They stop designing
They start rushing

And after enough cycles, their skill fades.
Not because they are bad, but because the system forces them to operate below their ability.

This is how organizations waste talent.
Not by lacking resources, but by making speed the only metric that matters.

4. Senior engineering is not about knowing everything. It is about knowing what decisions to refuse.

A senior who cannot say no is a technician with extra meetings.

Good engineers do not save projects by writing faster code.
They save projects by preventing bad directions from turning into irreversible failures.

But that only works if the organization respects reasoning.
If not, seniors become damage absorbers.
They protect the company from its own decisions until they burn out.

5. The higher you go, the more you see that the codebase is a reflection of the power structure.

Bad code is rarely caused by incompetence.
It is caused by:

rushed timelines
poor alignment
unclear ownership
politics
mismanaged expectations

Most senior engineers spend more time taming the system around the code than the code itself.

And that is the ugly truth nobody tells juniors.

Conclusion

One year at the senior level taught me more about organizations than technology.

I learned that code is the easy part.
The hard part is navigating decisions made by people who never see the technical impact of their choices.

In healthy companies, senior engineers guide the direction.
In unhealthy ones, senior engineers shield the team from a storm that never stops.

If you want to grow, learn the tech.
If you want to survive, learn the system.
If you want to thrive, choose where you work as carefully as you choose your tools.

Digital Manual: Thailand’s workflow landscape and why we will not see AI adoption at the level of the US

Boraxpr — Sun, 23 Nov 2025 00:00:00 GMT

Let’s be honest. Thailand’s workflow landscape is nowhere near ready for the kind of AI-driven transformation we see in the United States. The problem is not complicated. Our systems are still stuck in a “digital manual” era, where paper has simply been converted into files, but the processes behind those files were never redesigned for real automation.

The US built its foundations differently. Data pipelines, APIs, centralized systems, standardized processes. When AI arrived, it plugged into workflows that were already designed for machines. Replacing human labor became straightforward.

Thailand never built those foundations, and here is why.

1. Digital manual is not digital automation

Most Thai organizations still follow their old manual workflows, just with Excel and PDF instead of paper.
Data is entered by hand with no validation, no schema, no automated checks.
Every step still needs a person to click, sign, forward, and approve.
AI cannot replace humans when humans remain the glue that keeps the workflow alive.

2. Fragmented data with no standards

The US has invested heavily in mature data pipelines.
Thailand stores data based on personal habits.
Files with identical names but different structures.
PDF scans mixed with photos taken on mobile phones.
Duplicate data, missing data, and fields filled only to make forms “pass”.
AI ends up drowning in noise before it finds anything useful.

3. Legacy systems that cannot be extended

Many organizations still run systems built more than a decade ago.
Some have no API.
Some rely on code no one dares to touch.
These environments cannot support AI, because AI requires continuous workflow integration and automated data access.
In Thailand, the rule is simple: “Don’t touch it or it breaks.”

4. AI needs clear processes, but Thailand relies on people

The US has well-defined SOPs.
Thailand relies on individual experience.
Two employees handling the same task often follow two different methods.
AI cannot work with this level of variability, because the underlying process is not deterministic.

5. Decisions depend on relationships, not systems

Many Thai workflows depend on who calls whom, who signs what, who knows the right person.
These are inherently human-driven steps that AI cannot replace.
The US removed this dependency long ago by shifting trust to systems instead of individuals.

6. AI cannot replace people when people spend their time fixing broken systems

In many Thai workplaces, employees spend more time “fixing the system” than using it.
Automations break.
Data is wrong.
Forms fail.
Servers crash.
People work around problems manually.
Expecting AI to replace jobs in this environment is pure fantasy.

7. Thailand confuses using files with being digital

This is the core misunderstanding.
Many organizations believe they are digital because they use documents in electronic form.
In reality, this is still digital manual.
No automation.
No workflow engines.
No pipelines.
No orchestration.
AI has nothing to integrate with because the process is not a system, it is just files moving around.

Conclusion

AI will only replace labor in Thailand when the entire workflow landscape is rebuilt.
Buying AI tools will not magically automate anything.
The US redesigned its foundations decades ago.
Thailand only started cleaning up Excel sheets yesterday.

This is why we will not see AI-driven workforce reduction at the US scale anytime soon.
The country still depends on people to support systems that were never designed for automation.

Before AI can work, Thailand needs real digital automation, not digital manual wrapped in a modern façade.

Bodyshop: Thai Software Job Market Landscape

Boraxpr — Sun, 23 Nov 2025 00:00:00 GMT

Most people talk about the tech industry in Thailand as if it works like the United States.
It does not.
The Thai software market is built on a foundation that almost guarantees shallow work, unstable careers, and limited long term growth.

The reason is simple.
Our market is not driven by product companies.
It is driven by bodyshops.

1. The market is dominated by contractors, subs, and outsourced teams

When a country has more contracting firms than product companies, the incentive structure flips completely.

Product companies build.
Bodyshops bill.

One cares about long term capability.
The other cares about man hours.

This shapes everything in the market.

Juniors are cheap labor
Seniors are expensive labor
Training is seen as cost
Stability is rare
Skill progression depends on luck, not structure

Most engineers in Thailand do not grow because the system is not designed for their growth at all.

2. Most devs work for the client, not the company on their payroll

Bodyshops put you inside a client site, then the client drives your workload, your stress, your timeline, your pressure.

So who do you belong to?
Your employer?
Your client?
Neither.
You become a floating worker with no home and no real identity.

This is why turnover is high.
You cannot build culture or craft when engineers are treated like replaceable parts.

3. Skill depth is low because nobody owns the product

A product team wants people who understand the system deeply.
A bodyshop team wants people who can be swapped easily.

The result is a landscape full of:

quick deliverables
shallow code
minimal architecture
high pressure
low ownership

Engineers write code, but rarely build systems.
This prevents the market from producing strong mid to senior engineers in large volumes.

4. Promotion in a bodyshop market is not based on skill

It is based on:

how billable you are
how fast you deliver
how much margin you generate

Not whether you think well, design well, or understand systems.

That is why many so called seniors are actually juniors with more years, not more depth.

5. The market punishes those who want to grow beyond coding

If you think in terms of systems, incentives, architecture, or power structure, you are already above the local average.

But the market is slow to reward it.
Because the market is not built around product sophistication.

It is built around headcount reselling.

That is why deep thinkers feel like a minority.
And they are.

6. Why this matters

If Thailand wants strong engineers, we need more product companies and fewer bodyshops.
We need incentives that reward long term thinking, not quick labor rental.

Until then, the job landscape will stay the same.

Most engineers will be stuck in shallow work.
Only a small percentage will break out by entering product companies, global companies, or tech first environments.

Conclusion

The Thai software market is not broken.
It is simply built differently.
It rewards the wrong behaviors and punishes long term thinking.

If you want to grow, you must choose environments that let you build rather than environments that rent you out.

The market will not change soon.
But your path can.

Atomicity is not magic

Boraxpr — Sat, 29 Nov 2025 00:00:00 GMT

image from : https://www.scylladb.com/glossary/acid-database/

CS courses love to say “RDBMS gives you atomicity.”
Yeah, no. That’s the classroom version.

In reality, atomicity is not magic. It’s a fragile outcome created by a bunch of lower-level components doing the right thing at the right time. Miss one, and the whole idea falls apart.

Atomicity only holds because of:

write-ahead logging
strict write ordering
real fsync behavior
crash-consistent metadata updates
durable page flushing
atomic rename semantics
predictable disk guarantees

Break any of these and atomicity is gone.
Run a database on fake-POSIX storage like SMB or Azure Files and you’ll see how quickly things go sideways.

RDBMS doesn’t “provide” atomicity.
It depends on the filesystem being honest, consistent, and actually durable.

If the disk lies, atomicity dies.

Understanding Why Azure File Share Fails Under Heavy Linux File Operations

Boraxpr — Sat, 29 Nov 2025 00:00:00 GMT

Why Azure File Share breaks TSDB/WAL workloads (SMB and NFS)

Azure File Share is built on top of a Windows-based backend. This matters because Windows and Linux have fundamentally different filesystem semantics, especially around atomic operations and metadata consistency.

If you only read/write small files, you won't notice the difference. The problems appear when you do:

massive writes
rapid rename/delete
concurrent writes
database-style workloads
TSDB/WAL workloads

WAL = Write-Ahead Log used by Prometheus TSDB, Loki (Single binary/local mode), Postgres DB, Other reliable databases. It is used for making ingestion resilient: if the service crashes, data is not lost. Read more

This is where Azure File Share fails.

Azure File Share Protocols

Azure File Share offers two ways to mount storage:

1. SMB

Native Windows behavior
NTFS ACLs
Zero POSIX semantics
Completely unsuitable for Linux apps requiring atomicity

2. NFS (Azure Files NFSv4.1)

Document claims “Fully POSIX”
But the limitation section states clearly: “ACLs aren’t supported.”

This is the key problem.

What ACL Means (Real POSIX vs Fake POSIX)

People think POSIX = rwxrwxrwx But POSIX also includes ACL (Access Control List) support for fine-grained permissions:

# file: notes.txt
# owner: tar
# group: devs
user::rw-
user:bob:rw-
group::r--
group:design:r--
mask::rw-
other::---

Azure NFS does not support these. No NFSv4 ACLs. Only rwx bits. This means Azure NFS is POSIX only on the surface.

Under the hood:

Linux App (Container)
      ↓
POSIX-like NFS Emulation Layer
      ↓
Azure File Backend (Windows ACL Logic)

There is a translation layer. Translation = inconsistency = bugs.

Why TSDB, WAL, Prometheus, Loki break

It’s not “lack of ACL” itself that causes corruption. It’s what that implies:

Azure NFS is not backed by a true POSIX filesystem.

This leads to:

1. Non-atomic rename/delete

Linux guarantees atomicity:

rename: instant old→new
delete: instantly gone

Windows needs multiple steps (temp file, move, commit). TSDB workloads rely heavily on atomic rename/delete for WAL and index files. Non-atomic operations cause partial files and corruption.

2. Metadata drift

Real POSIX filesystems store strong metadata in inodes, including:

owner
group
permissions
file size
last modified/accessed
block pointers
hardlinks
inode number

Databases depend on these for correctness.

Azure File NFS uses backend ACL logic (Windows-style), so inode metadata is emulated and can drift.

3. Inode instability

Prometheus maintainers found inode drift on Azure File. This causes:

duplicate inodes
stale filehandles
corrupted index blocks
WAL segment corruption

Reference: https://github.com/prometheus/prometheus/issues/10679

4. Latency in metadata operations

Azure File NFS metadata latency is high single-digit milliseconds. TSDBs expect microseconds.

High-latency metadata = race conditions.

5. Not suitable for databases at all

This affects not just Loki/Prometheus, but also:

PostgreSQL
MySQL
MSSQL
SQLite
Any ACID database

It’s the reason data centers use Linux filesystems (xfs/ext4) for database storage. Linux guarantees atomicity. Windows-like filesystems do not.

Final Summary

Azure File Share:

SMB uses Windows filesystem semantics,
NFSv4.1 is only a POSIX emulation layer,
Backend permissions logic is Windows ACL based,
Atomicity, metadata, and inode behavior do not match real Linux filesystems,

Which means it cannot guarantee consistency for workloads that rely on strict POSIX guarantees.

This is exactly why corruption eventually shows up under:

TSDB workloads (Prometheus, Loki)
WAL-heavy systems
database workloads
anything doing rapid rename/delete cycles
anything depending on strong inode semantics

TLDR

Do not use Azure File Share (SMB or NFS) for databases, TSDB, WAL, or any index-heavy workload.
Use a strict POSIX-compliant block device instead.

On Azure, that means:

Azure Managed Disks via managed-csi
ext4 or xfs
ReadWriteOnce (single node)
Guaranteed POSIX atomicity and metadata stability

Azure File Share fakes POSIX at the protocol layer but is backed by Windows ACL semantics.
That translation introduces nondeterministic behaviors under load.
This is not a throughput problem, it is a correctness problem.

Workloads that require real Linux filesystem guarantees include:

Prometheus TSDB
Loki local storage
Postgres, MySQL
Redis with persistence
Any ACID database
Any component that uses WAL or atomic rename/delete

If your workload cares about data integrity, you must run it on real disk, not network-emulated POSIX.

Someone Told Me ‘Just Add Cache’, Here’s What Actually Happened

Boraxpr — Sat, 29 Nov 2025 00:00:00 GMT

In this era, it’s incredibly easy to take a wrong turn. Large language models answer with confidence, and that confidence tends to spill into human conversations. People, regardless of their actual experience, can end up suggesting architectural decisions they aren’t equipped to evaluate. “Just add cache” is one of the most common oversimplifications.

We’re running an application with multiple instances on Kubernetes, and like everyone else who has done horizontal scaling, we have Redis as a shared component.

A while ago, I used to think Redis was a universal speed booster. It’s RAM, it’s fast, it must make everything faster. Right?

Not quite.

Redis doesn’t magically lower latency. Redis doesn’t fix poorly shaped data. Redis doesn’t improve performance if the root problem is upstream. In most real systems, Redis is used to keep distributed instances in sync and reduce repeated heavy work, not as a silver bullet for slowness.

And this is where the misconception hits hardest.

If your JSON payload is massive, especially when it crosses into multi-MB territory, pushing it into Redis won’t save you. You aren’t reducing cost, you’re just relocating it. The biggest penalty stops being storage access, and becomes the unavoidable JSON.parse overhead in your application.

Parsing a huge structure costs far more CPU time than whatever micro-latency Redis saves by being in RAM. You trade one bottleneck for another, and the system doesn’t actually get faster. It can even get slower due to network overhead, replication load, memory pressure, and throughput degradation.

In short, caching works when the data is small, stable, and cheap to serialize. Caching giant blobs is not optimization, it’s misdirection.

The “Just Use X” Fallacy

Boraxpr — Thu, 18 Dec 2025 00:00:00 GMT

In modern engineering discussions, complex problems are often reduced to simple prescriptions.

“Just use AI.”
“Just add cache.”
“Just switch the language.”
“Just change the framework.”

Different words. Same pattern.

This kind of thinking is not optimization.
It is avoidance.

Why “Just Use X” sounds convincing

“Just use X” feels efficient. It suggests decisiveness and competence without requiring a deep explanation. The listener is spared the discomfort of uncertainty, trade-offs, and messy constraints.

When such statements come from people with perceived authority, seniority, reputation, or even from AI systems that speak with confidence, they spread easily. The idea gains momentum not because it is correct, but because it feels complete.

AI amplifies shallow reasoning

Large language models do not reason about problems in the way humans expect them to. They respond to the structure and assumptions embedded in a prompt.

If a question assumes that a problem is simple and solvable by a single tool, the answer will often reinforce that assumption. Not maliciously, but fluently.

The result is subtle but dangerous. Weak mental models are not challenged. They are refined, polished, and made more persuasive.

Tools do not remove cost, they move it

There is no such thing as a free optimization.

Adding a tool does not eliminate cost.
It relocates it.

Caching shifts cost from IO to memory, CPU, serialization, and invalidation complexity.
AI shifts cost from deterministic logic to probabilistic behavior, verification, and trust boundaries.
Switching languages shifts cost from runtime to migration, tooling, and human expertise.
Adding infrastructure shifts cost from simplicity to operations, failure modes, and long-term maintenance.

If you do not understand where the original cost lives, you will not notice where it moved. The system may look faster, smarter, or more modern, while becoming harder to reason about and easier to break.

Understanding is not optional

Real problem-solving requires understanding constraints, trade-offs, and failure modes. It requires knowing who pays the cost and when that cost surfaces.

No tool can substitute for this. AI included.

If AI truly understood systems, it would consistently identify root causes without human intervention. What we have instead is something more reflective than intelligent. It mirrors the depth of the thinking we put into it.

Closing thought

“Just use X” is rarely an answer.
More often, it is a signal.

A signal that the problem has not been understood yet.

Open-source AI is not free, even on cloud GPUs

Boraxpr — Fri, 19 Dec 2025 00:00:00 GMT

Lately I keep hearing the same pitch.

Open-source AI models.
Run them yourself.
Even better, just use cloud GPUs.
No vendor lock-in. No per-token billing. Problem solved.

It sounds clean. It sounds principled.
It also ignores how systems actually behave in production.

“Free weights” is a distraction

Yes, the model weights are free.
That part is true.

What is not free is everything required to turn those weights into a reliable service.

Inference is not a one-time cost. It is a continuous, operational expense. Once traffic exists, compute dominates the bill.

That reality does not change just because the GPU lives in the cloud.

Cloud GPUs do not change the economics

Using cloud GPUs sounds like a cheat code. No hardware to buy, no racks, no data center drama.

In reality, cloud GPUs only change how you pay, not what you pay for.

Inference workloads do not scale like stateless web servers. You cannot spin GPUs up and down freely without paying a penalty. Models take time to load, memory is sticky, and latency SLOs force you to keep capacity warm.

So you provision for peaks, not averages.

That means:

GPUs sit idle and still cost money.
You pay retail pricing for specialized hardware.
Redundancy multiplies the bill, not the reliability alone.

At small scale this looks acceptable.
At sustained traffic, the math stops being friendly.

The cloud does not make this cheap.
It just delays when you notice the cost.

You are competing with hyperscalers on their own ground

Managed AI providers:

Buy GPUs at prices you will never get.
Run them close to constant utilization.
Share infrastructure across thousands of customers.
Optimize the full stack, from kernels to schedulers.

When you run open-source inference on cloud GPUs, you are paying retail to compete with companies built around wholesale economics.

That gap never closes.

“We can optimize later” is wishful thinking

Performance is not an afterthought.
It is the product.

Real inference optimization means:

Kernel-level tuning.
Memory layout and KV cache strategy.
Batching, queuing, and request shaping.
Constant tradeoffs between latency and throughput.

Teams saying “we’ll optimize later” usually discover that optimization was the job they never staffed for.

By then, production traffic has already locked in your worst costs.

Production is where the math becomes honest

POCs are cheap.
Production is not.

As soon as users exist:

Latency complaints arrive.
Context lengths grow.
Parallel requests increase.
Reliability expectations harden.

One GPU becomes two.
Two become a pool.
The pool needs redundancy.
Now you are running GPU infrastructure, not just a model.

At that point, the illusion of “free” is gone.

When this tradeoff actually makes sense

There are valid reasons to run open-source AI yourself:

Research and experimentation.
Low, predictable internal workloads.
Strict data locality or compliance needs.
Existing infra and ML expertise.

Notice what is missing from that list, saving money by default.

The honest takeaway

Open-source AI is powerful.
Cloud GPUs are useful.

But together they do not magically become cheap, simple, or risk-free.

They are a conscious trade:

Less vendor lock-in.
More operational responsibility.
More hidden cost surfaces.

That trade can be worth it.
Just do not pretend it is free.

Reality always sends the invoice.

Excel Is Not Machine-Readable Data (And OCR Won’t Save You)

Boraxpr — Fri, 19 Dec 2025 00:00:00 GMT

TL;DR

OCR accuracy does not help if documents are full of process debt.
Excel is a human-readable UI, not a data contract.
CSV and JSON are transport formats, not places where meaning lives.
Without a database that enforces schema and semantics, automation will not scale.
AI does not reduce cost. It merely relocates it into glue and exception handling.

OCR Accuracy Is Not the Bottleneck

OCR news shows up constantly.
Higher accuracy. Lower cost. Better language support. Easier workflow integration.

But the real question is not
Can you read the document?

The real question is
What can you do with the output next?

Most enterprise documents were never designed to be machine-readable.

Rows exist for reasons nobody remembers.
Addresses are split across pages due to legacy system limits.
The same field means different things in different departments.
Codes like 01 or AZ1202 require asking someone or opening another document.

OCR solves only one step:

pixel → text

Automation requires something very different:

text → meaning → action

And this is where most systems break down.

The Real Enemy Is Tribal Knowledge

You can have 120 percent OCR accuracy.
It still does not matter if meaning lives in people.

“What does code 01 mean? Ask someone.”
“This code needs to be looked up in another Excel file.”
“These two fields are actually one value.”

At that point, human-in-the-loop is not optional.
It is a hard requirement.

AI cannot fix this, because the problem is not intelligence.
The problem is undefined semantics.

Guessing is non-deterministic.
Non-deterministic systems cannot be audited.
Unauditable systems do not survive production.

This is not technical debt.
It is organizational debt.

Excel Is Human-Readable First

Excel is readable by machines.
But it was never designed to be machine-readable.

Excel is a UI for humans.

merged cells
color-coded meaning
floating headers
notes mixed with data
formulas that depend on context

Machines can parse Excel files.
Machines cannot reliably infer meaning from them.

Excel works well when humans are part of the loop.
It fails as the foundation of automation.

CSV and JSON Are Not Storage

A common misconception is that converting Excel to CSV or JSON makes data machine-readable.

It does not.

CSV and JSON are transport formats.
They are not sources of truth.

No serious system stores long-term meaning in CSV or JSON files.

What you actually need is a database.

A database enforces things files never will:

schema
constraints
referential integrity
versioned structure
deterministic queries
auditability

Without these guarantees, you are not storing data.
You are storing ambiguity.

Cost Did Not Disappear. It Moved.

Before OCR and AI:

people type
people check

After OCR and AI:

people interpret intent
people maintain mappings
people fix exceptions
people maintain the bridge between OCR, AI, and the database

The cost does not go away.
It gets redistributed, often into more expensive roles.

Over time, that bridge layer becomes the next generation of process debt.
“Do not touch it. It will break.”

Excel as a Source of Truth Is Just Vibe Coding for Data

Using Excel as a source of machine truth is equivalent to letting a vibe coder do a database engineer’s job.

A database engineer’s responsibility is to make meaning explicit and enforced.
Schema, constraints, references, invariants, migrations, ownership.
The system is allowed to say no.

Excel does the opposite.

Excel is permissive by design.
Anything goes. Any shape. Any workaround.
Validation is optional. Semantics are implicit. Errors are silent.

That is exactly how vibe-coded systems behave.

Rules live in someone’s head.
Structure emerges accidentally.
Edge cases are handled “later.”
Everything works until scale or automation shows up.

When Excel becomes the source of truth, the failure modes are the same:

Schema drift with no visibility.
Business rules encoded in layouts, colors, or side documents.
Integrity enforced socially instead of technically.
Automation that breaks the moment a new person touches the file.

It feels productive at first.
You move fast. Nothing blocks you.

Until auditability, reliability, or automation becomes a requirement.
Then everything collapses at once.

The core problem is simple:
you replaced enforced contracts with vibes.

If You Want Automation, Redesign First

If an organization is serious about automation, the hard work comes first:

eliminate tribal knowledge
define a canonical schema
create a single source of truth
enforce validation
reject ambiguous input

This is process redesign, not tooling.

Deploying AI before doing this is cosmetic engineering.

Conclusion

OCR is not failing.
AI is not failing.

Organizations fail when they refuse to formalize their own knowledge
and expect intelligence to emerge from ambiguity.

As long as meaning lives in people instead of systems,
people will always be pulled back into the loop.

No model, no matter how advanced, can change that.

Some Models Are Flashy. Some Models Are Forever.

Boraxpr — Sun, 21 Dec 2025 00:00:00 GMT

Every few months, the industry discovers the next model.

This time it’s
Gemini 3 Pro Ultra Whatever™.

Next time it’s 3.5, and suddenly we’re back to
“human race extinction is imminent.”

Same movie. New trailer.

Benchmarks go up.
Slides get cleaner.
Threads declare “this changes everything” before the weights even finish uploading.

And just like that, the timeline resets.
New year. New model. Same prophecy.

The part everyone forgets

What the industry conveniently forgets
or never learned in the first place
is that none of this runs in a vacuum.

Most “vibe coders” have never heard of the OSI Model.

Not because it’s outdated.
Because it’s boring.

No hype cycle.
No launch event.
No extinction countdown.

Yet this unsexy, decades-old abstraction
is still quietly holding the entire internet together.

The longest-running model in tech

Packets still move.
Failures still cascade at Layer 1–3.
Latency still ruins your “AI-native” demo.
And debugging still begins with:

“Is the network actually up?”

The OSI Model doesn’t get rebranded.
There is no OSI 3.5.
No OSI Pro Max.

It doesn’t promise to replace humans.
It just ensures your miracle model can talk to anything at all.

OSI isn’t alone

The OSI Model isn’t special because it’s old.
It’s special because it never needed rebranding.

And it’s not the only one.

Modern systems quietly run on models most hype-driven engineers never name: consistency tradeoffs, failure domains, queueing behavior, latency budgets, organizational incentives.

They don’t trend. They don’t ship with release notes. They don’t care how smart the next model is.

They just describe reality.

You don’t replace these models. You inherit them.

Yet everything depends on them.

CAP Theorem – pick two, live with the third
ACID – because data loss isn’t a “temporary inconvenience”
Amdahl’s Law – your AI won’t fix the slow part you ignored
Latency budgets – physics still clocks your ambition
Queueing theory – why your “agent swarm” collapses under load
Failure domains – why one smart model can still take everything down

Intelligence doesn’t bypass physics

Every year, we announce a new intelligence revolution.
Every year, we forget the same fundamentals.

Models get smarter.
Reality stays stubborn.

Your system still:

times out
drops packets
fails under load
breaks at Layer 8

Some models are flashy. Some models are forever.

The future may be intelligent.
It may reason.
It may generate code faster than you can read it.

But it will still run on networks.
It will still fail in mundane ways.
And it will still depend on models that never trend on social media.

Some models chase headlines.
Some models just keep the world running.

Technical Avoidance and Its Impact on Thai Tech

Boraxpr — Fri, 26 Dec 2025 00:00:00 GMT

People like to preach as if Thai tech is on par with Silicon Valley.

You hear it all the time.

Silicon Valley says software engineering is cooling down,
so people here assume the same thing will happen to Thailand.

No. It will not.

Our tech industry is built on completely different assumptions, incentives, and realities.
At the most basic level, it is a different ecosystem.

Capability vs density

The US does not win because every engineer there is a genius.
They win because they have a higher density of people who take technical depth seriously.

In stronger programs, students are pushed into real engineering work early. Many of them:

Build or modify operating systems
Write parts of compilers or runtimes
Treat systems programming as normal, not exotic

Not everyone does this, and plenty still coast.
But there is a critical mass that pulls everything forward.

In Thailand:

Year 1: Hello World
Year 2: Hello World, now object-oriented
Year 3: Hello World, now with a database

That is not an insult. That is curriculum design.

This is not because the US is magical.
They built environments, incentives, and expectations that force more people to go deeper.

You do not close a gap by denying it exists.

The root problem is not talent, it is avoidance

When I was in college, the majority of people I knew hated coding.

Not struggled with it.
Not found it hard but interesting.
They outright hated it.

They would do anything except code.

Why were they there?
Almost always, “my parents told me to study this.”

That is not unusual here.
But the downstream effects are brutal.

Do anything except the hard part

This mindset repeats everywhere:

Do anything except coding
Do anything except math
Do anything except systems
Do anything except responsibility

Not because the subject is impossible.
Because changing direction is costly, and avoiding the discomfort feels safer.

So people stay in careers they dislike and optimize for escape routes.

Slides.
Presentations.
Buzzwords.
Process.

I still remember forming a group for a term project.
One friend said, without hesitation:

“I’ll do anything except coding.”

That sentence explains a lot.

Fast forward: our tech job landscape

Years later, the same avoidance patterns show up again, this time institutionalized as career tracks.

Tester
Business analyst
Project manager
System analyst
AI engineer
Architect
And more

These roles are legitimate when they stay connected to engineering reality.

The problem starts when they become escape hatches from responsibility, while still controlling direction.

People end up directing implementation without having to carry the cost of executing it.
And once that structure exists, it reinforces itself.

Within those structures, cargo-cult narratives thrive:

“Developers will be replaced by AI”
“Just use AI”
“Coding won’t matter anymore”

We are not San Francisco, and pretending otherwise only keeps us stuck.

Compare this with the US reality

In healthier tech ecosystems, many managerial roles are held by people who:

Have shipped real systems
Understand where things usually break
Can drop into the weeds when necessary
Give implementation-level guidance instead of slogans

Not all of them. There is plenty of fluff there too,
but there is a larger share of people who have actually done the work.

It is not perfect. They have cargo cult behavior too.
The difference is that more people recognize it when it shows up.

The idea exists in Thailand, but it is rarely discussed openly, and almost never named.

In Thailand, not always, but often, direction stops at “go do [buzzword].”

Meanwhile:

Testers frequently write code.
Architects are usually engineers who have survived multiple failures.
AI engineers tend to be strong developers who later moved into a specialized domain.

I came across a comment from an AI engineer that summed it up:

“I wish I weren’t an AI engineer.
The pay isn’t much better than dev,
but the job is still dev plus ops plus unclear requirements.”

That line says a lot.

AI engineering there is not a shortcut.
It is extra responsibility stacked on people who already know how to build.

Thailand’s AI illusion

In Thailand, too many “AI engineer” roles are built around optics instead of engineering.

The selection criteria often look like:

Polished English
Beautiful slides
Fluency in buzzwords
Comfort presenting to executives

But when it comes to fundamentals, things fall apart.

Roadmaps get written that the authors cannot execute.
Milestones are “validated” by LLM answers they do not know how to evaluate.

That is not innovation.
That is theater.

Leadership often ends up rewarding the theater, because it is easier to measure slide decks and demos than real technical resilience.

Reality check

Even if AI wiped out a lot of coding jobs in Silicon Valley tomorrow,
it would not wipe them out in Thailand anytime soon.

Because we still do not have enough people who can:

Debug deeply
Trace problems across systems
Own outcomes end to end
Take responsibility when things break

AI does not replace absence.
AI amplifies capability that already exists.

If you cannot reason about systems, AI only helps you produce wrong answers faster.

If we want to move forward

We need to stop lying to ourselves.

This is not about nationalism.
It is not about pride.

It is about admitting that:

Our education system rarely rewards real technical depth
Our workplaces often reward appearances over mastery
Our leadership pipelines filter for presentation more than competence

Until those incentives change, no amount of “Thai talent is world-class” posts will make it true.

You do not close a gap by denying it.
You close it by telling the truth first, then building differently.

AI and the Illusion of Easy Work

Boraxpr — Fri, 09 Jan 2026 00:00:00 GMT

image from : https://www.icopilots.com/strategyzer-and-the-dunning-kruger-effect/

There's a pattern I keep seeing lately, especially with AI and LLMs.

When people don't understand a field, they think it's easy.
When they understand it a little, they think AI lets them replace it.
When they actually understand it deeply, they stop making bold claims.

That's not opinion. That's Dunning–Kruger.

The illusion of "easy work"

Non-coders say coding is easy now. AI writes code. Why hire developers?

Some developers say business is easy now. AI writes marketing copy.
"I'll just go solopreneur and bag the cash myself."

Others say we don’t need mathematicians, lawyers, security engineers, designers, or analysts anymore. AI already knows more than humans. Who needs verification when confidence feels good?

This logic always comes from the same place: not knowing what the real work actually is.

People confuse output with expertise.

What expertise really looks like

Expertise is not typing faster.
It's not producing artifacts.
It's not knowing syntax, formulas, or buzzwords.

Expertise is knowing:

where things fail
which assumptions are dangerous
which edge cases matter
what cannot be trusted
how context changes decisions
when a "correct" answer is still wrong

These are the parts AI struggles with the most. Not because the model is bad, but because these things live outside clean inputs and clean rules.

LLMs make ignorance louder, not smarter

LLMs are extremely good at sounding right.
They are extremely bad at telling you when they are wrong.

If you don't know a domain well enough, you will not spot hallucinations. You won't even know what to verify. You'll accept confident nonsense because it aligns with what you already believe.

That's why people who lack depth are often the most confident about replacement. They cannot see the gaps, so they assume there are none.

Why "AI will replace X" is usually a tell

When someone says AI will replace a profession, what they are really saying is this:

"I don't understand what that profession actually does."

Security is not just writing secure code.
Design is not just drawing interfaces.
Business is not just writing pitches.
Math is not just producing answers.

If any of those were true, those fields would have collapsed long before AI showed up.

The uncomfortable conclusion

AI does not flatten the skill curve.
It steepens it.

It removes shallow work and exposes shallow thinking.
It rewards people who understand systems, constraints, and failure modes.
It punishes people who mistake surface-level competence for mastery.

Experience doesn't make you louder.
It makes you more careful.

If something looks easy, the honest move is not confidence.
It's suspicion.

Because the moment everything feels obvious is usually the moment you've stopped seeing what matters.

TanStack is optional. Somehow it got sold as mandatory.

Boraxpr — Sat, 10 Jan 2026 00:00:00 GMT

TanStack is optional.

That’s the entire point that keeps getting lost.

Somewhere along the way, it stopped being presented as a tool with tradeoffs and started being sold as a must use for React developers.

Not as “use this when it fits.”
Not as “here’s what it solves.”
But as a baseline.

Once that narrative sets in, people stop thinking.

Newer developers assume it’s required.
They reach for it by default.
And when you ask why, the answers are vague.

“Better performance.”
“Industry standard.”
“Everyone uses it.”
“It handles caching.”

None of those explain why this app needs it.

It starts to feel less like engineering and more like belief.

The truth is simpler.

TanStack solves a specific class of problems:

shared server state
read-heavy data
background revalidation
convenience around caching

That’s it.

It does not make data more correct.
It does not eliminate race conditions.
It does not replace thinking about async behavior.

It just gives you tools.

Useful ones.
Optional ones.

The moment you introduce a client-side cache, you introduce time as a concern.

Multiple requests in flight.
Out-of-order responses.
Background refetch.
Mutations racing reads.
Optimistic updates guessing the future.

Now you’re not just fetching data.
You’re reasoning about ordering, invalidation, and overwrite windows.

That complexity is real, even if the abstraction hides it.

What gets glossed over is that most apps don’t need this.

Fetching on demand works.

Component mounts, fetch.
User acts, refetch.
Server stays authoritative.

It’s slower.
It shows loading states.
And it’s correct.

I’d rather show a spinner than lie.

There are places where TanStack fits well:

app configuration
feature flags
read-heavy, low-mutation reference data

Notice the pattern.

Global meaning.
Rare writes.
Tolerance for brief staleness.

That’s not most CRUD.

Auth isn’t one of them either.
Auth should be validated by the server on every page or navigation. It’s security-critical and intolerant to staleness.

If calling an auth endpoint on every page is a problem, that’s a backend issue, not a reason to cache it on the client.

The problem isn’t TanStack.

The problem is how it’s talked about.

When a tool is oversold as mandatory, people stop evaluating it.
They stop understanding it.
They stop questioning whether it fits.

At that point, it’s no longer a tool.
It’s doctrine.

So no, I don’t use TanStack by default.

Not because it’s bad.
Not because it’s useless.

Because it’s optional.
And treating optional tools as mandatory is how complexity sneaks in unnoticed.

Speed VS Velocity - What is Productivity

Boraxpr — Sun, 15 Feb 2026 00:00:00 GMT

Most organizations obsess over two metrics: Productivity and Capability. But we’ve stripped these words of their meaning.

In the modern corporate machine, these terms have been oversimplified into dangerous caricatures:

Productivity is reduced to: "Are all your time slots filled?"
Capability is reduced to: "Do you know more today than you did last year?"

Here is why this logic is failing the people who actually build the systems.

Productivity : The Utilization Myth

If you squeeze your people hard enough, you can achieve 100% time utilization. Everyone is "busy." Everyone has a full calendar.

But the missing variable is Value.

When management talks about productivity, they assume the tasks assigned are beneficial to the organization. But what if they aren't? What if most tasks exist solely to appear "busy" or to satisfy a hollow KPI?

When "Speed" becomes the excuse for rushing out "trash work," you aren't being productive. You are just creating a high-speed assembly line for features no one uses and systems no one can maintain.

Speed is Not Velocity

We often hear that "the business can’t wait," so we need more speed of execution.

But Speed is a scalar; it’s just how fast you’re moving. Velocity is a vector; it’s speed with a specific direction. If your organization demands speed without velocity, you aren't building a product; you’re building a junkyard. You might cross the finish line fast, but you’ll leave behind a mess of technical debt that someone else—usually your most capable engineers—will have to clean up later. Moving fast in the wrong direction provides zero benefit to the organization.

Capability : The Infinite Horizon

"Know more than yesterday." It sounds noble, but in a dysfunctional system, it becomes a burden. At what point is it enough?

When the organization prioritizes "speed" (trash work) over "velocity" (meaningful direction), the most capable people are punished. They are the ones expected to learn every new tool, fix every legacy disaster, and teach every new hire-only to watch the cycle repeat.

Capability without a meaningful goal isn't growth. It's just a faster way to burn out.

The Bottom Line

If you are measuring productivity by how many hours your engineers are "busy," you’ve already lost the plot. Stop asking for speed. Start defining the velocity.

Otherwise, you’re just paying people to build a pile of junk faster.

Can't Unsee It: The KPI Work Factory

Boraxpr — Mon, 23 Feb 2026 00:00:00 GMT

I used to wonder why engineering teams are constantly bombarded with work. Why the backlog never shrinks, and why every day feels like a sprint.

After years in the industry, delivering projects and witnessing dozens of others, the realization finally hit me. And once you see it, you can’t unsee it.

Much of the industry's work is just "KPI Work."

It’s work designed to satisfy a metric, not a user. It’s work created to justify a budget, not to solve a problem. These projects are launched, celebrated in slide decks, and then quietly left to rot because they have absolutely zero impact on anything that actually matters.

Instead of building a product, teams often end up building a paper trail of "achievement."

Companies burn their best engineers on these hollow tasks just so someone can check a box at the end of the quarter. Architecture, stability, and sanity are sacrificed to maintain the illusion of progress.

It’s an exhausting cycle of moving at high speed toward a destination that doesn't exist. If "Productivity" means being 100% utilized on projects that provide zero value, then we aren't being productive. We’re just being busy while the ship stays in the same place.

The question shouldn't be "How can we work faster?" The question must be "Why are we doing this at all?"

The Missing Feedback Loop

The most terrifying part of a KPI Work Factory isn’t the useless projects—it’s the total absence of a feedback loop.

When success is defined by 'finishing' rather than 'solving,' we lose our North Star. Without feedback from real-world performance metrics, we are flying blind. How can teams know where to improve if they don't even know where they are? How can they iterate when they are already being forced to sprint toward the next hollow goal?

The irony is that in a culture of corporate 'politeness,' you’ll rarely hear the truth. If you have a good connection or if you're just a decent colleague, no one will ever look you in the eye and say, "This system doesn't actually solve our problem, and we never use it."

They’ll just smile, thank you for the hard work, and let the project rot in silence.

In the absence of brutal, data-driven feedback, we aren't just flying blind; we’re operating on a false premise.

Breaking the Cycle

To escape the KPI Work Factory, we have to start demanding to see the impact.

As engineers and product builders, we need to ask harder questions before the sprint even begins. What is the baseline metric we are trying to move? How will we measure adoption? What does failure look like for this feature?

If the answers aren't clear, the project isn't ready. We have to shift the culture from celebrating output to celebrating outcomes. Until we tie our engineering efforts to actual user value rather than internal scorecards, the factory will just keep humming along.

AI Fatigue and peak of non-tech expectation

Boraxpr — Sat, 07 Mar 2026 00:00:00 GMT

I think I’ve hit AI fatigue.

Not because I don’t use it. I use it every day. Constantly. It’s part of how I debug, design, and ship systems. I was following this space long before mass enterprise adoption, before every executive suddenly had an “AI strategy.”

What burns me out is the noise. The endless wave of headlines and demos with the same tired promise: “AI will replace us in 6–12 months.”

This narrative should’ve died already. If AI is going to replace me, then replace me. Don’t warn me. Don’t hype it. Don’t count down. If the replacement is real, just do it. Otherwise, stop the clock.

The Gap Between Demo and Reality

Instead of replacement, we get an endless sequence of tools: Copilot, Claude Computer Use, Cursor, Claude Code, and an army of "agents." Each is framed as the moment humans become optional.

And yet, I use them every day, and I find mistakes every single day. Not rare edge cases—daily, systemic errors:

Flawed Assumptions: Logic that breaks the moment it hits a real-world constraint.
Hallucinated Syntax: Code that looks elegant but relies on non-existent libraries.
Confidently Incorrect Logic: Solutions that pass a superficial glance but fail under load.

Wiring Probability into Determinism

The current push is to connect these systems directly to actions—letting them run commands, modify infrastructure, and operate production environments with the assumption that it will “just work.”

It won’t. At its core, an LLM is a probabilistic system. It predicts; it does not "know." It does not verify unless forced. It does not carry responsibility.

We spent decades engineering deterministic systems because predictability and reliability matter. Now, we’re wiring probabilistic engines into deterministic infrastructure and hoping for the best.

Hope is not an engineering strategy.

The Human Bottleneck: Judgment

AI is the most powerful force-multiplier I’ve ever used. It removes friction and lets one person do the work of many. But acceleration is not replacement.

The bottleneck in software engineering was never typing speed; it was judgment. It’s the ability to know something is wrong even when it looks correct. AI can generate at light speed, but it cannot care if it’s right.

So I’m done with the countdowns. If replacement arrives, it won’t be through a press release or a flashy demo. It will arrive quietly, when the results finally speak louder than the hype.

Until then, I’ll keep using it. And I’ll definitely keep checking its work.

Scaling Multi-Tenant Runtimes: Why Isolation is Mandatory at 500+ DAU

Boraxpr — Sat, 07 Mar 2026 00:00:00 GMT

Managing an internal AI platform (OpenWebUI/LiteLLM) at a 500+ DAU scale is a constant lesson in the high cost of "Optics." When working with innovative teams that demand the latest Gemini models the morning they drop, high velocity is expected. But following the hype is easy—noticing the wall before you hit it is the real engineering challenge.

The Prototype Fallacy

A centralized terminal feature is a perfect example. A prototype for 1-2 users in a sandbox is trivial. Releasing it to 500+ users without strict Kernel-level Isolation is an invitation to disaster.

If you don't have isolation, you aren't running a platform; you're running a ticking time bomb:

The "RAG" Data-Plane Failure: Choosing a model for "superior accuracy" is a common trap. In the real world, a single RAG response can hit 300MB+ of JSON. Without resource limits, this causes a pod to die on arrival due to OOM (Out of Memory) before the data can even be processed.
The "Vibe Coder" Failure: It only takes one "vibe coder" running a single naive, unoptimized script to leak memory or fork-bomb the shared runtime. Without isolation, that one volatile process causes total failure for every other user on the terminal.
Dependency Collisions: User A’s Python 3.10 requirement breaking User B’s 3.12 environment. Relying on "pre-prompting" an agent to handle isolation is a naive safeguard; in a probabilistic system, there is zero guarantee of compliance. One hallucinated pip install or a manual override is enough to corrupt the environment for the entire pool.
Security & Integrity: The risk of environment variables leaking secrets between users, or a "watch the world burn" moment where a user executes sudo rm -rf /—taking the entire platform offline and triggering an emergency on-call recovery.

Total Cost of Ownership vs. "Optics"

The only way to do this right is Dynamic Provisioning—effectively becoming an internal Cloud Provider. Each user needs a dedicated, isolated slice: 1-2 cores, 4GB RAM, and 50GB of persistent storage.

Building it is the easy part; surviving the Day 2 operations—patching, scaling, and handling the stateful storage of 500 isolated environments—is where the real cost hides.

The hard truth: The Total Cost of Ownership (TCO) for a production-grade system is vastly different from a prototype. You quickly find yourself building an internal replication of a clearly under-resourced and under-business-value Azure Cloud Shell. If the business value doesn't justify the massive resource overhead and the technical stakeholders aren't heard, you aren't building a platform—you're building an empire waiting to fall.

In platform engineering, the goal isn't just to make it work; it's to make it survive the scale.

I'm not going to be a part of the Dead Internet: I'm back to 100% hand-written posts.

Boraxpr — Sun, 15 Mar 2026 00:00:00 GMT

The Dead internet is a phenomenon which majority of content online—previously crafted by humans—is now being automated by LLMS. In 2026, we're seeing "samey" contents all over social media. It all sounds the same; It all gives the same calls-to-action, key takeaways and advice.

Jokingly, I sometimes even guess which model a writer used. Gemini, ChatGPT, Claude each have their own signature writing styles (I can feel it because I've been using all of them).

It's not just images and videos; I highly suspected the majority of content creators are using AI to generate their writings. Even with friends, normies are starting to sound identical, which, in my book, defeats the purpose of creating content.

Personally, I've been using AI to refine and edit my posts, but I've reached a point where I have a hard time expressing my authentic thoughts. Because I use AI so regularly, I'm officially quitting the habit of using it to "make my writing better." I might still ask for insights or basic grammar fixes, but no more automated writing. It defeats the purpose of the act itself.

Would it still be "me" writing if 80% of it is AI?. For a long time, I convinced myself the answer was yes. But lately, it’s become difficult to tell which thoughts are actually mine.

From now on, my posts will be 100% hand-written.

Low Maturity Software Culture: They want order-takers, not systems-thinkers

Boraxpr — Tue, 24 Mar 2026 00:00:00 GMT

In the Thai market, I find it truly challenging to find the right place for me. As a systems-thinker, I evaluate every order and reject the ones that don't make sense. I focus on doing what is right for long-term maintainability.

However, what I’ve found in Low Maturity Software Culture is that most stakeholders don’t want systems-thinkers. Even though we actively prevent "the shit hitting the fan" so they never have to feel the pain, egos and corporate culture often get in the way. They ignore us, prioritizing optics and relationships over working systems.

Once the system is shipped and the KPI checkbox is green, the Business moves on. The app is in production. But when the cracks inevitably show, the failure is blamed on the implementers, not the flawed logic that forced it.

They want order takers. not me, never will be able to fit in to that role. And when shit happens according to their order being followed to the letter (otherwise they would label you as difficult) they blame you.

Weird of all things, most if not all world top software such as Google, Facebook, Apple and I'd argue many products that are able to hit mass adoption are this scalable because they listen to the doers. recently, i've been into a HBO MAX Series named "Sillicon Valley", I feel like technological advancement, usable and working longterm products can not and will not magically appear because a group of dev listen and execute based on business stakeholder word by words, character by characters.

The main character in Silicon Valley had two offers to choose from. He built a world-class, efficient compression and search algorithm. He was offered 10M USD to instantly buy his algorithm, but he chose to accept 200,000 and support for the business to grow his own app instead. That's what I'm talking about.

As far as thai tech market is heading, I only see disappointment, demo driven development. what these people do is replaced their own software once in a while with an external vendor (who doesn't even own the platform if they aren't buying MA support).

It is architecturally difficult to make a great software product in Thailand.

3-5 years ago, we were talking "hey, kids should go to computer science". But when the kids went to computer science and came out. You don't listen to them but instead listen to MBA people.

One of the tolls of working in this sort of environment and culture is that your engineering skills will vanish within years. You won't know what is logically or architecturally right anymore because you're forced to do what "someone important" wants to happen.

Maybe it's just the culture of tech as supporting, not business value center but as a cost center.
Maybe one day it would be better.