gitea
8b6ecc727d
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 10m44s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m28s
Testy / Testy warstwy bazodanowej (ochrona baz) (pull_request) Successful in 9m28s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 20s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 8s
build / build (push) Successful in 23s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m38s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m28s
Testy / Testy warstwy bazodanowej (ochrona baz) (push) Successful in 9m28s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 17s
Testy / Kontrola składni wszystkich warstw (push) Successful in 9s
ETAP 5, część pierwsza: assign_house pod wyrocznią (swe_house_pos). Osobny rodzaj błędu niż same cuspy — i od razu jeden znalazł. BŁĄD: assign_house szło ZAWSZE do przodu. Przy dużych szerokościach systemy dzielące koła wielkie mają kolejność domów ODWRÓCONĄ (przy φ=−84,3° cusp domu I wypada na 174,2°, a domu II na 165,3°) — co nie jest usterką, bo wyrocznia zwraca dokładnie te same wartości. Suma przeskoków „do przodu" wychodziła 3960° zamiast 360°, czyli każdy krok obchodził koło dookoła. Planety lądowały w złych domach dla regiomontanusa, campanusa i topocentrica: 9,7-12,5% przypadków. Błąd cichy — wykres wyglądał bez zarzutu. Kierunek bierzemy teraz z samych cuspów. TOPOCENTRIC MA JEDNAK GRANICĘ DZIEDZINY — korekta tego, co pisałem wcześniej. Cuspy są poprawne wszędzie (zgodne z wyrocznią co do zera), ale powyżej koła podbiegunowego przestają DZIELIĆ OKRĄG: cusp VII (= I + 180°) wypada przed cuspem VI i domy nachodzą na siebie. Przypisanie planety traci wtedy sens — co potwierdza sama wyrocznia, której swe_house_pos przeczy tam własnym cuspom (100% zgodności do 62°, 83,9% przy 66°, ok. 50% przy 72°; regiomontanus 100% w tych samych punktach). Odmawiamy, z jawnym fallbackiem jak Placidus i Koch. Próg jest WYPROWADZONY z warunku „dwanaście cuspów sumuje się do 360°", nie dobrany pod wynik testu — i wypada na kole podbiegunowym (zmierzone: 100% podziałów do 65°, 78% w pasie 66-67°). To inny rodzaj granicy niż u Placidusa i Kocha: tam nie istnieją same cuspy, tu istnieją, tylko nie tworzą podziału. Framework dostał pojęcie dziedziny WĘŻSZEJ niż wyroczni (NARROWER_THAN_ORACLE), zamiast wyjątku „bo topocentric": skoro wyrocznia przeczy sama sobie, nie może rozstrzygać, więc tam nie porównujemy — a nasze przypisanie jest w tym obszarze sprawdzane testem samospójności z cuspami, bez swissepha. UKŁAD STRONY — zmierzony na żywej stronie, nie na oko: - tabela porównania przy 13 systemach miała 14 kolumn i 1863 px, a stała w rodzicu bez overflow-x, więc ROZPYCHAŁA CAŁY DOKUMENT: 1713 px przy oknie 1280 px, poziomy pasek na body. Teraz ma własny kontener przewijany (dokument 1265 px, nie przewija się), a numer domu jest przyklejony do lewej, bo inaczej po przewinięciu nie wiadomo, który to wiersz. - przypis „* nie działa za kołem podbiegunowym" siedział WEWNĄTRZ <label> selektora, łamał się na dwie linie i rozciągał wiersz siatki ze 66 do 108 px, rozjeżdżając go z sąsiednim polem. Wyjaśnienie stoi teraz raz, przy checkboxach z gwiazdkami; wiersz wrócił do 66 px. - 13 checkboxów na flexie zawijało się w poszarpane wiersze — jest siatka o stałej szerokości kolumny (auto-fill, więc na wąskim ekranie kolumn mniej). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
astrololo
Aplikacja w modelu trójwarstwowym, w pełni modułowa: trzy niezależne usługi, każda komunikuje się wyłącznie z sąsiadem (nigdy „przez głowę”).
┌──────────────────────┐ formularz (w dół) ┌──────────────────────┐ zapytanie (w dół) ┌──────────────────────┐
│ PREZENTACJA (:8000) │ ───────────────────▶ │ LOGICZNA (:8001) │ ───────────────────▶ │ BAZODANOWA (:8002) │
│ strona WWW + form │ ◀─────────────────── │ reguły biznesowe │ ◀─────────────────── │ wyszukiwanie danych │
└──────────────────────┘ wyniki (w górę) └──────────────────────┘ dane (w górę) └──────────────────────┘
HTML/UI pośrednik + logika Excel(+cache) ▸ SQL
Każda warstwa to osobny katalog, osobny requirements.txt, osobny Dockerfile
i osobne README. Komunikacja przez HTTP/JSON. Warstwa zna tylko adres warstwy
bezpośrednio pod nią — nic o jej wnętrzu.
| Warstwa | Katalog | Zna w dół | Zadanie |
|---|---|---|---|
| Prezentacji | services/presentation |
LOGIC_URL |
serwuje stronę, przekazuje formularz, renderuje wyniki |
| Logiczna | services/logic |
DATA_URL |
reguły biznesowe, tłumaczenie zapytań, opracowanie wyników |
| Bazodanowa | services/data |
pliki Excela / SQL | tylko wyszukiwanie danych i podanie ich w górę |
Szybki start (Docker)
make sample # przykładowe pliki .xlsx do warstwy bazodanowej
make up # zbuduj i uruchom 3 warstwy
# otwórz http://localhost:8000
Szybki start (lokalnie, bez Dockera — zalecane)
python -m venv .env && source .env/bin/activate # venv (jednorazowo)
make install # zależności WSZYSTKICH warstw
make sample # opcjonalnie: dane przykładowe
Potem w 3 osobnych terminalach (w każdym source .env/bin/activate):
make dev-data # terminal 1 -> :8002
make dev-logic # terminal 2 -> :8001
make dev-presentation # terminal 3 -> :8000 -> http://localhost:8000
make installinstaluje zależności wszystkich trzech warstw do aktywnego venv. Testy silnika:make test. Wyczyszczenie cache:make clean-cache.
Modułowość — dowód
- Wymień prezentację (np. na SPA/React) → reszta bez zmian, kontrakt
/api/querystały. - Wymień bazę (Excel → SQL) → prezentacja i logika bez zmian (patrz niżej).
- Każdą warstwę da się uruchomić, testować i wdrażać osobno.
Wydajność warstwy Excela — cache 4-poziomowy
Dziś dane to setki dużych .xlsx, przeszukiwanych po wykrytym nagłówku i
układzie kolumn. To kosztowne, więc warstwa bazodanowa ma cache (szczegóły:
services/data/README.md):
- Schemat (L1, SQLite) — wykryty nagłówek + mapowanie kolumn zapisane raz na wersję pliku.
- Dane (L2, Parquet) — znormalizowany arkusz; kolejne odczyty 10–100× szybsze niż
.xlsx. - Zapytania (L3, in-memory TTL/LRU) — powtarzalne wyszukiwania natychmiast (łatwo podmienić na Redis).
- Odwrócony indeks (L4, SQLite) —
wartość → plik; otwieramy tylko trafione pliki zamiast skanu setek.
Unieważnianie automatyczne: klucz cache = odcisk pliku (mtime+rozmiar,
opcjonalnie sha256). Zmiana pliku → przebudowa tylko jego wpisów.
Droga na przyszłość — migracja do SQL
Warstwa bazodanowa ukrywa źródło za interfejsem DataProvider (wzorzec
Repository). Migracja:
make migrate # ETL: tym samym loaderem Excel -> tabela 'records' + indeksy
export DATA_PROVIDER=sql # przełącz całą warstwę
SqlDataProvider realizuje ten sam kontrakt /search, więc warstwa logiczna i
prezentacji nie zmieniają ani jednej linii. Odwrócony indeks z L4 (SQLite) jest
już pomostem — rozbudowa o wszystkie kolumny = docelowa baza.