Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - BoneFlute

Stran: [1] 2 3 ... 110
1
Co takhle?

A dukaz pro to mas? Nebo to je tve prani aby to tak bylo? Pripadne bych prosil zdroj. Protoze ty jsi z toho udelal Schrodingerovu kocku ted.
Jaká Schrodingerova kočka? Jakej důkaz? Důkaz čeho? Se obávám, že ti vůbec nerozumím.

Jirsák je tradičně agresivní, ty zase línej přemejšlet, a tak jste se tu krapet porafali. Přišlo mi užitečné vytáhnout z toho marastu invektiv to podstatné. Přirozeně přemýšlet už musíš sám.

2
Co takhle?

V šabloně se má číst stav/props. Díky tomu, že to nejsou funkce, React ví, že že je to cajk. Když je ta prop computed, tak React ví, že je computed, a tranzitivně projde všechen stav, který ta prop zasahuje. Tím má React vše pod kontrolou, a je schopen udělat diff a překreslit jen něco. Pokud není tato podmínka splněna, nemůže React spolupracovat. Tudíž není překvapující, že se to bude chovat neoptimalizovaně. Není to chyba Reactu, je to šikovné chování, vzhledem k tomu, že porušujete pravidla - ačkoliv já bych tam vyřval výjimku a vůbec se s váma nebavil.

Poučení:
- nepoužívejte v šabloně funkce
- v prvé řadě používejte to, co je v dokumentaci doporučované, funkce tam doporučované nejsou
- nevyvozujte kategorické závěry, když nedosáhnete nohama na dno

3

Co vsak ale musim udelat (resp. jeste pred 3 lety (v javascriptu pravek?) jsem musel udelat) v te dobe v nejpopularnejsim frameworku na svete, v Reactu, je tenhle strasny a sileny hoven:
...
Tzn. musel bych kompletne vytvorit znovu cely objekt, aby to bylo jak to React vyzaduje.
Je to tak. V čem je problém? React ctí funkcionální paradigma. Má to své výhody i nevýhody. Určitě by se nějaká ta syntax dala vylepšit. Ale skutečnost, že vytvoří nový celý objekt je očekávané a požadované chování.

Jak jako ze vytvori?  To TY MUSIS VYTVORIT cely novy chain objektu od korenoveho az po ten nejvice nested kteremu jsi modifikoval value.

A jak jako ze cti funkcionalni paradigma, co to s tim ma spolecneho? To ze nezaobali state, a neumi si automaticky nasledne zjistit co presne se mu zmenilo, nema nic co spolecneho s funkcionalnim paradigmatem, to je proste jen strohost a spartanskost te knihovny.

Btw tak jak se to dela ve vue, tak z pohledu vyvojare to tak bylo i u desktopovych UI. Stacilo naprimo zmenit nejake field a hotovo. To k cemu nutu react je uplne brutalni overkill. Porad nemuzu uverit svym ocim, nechapu proc tohle chteji vsichni pouzivat.

Jako s tim Reactem se realne nejak neda dela DDD, protoze bych pro modifikaci kazdeho jednoho fieldu v domene snad musel mit udelany vyse uvedeny straslivy setState

Nerozumíme si.

React ctí funkcionální princip. To znamená, že když chceš modifikovat field, tak musíš vytvořit celej novej objekt. Tak to prostě je. Jestli si ho budeš tvořit ručně, nebo si na to vytvoříš nějaký nástroj, nebo začneš používat nějaký již existující - to už je jinej příběh.

V čem si dále nerozumíme, je to, že:
Stacilo naprimo zmenit nejake field a hotovo.
Tohle my nechceme dělat. A na tobě je zjisit proč to nechceme dělat, jaké k tomu máme důvody.

4
Nasledne, co ocekavam ze muzu udelat:

Kód: [Vybrat]
myDomain.zaznamyPotravin
   .filter(zaznam => zaznam.datum === '1.2.2021' && zaznam.potravina.nazev === 'ryze')
   .forEach(zaznam => zaznam.mnozstvi = 50);

A dojde k automatickemu promitnuti teto zmeny do vykreslene instance komponenty TabulkaZaznamu:

