Příspěvky

241

Vývoj / Re:Rust - std::ANY alebo lepší návrh?

« kdy: 02. 12. 2021, 17:32:33 »

Inspiroval bych se co ostatní uváděli: mám verzovanou databázi. Změním tabulku, přejmenuju pár sloupců. schema-manage mi zařve, že je tam neverzovaná změna. Řeknu mu teda, aby vygeneroval sql-commit z té změny. Jenže jsem ty sloupce přejmenoval tak šikovně, že jsem ten nástroj zmátl, a on místo aby udělal příkaz pro přejmenování, tak udělá drop table + create table. Takže to předělám jak to má být, a commitnu.

S verzovanim DB schemat mam trochu problem... (kdyz neco verzuju tak predpokladam ze se snadno budu moct vratit k predchozi verzi ale to u DB a netrivialnich zmen "snadno" nejde) ale to je asi jedno.
V tomhle pripade je to stejne jedno.... co znamena ze "prejmenuju par sloupecku"
Pripojim se k DB a spustim nejaky "alter table" ne?

Takze jestli te spravne chapu tak si pustis nejakej kod nad DB, ten si neulozis protoze mas prece schema manage.
Ten ti ho vygeneruje spatne, takze to tam prepises aby to bylo tak jak uz si to jednou delal... a pak to commitnes.
Je to tak?
V tom pripade mi prijde jednodussi rovnou commitovat ty zmeny tak jak sem je psal predtim rucne a vynechat generator.

Ono je to tak jak říkáš. A je to pravda, že by to bylo jednodužší, kdyby to lidi dělali. Ale oni to nedělají. Takže než poslouchat nadávky, to tam je ten generátor, a vysvětlit jim, že si to jen musí ještě zkontrolovat je reálnější.

Nebo z PHP světa, composer: nastavím si balíček, že má být ve verzi vendor/balicek:1.*, a on mi vygeneruje graf závislostí, kde bude jinejvendor/jinejbalicek:1.8.6, ale já vím, že zrovna tento má chybu, a potřebuju nižší/vyšší. Tak to poedituju/přinutím mu dát konkrétní verzi, a zase dám composerem zkontrolovat závislosti a vygenerovat graf.

V php sem uz dloooouho nic nedelal takze si nejsem jistej v kramflecich, ten graf zavislosti je potreba commitovat?
Ale obcene bych nepovazoval konfiguraci dependency managementu za "kod".
Takze tam jsem OK s tim ze se kousek nejak generuje a kousek pise rucne.

Ten graf závislostí je třeba commitovat (není to specifikum php, je to principielní problém), protože ty máš v jednom souboru uvedený cca verze a balíčky, které chceš, zatímco v tom druhém souboru jsou už přesné verze všech balíčků. Aby se pokaždé vygeneroval stejný graf a stáhly se vždycky ty samé balíčky - důsledky si asi domyslíš.

242

Vývoj / Re:Rust - std::ANY alebo lepší návrh?

« kdy: 02. 12. 2021, 14:57:54 »

Přesně takto se to používá:
1/ Generovaný kód, jehož znění nevyžaduje schválení člověkem = generuje se na CI serveru (nebo kdekoliv jinde) + necommituje se.
2/ Generovaný kód, který mi vygeneruje stroj, ale musí projít schválením člověkem = generuje se u vývojáře, a pak se commituje.

Má to tyto důsledky:
V prvním případě se jede na tvrdo optimalizace, stroj může cokoliv.
V druhém případě je očekáváno, že to co se vygeneruje musí být co nejvíce čitelné; nejlépe optimalizované pro diff. (A následně se to třeba celé ještě projede první variantou.)

TypoProvidery a podobně jsou jen první varianta. Jen už zakomponovaná do překladače. Jak už tu někdo zmínil. Ve skutečnosti je to ale spousta dalších případů: gcc, javac, scalac, ... etc, kde by tě ani nepadlo uvažovat, že je to jen prachsprostej generátor kódu. A ne, není to něco jiného

Mel bys nejakej netrivialni priklad 2?

