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 - Idris

Stran: 1 ... 49 50 [51] 52 53 ... 153
751
On teda byl rockstar, zvladal i deleni nulou
Nebyl to Chuck N.?

752
Testy jsou naprd, o tom žádná. [...] Samozřejmě typy jsou všespásné
To právě naplatí. Jenže testy jsou o sémantice, kdežto typy kontrolují spíš syntax (je tam průnik, ale malý). Můj aktuální problém jsou tupé chyby (copy/paste překlepy) v boilerplate kódu, to je obzvlášť hnusná a v ideálním světě zbytečná kategorie. Maníci píšou v Go, ale v Rustu nebo Javě by byl stejný problém. Pro tu dnešní módu mikroslužeb asi neexistuje vhodný jazyk, boilerplate se píše všude. Přitom přesně v tomto bodě jsme už jednou byli.
No.. neni trochu problem, ze Go tak neprimo vybizi k psani boilerplatu, kdyz nepodporuje generika a stylem errorhandlingu? Popravde Go moc neznam.. pricichl sem k tomu davno a fakt se mi nelibil, takze jsem ho nechal...
Není. Boilerplate z gRPC nebo ORM s generickými typy vůbec nesouvisí.

753
místo poměrně jednoduchého kola vymýšlí robotickou stonožku
;D tak to je krásný popis toho, co teď právě dělám  ;D
Gratuluju. Sejdeme se v Bohnicích :)

754
Můj aktuální problém jsou tupé chyby (copy/paste překlepy) v boilerplate kódu, to je obzvlášť hnusná a v ideálním světě zbytečná kategorie. ... boilerplate
Můžeš to rozvést?
Viz výše, jen doplním, že před bratru třiceti lety už tato technologie existovala (akorát se jí neříkalo mikroslužby) a technické řešení bylo mnohem příčetnější, než dnešní splácanec RPC, ORMu a RESTu. Koukám, že většina dnešních vývojářů tuhle část SW historie vůbec nezná a místo poměrně jednoduchého kola vymýšlí robotickou stonožku.

755
Pro tu dnešní módu mikroslužeb asi neexistuje vhodný jazyk
Mikroslužby jsou tak trochu problém sám o sobě. Protože tím jak je to rozcapené, tak se to blbě hlídá (zda jsou dodržené kontrakty, zda je problém v dostupnosti, nebo v kódu, ...) Možná by to nemusel být technický problém, ale jsme ve fázi, kdy se snad všechny služby píšou ad-hoc, takže je snadné se na to či ono vybodnout.

Pochlub se detaily.
Detaily nejsou moc zajímavé, problém je celková koncepce — každá entita (třeba User nebo Invoice) má jednu reprezentaci (třídu) pro komunikaci s API (veřejné endpointy), jednu pro ukládání do databáze (ORM) a další pro gRPC (zprávy pro protokol). Většina kódu dělá jen to, že převádí instance těchto nádher z jedné na druhou podle toho, co se právě volá nebo ukládá. A nejde to jednoduše sjednotit, protože velká část kódu se generuje různými nástroji.

Ten převodní kód se píše ručně, vesměs kombinace copy/paste a ad-hoc úprav.

756
Testy jsou naprd, o tom žádná. [...] Samozřejmě typy jsou všespásné
To právě naplatí. Jenže testy jsou o sémantice, kdežto typy kontrolují spíš syntax (je tam průnik, ale malý).
Testy verzus Typy jsme už jednou probírali. Asi netřeba to otevírat znova.
Více než jednou :) Jo, netřeba. Navíc teď mě trápí něco jiného, co nevyřeší ani testy, ani typy (aspoň ne typy v běžných jazycích, že to řeší kategorie monomorfických endofunktorů osmého řádu mi asi s gRPC nepomůže).

757
Vývoj / Re:Agregace velkého množství streamovaných dat
« kdy: 26. 09. 2021, 22:40:10 »
Osobne mam pocit, ze custom bastl prosazuje "stara skola", tj ti co si umi predstavit data a pametovy/souborovy format a vi jak efektivne napsat praci s daty.

Pak je zde tapajici "stredni" trida, kdo se to snazi lepit skrze knihovny nebo jazykove konstrukty, ale netusi uz jak to je ve skutecnosti narocne (casove/pametove).

A pak tady dobehnou decka jako vy, ktery vytasi zazracny frikulinsky jazyk/framework, ktery by to mel udelat, ale o pocitaci vedi snad jenom tolik, ze to bez internetu neudela ani tuk :-)
Tak žádný učený z nebe nespadl...

758
Testy jsou naprd, o tom žádná. [...] Samozřejmě typy jsou všespásné
To právě naplatí. Jenže testy jsou o sémantice, kdežto typy kontrolují spíš syntax (je tam průnik, ale malý). Můj aktuální problém jsou tupé chyby (copy/paste překlepy) v boilerplate kódu, to je obzvlášť hnusná a v ideálním světě zbytečná kategorie. Maníci píšou v Go, ale v Rustu nebo Javě by byl stejný problém. Pro tu dnešní módu mikroslužeb asi neexistuje vhodný jazyk, boilerplate se píše všude. Přitom přesně v tomto bodě jsme už jednou byli.

