You are browsing as a guest. Sign up (or log in) to start making projects!

babali

@babali

Joined June 6th, 2026

  • 3Devlogs
  • 3Projects
  • 1Ships
  • 1Votes
Open comments for this post

1h 4m 20s logged

Nyx — Dev Log

Date: 2026-06-06
Time: ~5+ hours
Focus: Backend architecture, system boundaries, documentation
Use of Ai: Only used to polish the devlog from my drafts.


Summary

This session was split into two parts:

  • ~4+ hours: architectural thinking (partially unrecorded due to lapse)
  • ~1 hour: Markdown documentation and formalization

The main output was system design, not implementation.


Phase 1 — Architecture (~4+ hours, partially lost)

Designed Nyx as a Spring Boot backend with strict epistemic constraints.

Key decisions:

  • Backend is the authoritative system layer
  • Frontend is read-only
  • Domain-first structure replaces controller/service/repo layering
  • Core entities:
    • location
    • index
    • snapshot
    • comparison

Epistemic boundary defined

Nyx only:

  • derives normalized light indices from satellite data
  • performs comparative geographic reasoning
  • maps to heuristic scales
  • produces order-of-magnitude outputs

Nyx does NOT:

  • simulate sky conditions
  • predict human perception
  • output observational truth

System design additions

  • PostgreSQL + PostGIS persistence layer
  • Flyway migrations
  • JPA/Hibernate ORM
  • Event-driven pipeline (replacing PipelineRunner)
  • Observability (metrics, tracing, logging)
  • Security layer (rate limiting, API keys)

Phase 2 — Documentation (~1 hour)

Converted design into structured Markdown system.

Added:

  • CLAIM_CHARTER
  • METHODOLOGY
  • DATA_SOURCES
  • LIMITATIONS
  • GLOSSARY
  • ONTOLOGY
  • VALIDATION

Architecture decisions:

  • ADR system introduced
  • OpenAPI-first API design
  • Domain-driven backend structure finalized
  • Infrastructure + deployment roadmap defined

Outcome

Nyx now has:

  • Spring Boot backend architecture
  • strict claim boundary system
  • domain-first design
  • event-driven pipeline plan
  • persistence + infrastructure design
  • full documentation framework

Next steps

  • Scaffold backend project
  • Implement ClaimGuard
  • Define OpenAPI spec
  • Build persistence layer
  • Start ADR-001

Nyx — Dev Log

Date: 2026-06-06
Time: ~5+ hours
Focus: Backend architecture, system boundaries, documentation
Use of Ai: Only used to polish the devlog from my drafts.


Summary

This session was split into two parts:

  • ~4+ hours: architectural thinking (partially unrecorded due to lapse)
  • ~1 hour: Markdown documentation and formalization

The main output was system design, not implementation.


Phase 1 — Architecture (~4+ hours, partially lost)

Designed Nyx as a Spring Boot backend with strict epistemic constraints.

Key decisions:

  • Backend is the authoritative system layer
  • Frontend is read-only
  • Domain-first structure replaces controller/service/repo layering
  • Core entities:
    • location
    • index
    • snapshot
    • comparison

Epistemic boundary defined

Nyx only:

  • derives normalized light indices from satellite data
  • performs comparative geographic reasoning
  • maps to heuristic scales
  • produces order-of-magnitude outputs

Nyx does NOT:

  • simulate sky conditions
  • predict human perception
  • output observational truth

System design additions

  • PostgreSQL + PostGIS persistence layer
  • Flyway migrations
  • JPA/Hibernate ORM
  • Event-driven pipeline (replacing PipelineRunner)
  • Observability (metrics, tracing, logging)
  • Security layer (rate limiting, API keys)

Phase 2 — Documentation (~1 hour)

Converted design into structured Markdown system.

Added:

  • CLAIM_CHARTER
  • METHODOLOGY
  • DATA_SOURCES
  • LIMITATIONS
  • GLOSSARY
  • ONTOLOGY
  • VALIDATION

Architecture decisions:

  • ADR system introduced
  • OpenAPI-first API design
  • Domain-driven backend structure finalized
  • Infrastructure + deployment roadmap defined

Outcome

Nyx now has:

  • Spring Boot backend architecture
  • strict claim boundary system
  • domain-first design
  • event-driven pipeline plan
  • persistence + infrastructure design
  • full documentation framework

Next steps

  • Scaffold backend project
  • Implement ClaimGuard
  • Define OpenAPI spec
  • Build persistence layer
  • Start ADR-001

Replying to @babali

0
18
Ship Pending review

The Little Austronaut is a modular Slack bot that brings fun to your workspace. Hit /dsb-ping to check latency, /dsb-catfact for random cat facts, /dsb-joke for laughs, or /dsb-help to see what's available.

What makes it clean:

Each slash command is its own class — super easy to add new ones.
Smart error handling that doesn't break the bot or spam users with stack traces.
Dynamic help that always knows what commands exist.
Consistent ack / respond pattern throughout.
Why you should care:
Built this to show how to structure a Slack bot without spaghetti code. Commands are modular, errors are handled gracefully, and adding new features takes minutes, not hours. Perfect starter template for anyone building Slack bots.

Tech: Node.js, Slack Bolt, Axios, Socket Mode.

To run it: Grab your Slack bot and app tokens, drop them in .env, run npm start, and start slashing.

Try project → See source code →
Open comments for this post

34m 29s logged

Hi There,

Finished the Stardance Slack Bot,

Did a little cleanup, moved each slash command into its own class under commands.

Made a BaseCommand so they all behave the same and don’t scream at errors.

Pulled the registration logic out of index.js and now it just loads and registers the command objects. Now way cleaner and less spaghetti.

Wrote (thanks gpt) a tiny README.md so whoever clones this isn’t lost at 2am.

I tweaked the command logic compared to the tutorial.

Thanks for reading :)

Hi There,

Finished the Stardance Slack Bot,

Did a little cleanup, moved each slash command into its own class under commands.

Made a BaseCommand so they all behave the same and don’t scream at errors.

Pulled the registration logic out of index.js and now it just loads and registers the command objects. Now way cleaner and less spaghetti.

Wrote (thanks gpt) a tiny README.md so whoever clones this isn’t lost at 2am.

I tweaked the command logic compared to the tutorial.

Thanks for reading :)

Replying to @babali

0
3

Followers

Loading…