Weekly Ask Anything Thread

Feel free to ask any questions you think may not warrant a post. Asking for help here is also fine.

https://redd.it/1psq6cx
@r_php

Help! React CV layout breaks when exporting to PDF (Tried html2canvas and dompdf)

Hi everyone,

I’m building a CV generator in React. The UI looks perfect on the frontend, but I’m struggling to export it to PDF.

I first tried html2canvas (with jsPDF), but the quality was blurry and the scaling was off. Then I tried dompdf on the backend, but it doesn't support modern CSS (Flexbox/Grid), so the layout completely falls apart.

Does anyone have a proven way to get a "What You See Is What You Get" (WYSIWYG) PDF export from a React component? I need it to respect my exact CSS. Thanks!

https://redd.it/1pst80w
@r_php

Weekly help thread

Hey there!

This subreddit isn't meant for help threads, though there's one exception to the rule: in this thread you can ask anything you want PHP related, someone will probably be able to help you out!

https://redd.it/1pst3z3
@r_php

Spikard v0.5.0 Released

Hi peeps,

I'm glad to announce that [Spikard](https://github.com/Goldziher/spikard) v0.5.0 has been released. This is the first version I consider fully functional across all supported languages.

## What is Spikard?

Spikard is a *polyglot web toolkit* written in Rust and available for multiple languages:

- Rust
- Python (3.10+)
- TypeScript (Node/Bun)
- TypeScript (WASM - Deno/Edge)
- PHP (8.2+)
- Ruby (3.4+)

## Why Spikard?

I had a few reasons for building this:

