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 - Mirek Prýmek

Stran: 1 ... 139 140 [141] 142 143 ... 618
2101
Vývoj / Re:Programovanie a modne trendy?
« kdy: 31. 08. 2017, 09:48:17 »
Prodejci nikdy nechtějí pochopit, jak je to možné, že na té nejobyčejnější posteli s nejobyčejnější matrací se vyspím taky úplně normálně a bolest zad znám jen z vyprávění.
To je velice dobrá analogie. Když si totiž koupíš pořádnou matraci, tak na té "obyčejné" už se nevyspíš. Neboli, jak říká klasik: "Která jednou zkusí, už nechce jinak".

Nemám žádný důvod tě přesvědčovat, programuj si v čem a jak chceš, je to tvůj život :)

2102
Vývoj / Re:Programovanie a modne trendy?
« kdy: 31. 08. 2017, 08:46:23 »
Ano, tohle je ta obvyklá cool věta, která se říká začátečníkům, aby věděli totéž, co předtím. Nenese totiž žádnou informaci o FP.
Ne, pokud člověk není pitomec, který si potřebuje honit triko, tak začátečníkům říká, že v FP:

1. je funkce (prakticky) totéž co se tím slovem myslí v matematice - je referenčně transparentní
2. data jsou imutabilní

...přičemž tohle ideálně platí absolutně, zatímco u reálných jazyků je to naplněno různou měrou.

Pokud je záhodno to začátečníkovi říct ještě polopatičtěji, použije se analogie s výrobní linkou: program v FP je taková továrna, ve které jsou za sebou poskládané různé stroje - do každého něco pásem jede a něco jiného z něj vypadne.

Zavadzanie FP paradigmy do imperativnych OOP jazykov mi preto pripada ako ked v cestine a slovencine silou mocou uplatnujete japonsky slovosled s prisudkom vzdy a len na konci vety.
S tím se celkem dá souhlasit - pokud se zavádí FP prvky jenom proto, aby tam byly, a nemá to žádný pořádný přínos (například proto, že ostatní rysy jazyka ten kýžený efekt zabijí), je to trochu křeč.

ale vacsina jazykoveho spolocenstva v tom nevidi benefit, ked zhruba to iste ide aj po starom so sideeffectami.
A s tímhle už se souhlasit nedá. FP prvky se nezavádí proto, že by pomocí FP šlo udělat něco, co v OOP nejde, ale proto, že FP programovací styl (!!!!) často vede ke kódu, který dokáže člověk líp pojmout, přemýšlet o něm a dělat o něm závěry ("reason about"), což je samo o sobě velký přínos např. pro spolehlivost (viz Elm vs. JS).

Dají se popsat konkrétní důvody, proč je FP v tomhle vhodnější - jeden z nich např. je, že interakce jsou ("vynuceně") lokální - z principu se nemůže stát, že někde držím nějaká data a kód na úplně druhé straně planety mi je změní pod rukama - tahle eventualita prostě neexistuje, proto s ní nemusím počítat (u OOP musím) a mám přemýšlení o poznání jednodušší.

Imutabilní data jsou podle mě (a nikomu to necpu) silnější nástroj než funkce bez sideefectů. Pokud mám jazyk se striktně imutabilními daty, tak mi to přemýšlení nad kódem dramaticky zjednodušší. Pokud mám jazyk bez sideefectů, tak mi to sice pomůže taky, ale zároveň to přinese obrovské množství problémů při řešení praktických věcí, takže ve finále musím přemýšlet zase hodně :)

2103
Server / Re:Máte ve firmě ticket system?
« kdy: 28. 08. 2017, 19:05:10 »
Já se snažím protlačit ticket systém, ale nikomu se tickety vytvářet nechtějí. V praxi to pak vypadá tak, že na nás jako na IT každej pokřikuje nějaký problém na chodbě a při porádách se hádáme proč to není udělané nebo jak je to udělané. [...] Nebo Vám prostě lidi posílájí emaily s problémy typu:"Nefunguje to". Díky moc za všechny komenty.
Souhlasím s tím, co výš napsal ptc. Bez nějakého druhu evidence požadavků se nedá obejít - je to na zbláznění a vyhoření. A pokud se netrvá na pravidle, že co není v systému, to neexistuje, nebude ho nikdo používat, protože houknout na ajťáka na chodbě je jednodušší.

Z toho plyne: používat a vynucovat, to je jediná správná cesta ;)

Neochotu chápu a znám. Nemusíš uživatele nutit nějak se přihlašovat a cosi vyplňovat. Rozumný ticketovací systém umí přijímat maily. Osobně používám RT - tím způsobem, že o něm uživatelé ani neví, píšou maily a RT automaticky pozná, co je nový mail (vytvoří ticket) a co je RE na něco už existujícího (přidá záznam k příslušnému ticketu). Funguje to dobře, vřele doporučuju.

BTW, evidence se hodí i na věci, který předem nepředpokládáš - např. hledání opakujících se dotazů. Nebo jsem si třeba jednou sedl a během asi půl hoďky jsem měl nejenom statistiku počtu požadavků za měsíc, ale i udělanej hezkej graf, kolik procent požadavků se vyřeší do jaké doby (silný argument na uživatelské brblání, že věčně nic není a všechno trvá dlouho :) ).

Další věc, kterou ticket system dost zjednodušší, je dělba práce. Kouknu a vidím, kde kolega skončil a navážu. Systémem mailů, GDoců a papírků nejde bez skončení na psychiatrii realizovat ;)

