@nooga: vaprowave? podrzuć jakiś youtube

@jedi: dawno temu słuchałem sporo post-rocków, trochę bardziej w kierunku "GY!BE" może niż "God is..."

http://noizz.pl/big-stories/1995-rok-to-ostatni-rok-gdy-wszystko-bylo-estetyczne-tlumaczymy-czym-jest-vaporwave-w/1k8c5g9

@szymon_k: ^^

😄

zartowalem ;d

serio? mega ciekawa estetyka moim zdaniem

proste

Jak już mówimy o postrzeganiu rzeczywistości to ja się zapisuję do szkoły Kanta — tj. że nie możemy postrzegać rzeczywistości samej w sobie, tylko nasza świadomość zbudowana jest w pewien sposób który pozwala nam doświadczać świata empirycznie i na tej podstawie budować sobie jego jakiś fenomenologiczny obraz. I prawdy samej w sobie nie jesteśmy w stanie nigdy poznać, ale możemy budować sobie coraz lepsze teorie w jakiś sposób ją aproksymujące.

A jak chodzi o muzykę to postrock ma mą okejkę, choć progrock też fajny.

A bardziej programistycznie — Wy tutaj jak bardzo w komponenty?

rozsądnie

czasem wcale czasem bardzo

zrobiłem jedną apkę na componentach sierry i jest to fajowa opcja, ale odnoszę wrażenie, że jeśli by miała być naprawdę duża to szukałbym czegoś innego

nie wiem czego

u sierry jak wstaje ci system i gdzieś skopiesz inicjalizację to dostajesz np. mega gigantyczne error message

i weź kmiń co się dzieje

no tak, ale to tylko jak popsujesz główny komponent nie?

ja jak ustawiałem sobie komponenty jak chciałem

to potem tego nie ruszałem

którykolwiek

a (go) i działa to super sprawa moim zdaniem

używałem kilka razy i na razie zostaje przy tym

No ja właśnie mam taki problem, że nie umiem się zdecydować jakie stężenie componenta jest dobre

Przykładowo w mojej inżynierce zrobiłem coś takiego, że są komponenty domenowe udostępniające jakieś handlery i komponenty, nazwijmy to architekturalne, które ze swoich zależności filtrują te interesujące je po jakimś protokole i składają z nich np. jakiś dispatch function czy coś. Przykładowo

https://gitlab.com/jaen/thesis-code-new/blob/master/src/thesis/backend/components/command_dispatcher.clj#L58-70

Bierze, zbiera, wrzuca do multimetody którą potem dispatchuje

A inne komponenty udostępniają handlery — https://gitlab.com/jaen/thesis-code-new/blob/master/src/thesis/backend/components/logic/users.clj#L86-88

I z jednej strony jest to spoko

Bo jak chcesz dodać nową rzecz to ją piszesz, wpinasz i Shit Just Works™

Ale czuję się prawie jakbym pisał Javę z za dużą ilością nawiasów

I mam wrażenie że to jest z kolei przesada z taką segregacją na komponenty

Zwłaszcza, że wtedy albo a) praktycznie każda funkcja musi dostawać interesujące ją komponenty jako argumenty, albo b) musisz je pisać w ciele defrecord aby się domknąć nad polami.

I tak źle, i tak niedobrze.

No i nie wiem jak to lepiej ogarnąć : F

robisz komponent jak potrzebujesz przechować jakiś stan

tyle

nie robisz komponentu jak nie potrzebujesz trzymać stanu

Okej, to brzmi jak jakaś heurystyka

Tylko się wtedy traci to automatyczne składanie systemu jak tylko dołożysz klocek. Chyba że to overengineering żeby coś takiego robić? Kojarzę że podobno niektórzy używają graph z prismaticowego plumbing do podobnych rzeczy, ale nie mam pojęcia jakby to mogło wyglądać w praktyce.

Dobra architektura jest trudna : |

nie heurystyka, komponenty są po to żeby trzymać stan

przeczytaj manuala do komponentu s. sierry

ja sie przestalem martwic i pokochalem mount

oo, obadam przy najbliższej okazji

No ale to jednak jest jakaś heurystyka chyba — jeżeli trzymasz stan, to stwórz komponent. W przeciwnym wypadku nie. Tylko mam wrażenie, że enkapsulacja stanu to nie jedyny zysk z componenta — osobiście możliwość opisania systemu jako grafu zależności w jednym miejscu, z zależnościami i ko-zależnościami, opisania komponentu jako funkcji jego zależności i łatwiej podmiany takiego klocka, wydaje mi się równie przydatna. Całkiem możliwe że te rzeczy można też bez componenta osiągnąć i ograniczyć go tylko do stricte zarządzania stanem, ale nie jestem w tym momencie pewien jak by to można było dokładnie zrobić. Mount niby jest ciekawy, ale jakoś mu nie do końca ufam (ot choćby dlatego, że zależności są implicite w strukturze przestrzeni nazw i nie można mieć kilku instancji takiego komponentu), a nie miałem go okazji spróbować w czymś większym, żeby się przekonać czy słusznie czy nie. Podobnie bounce (https://github.com/jarohen/bounce) wydaje mi się ciekawy, ale też nie miałem okazji go w czymś większym spróbować.

To jest w ogóle trochę śmieszne, że mam z tym problem, bo nie jestem zatwardziałym programistą obiektowym ani nic, ale trochę nie umiem ugryźć jak do tego sensownie podejść.

no to troche wyglada jak obiektowka pozniej

mount jak na razie mnie nie ugryzl

chociaz zdaje sobie sprawe z tradeoffów i różnic między nim a componentem