Mě se to nelíbí. Jako ten zápis, že si vyfiltruju očekávané záznamy - potuď dobré. Ale jak jako, že se to někam promítne?! Já nechci aby se to tam promítlo jen tak, aniž bych mu cokoliv řekl! Ten kód mi přijde nebezpečně nečitelný.


Co vsak ale musim udelat (resp. jeste pred 3 lety (v javascriptu pravek?) jsem musel udelat) v te dobe v nejpopularnejsim frameworku na svete, v Reactu, je tenhle strasny a sileny hoven:
...
Tzn. musel bych kompletne vytvorit znovu cely objekt, aby to bylo jak to React vyzaduje.
Je to tak. V čem je problém? React ctí funkcionální paradigma. Má to své výhody i nevýhody. Určitě by se nějaká ta syntax dala vylepšit. Ale skutečnost, že vytvoří nový celý objekt je očekávané a požadované chování.

5
Vývoj / Re:Zlepšení čitelnosti vlastního kódu
« kdy: 07. 06. 2021, 17:26:15 »

.... Jenže u programování se nejen vždy znovu vynalézá kolo, to se montuje do celé sestavy a to často za běhu motoru a s cestujícími na palubě, ale během cesty se z původního stroje stává často něco zcela jiného, než bylo původně zamýšleno a zdokumentováno.

a tenhle nesmyslny styl prace vylepsime tedy tim, ze budeme psat srozumitelnejsi komentare, budeme psat jen 65 znaku na radku .... ?

Ano.

6
Vývoj / Re:Zlepšení čitelnosti vlastního kódu
« kdy: 07. 06. 2021, 14:19:06 »
kdyz jsem procital diskuzi, tak jsem si rikal, jestli je rok 1980.

Ale tenkrat vlstne root jeste neexistoval. No nic, asi ten vyvoj nejde tak rychle - tedy jak jsem si to ja kdysi predstavoval.

Pred nedavnem jsem byl u znameho ve firme. Tam jsem ve vyrobni hale na stolech videl taky takove predpisy, navody, pracovni postupy, jak je co treba delat. Rikali tam tomu vykres. Bylo dost prekvapive, ze kazdy tem navodum rozumnel - dokazal je cist. A dokonce ani neznali toho, kdo ty navody(programy  :)) ) psal.
Ani tam nepouzivali tu metodu, jak ji tady nekdo propaguje v diskuzi, totiz ze by u soustruhu stali 2 zamestnanci a delali by na jedne veci spolecne.
Co je podobne je ten review - to u tech vykresu taky nekdo dela, je tam dokonce kolonka, kde ten kontroler napise jmeno a datum. Ale jenom jeden a asi to kontroloval jen na jedne urovni , ne jako u toho postgresql.
Co jsem take nevidel byly  komentare. A kdyz, tak jsou porad stejne ... to je divne ???

Dělal jsem čtyři roky ve fabrice. Když jsem nastupoval, ptal se mě ředitel, zda rozumím výkresům - no, učil jsem se to, no.
Pak jsem pravidelně chodil za mistrem s tím, ať zavolá zadavateli, že na tom plánu jsou tyhle kóty dvakrát, rozporné, a tady zase rozměr chybí.

Tož asi tolik k tvému příspěvku :-)

7
Vývoj / Re:git, merge --no-ff a rebase
« kdy: 21. 05. 2021, 00:33:51 »
git rebase --rebase-merges
možná udělá to co chcete.  Já to tedy používám v situaci kdy chci nějaké merge pushnout do masteru a zjistím že mezitím do masteru ještě pushnul někdo jiný - a pak chci jen své merge posunout a ne je "klasicky rebasnout".

Skvělé. To je přesně to co chci! Díky moc.

8
Vývoj / git, merge --no-ff a rebase
« kdy: 16. 05. 2021, 16:25:05 »
Ahoj.

Používám následující postup:
Mám branch master, ze které buildím produkční verzi aplikace. Z ní mi vychází něco jako verze branch, například v1.0. Z ní vychází feature branch, například v1.0-foo.
Vždycky, když mám feature branch (v1.0-foo) hotovou, tak ji mergnu do verze (v1.0) s přepínačem --no-ff. Když mám hotovou verzi, tak ji mergnu do master, opět s přepínačem --no-ff. Díky tomu tam mám pěkné kolejničky, které mi ty commity seskupují.