2104
Studium a uplatnění / Re:Oplatia sa certifikaty?
« kdy: 23. 08. 2017, 12:17:13 »
Vsetci si robia Cisco
Jo. To jsem takhle jednou mluvil s člověkem, kterej si dělal nějaký to základní Cisco a říkám mu "Umíš vyjmenovat privátní rozsahy?" A on: "No vím, že to existuje, ale teď si nevzpomenu."

Takže asi tak k certifikacím...

2105
Odkladiště / Re:Kde koupit bitcoin online ?
« kdy: 22. 08. 2017, 18:42:58 »
jen tak na hrani
Není větší zábava hodit klíče do kanálu?

2106
Studium a uplatnění / Re:Oplatia sa certifikaty?
« kdy: 22. 08. 2017, 18:18:35 »
To skôr keby si chcel robiť admina. [...] lebo to zväčša robia ľudia, ktorí sa vedia ledva podpísať.
Aniž bych chtěl zahajovat flejm: mám opačnou zkušenost. Viděl jsem adminy programovat a byl to slušný kód. Viděl jsem programátory adminovat a bylo to na okamžitou (sebe)vraždu.

(Samozřejmě se nebavím o Windows klikačích, to zhusta nejsou vůbec admini)

Je to jedna z moznosti, no chcel som najprv pocut vase skusenosti.
Chybí mi v tom dotazu jedna klíčová informace: co chceš dělat a o jakých certifikátech uvažuješ. Pokud chceš dělat vývojáře, je ti logicky certifikát z ITILu nebo Photoshopu dost na prd žejo :)

2107
Vývoj / Re:výjimky
« kdy: 22. 08. 2017, 11:18:17 »
Tohle ale není moc dobrý příklad použití výjimek. Když použijete výjimky správně, budete výjimku pořád ošetřovat v místě jejího vzniku, kde znáte kontext, a pokud se nepodaří ji na daném místě vyřešit, pošlete dál nějakou obecnější výjimku.
A taky je výhoda v tom, že člověk může na nějakém místě ošetřit jenom určitou třídu výjimek (např. ty souborové chyby) a ostatní pustit na vyšší vrstvu - přičemž je hnedka z kódu jasné, co pouští dál (třeba u Javy úplně explicitně). To se sice dá s návratovými kódy taky simulovat, ale je to krkolomnější, málo explicitní a většina jazyků neumí zkontrolovat, že bylo ošetřeno opravdu všechno, co může nastat (pokrytí celého výčtového typu kontrolují většinou jenom funkcionální jazyky).

2108
není to přímo problém samotných výjimek, ale jejich přístup programátory nemotivuje k lokalizaci chyby; čím výše chyba propadne, s tím větším kanónem se pak na ni jde
No, tak jsme se dostali k tomu, co jsem říkal: ve výjimkách problém není - pokud je to potřeba, dají se používat se stejnou granularitou jako návratové kódy.

V Erlangu se výjimky používají a těžko bysme hledali něco, co je víc synonymem pro robustnost než Erlang.

2109
Až doteď jsem si myslel, že ti to pálí trochu víc... ;)
Pálí a nepálí jsou dvě strany téže mince, takže ses nespletl.

2110
Toto je přístup tvůrce softwaru pro jaderné elektrárny nebo sondu, co má přistát na kometě. Dobře, trochu přeháním... Ono to je v podstatě metodicky správné a kdyby bylo bezprostřední ošetření chyby na jeden řádek, tak by to bylo ideální. Problémem v Go je to nešťastné gofmt, které z každého "if err!=nil{return nil,err}" udělá tři řádky.
Ale vy oba pletete hrušky s jabkama. Výjimky umožňují reagovat na chybu v nějakém *bloku*. Tj. je mi jedno, na jakém řádku v bloku k chybě X došlo, prostě blok jako celek selhal kvůli X a reaguju na to způsobem Y. Výjimky slouží k tomu, abych nemusel Y opakovat po každém řádku v bloku. Se spolehlivostí to nemá co dělat.

2111
Server / Re:Microsoft Hyper-V
« kdy: 20. 08. 2017, 21:58:46 »
Poslední dobou mám pocit, že sw ZADARMO je nejdražší.
Nekvalitní sw je nejdražší. Zadarmo =/= nekvalitní.

2112
Navic GO funkce podporuji navrat vice hodnot (obvykle payload + error struct), takze explicitni vyjimka neni potreba.
Jak už rečeno, rozdíl oproti výjimce je ten, že chybový kód se musí explicitně checkovat. Výjimka se checkovat nemusí (ale může, stejně jako chybový kód, čili je "obecnější", "mocnější").

2113
chyby se ošetřují blízko vzniku
Což se dá dělat i s výjimkami, takže to není argument.

2114
panic/recover (jen jinak pojmenované výjimky)
Aha, na to jsem ještě nenarazil :) Na první pohled to nevypadá úplně blbě, problém je, že se to nikde nepoužívá - všude jsou ty explicitní návratový kódy.

2115
Výjimky tam jsou.
Kde/jaky?

Ta generika jsou jiná otázka, je fakt, že pro někoho z FP může být jejich absence bolestná, ale jakmile se člověk naučí používat správně ta jejich rozhraní, tak se bez nich dá obejít.
Jasne no. Ale traity z Rustu to nejsou...

Stran: 1 ... 139 140 [141] 142 143 ... 618