Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)A

Aijan

@ Aijan @programming.dev

Posts
14
Comments
10
Joined
2 yr. ago

  • Testing Side Effects Without the Side Effects

    Jump

  • I think you might be focusing on the execution of the request rather than the orchestration. The decision of when and why to make an API request is absolutely business logic. In imperative code, that logic is hard-coded to the execution. By separating the intent from the execution, we can test that decision flow without spinning up the infrastructure.

  • Testing Side Effects Without the Side Effects

    Jump

  • Integration tests against a real database can and should still be performed. The idea here is the ability to test business logic in isolation without using mocks. Effect systems also have other benefits. You basically get cross-cutting concerns like logging and profiling for free. Every single database call, API request, and file read in your entire application can be easily logged and profiled.

  • Testing Side Effects Without the Side Effects

    Jump

  • You can still test the functions individually or run the entire flow against a test database, but without an effect system like this, it's very hard to test business logic in isolation.

  • Programming @programming.dev
    Aijan @programming.dev

    Testing Side Effects Without the Side Effects

    lackofimagination.org /2025/12/testing-side-effects-without-the-side-effects/

  • Managing Side Effects: A JavaScript Effect System in 30 Lines or Less

    Jump

  • I've added JSDoc type annotations to the library.

  • Managing Side Effects: A JavaScript Effect System in 30 Lines or Less

    Jump

  • Author here. In my experience, AI coding tools like Claude Code can write code in the Effect system style, and that could be a great starting point for getting developers not familiar with this approach on board.

    I considered adding JSDoc type annotations, but that would make the code a bit verbose.

  • Programming @programming.dev
    Aijan @programming.dev

    Managing Side Effects: A JavaScript Effect System in 30 Lines or Less

    lackofimagination.org /2025/11/managing-side-effects-a-javascript-effect-system-in-30-lines-or-less/
  • Programming @programming.dev
    Aijan @programming.dev

    The Innocent Loop

    lackofimagination.org /2025/04/the-innocent-loop/
  • Programming @programming.dev
    Aijan @programming.dev

    Lessons from David Lynch: A Software Developer's Perspective

    lackofimagination.org /2025/02/lessons-from-david-lynch-a-software-developers-perspective/
  • Programming @programming.dev
    Aijan @programming.dev

    Runtime Diagnostics: Catching Bugs as They Happen

    lackofimagination.org /2025/01/runtime-diagnostics-catching-bugs-as-they-happen/

  • Writing Composable SQL using Knex and Pipelines

    Jump
  • Programming @programming.dev
    Aijan @programming.dev

    Writing Composable SQL using Knex and Pipelines

    lackofimagination.org /2024/11/writing-composable-sql-using-knex-and-pipelines/

  • Self-documenting Code

    Jump

  • Perhaps I was unclear. What I meant to say is that, whenever possible, we shouldn't have multiple versions of a field, especially when there is no corresponding plaintext password field in the database, as is the case here.

  • Self-documenting Code

    Jump

  • I appreciate the security concerns, but I wouldn't consider overriding the password property with the hashed password to be wrong. Raw passwords are typically only needed in three places: user creation, login, and password reset. I'd argue that having both password and hashedPassword properties in the user object may actually lead to confusion, since user objects are normally used in hundreds of places throughout the codebase. I think, when applicable, we should consider balancing security with code maintainability by avoiding redundancy and potential confusion.

  • Self-documenting Code

    Jump

  • Thanks for the tip. password.trim() can indeed be problematic. I just removed that line.

  • Programming @programming.dev
    Aijan @programming.dev

    Self-documenting Code

    lackofimagination.org /2024/10/self-documenting-code/
  • Programming @programming.dev
    Aijan @programming.dev

    Avoiding if-else Hell: The Functional Style

    lackofimagination.org /2024/09/avoiding-if-else-hell-the-functional-style/
  • Programming @programming.dev
    Aijan @programming.dev

    Firewalling Your Code

    lackofimagination.org /2024/08/firewalling-your-code/
  • Programming @programming.dev
    Aijan @programming.dev

    I Don't Trust My Own Code

    lackofimagination.org /2024/05/i-dont-trust-my-own-code/
  • Programming @programming.dev
    Aijan @programming.dev

    Easy Application Deployments with Linux

    lackofimagination.org /2024/05/easy-application-deployments-with-linux/