Nowości techniczne .182

Przez cały sierpień pracuję nad programami, które rysują, zapamiętują i odczytują kosmogramy. Po co to robię? Z powodu pewnego dualizmu. Kosmogramy na stronach AA są robione (wykreślane, rysowane) na dwa wybitnie niepodobne sposoby*:

1) Pierwszy i starszy, pochodzący z 2006 r., to robienie ich czyli generowanie jako plików graficznych, które są gromadzone (storowane – to ang. słówko najlepiej to oddaje) w pamięci serwera i na żądanie ściągane przez twoją przeglądarkę i wyświetlane na stronie. Jak każda grafika ściągalna.

2) Drugi i nowszy, opracowałem go w r. 2016 i rozwinąłem niedawno w 2021, to rysowanie techniką canvas. W tym sposobie rysunek kosmogramu jest wykreślany „w przelocie” na stronie w twojej przeglądarce, i po zamknięciu strony lub pobraniu nowej treści – znika. Tzn. istnieje tylko w ulotnej pamięci twojej przeglądarki.

(*Chociaż wyglądają prawie tak samo!)

Obecnie jestem w takiej fazie, że technologia canvas bardziej mi się podoba i chciałbym w dalszym planie głównie ją rozwijać. Już obecnie więcej robi, niż technologia serwerowych plików graficznych: rysuje harmoniki, rysuje kosmogramy podwójne (porównawcze), dopisuje numery-rzędy aspektów do ich kresek, wyświetla aspekty wzajemne (czyli tranzyty lub synastrie) lub same „wewnętrzne”. Chcę dorobić w nich rysowanie punktów harmonicznych. Łatwiej też (dużo łatwiej!) niż w programach serwerowych będzie dołączać nowe obiekty, jak węzły lub (legendarną) Lilith. Chcę zrobić łatwe przesuwanie kosmogramu w czasie o jakiś interwał, np. 1 dzień lub 1 rok. Następnym krokiem, który nie wydaje mi się trudny, jest zrobienie animacji kosmogramów. Żeby się ruszały modelując ruch planet w czasie.

Ale żeby przejść na drogę rozwijania canvas, chcę uporządkować technologie z plikami graficznymi serwerowymi.

Do tej pory, chyba od tamtego początkowego roku 2006, było tak, że w bazie danych, czyli w pamięci długotrwałej (właściwe: wiecznej, o ile ja lub ktoś nie wrzuci komend DELETE lub DROP, lub ja lub ktoś nie opłaci w terminie abonamentu serwera) są storowane tylko surowe dane czasowo-przestrzenne, czyli: data narodzin lub wydarzenia, czas godzinowy, strefa czasowa, kalendarz (czy gregoriański, czy juliański czy przed naszą erą) i szerokość-długość miejscowości. Plus tytuł, opis, kategoria i in. dodatki. Te surowe wyjściowe dane storowane dotąd były lekkie. Tzn. było ich mało, zawierały mało bajtów i do przetwarzania nie wymagały „ciężkich” zabiegów.

Kiedy ktoś chciał na ich podstawie zobaczyć kosmogram, to program na serwerze mu liczył „ascendenty” i pozycje planet i na ich podstawie rysował kosmogram, wrzucał go do piliku graficznego i przesyłał na serwer. Tak działał program chart.php, który zaniechałem dopiero parę dni temu.

W zasadzie w tym sposobie pracy nic prócz surowych (gołych) danych nie musiało być zapamiętywane.

Kiedyś tak było, ale powstawał problem taki, że pliki, wciąż rysowane od nowa, gromadziły się na serwerze i trzeba było je kasować osobnym programem. Kiedyś postanowiłem te pliki graficzne z kosmogramami wykorzystywać wielokrotnie. Bo skoro już są, to powinny jakoś pracować, prawda? W tym celu założyłem w bazie danych tabelę pod nazwą „history” (I wonder, dlaczego komputerowym obiektom daję angielskie nazwy?), która odnotowywała każde wygenerowanie kosmogramu i rejestrowała nazwę jego pliku. Od tamtej pory tylko dostatecznie długo nieużywane pliki graficzne były kasowane. Zdarzało się to też kosmogramom, które powinny być stale dostępne, np. kosmogramom z kolekcji sławnych osób. Co jeszcze: w tabeli „history” były zapamiętywane i trzymane (czyli storowane) obliczone pozycje planet. Budując to, wymyśliłem na poczekaniu nie najbardziej wygodny sposób zapisu planet, ale nie będę się nim chwalić, bo „history” od paru dni przeszła do historii, tzn. nie jest już używana.

Czyli było tak, że zaczynałem od storowania lekkich surowych danych czasowo-przestrzennych, a życie skłoniło mnie do storowania również tych ciężkich danych, tzn. obliczonych pozycji planet i osi, i nazw plików kosmogramów. (Same pliki są trzymane poza bazą danych.) Oba te rodzaje danych były gdzie indziej, w różnych tabelach, i kiedy z jakiegoś powodu był kasowany jeden zapis, drugi pozostawał i trzeba było zająć się nim osobno, itp., pominę nieinteresujące szczegóły.

W tym roku postanowiłem (a) nie zmieniać czyli nie rozwijać dalej kosmogramów serwerowych, (b) istniejącą technologię uporządkować, tzn. wszystkie dane dotyczące jednego wydarzenia (w tym: urodzenia) trzymać jako jeden rekord w jednej tabeli, która od niedawna istnieje i nazywa się „astro_data”. Do przeglądania istniejących (zasysanych z serwera) kosmogramów wraz z pozycjami planet, i do liczenia, rysowania i zapamiętywania nowych, służy jeden skrypt (program) chart_show.php. (Nie całkiem jeden, ale znów szczegóły pominę.)