Inspiroval bych se co ostatní uváděli: mám verzovanou databázi. Změním tabulku, přejmenuju pár sloupců. schema-manage mi zařve, že je tam neverzovaná změna. Řeknu mu teda, aby vygeneroval sql-commit z té změny. Jenže jsem ty sloupce přejmenoval tak šikovně, že jsem ten nástroj zmátl, a on místo aby udělal příkaz pro přejmenování, tak udělá drop table + create table. Takže to předělám jak to má být, a commitnu.

Nebo z PHP světa, composer: nastavím si balíček, že má být ve verzi vendor/balicek:1.*, a on mi vygeneruje graf závislostí, kde bude jinejvendor/jinejbalicek:1.8.6, ale já vím, že zrovna tento má chybu, a potřebuju nižší/vyšší. Tak to poedituju/přinutím mu dát konkrétní verzi, a zase dám composerem zkontrolovat závislosti a vygenerovat graf.

243

Vývoj / Re:Rust - std::ANY alebo lepší návrh?

« kdy: 01. 12. 2021, 22:13:36 »

dokud ten generovany kod nekdo necommitne do repositare nebo nedej boze nezacne rucne editovat tak mi generovany kod nevadi... v opacnem pripade souhlasim, ze je to zlo

A jaký to je problém, když to commitne? Když se to API mění jednou za uherský rok nebo vůbec, nevidím v tom žádný problém.

To co se muze zmenit se zmeni... kdyz se to deje zridka tak to znamena ze na to nejsem zvyklej a o to vic me to muze zmast.
Za to co je v repositari citim odpovednost. Nechci citit zodpovednost za neco co vygeneroval stroj.
Kdyz delam code review tak se musim podivat jestli zmena ve schematu odpovida zmene v generovanem souboru...
Kdyz na tom dela vic lidi najednou tak se pak treba musi resit ze nekdo commitne zmenu schematu, ale uz ne zmeny v generovanem kodu... Nic se nerozbije, ale je to matouci...
Kdyz budes mit v aplikaci nejaky submodul ktery se meni zridka nebo vubec a nejaky jiny na nem zavisi... tak budes commitovat i binarku?

Přesně takto se to používá:
1/ Generovaný kód, jehož znění nevyžaduje schválení člověkem = generuje se na CI serveru (nebo kdekoliv jinde) + necommituje se.
2/ Generovaný kód, který mi vygeneruje stroj, ale musí projít schválením člověkem = generuje se u vývojáře, a pak se commituje.

Má to tyto důsledky:
V prvním případě se jede na tvrdo optimalizace, stroj může cokoliv.
V druhém případě je očekáváno, že to co se vygeneruje musí být co nejvíce čitelné; nejlépe optimalizované pro diff. (A následně se to třeba celé ještě projede první variantou.)

TypoProvidery a podobně jsou jen první varianta. Jen už zakomponovaná do překladače. Jak už tu někdo zmínil. Ve skutečnosti je to ale spousta dalších případů: gcc, javac, scalac, ... etc, kde by tě ani nepadlo uvažovat, že je to jen prachsprostej generátor kódu. A ne, není to něco jiného

244

Vývoj / Re:Rust - std::ANY alebo lepší návrh?

« kdy: 01. 12. 2021, 15:16:53 »

generovany kod je zlo.

Silná slova. Pokud své tvrzení něčím nepodložíš, tak platí, že "generuj co můžeš".

245

Vývoj / Re:Rust - std::ANY alebo lepší návrh?

« kdy: 30. 11. 2021, 10:55:19 »

Aniž bych ostatní text ignoroval, tak:

Chceš poslat zprávu o tom, že Pepa Novák si kupuje ponožky za 10 dolarů

Mě na SOAP oslovilo právě a hlavně to WSDL. Nalinkuju jedno url, a hned mám kompletní knihovnu včetně dokumentace (fandím), typů, etc. A s žádným XML se vůbec nemusím dostat do styku (já vím, v reálu to tak nefungovalo) a nemusí mě zajímat.

To mě třeba na tom RESTu přišlo blbé. Že to sice je štíhlejší, a můžeš si to naimplementovat pár řádky kódu, ale problém je v tom, že vlastně musíš. Nejsou (nebyli) nástroje, které by udělali automaticky knihovnu a mohl jsi ty endpointy volat transparentně.

(Argument s OpenAPI prosím nechte. Pochopil jsem. Nastuduji si.)

246