Mám problém s tím, že když rebasuju master do v1.0, a následně do v1.0-boo, v1.0-foo, tak mi ty kolejničky zmizí. Jako celkem chápu proč to je. A znám řešení - prostě musím všechny feature rebasnout, a zmergnout znova. Ale je to dost pracný, a přijde mi to trochu blbý.

Nevíte jak na to? Jak to dělat lépe?

Cíl je, abych tam měl kolejničky, rebasovat a mít méně práce.

Díky moc.

9
Software / Re:Geary se nepřipojí na IMAP Seznam.cz
« kdy: 12. 05. 2021, 20:41:42 »
Mám Thunderbird a imap.seznam.cz:993 SSL/TLS (heslo, zabezpečený přenos) mi funguje u mailu na seznamu i vlastní doméně. Odchozí pošta to samé, akorát port 465. Autorizace v obou případech celým mailem a heslem.
A google účet ti jde? Co máš za verzi TB?

10
I tak by se musel naučit:
- SQL
- principy normalizace/deduplikace/optimalizace (jak se tomu souhrně nadává?)
- procedůry
- git/správu zdrojáků
- programovací jazyk
- testovat svůj kód
- návrhové vzory (to z jedné knížky nedá)
- pochopit princip spousty technologií
- naučit se mrtě knihoven

Je zajímavé, že spousta kolegů kolem mě z toho seznamu umí:
- programovací jazyk
- pár knihoven
- select, insert, update z SQL
a celkem v pohodě fungují a berou slušný prachy.

Normalizaci nezná nikdo z nich.

Netestují.

Návrhové vzory jsou blbost, to ať se nikdo neučí. To spíš SOLID a spol. To je mnohem užitečnější.

K otázce:
Je hlad po programátorech. Takže pokud umí víc než průměr, bude brát víc než průměr, a určtiě se může chytit. Pokud ho to baví, nebo má jinou motivaci, může růst, a tím i brát víc.

11
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 26. 04. 2021, 00:52:16 »
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.
Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.
A nechceš si napsat prototyp, ať se máme nad čím bavit? ;) Nevím, jestli přímo ve Smalltalku, ale určitě by to bylo zajímavé.

Chci. Je to aktuálně můj primární hobby projekt. Ale je málo času, tak o tom maximálně žvaním tady na rootu :-)

12
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 25. 04. 2021, 23:46:45 »
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.
Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.

13
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 25. 04. 2021, 21:27:39 »
Čili se nakonec celá debata vede o tom, co z ACID (atomicity, consistency, isolation, durability) mohou objektové (či NoSQL) databáze vlastně nabídnout.
No, já bych prosil komplet. Jinak nemám důvod PostgreSQL opouštět.

14
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 25. 04. 2021, 21:25:08 »
Případně, pokud chci transakčnost, tak:
- začni atomický blok
- najdi v poli požadovaný záznam
- uprav v něm co potřebuješ
- commit
Tohle zní slibně. Takhle nějak fungoval jeden z módů db4objects.

Tenhle postup je důvod, proč jsou objektové databáze i vlastně i věci napsané nad ORM pomalé. Pokud objekt není už v paměti, tak načtení objektů po jednom je drahé (počínaje diskovými operacemi a konče sítí). Částečným řešením je držet si objekty v RAMce - ale tím se dostanete do problémů s udržením konzistence, zamykáním a se správou cache. A navíc potřebujete kopii databáze v paměti. V momentě, kdy se mi hromadná operace změní na cyklus nad individuálními operacemi, tak jde výkon do háje.

Oproti objektovému přístupu SQL popisuje pouze hromadné operace (operace nad relacemi). Operace nad jedním záznamem je jen jeden speciální případ. Díky tomu má optimalizátor prostor pro výběr z implementací vhodné pro zpracování většího množství záznamů (seq scan, merge join) nebo naopak menšího množství (index scan, nested loop). Podle mne je tohle základní problém.