I am the original author of [Litestar](https://litestar.dev/) (no longer involved after v2), and I have a thing for web frameworks. Following the work done by [Robyn](https://github.com/sparckles/Robyn) to create a Python framework with a Rust runtime (Actix in their case), I always wanted to experiment with that idea.

I am also the author of [html-to-markdown](https://github.com/Goldziher/html-to-markdown). When I rewrote it in Rust, I created bindings for multiple languages from a single codebase. That opened the door to a genuinely polyglot web stack.

Finally, there is the actual pain point. I work in multiple languages across different client projects. In Python I use Litestar, Sanic, FastAPI, Django, Flask, etc. In TypeScript I use Express, Fastify, and NestJS. In Go I use Gin, Fiber, and Echo. Each framework has pros and cons (and some are mostly cons). It would be better to have one standard toolkit that is correct (standards/IETF-aligned), robust, and fast across languages.

That is what Spikard aims to be.

## Why "Toolkit"?

The end goal is a toolkit, not just an HTTP framework. Today, Spikard exposes an HTTP framework built on [axum](https://github.com/tokio-rs/axum) and the Tokio + Tower ecosystems in Rust, which provides:

1. An extremely high-performance core that is robust and battle-tested
2. A wide and deep ecosystem of extensions and middleware

This currently covers HTTP use cases (REST, JSON-RPC, WebSockets) plus OpenAPI, AsyncAPI, and OpenRPC code generation.

The next step is to cover queues and task managers (RabbitMQ, Kafka, NATS) and CloudEvents interoperability, aiming for a full toolkit. A key inspiration here is [Watermill](https://watermill.io/) in Go.

## Current Features and Capabilities

- REST with typed routing (e.g. `/users/{id:uuid}`)
- JSON-RPC 2.0 over HTTP and WebSocket
- HTTP/1.1 and HTTP/2
- Streaming responses, SSE, and WebSockets
- Multipart file uploads, URL-encoded and JSON bodies
- Tower-HTTP middleware stack (compression, rate limiting, timeouts, request IDs, CORS, auth, static files)
- JSON Schema validation (Draft 2020-12) with structured error payloads (RFC 9457)
- Lifecycle hooks (`onRequest`, `preValidation`, `preHandler`, `onResponse`, `onError`)
- Dependency injection across bindings
- Codegen: OpenAPI 3.1, AsyncAPI 2.x/3.x, OpenRPC 1.3.2
- Fixture-driven E2E tests across all bindings (400+ scenarios)
- Benchmark + profiling harness in CI

Language-specific validation integrations:

- Python: msgspec (required), with optional detection of Pydantic v2, attrs, dataclasses
- TypeScript: Zod
- Ruby: dry-schema / dry-struct detection when present
- PHP: native validation with PSR-7 interfaces
- Rust: serde + schemars

## Roadmap to v1.0.0

**Core:**
- Protobuf + protoc integration
- GraphQL (queries, mutations, subnoscriptions)
- Plugin/extension system

**DX:**
- MCP server and AI tooling integration
- Expanded documentation site and example apps

**Post-1.0 targets:**
- HTTP/3 (QUIC)
- CloudEvents support
- Queue protocols (AMQP, Kafka, etc.)

## Benchmarks

We run continuous benchmarks + profiling in CI. Everything is measured on GitHub-hosted machines across multiple iterations and normalized for relative comparison.

Latest comparative run (2025-12-20, Linux x86_64, AMD EPYC 7763 2c/4t, 50 concurrency, 10s, oha):

- spikard-rust: 55,755 avg RPS (1.00 ms avg latency)
- spikard-node: 24,283 avg RPS (2.22 ms avg latency)
- spikard-php: 20,176 avg RPS (2.66 ms avg latency)
- spikard-python: 11,902 avg RPS (4.41 ms avg latency)
- spikard-wasm: 10,658 avg RPS (5.70 ms avg latency)
-

spikard-ruby: 8,271 avg RPS (6.50 ms avg latency)

Full artifacts for that run are committed under `snapshots/benchmarks/20397054933` in the repo.

## Development Methodology

Spikard is, for the most part, "vibe coded." I am saying that openly. The tools used are Codex (OpenAI) and Claude Code (Anthropic). How do I keep quality high? By following an outside-in approach inspired by TDD.

The first major asset added was an extensive set of fixtures (JSON files that follow a schema I defined). These cover the range of HTTP framework behavior and were derived by inspecting the test suites of multiple frameworks and relevant IETF specs.

Then I built an E2E test generator that uses the fixtures to generate suites for each binding. That is the TDD layer.

On top of that, I follow BDD in the literal sense: Benchmark-Driven Development. There is a profiling + benchmarking harness that tracks regressions and guides optimization.

With those in place, the code evolved via ADRs (Architecture Decision Records) in `docs/adr`. The Rust core came first; bindings were added one by one as E2E tests passed. Features were layered on top of that foundation.

## Getting Involved

If you want to get involved, there are a few ways:

1. Join the [Kreuzberg Discord](https://discord.gg/wb8SEWvM)
2. Use Spikard and report issues, feature requests, or API feedback
3. Help spread the word (always helpful)
4. Contribute: refactors, improvements, tests, docs


https://redd.it/1psv4y8
@r_php

Spikard v0.5.0 Released

Hi peeps,

I'm glad to announce that [Spikard](https://github.com/Goldziher/spikard) v0.5.0 has been released. This is the first version I consider fully functional across all supported languages.

## What is Spikard?

Spikard is a *polyglot web toolkit* written in Rust and available for multiple languages:

- Rust
- Python (3.10+)
- TypeScript (Node/Bun)
- TypeScript (WASM - Deno/Edge)
- PHP (8.2+)
- Ruby (3.4+)

## Why Spikard?

I had a few reasons for building this:

I am the original author of [Litestar](https://litestar.dev/) (no longer involved after v2), and I have a thing for web frameworks. Following the work done by [Robyn](https://github.com/sparckles/Robyn) to create a Python framework with a Rust runtime (Actix in their case), I always wanted to experiment with that idea.

I am also the author of [html-to-markdown](https://github.com/Goldziher/html-to-markdown). When I rewrote it in Rust, I created bindings for multiple languages from a single codebase. That opened the door to a genuinely polyglot web stack.

Finally, there is the actual pain point. I work in multiple languages across different client projects. In Python I use Litestar, Sanic, FastAPI, Django, Flask, etc. In TypeScript I use Express, Fastify, and NestJS. In Go I use Gin, Fiber, and Echo. Each framework has pros and cons (and some are mostly cons). It would be better to have one standard toolkit that is correct (standards/IETF-aligned), robust, and fast across languages.

That is what Spikard aims to be.

## Why "Toolkit"?

The end goal is a toolkit, not just an HTTP framework. Today, Spikard exposes an HTTP framework built on [axum](https://github.com/tokio-rs/axum) and the Tokio + Tower ecosystems in Rust, which provides:

1. An extremely high-performance core that is robust and battle-tested
2. A wide and deep ecosystem of extensions and middleware

This currently covers HTTP use cases (REST, JSON-RPC, WebSockets) plus OpenAPI, AsyncAPI, and OpenRPC code generation.

The next step is to cover queues and task managers (RabbitMQ, Kafka, NATS) and CloudEvents interoperability, aiming for a full toolkit. A key inspiration here is [Watermill](https://watermill.io/) in Go.

## Current Features and Capabilities

- REST with typed routing (e.g. `/users/{id:uuid}`)
- JSON-RPC 2.0 over HTTP and WebSocket
- HTTP/1.1 and HTTP/2
- Streaming responses, SSE, and WebSockets
- Multipart file uploads, URL-encoded and JSON bodies
- Tower-HTTP middleware stack (compression, rate limiting, timeouts, request IDs, CORS, auth, static files)
- JSON Schema validation (Draft 2020-12) with structured error payloads (RFC 9457)
- Lifecycle hooks (`onRequest`, `preValidation`, `preHandler`, `onResponse`, `onError`)
- Dependency injection across bindings
- Codegen: OpenAPI 3.1, AsyncAPI 2.x/3.x, OpenRPC 1.3.2
- Fixture-driven E2E tests across all bindings (400+ scenarios)
- Benchmark + profiling harness in CI

Language-specific validation integrations:

- Python: msgspec (required), with optional detection of Pydantic v2, attrs, dataclasses
- TypeScript: Zod
- Ruby: dry-schema / dry-struct detection when present
- PHP: native validation with PSR-7 interfaces
- Rust: serde + schemars

## Roadmap to v1.0.0

**Core:**
- Protobuf + protoc integration
- GraphQL (queries, mutations, subnoscriptions)
- Plugin/extension system

**DX:**
- MCP server and AI tooling integration
- Expanded documentation site and example apps

**Post-1.0 targets:**
- HTTP/3 (QUIC)
- CloudEvents support
- Queue protocols (AMQP, Kafka, etc.)

## Benchmarks

We run continuous benchmarks + profiling in CI. Everything is measured on GitHub-hosted machines across multiple iterations and normalized for relative comparison.

Latest comparative run (2025-12-20, Linux x86_64, AMD EPYC 7763 2c/4t, 50 concurrency, 10s, oha):

- spikard-rust: 55,755 avg RPS (1.00 ms avg latency)
- spikard-node: 24,283 avg RPS (2.22 ms avg latency)
- spikard-php: 20,176 avg RPS (2.66 ms avg latency)
- spikard-python: 11,902 avg RPS (4.41 ms avg latency)
- spikard-wasm: 10,658 avg RPS (5.70 ms avg latency)
-

spikard-ruby: 8,271 avg RPS (6.50 ms avg latency)

Full artifacts for that run are committed under `snapshots/benchmarks/20397054933` in the repo.

## Development Methodology

Spikard is, for the most part, "vibe coded." I am saying that openly. The tools used are Codex (OpenAI) and Claude Code (Anthropic). How do I keep quality high? By following an outside-in approach inspired by TDD.

The first major asset added was an extensive set of fixtures (JSON files that follow a schema I defined). These cover the range of HTTP framework behavior and were derived by inspecting the test suites of multiple frameworks and relevant IETF specs.

Then I built an E2E test generator that uses the fixtures to generate suites for each binding. That is the TDD layer.

On top of that, I follow BDD in the literal sense: Benchmark-Driven Development. There is a profiling + benchmarking harness that tracks regressions and guides optimization.

With those in place, the code evolved via ADRs (Architecture Decision Records) in `docs/adr`. The Rust core came first; bindings were added one by one as E2E tests passed. Features were layered on top of that foundation.

## Getting Involved

If you want to get involved, there are a few ways:

1. Join the [Kreuzberg Discord](https://discord.gg/wb8SEWvM)
2. Use Spikard and report issues, feature requests, or API feedback
3. Help spread the word (always helpful)
4. Contribute: refactors, improvements, tests, docs


https://redd.it/1psv4s6
@r_php

How do you handle simple content websites when your main stack is Laravel?

I have a question for the Laravel community as the year comes to an end, just before logging off for a few days:

What tools, stack, or workflow do you use for projects that would clearly benefit from static hosting?

At Code 16, we regularly have projects like this and we’ve been developing and maintaining a tool for the past 2–3 years specifically for these cases. It let us use our Laravel stack (Laravel, MySQL, Tailwind, Alpine), deploy the website anywhere in one click and manage the content with a custom CMS. The problem it solves is quite complex, and our solution has proven to be very effective for us. We use it in production, including for our own website.

I’m genuinely curious if other Laravel developers have similar needs, and if so, how do you usually address them?

https://redd.it/1psz5gp
@r_php

Easy deployment option for a Laravel Livewire+Octane+Reverb application

Hey, I'm looking for some simple deployment option for my laravel application.

I was thinking about dockerizing everything, which would be the best thing but I've discovered some interesting options... for example VitoDeploy or Deployer.org or Coolify etc...

My application currently uses:

* Livewire

* Octane

* Reverb


I do multiple deployments of this application for each "customer". I am looking for the simplest option.

At the moment I'm using Docker+Caddy as proxy, but every time there is a small change to do I have to wait for the docker container to rebuild and restart.

VitoDeploy looks really cool but at the moment it does not support giving restricted access to only some websites to users.

What are you guys using?

https://redd.it/1pszt44
@r_php

Pay What You Want for a NativePHP Mobile Mini License through OpenCollective
https://nativephp.com/blog/pwyw-mobile-mini-license

https://redd.it/1pt2bd6
@r_php

GitHub - rcsofttech85/AuditTrailBundle: A lightweight, high-performance Symfony bundle that automatically tracks and stores Doctrine ORM entity changes for audit logging and compliance.
https://github.com/rcsofttech85/AuditTrailBundle

https://redd.it/1pt3z8p
@r_php

Why Is There So Little Laravel Content on YouTube?

This might annoy some people, but I keep noticing it.

Laravel is huge. Plenty of serious apps running on it. But when you go on YouTube, it feels almost empty unless you are watching something from the Laravel team.

Search Laravel and you mostly get official talks, release stuff, or very basic tutorials. Same few channels over and over.

Compare that to React or Next. Endless videos. Opinions. Deep dives. People arguing about architecture. People building in public.

With Laravel it feels like everyone just goes to work, builds their app, and logs off.

Why is that?

Are Laravel devs just not into making videos?
Is it because most Laravel work is agency or client stuff that you cannot really share?
Is PHP still uncool enough that people do not want to put their face on YouTube talking about it?

I love Laravel, but compared to other ecosystems, the lack of independent YouTube creators is hard to ignore and probably costs it new users.

Does PHP just not get enough views?

https://redd.it/1pt8qag
@r_php

Why no Elasticsearch support in Forge?

Just wondering if this is a legal issue, maintenance cost, or something else.
Forge supported Meilisearch but not Elasticsearch?




https://redd.it/1pt90o5
@r_php

New Job. Awesome People. Terrible Codebase Management.

I recently started at a new place. And I absolutely love 99.9% of it. My co workers are fun to work with (mainly grey beards who’ve been at it for awhile), my boss is easy going and it’s overall very relaxed. But theres a few small things that just keeps eating at me.

1. They don’t update hardly anything. I’m currently working on a large legacy codebase that was born long before my coworkers started there. Buuuttt, no one has made an effort to clean it up, update it, nothing. It works (barely), but it’s running on PHP 7.4, every dependency version is at an unmaintained level. It’s a giant spaghetti mess with absolutely zero tests. There is no style standard or formatting norm. Not to mention it’s all vanilla PHP with Apache handling the routing. It’s bad.

2. Applications they have built in the last few years in Laravel haven’t been updated since they have been scaffolded. One of which isn’t very large, but still running on Laravel 10. This one also has a slight spaghetti feel to it, but is salvageable.

We are going to be starting a rewrite of the legacy app within the next ~6 months. And I’m getting worried that it’s at risk of being a sloppy build. My lead is already talking about how he wants to restructure the directory layout so it’s “easier to maintain”. He is vehemently against frontend frame works even though a large part of the app would really benefit from client side rendering (registration flows, realtime updating tables, dashboards, heavy data things, etc).

So what I want to know is, how do I start trying to turn the ship in the right direction? My boss seems to really latch on to my ideas and likes my approach to work. But my lead is already trying to shoot down any idea I have (like just sticking to normal conventions).

Any advice on any of these ramblings would be greatly appreciated!!

https://redd.it/1pthtej
@r_php

Simple LLM Tool Calling in Laravel using Prism
https://brice.codes/posts/simple-llm-tool-calling-in-laravel-using-prism.html

https://redd.it/1pti1bt
@r_php

Simple LLM Tool Calling in Laravel using Prism
https://brice.codes/posts/simple-llm-tool-calling-in-laravel-using-prism.html

https://redd.it/1ptiy50
@r_php

Cursor is really good at Laravel. 15.8 billion tokens used and top 0.5% of usage. Most of this is Laravel apps and packages.
https://redd.it/1ptp4y5
@r_php

How to keep an API running for years: Versioning vs Evolution Pattern or another solution ?

Keeping an API working on the long run is a challenge.

Even an API we developed 3 years ago has already received dozens of updates, some of them unrelated to functionality.



To keep it working securely and optimally, we performed:

\- Updates to our dependencies.

\- Performance optimizations for improved response times.

\- Code refactoring.

\- CI/CD and unit tests to check the code.



With all of the above, one issue still remains: how to handle changes to existing endpoints?

Almost anything changed at that level can impact execution for customers.

Adding new parameters might not impact existing implementations, but changing or removing existing parameters will instantly generate errors for API clients consumers.

We brainstormed and researched ways to handle this topic efficiently.

The community mentions terms like versioning, sunsetting, and evolution pattern.

We are leaning more towards evolution pattern because we are convinced that cloning code or managing multiple branches is not sustainable on the long run.

https://www.dotkernel.com/headless-platform/evolution-pattern-versus-api-versioning/


https://api-platform.com/docs/core/deprecations/

Deprecating endpoints or individual properties from an endpoint via sunsetting sounds like the more manageable solution.

It's difficult to be 100% certain at his point, because each project is different and we must adapt accordingly.

We haven't yet worked on APIs that would benefit from versioning.

It feels like versioning fits enterprise-level projects with increased complexity.

How about you guys?

What solution do you use (or prefer) more - versioning or evolution pattern?

https://redd.it/1ptrib5
@r_php

Boost - Laravel supercharged with AI
https://youtu.be/av4TqZVOXLs

https://redd.it/1ptsrai
@r_php

Would love some constructive feedback from anyone that has the time...

So i'm working on a new greenfield project for myself based on modern php that is a full ecosystem, from philisophical methodology & standards / educational content to actual code, composable enterprise capability runtime, marketplace, etc... The ruling philosophy and methodology (brainy stuff more then code) is named 'Buildshido' and I'm basically working on applying 'Bushido' (The samurai code, "Way of the Warrior") to software development, and i'm using buildshido to build 'Shinobi' (composable enterprise capability runtime) and the rest of it's ecosystem. Ultimately hoping that the approach/etc... can replace agile/scrum/etc.. in some intances but at the end of the day i just want to help people create bad ass systems that are better then the ones of days gone past and do something cool w/ it.

I'm copying and pasting the rough drafts of the 'forward' and the 'meet buildshido' pages of my projects docs. If you have the time, please take a quick read and I'd be super grateful for any constructive feedback (not on grammar and the like, but the general concept and what not). I'll be adding more polish/etc... over the next few days in prep for my hopeful jan 1st launch/release so I'm hoping for more of the abstract thoughts/feedback but everythins welcome.

Thanks in advance!

\-----

# Forward

Ok, so you’re here and maybe you’re a little confused. Maybe you purchased this ebook thinking it was about Bushido or The Way of the Warrior and you wanted to be a samurai. If so, sorry about your luck; this ain’t that.

It’s close, though. This is actually Buildshido—which is Bushido applied to software development. It’s a set of best practices, methodologies, and design patterns proven to help build composable, self-evolving, badass software systems that outlast their creator. We directly address the biggest issues bespoke systems face: quickly becoming obsolete/legacy, the inability to keep up with changing business requirements, and the “enshittification” that happens when scope creeps and code becomes a spaghettified nightmare.

Oh, and if you haven’t noticed, the language is a little rough. While I try to keep it professional, we’re adults here and I’m not the best guy for prim and proper presentations. I’m the guy in the trenches, blood up to my elbows as I wade through an ocean of chitin and bug remains after a doomed Friday launch. I’m the one trying to keep production from bursting into flames and our churn below 100% because some FNG decided they could just “wing it,” bypass policies, and push a half-assed hotfix without a basic understanding of how things function.

Here in the mud, in the trenches, shit gets real. As such, I stay real. I keep a 100% no-bullshit approach with directness and honesty that is a hell of a change of pace after a week of meetings full of corporate lingo and buzzword bullshit.

# What the Fuck is This?

If you’re looking for a dry, academic breakdown of Design Patterns or a “Hello World” tutorial for the latest trendy JavaScript framework, put this book down and walk (better yet, run) TF away. You’re wasting your time, and you’re wasting mine. There’s no way that ends well for either of us.

This isn’t a textbook. It’s a manifesto for the survivors, the grinders, and the architects who are tired of building digital landfills for corporate ghouls. It’s a path that will turn you into the type of engineer that doesn’t waste their potential or inflict the anguish of endless rewrites on future generations. This is a philosophy for warriors—the crazy bastards making it happen when everyone else thinks it can’t be done. This is how the real ninjas get shit done.

# The Reality

Most software development is a lie. We’re taught to build rigid, fragile boxes and call it “Enterprise Architecture.” We’re told to follow “best practices” written by people who have never had to keep a server running while their world was falling apart.

Buildshido is about a different path. It’s the intersection

of the Bushido Code and modern, composable, intelligent, self-evolving software. It’s about building systems that don’t just “run”; these systems have the grit to survive, optimize, and eventually, evolve themselves or create entirely new, improved versions of themselves.

# Social Cause: Project BooBoo Personal Dedication

This book and the entire Shinobi Ecosystem is dedicated to Samantha, my Boo Boo. She was the amazing woman who reignited my spark and had her own snuffed out way too soon.

She was my rock. She was the one in the trenches with me when the lights were flickering and the decisions were life-or-death. We didn’t have the luxury of “clean code” or “agile workflows”; we had the raw necessity of survival.

This world could not contain an angel like her. She was taken on December 10th, 2025, from heart failure in her sleep—as I sat a few feet away working on the initial draft of all this.

She was the most generous, kind, and amazing person I’ve had the pleasure of knowing, made of stuff harder than the steel in a samurai’s sword. She showed me what love was when I was unlovable. Her day-to-day followed those core tenets of Bushido in their purest sense: Justice, Courage, Compassion, Respect, Honesty, Honor, Loyalty, and Self-Control.

In an attempt to continue her legacy of helping people, a portion of every cent made from this book or the Shinobi Ecosystem goes to Project BooBoo, a foundation built on “Direct Action.”

No red tape. No corporate overhead. We provide resources to people who are one bad break away from the edge—the people in the trenches who are doing what they have to do to keep their own fire burning. We venture into the mud to help pull out those being eaten alive by it. It is a mission to restore the light lost when the world lost such an amazing soul, trying to do the memory of my beloved BooBoo some measure of honor and justice.

If I can be half as good of a person as she was, I’ll consider my life a success and my legacy secure.

>

Here’s to you, BooBoo!


\-------

# Meet Buildshido

You might be asking how many sleepless nights it took of hard narcotics to come up with the idea of applying the samurai code of Bushido to software development and having a crazy ass idea like Buildshido. The answer is: too many (minus the narcotics—those were baseless allegations!).

The really crazy part of Buildshido is that it works. Sure, it’s not a direct 1-to-1 translation of “How to kick ass as a samurai” to “How to make composable enterprise systems,” however, with multiple decades of development experience in the enterprise arena, I’ve managed to take the ancient code of the Samurai—Bushido—and drag it kicking and screaming into the digital age.

I managed to take those eight timeless virtues (Justice, Courage, Compassion, Respect, Honesty, Honor, Loyalty, and Self-Control) and learn to wield them as the scaffolding for software systems and life.

Let’s keep it real: staring at a list of virtues while your database is shitting itself doesn’t help much if you don’t know what the fuck to do other than trying not to be a POS. That’s where the magic comes in. We don’t worship the virtues; we execute them through a tactical framework I call The Three Gates.

>

# The Three Gates: Acceptance, Attitude, and Action

# 1. Acceptance The Zero-State

This is the entry point. You cannot fix a problem you refuse to acknowledge. Acceptance isn’t about liking your situation; it’s about seeing the “ocean of chitin” for exactly what it is. It’s acknowledging that your code has debt, your server has limits, and your timeline is fucked.

When you stop fighting reality, get your head out of your ass, and see clearly, only then do you have the power to do a damn thing about it. While you are in a useless state of denial, or busy tolerating bullshit you shouldn’t be, you are helpless to actually kick ass. Bathing in the blood of your enemies requires you to first acknowledge where they are standing.

# 2. Attitude The Architect’s Perception

After you accept reality—warts, scars,