Developer Sandbox
Personal Development Environment, Project Catalog, and Technical Knowledge System
Personal development environment for projects, references, experiments, learning, and technical knowledge.
The Developer Sandbox is a personal interface used to organize and display projects created through ongoing development learning and experimentation. It also serves as a technical reference system, project catalog, and experimental workspace.
The Developer Sandbox is a personal interface used to organize and display projects created through ongoing development learning and experimentation. It also serves as a technical reference system, project catalog, and experimental workspace.
Project Overview
The Developer Sandbox is a personal development environment, technical reference system, project catalog, and experimental workspace. It is also a personal interface used to display projects created as part of ongoing learning and development work. It was built to bring different forms of development work into one organized system rather than maintaining a collection of unrelated project pages and reference files.
The Sandbox is designed to hold complete projects, development experiments, Rosetta Stone language comparisons, reference guides, data work, technical documentation, and other material that may need different presentation structures while still belonging to the same overall system.
Instead of forcing every item into one rigid page template, the system separates the identity of an item from the content used to construct its page. This makes the Sandbox useful both as a portfolio and as a long-term development knowledge base.
Purpose & Learning Objectives
Purpose
The purpose of the Developer Sandbox is to provide one organized environment for building, documenting, reviewing, and displaying development work created during continued technical learning.
Rather than maintaining unrelated project pages, reference files, and experiments separately, the Sandbox provides a common system where different types of development work can be cataloged and presented while still allowing each item to use its own content structure.
Learning Objectives
- Design and maintain a structured project from frontend interface through data storage.
- Use TypeScript to manage structured application data and editor logic.
- Use Node.js for local server-side application logic.
- Design and query a relational SQLite database.
- Model relationships between records, categories, tags, technologies, and content.
- Implement database-backed CRUD and content-management workflows.
- Separate application data from presentation markup.
- Create reusable Parent and Child content structures for different page layouts.
- Use Git and GitHub to maintain and present the project source.
Technologies
Project Details
Public Interface. A static HTML, CSS, and JavaScript interface is used to browse and display projects, reference guides, experiments, and other development work.
Local Editor. A browser-based TypeScript editor provides the authoring interface used to create, update, organize, preview, and manage Sandbox content.
Application and Database Layer. A local Node.js server connects the editor to an SQLite relational datastore and handles database reads, writes, searches, and structured content operations.
Content Model. Main entries are stored as records and can be related to categories, tags, and technologies. Detailed page content is stored separately as Parent and Child Content Nodes, allowing different projects and resources to use different presentation structures while remaining part of one system.
Version 1 Implementation Complete
The first complete working architecture is implemented and remains the active foundation.Version 1 established the Sandbox as a working application rather than a static portfolio mockup.
The project remains active because new projects, references, labs, data structures, and refinements will continue to be added.
- Static public interface for projects, Rosetta Stones, reference guides, labs, system documentation, and database documentation.
- Local TypeScript editor served through a Node.js application.
- SQLite relational datastore with records, categories, tags, technologies, relationships, and hierarchical content nodes.
- Database-backed create, edit, reorder, delete, search, preview, and SQL-batch workflows.
- TypeScript generator that produces static project and collection pages from structured data.
- Read-only public database documentation/viewer concept with local editing kept separate.
- Shared rendering structures for NAV, DISPLAY, STANDARD, SPLIT, GRID, and CODE content.
- Populate the catalog with real projects, labs, and Rosetta Stone implementations.
- Expand technical reference material as new technologies are learned or revisited.
- Refine renderer parity, accessibility, diagnostics, and content-authoring ergonomics.
- Use the Sandbox as a durable record of implementation decisions and learning evidence.
Implemented Architecture
The current working layers and their responsibilities.Design Evolution
Important architectural decisions that changed while the system became more capable.The early design used a human-readable .sdb key/value format with lightweight markup tokens.
As categories, tags, technologies, relationships, hierarchical nodes, searching, and editing expanded, SQLite became the stronger primary datastore.
The custom-format idea remains useful as a future import/export or document-format experiment rather than the main database.
- Individual project repositories remain independent from the Sandbox repository.
- Sandbox stores catalog and documentation data rather than absorbing every project's source code.
- The local editor is an authoring tool; the public site remains static and read-only.
- Structured data can be rendered differently without rewriting project identity.