Skip to content

Day 112 — Month 4 Review + Tag v0.4.0

Month 4 · Week 4 · ⬅ Day 111 · Day 113 ➡ · Journal index

🎯 Learning Objective

Close out Month 4: ship the layered REST capstone, write the week and month retrospectives, and cut the v0.4.0 release.

📚 Topics

  • Week 4 retrospective + Month 4 retrospective
  • Spaced-repetition re-quiz across the month
  • Semantic-version tagging and release notes

📖 Reading / Sources

📝 Notes

  • This is a light review day — the substance lives in the Week 4 review and Month 4 review. Re-quiz, score confidence, set next month's goals.
  • The capstone is a clean layered REST service: handlers → service → repository → domain, integration-tested with httptest + testcontainers, documented with OpenAPI, containerised, and CI-gated → [[layered-architecture]].
  • Tag the release with an annotated tag (git tag -a v0.4.0 -m "..."), which stores author/date/message — preferred over lightweight tags for releases → [[semantic-versioning]].
  • Confidence up from 3→4 across the month: comfortable building, testing, and shipping a database-backed REST API end to end.

💻 Code Examples

# Cut the Month 4 release once the project is green in CI.
git tag -a v0.4.0 -m "Month 4: web, REST APIs & databases — layered service capstone"
git push origin v0.4.0

Review-day note — no new runnable example. See the week/month reviews for the full retrospective.

🏋️ Exercises / Practice

Exercise Status Link
Week 4 capstone packages all green ✅ exercises/month-04/week-4
Re-quiz (spaced repetition) ✅ week-4-review.md

🐛 Mistakes Made

  • Almost cut a lightweight tag; switched to -a so the release carries a message and author metadata.

❓ Open Questions

  • Month 5 focus — gRPC, message queues, observability? Decide in the month review.

🧠 Active Recall (answer without looking)

  1. Q: What does the v0.4.0 tag signify in this journal's scheme?
A The completed Month 4 milestone (minor version 4): web, REST APIs & databases, capped by the layered service capstone.
  1. Q: Why prefer an annotated tag over a lightweight one for a release?
A Annotated tags (`git tag -a`) are full objects storing tagger, date, and message (and can be signed), which is what you want for a documented release; lightweight tags are just a moving pointer with no metadata.

🪶 Feynman Reflection

A month of layers, queries, tests, and pipelines compresses into one shippable thing: a service I could hand to another team with a contract (OpenAPI), a way to run it (container), and proof it works (integration tests). The v0.4.0 tag is the bookmark that says "this is the state I'm proud of."

🕳️ Knowledge Gaps

  • See the Month 4 review "Areas for Improvement" — mainly pgx specifics and CI supply-chain hardening.

✅ Summary

Month 4 is done: a tested, documented, containerised layered REST service, retrospectives written, and v0.4.0 tagged.

⏭️ Next Steps / Prep for Tomorrow

  • Day 113: kick off Month 5 — read the roadmap and set up the first project skeleton.
Time spent Difficulty Confidence
90 min 🟦⬜⬜⬜⬜ 🟦🟦🟦🟦⬜

Suggested commit: docs(journal): month 4 review and v0.4.0 release (day 112)