759
Dříve jsem byl fanatik a dnes tak nějak zjišťuji, že testy nejsou zase tak důležité, jak se říká. Nehledě na to, že stejně nikdy nepokryjete 100% variant.
Důležité je odhalovat chyby. Testy mají tu nevýhodu, že je člověk musí napsat navíc (je to mrtvý kód) a že stejně pokryjí jen poměrně malou část minového pole. Zrovna na jednom projektu vidím, jak maníci použili gRPC, ORM a JSON REST a nejvíc chyb nasekali v kódu převádějícím objekty mezi frameworky. Testy napsali tak nešikovně, že mnoho chyb neodhalily. Nejsmutnější je, že v podstatě píší jen boilerplate kód. Eliminací boilerplatu by se zbavili i těch bugů.
Jak kde. Nektere backend services by bez testu nebyly provozovatelne a vyvinutelne.
Které třeba? Neříkám, že ne, jen by mě zajímaly podrobnosti nebo příklad.

760
Mě by zajímalo, kteří "zkušení" programátoři jsou ochotni tvořit kód bez testů.
Myslím si, že zde platí přísloví, pes který štěká nekouše, neboť pak by se jeho klienti dozvěděli, že svěřuje jejich weby juniorům bez praxe.
myslím, že docela dost. Prošel jsem hodně firem a dost jsem testy v projektu buď vůbec neviděl, nebo byly zakomentované či tam byl assert(true).

A jestli se pamatuji správně, tak kdysi mělo K**i průser a majitel říkal, že testy nepíšou, že je to ztráta času (rozuměj peněz), že případnou pokutu zaplatí znova a že to bude méně něž by stál čas na testy. Nevím jak je to dnes, ale částečně má pravdu. Dříve jsem byl fanatik a dnes tak nějak zjišťuji, že testy nejsou zase tak důležité, jak se říká. Nehledě na to, že stejně nikdy nepokryjete 100% variant.
U knihovny testy píšu (už) asi samozřejmě. U webové aplikace to je na zvážení, zda mají ekonomický smysl. Business logika určitě ano (i když taky to flákám). View výjimečně. To už musí být nějaká fakt vytížená aplikace.

V případě eshopu na zakázku by mě testy opravdu překvapili.
Po mé poslední zkušenosti s testy (v seniorním týmu) se usilovně snažím vymyslet nějaký spolehlivější způsob odhalování tupých chyb.

761
Dříve jsem byl fanatik a dnes tak nějak zjišťuji, že testy nejsou zase tak důležité, jak se říká. Nehledě na to, že stejně nikdy nepokryjete 100% variant.
Důležité je odhalovat chyby. Testy mají tu nevýhodu, že je člověk musí napsat navíc (je to mrtvý kód) a že stejně pokryjí jen poměrně malou část minového pole. Zrovna na jednom projektu vidím, jak maníci použili gRPC, ORM a JSON REST a nejvíc chyb nasekali v kódu převádějícím objekty mezi frameworky. Testy napsali tak nešikovně, že mnoho chyb neodhalily. Nejsmutnější je, že v podstatě píší jen boilerplate kód. Eliminací boilerplatu by se zbavili i těch bugů.

762
Studium a uplatnění / Re:Jaká kniha pro naučení C#
« kdy: 25. 09. 2021, 19:49:44 »
Já bych doporučil něco od Miroslava Viriuse, nepamatuju si přesné názvy, ale tuším "Programování v C#" a "C# - Hotová řešení" jsou dobré knížky. Nebude to o nejnovější verzi, ale pro začátečníka vhodné.

763
Tzn. naprostí diletanti. Na druhou stranu tato firma určitě není žádnou výjimkou.
V ČR jsou dva typy malých IT firem: typ z tohoto příběhu (neschopný retardovaný šéf dávající almužnu, podle toho to pak vypadá všechno, nikdo rozumný tam nevydrží) a pak takové, kde jsou vývojáři nadprůměrně schopní a firma (šéf) si jich váží (a náležitě je platí; tam ale nevezmou kdekoho). Kupodivu moc neexistuje nějaký střed.

764
stačí se naučit Indicky a zdrhnout do Indie, jednak tam tvůj naprasený kód nevzbudí pohoršení a jednak z tebe bude rázem senior.
Ať se naučí švýcarsky nebo belgicky, to je blíž a Indů tam taky najde dost.

765
Mě by zajímalo, kteří "zkušení" programátoři jsou ochotni tvořit kód bez testů.
Jsou i jiné metody zajištění kvality. Nicméně v tomto případě je ta firma evidentně kompletní bordel a šéf idiot.

Stran: 1 ... 49 50 [51] 52 53 ... 153