Vývoj / Re:Rust - std::ANY alebo lepší návrh?

« kdy: 29. 11. 2021, 23:45:19 »

SOAP je peklo a patří na smetiště IT dějin.

Proč?

To je vážně míněná otázka? Odpovědí jsou všechny důvody, proč vzniklo například gRPC.

Aktuálně frčí REST, ale přijde mi to jako trochu jinak řešený stejný problém, akorát že tam zatím není standardizovaný nějaký popis rozhraní jako WSDL. Třeba časem.

gRPC neznám, díky za tip.

Je to celé o efektivitě, REST je poměrně pomalý a parsovat XML je taky zbytečně zdlouhavé. Proto vymysleli Protobuf, což je extrémně úsporný protokol, a gRPC nad ním jede přes HTTP/2, takže bez zbytečných latencí. Žádná věda v tom není, ostatně pokud člověk neřeší miliony RPC volání za hodinu, tak ho asi použití JSONu nebo XML pálit nebude. Jen prostě parsování sežere dost CPU cyklů a paměti.

Takže to

je peklo a patří na smetiště IT dějin

je čistě proto, že SOAP je neefektivní? Nebo je mu vyčítáno i něco jiného?

Aktuálně frčí REST, ale přijde mi to jako trochu jinak řešený stejný problém, akorát že tam zatím není standardizovaný nějaký popis rozhraní jako WSDL. Třeba časem.

OAS nestačí? https://en.wikipedia.org/wiki/OpenAPI_Specification

OpenAPI (aka Swagger) je jeden z mála standardů, co se v poslední povedl.

Už jsem o něj zavadil, ale ještě jsem si na něj neudělal závěr. Takže díky za referenci.

247

Vývoj / Re:Rust - std::ANY alebo lepší návrh?

« kdy: 29. 11. 2021, 01:25:30 »

SOAP je peklo a patří na smetiště IT dějin.

Proč?

To je vážně míněná otázka? Odpovědí jsou všechny důvody, proč vzniklo například gRPC.

Jo, je to vážně míněná otázka.