Mając w bazie tabelę z pełnymi danymi o rozkładach planet (czyli obecną „astro_data”) będę mógł w oparciu o nią robić rzeczy, które były niemożliwe lub mało możliwe w dawnym systemie. Pierwszą rzecz już zacząłem robić: to tagowanie kosmogramów, czyli opatrywanie ich tematycznymi wskaźnikami. Będzie to wymagało jeszcze trochę pracy, może kiedyś więcej o tym. Następną będzie wybieranie kosmogramów według ich wartości, np. tylko te, które mają koniunkcję Słońca z Plutonem. Albo które mają którąś planetę (lub którąkolwiek) w zasięgu, powiedzmy, punktu harmonicznego „Baran z młotkiem”, 12°51' Bar. Będzie też można układać (sortować) kosmogramy w kolejności pozycji którejś planety, albo osi, albo kąta między planetami czyli według koła aspektów.* Po co? – Np. po to, żeby porównać swój lub czyjś kosmogram z natalami sławnych postaci. Albo bieżące wydarzenie z serią wydarzeń historycznych.

(*Próbowałem to już robić w poprzednich latach, ale gdy korzystałem z poprzedniego systemu storowania, padłem z powodu zawiłości.)

Czyli każda z obu technologii, serwer i kanwas, będzie rozwijana w innym kierunku i każda służyć będzie do innych celów.

Miałem na to lato plan Trzech Dużych Zmian. (1) Tagi. (2) Zmiana systemu składowania (storowania) kosmogramów. (3) Usprawnienie forum.

Tagi (#1) zrobione i działają. Prócz małych dodatków, które mogą poczekać.
Składowanie kosmogramów (#2) zrobione i działa. Prawie nic mu nie brakuje.

Poważnie zastanawiam się, czy przebudowa forum (#3) jest teraz najważniejsza, bo inne potrzeby mogą być pilniejsze.

Te potrzeby, to:
#4. Poprawki w rysowaniu na kanwasie, drawCanvas.php. Żeby program poprawnie brał pod uwagę strefę czasu zdarzenia. Bardziej logiczne zapamiętywanie wykresów z kanwasu. (Obecne jest niedopracowane.) Przesuwanie czasu, tzn, żeby można było prosto wprowadzić „czas późniejszy o 1 godz.”, dzień, miesiąc, rok itp. Filtrowanie aspektów i planet: żeby nie rysować niektórych planet lub aspektów tych planet. (Np. wyciszyć tranzyty od Księżyca.) Też chcę zrobić pewne niewidoczne dla użytkownika poprawki, które przyspieszą obliczenia. Plan dalszy: animacja horoskopów na kanwasie.
Skala trudności: dużo dłubaniny, ale mam w głowie to, co robić. Nie wymaga nowego uczenia się.

#5. Zrobić responsywność AA! Czyli, żeby dawało się z AA pracować w telefonach. Zadanie wielkie, bo...
skala trudności: hm... przerażająca. Z grubsza wiem jak to się robi lub raczej robiło 4 lata temu. (Jedna responsywną stronę zrobiłem: pensjonatdlapsow.pl. Ale to pociąga trudną do wyobrażenia masę dłubaniny, ponieważ najpierw wymagałoby to wyrównania (ujednolicenia) deklaracji CSS dla całego serwisu, a możliwe błędy, których na pewno jest wiele, przy obecnym szerokoekranowym stanie witryny są uśpione. Wyjdą na jaw i zaczną bruździć dopiero po przestawce na wąski ekran (smartfonowy). Dodam, że „strojenie” stron przy pomocy CSS jest najbardziej up..dliwą częścią tworzenia stron, ponieważ CSS jest w większości niezgodny z naszymi intuicjami. Bo komputer widzi tylko jeden wymiar, a przetłumaczanie dwóch wymiarów ekranów na jego jednowymiarowość często jest niezgodne z naszą trójwymiarową logiką. I robi się kaszana. CSS jest największym możliwym producentem kaszany ze wszystkich technologii, które pracują żeby wyświetlić stronę.

Tak, że nawet zastanawiałem się, czyby nie zlecić tego fachowcom, ale koszt.

#6. Szukarka dla kosmogramów. Wyszukiwałaby kosmogramy z naszych zbiorów według pozycji planet na osi. Czyli mogłaby wyfiltrować np. ludzi lub wydarzenia z wielkim trygonem, albo ze Słońcem w zasięgu 18° Wagi („wiedzących lepiej”), albo z aspektami Mars-Saturn („twardzieli”). Dalszy plan: porównywarka, która to samo by robiła dla dwóch kosmogramów czyli dla tranzytów lub synastrii. Z myślą m.in. o takim zastosowaniu robiłem nowe składowanie kosmogramów.
Skala trudności: koncepcyjnie i programistyczne łatwe i przyjemne, można się mylić i zacinać w szczegółach, ale to tak zawsze.

#7. Detekcja tranzytów. Program, który coś podobnego robił, częściowo zrobiłem ok. 2016. Ale przybyło mi doświadczenia i przemyśleń i czuję, że powinienem do tego wrócić. Ktoś to powinien wreszcie zrobić. Skala trudności: teraz trudna do określenia, ale duża. Kiedyś już się raz na tym zawiesiłem.

Piszę o tym, bo potrzebuję zwrotnej informacji, co z tych rozbudów wydaje się Wam ważniejsze?