Skip to content
This repository has been archived by the owner on Aug 7, 2023. It is now read-only.

Latest commit

 

History

History
173 lines (138 loc) · 4.97 KB

teodor.org

File metadata and controls

173 lines (138 loc) · 4.97 KB
Raw

Teodor

2023-03-28

notater

Oddmund, Lars og Richards mikroblogg

  1. Hva gjør du akkurat nå?
  2. Finner du kvalitet i det?
  3. Hvorfor / hvorfor ikke?

Olorm.iterate.no

Bb tui
git pul l --rebase
FZF for å velge builder
$EDITOR
Save
Git commit og push

#olorm på Slack Teodor følger opp manuelt i starten, backup fra Magnus (?)

retro

funka det!

  • Var nok jobb i å ta CLI-biten.
  • Og ignorerer støtte for flere input-formater for nå.
  • Mulig IKI-gjenbruk her er … lite / optimistisk.

2023-03-30

prat med Lars

  1. lars sa han var villig til å prøve en uke
  2. tirsdag eller onsdag etter lunsj etter påske fungerte sannsynligvis bra for lars

Ikke hørt med Oddmund og Richard ennå. Håper vi kan finne et tidspunkt der alle kan være på kontoret.

2023-04-16

Åhh, kjempefornøyd med olorm.lib!!!

Dette synes jeg begynner å bli skikkelig bra.

Og clerk og babashka/fs!

❤️

meeeen

Jeg har hardkodet meg inn i at URL til OLORM-er skal være

/p/$OLORM

ooog nå vil jeg ha

/o/$OLORM

, selvfølgelig.

men meen

jeg kan jo bare fikse routeren, og la filene ligge?

hmm.

Jepp, vi gjør det sånn

2023-05-14

status

  1. jals starter tirsdag
  2. dagens arkitektur er laget for at OLORM er verktøyet, plattformen og kohorten
  3. jeg vil ha:
    1. én plattform (mikrobloggeriet)
    2. CLI per kohort
    3. forskjellige kohorter.

Skisse:

  • mikrobloggeriet.api - kjernelogikk.
    • client – hvilken mappe, etc.
    • document – en olorm, en jals, etc.
  • mikrobloggeriet.olorm.cli - OLORM CLI
    • bruker mirkobloggeriet.api
  • mikrobloggeriet.jals.cli
    • bruker =mikrobloggeriet.api

Plan:

  1. Skriv mikrobloggeriet.api
  2. Prøv å migrere over olorm.api til å bruke mikrobloggeriet.api.
    1. må hardkode inn en default API-klient for OLORM for å få det til å funke.

2023-05-15

status

tror jeg kom fram til noe jeg liker i går. To nye ting:

;; a cohort is a group of people who are writing together

:cohort/name "OLORM"                                  ;; user facing name (unique)
:cohort/ident :olorm                                  ;; identifier (unique)
:cohort/repo-subdir "o"                               ;; where cohort docs are on disk (unique)
:cohort/server-dir "o"                                ;; where cohort docs are on the server (unique)
:cohort/repo-path  "/home/teodorlu/dev/iterate/olorm" ;; where the repo is

;; a doc is a written thing
:doc/number 42       ;; document number, starts at 1
:doc/slug "olorm-42" ;; the documents slug is used on the URL. Globally unique
:doc/cohort :olorm   ;; refers to a cohort ident

goals for today

Want to:

  1. Land new abstraction that enables us to support multiple cohorts in a nice way
  2. and must be prepared for the start of the new cohort tomorrow.

step: document proposed data model in the right place

TODO

status:

  1. dokumentert ny måte å installere på. README er ish OK.
  2. har fått et nytt modulhierarki jeg har tro på.

mangler:

  1. mikrobloggeriet.olorm-cli peker til den gamle olorm-implementasjonen.
  2. mikrobloggeriet.jals-cli lager olormer (all koden er kopiert)

interlude

jeg har lyst til å endre navn fra lib til domainlogic.

step: olorm peker til rett olorm-backend

  1. [X] mikrobloggeriet.olorm-cli peker til den gamle olorm-implementasjonen.
    1. fikset!
  2. [ ] mikrobloggeriet.jals-cli lager olormer (all koden er kopiert)

2023-07-12

Hvordan får jeg testet disse greiene?

Det hadde vært fint med CI.

  1. Splitte koden i logikk som kan testes og kjøring av effekter
  2. Skriv tester på logikken
  3. Gå i prod med mindre usikkerhet.

Gjør det lettere å refaktorere, lettere å vite at jeg ikke brekker ting.

Lettere å refaktorere er kanskje hovedfordelen. 🤔

Eksempel: sjekke hva slags git-kommandoer som har blitt kjørt i forskjellige varianter kommandoer

--no-git og --no-edit

Nå er koden splittet i logikk og kommandoer! Hva med testing?

Dette var litt gøy.

Så, hva med testing? Nå kan det skrives tester!

Men. Jeg lurer på om jeg har splittet opp litt vel mye. Trenger egentlig ikke alle disse prosjektene. Kan heller ha:

  1. En krysskompatibel babashka-jvm-dings
  2. Litt JVM for å kjøre selve serveren.

Og det kan jeg splitte i forskjellige mapper:

  • src/ - krysskompatibelt
  • src-serve/ - JVM-servergreier

Da får jeg slettet en masse mapper.

I dag har jeg flere mapper:

  • cli/ - CLI-funksjonalitet
  • lib/ - jvm/bb-ting
  • olorm-cli/ - ekstra CLI-funksjonalitet som skal slettes
  • serve/ - serveren

Så det jeg vurderer er å fjerne alle toppnivå-prosjektene, og heller jobbe med én bøtte kildekode. Kan eventuelt beholde serve/ inntill videre, og legge til en avhengighet oppover med {:local/root ".."}.

I samme slengen vil jeg helst endre strukturen til mikrobloggeriet. mikrobloggeriet.serve, mikrobloggeriet.cli, mikrobloggeriet.documents. Eventuelt mikrobloggeriet.api i stedet for mikrobloggeriet.documents.