Se SOAP jsem dělal (Java, C#, PHP). Netvrdím, že je to nějaká slává, prostě jsem to vzal v potaz a používal (když to klienti chtěli...).

RPC jsem používal dřív, různé implementace v Pythonu (patnáct let zpět). A mám za to, že je to krapet něco jiného než SOAP, ale nechám se poučit.

Aktuálně frčí REST, ale přijde mi to jako trochu jinak řešený stejný problém, akorát že tam zatím není standardizovaný nějaký popis rozhraní jako WSDL. Třeba časem.

gRPC neznám, díky za tip.

Ptal jsem se proto, že občas slyším někoho nadávat na SOAP, ale většinou to jsou jen tak obecné nářky. A mě známé nevýhody, že je to ukecané a že je to v XML mi přijde trochu málo na takové zhodnocení. Hoď sem něco z patra prosím.

248

Vývoj / Re:Rust - std::ANY alebo lepší návrh?

« kdy: 28. 11. 2021, 02:43:56 »

SOAP je peklo a patří na smetiště IT dějin.

Proč?

249

Vývoj / Re:Python skript při startu ubuntu

« kdy: 14. 11. 2021, 16:22:14 »

Moc díky za typ.

Kód: [Vybrat]

import pyautogui

A já děkuji za typ na tohle. To jsem neznal, to se bude hodit.

250

Odkladiště / Re:Ztráta mobilu

« kdy: 20. 10. 2021, 16:23:24 »

Tak matematicky tam samozřejmě určitá pravděpodobnost je.

Čistě prakticky můžeš být klidný. Aby si měl takovou smůlu, že zrovna ten tvůj telefon bude někoho zajímat, že mu to bude stát za hodiny až roky času to lámat, a že zjistí komu ta hesla patří, a zjistí k čemu by mu mohla být dobrá... Ekonomicky (i zlodějové uvažují ekonomicky) můžeš být klidný.

251

Odkladiště / Re:Počítač bez integrovaných obvodů

« kdy: 09. 10. 2021, 23:56:21 »

Jestli s tím nemáš žádné zkušenosti tak se domnívám, že máš naivní představu.
Jinak se koukni na odkaz kde jsou knihy od Martina Malého
https://knihy.nic.cz/

Avšak 286, či něco podobného nebo kompatibilního, doma na koleně nevyrobíš. Ztráta času.
Zaměř se spíš na něco podobného Arduino, a aplikace nedělej v tom jejich prostředí, ale zkus si to napsat v céčku, netuším zda jde použít v Atmelu Assembler, zkrátka něco nízkoúrovňového. A nebo se zaměř na ARM.

Ale myslím si, že nechápeš ani základní souvislosti na úrovni instrukčních sad. V každém případě x86 se licencuje.

Jinak, asi za 20 EUR se dá koupit velmi levné Rapsberry. To nechť ti je vzorem!

Mě se ta otázka líbí. V čem je problém?

252

Vývoj / Re:Tutoriál pro Scalu pro programátora

« kdy: 09. 10. 2021, 21:30:40 »

To je zajímavý úhel pohledu - monády. Proč se používají v Clojure a proč v Haskellu?

protoze v Haskellu je na nich postavene IO (coz je podle me spis nevyhoda). V Clojure a jinde se pouzivaji nektere konstrukce, treba vyse zminene Promisy, ktere lze napasovat na definici Monady, ale uzivatel to nemusi vedet.

Promise je monáda. Každopádně, souhlas - ale co tím chceš říct?

Ještě doplním, v Haskellu nejsou monády kvůli IO. Ony tam prostě jsou. Třeba jsem narazil na pár jiných staticky typovaných jazyků, a byly tam demonstrovány monády i když IO bylo řešeno úplně jinak.

očekáváš, že ty typy přináší záruky. Těmi typy modeluješ. Funkce je typ. Vztahy jsou typ

Na to to chce ale hodně silný typový systém

Tak jasně. Ale někteří jsou schopni tvrdit, že třeba takové C# je staticky typovaný jazyk (přitom je to paskvil). To bychom se nikam nedostali. Bavím se o Haskellu, pokukuji po Idris/Agdě.

253

Vývoj / Re:Tutoriál pro Scalu pro programátora

« kdy: 09. 10. 2021, 19:03:58 »

Ale nemyslím si, že CT je to dobrá cesta, jak se učit funkcionálně programovat.

To by bylo na dlouhou debatu

Víno mám, můžem začít.

Chce to něco ostřejšího

Začal bych tím, že CT není to samé co FP. Jistě, v Haskellu se to třeba protíná, ale třeba v Clojure vůbec. Podobnej problém jako OOP verzus Typy. To, že to máme v některých jazycích dohromady neznamená, že to spolu souvisí.

AFAIK konstrukty, ktere lze popsat pomoci CT terminologie jsou i v Clojure, ale treba i Promisy v JS.

To je zajímavý úhel pohledu - monády. Proč se používají v Clojure a proč v Haskellu?

Ale v souvislosti s původním námětem: Udělal by si třeba v Clojure variantu na toto?

Kód: [Vybrat]

interface Identification {}

(tedy rozhraní bez metod)
?
Já klidně a s úspěchem.

Možná že prostě CT tě "poznamená", že očekáváš, že ty typy přináší záruky. Těmi typy modeluješ. Funkce je typ. Vztahy jsou typ

Zatímco ve FP je to jen o tom, že referenční transparentnost brání špagetovosti. Máš-li tam typy, tak ti slouží jen pro pattern matching. Ale záruky? O čem to mluvíš?!

254

Vývoj / Re:Tutoriál pro Scalu pro programátora

« kdy: 08. 10. 2021, 21:19:34 »

Ale nemyslím si, že CT je to dobrá cesta, jak se učit funkcionálně programovat.

To by bylo na dlouhou debatu

Víno mám, můžem začít.

Chce to něco ostřejšího

Začal bych tím, že CT není to samé co FP. Jistě, v Haskellu se to třeba protíná, ale třeba v Clojure vůbec. Podobnej problém jako OOP verzus Typy. To, že to máme v některých jazycích dohromady neznamená, že to spolu souvisí.

255

Vývoj / Re:Tutoriál pro Scalu pro programátora

« kdy: 07. 10. 2021, 23:31:14 »

Ale nemyslím si, že CT je to dobrá cesta, jak se učit funkcionálně programovat.

To by bylo na dlouhou debatu

Víno mám, můžem začít.