Když se pracuje s izolovanými hodnotami, tak objektové databáze nebo ORMka nemají jediný problém. Ale pro hromadné operace, tam vlastně není moc prostoru jak je implementovat efektivně (neduplikovat objekty v RAM, redukovat síťové operace, redukovat diskové operace). Řešitelné by to podle mne bylo - tytéž operace, které dělám nad objektem bych měl být schopen udělat nad kolekcí objektů - a mohlo by to fungovat pokud by vývojář použil tento interface. Jakmile programátor ale použije cyklus, tak tam není možná optimalizace - ledaže by se reimplementoval cyklus, a že by klient dokázal distribuovat volání operací na databázový server - a že by databáze dokázala pro implementaci cyklu použít vlastní optimální algoritmus (seq scan nebo index scan).

Chápu, že programátor chce být odizolován od implementace uložení dat. Nicméně je potřeba počítat, že data se mezi storage a aplikací nepřesouvají nekonečně rychle, a že je vždy režie na záznam, a na operaci. A totéž platí i o načítání dat. Pokud pak používám interface, který určuje, že mám pracovat s konkrétním záznamem, tak už neumožňuji efektivní implementaci (rozdíl v rychlostech v přístupech k izolovaným hodnotám a v hromadných operacích) může být i o řád nebo o dva. Pokud máte v datech milióny, desítky miliónů záznamů, tak rozdíl v efektivním a neefektivním zpracování bude v hodinách.

Co zaznělo v diskuzi, tak se vývojáři objektových databází zaměřili na co nejlepší bezešvou integraci databáze s objektovým prostředím. Ale pak naráží na  efektivitu přístupu ke uložišti. SQL databáze na to jdou úplně z druhé strany. V prvé řadě řeší efektivitu přístupu k datům (minimalizace random IO, minimalizace přenesených dat po síti). Pokud mám data uložená lokálně (nedochází ke sdílení, nemusím řešit síťovou komunikaci, data jsou na ssd - nemusím řešit random IO), tak ten objektový přístup může fungovat. V opačném případě si to moc nedovedu představit. SQL databáze se snaží vývojáře izolovat od některých implementačních detailů (nemusí řešit jestli se použije seq io nebo random IO, nemusí řešit síťovou komunikaci) - a tím končí. Vůbec se nesnaží o nějakou integraci s vývojovým prostředím. To ani nejde. Nemám a ani nechci Postgres pro Javu, a jiný pro C#.

Ano, to je další výhoda databáze jako externího řešení. Snadnější implementace.

Každopádně, abych spojil tvé připomínky s mou vizí:

Klasické řešení:
Kód: [Vybrat]
foreach (x in conn.query('SELECT * FROM post WHERE name LIKE ?', "Jozef%")) {
  format(map2object(x))
}

ORM řešení:
Kód: [Vybrat]
foreach (x in orm.find<Post>(type(Post).name.like("%Jozef%"))) {
   format(x)
}

se přeloží na:
Kód: [Vybrat]
foreach (x in conn.query('SELECT * FROM post WHERE name LIKE ?', "Jozef%")) {
  format(map2object(x))
}


Moje vize:
Kód: [Vybrat]
foreach (x in posts) {
    if startWith(x.name, "Jozef") {
        format(x)
    }
}

se přeloží na:
Kód: [Vybrat]
foreach (x in conn.query('SELECT * FROM post WHERE name LIKE ?', "Jozef%")) {
  format(map2object(x))
}

ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

15
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 25. 04. 2021, 02:14:41 »
Ano, nejspíš to tak je. Ale distr. transakce jsou celkem velká komplikace. Možná právě tento typ problémů tenhle typ řešení persistence zazdil? Na mě to působí jako málo muziky za hodně peněz. Každopádně nevím o žádné implementaci, která by nebyla jen akademickým experimentem. Ale úvahy to jsou bezpochyby zajímavé.
Mě se to nezdá. Na základě kanálů, které se začali používat v posledním roce dokazuješ, že se to proto neujalo?

IMHO se to neujalo proto, páč na začátku jsme u C byli rádi, když přišel GC. Pozdějc přišla móda dynamický jazyků se svým "hele jak hezky se to dá napsat". A pak už se usadil ten mindset, že data se vytahují a vrací z/do persistence. Technické obtíže bych v tom nehledal.

Stran: [1] 2 3 ... 110