From c3d3fc3b007c1713608f16491309d53ce990c7e8 Mon Sep 17 00:00:00 2001
From: Benjamin Palko <benjaminpalko@hotmail.com>
Date: Thu, 26 Feb 2026 16:11:42 -0500
Subject: [PATCH] unpublish

---
 .../posts/godot-dotnet-with-spacetimedb.md    | 22 +++++++++----------
 src/lib/posts/the-art-of-simple-design.md     | 18 +++++++--------
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/src/lib/posts/godot-dotnet-with-spacetimedb.md b/src/lib/posts/godot-dotnet-with-spacetimedb.md
index d5ecc2b..d4b9aa5 100644
--- a/src/lib/posts/godot-dotnet-with-spacetimedb.md
+++ b/src/lib/posts/godot-dotnet-with-spacetimedb.md
@@ -8,7 +8,7 @@ image:
 date: '2026-1-22'
 categories:
   - development
-published: true
+published: false
 ---
 
 I've been on and off again experimenting with Godot since the great Unity [controversy of 2023.](https://www.geekwire.com/2023/heres-why-so-many-video-game-developers-are-suddenly-abandoning-the-unity-engine/) At the time Godot came up pretty quickly as the open-source alternative, I'll spare you the history lesson we are here to talk SpacetimeDB! If you found this article I assume you already know what SpacetimeDB is.
@@ -60,16 +60,16 @@ services:
 
 ```json
 {
- "name": "massive",
- "scripts": {
-  "database:up": "docker compose up -d",
-  "database:down": "docker compose down",
-  "database:publish": "spacetime publish --project-path server massive",
-  "database:generate": "spacetime generate --lang csharp --out-dir client/module_bindings --project-path server"
- },
- "devDependencies": {
-  "@types/bun": "latest"
- }
+	"name": "massive",
+	"scripts": {
+		"database:up": "docker compose up -d",
+		"database:down": "docker compose down",
+		"database:publish": "spacetime publish --project-path server massive",
+		"database:generate": "spacetime generate --lang csharp --out-dir client/module_bindings --project-path server"
+	},
+	"devDependencies": {
+		"@types/bun": "latest"
+	}
 }
 ```
 
diff --git a/src/lib/posts/the-art-of-simple-design.md b/src/lib/posts/the-art-of-simple-design.md
index eb800e6..3f2ec04 100644
--- a/src/lib/posts/the-art-of-simple-design.md
+++ b/src/lib/posts/the-art-of-simple-design.md
@@ -7,7 +7,7 @@ image:
 date: '2026-1-22'
 categories:
   - development
-published: true
+published: false
 ---
 
 Project degradation as a result of contextual shifts during development is a common occurrence, contextual shifts are a natural part of the project development process, and we should always try to account for them in our design and as we develop. Some design frameworks like IDesign seek to solve this through functional decomposition, by reducing a project to a set of functional interactions, i.e a data access calls, business logic, orchestration, etc... This is certainly the correct path, but in the process of trying to develop a perfect solution, often falls into the pit of overdesign with strict naming conventions and complicated architecture. This actively becomes a hindrance to development cadence, the problem we were seeking to fix.
@@ -16,17 +16,17 @@ A strong design methodology should not be a strict instruction manual, but an in
 
 ```typescript
 interface User {
- id: string;
- name: string;
- email: string;
- hashed_password: string;
+	id: string;
+	name: string;
+	email: string;
+	hashed_password: string;
 }
 
 interface IUserAccessor {
- findUser(user_id: string): Promise<User>;
- createUser(user: User): Promise<User>;
- updateUser(user: User): Promise<User>;
- deleteUser(user_id: string): Promise<boolean>;
+	findUser(user_id: string): Promise<User>;
+	createUser(user: User): Promise<User>;
+	updateUser(user: User): Promise<User>;
+	deleteUser(user_id: string): Promise<boolean>;
 }
 ```