Příspěvky

661

Vývoj / Re:Typový system versus unittesty

« kdy: 27. 06. 2018, 17:39:18 »

Proto me se libi treba clojure.spec. I kdyz je clojure dynamicky jazyk tak spec mu pridava neco jako "velmi silny typovy system" (Neni to primo v jazyku takze jsou potreba nejake nastroje na instrumentaci, proto "neco jako"). A krasne to integruje s testcheckem takze tomu muzu rict aby se pri buildu nahodne vygenerovalo bambilion vstupu odpovidajicich SPECifikaci a projelo se to funkci a vyhodnotilo jestli vystup taky odpovida specifikaci(a do znacne miry i jestli je spravne vzhledem ke konkretnim vstupum). Takze nemusim napsat jedinny unit test a mam pokryto radove lepe nez s unit testy.

Domnívám se, že v tomto případě jde spíše o automaticky generované testy. Což je taky dobrý. Ale typy jsou imho o něčem jiném. Viz ta ukázka https://forum.root.cz/index.php?topic=18804.msg271719#msg271719

Můžeš udělat typy, které se budou checkovat třeba týden. Ale udělat testy na bambilion vstupů budou ještě mnohem horší s horší efektivitou.

Ja to vidim nekde mezi. V clojure (ale i v dalsich lispech) je totiz "write time" = runtime. To znamena, ze kazdy vyraz ktery napisu hned evaluuju a mam ho k dispozici v bezicim REPLu. Takze kdyz treba pisu funkci a jeji specifikaci viz https://clojure.org/guides/spec#_spec_ing_functions  muzu klidne tam kde ji volam pomoci valid? nebo conform overit jestli je dane volani odpovida specifikaci. A kdyz si to budu nechavat instrumentovat abych to nemusel zkouset rucne tak se blizim typovemu systemu. (popravde ja to tak nedelam, ale ja taky uz dneska moc kodu nenapisu...)

To ze z toho generuju testy je side effect, ale velmi prijemny. Podle me to prave preklenuje tu mezeru kterou zpusobuji prakticka omezeni na strane unit testu a typoveho systemu. Tam kde by typova specifikace zacinala byt neprakticka a pri tom nebyla kriticka muzu nechat generator chroustat misto abych ja musel cucat z prstu hodnoty ktere se maji vyzkouset.

662

Vývoj / Re:Typový system versus unittesty

« kdy: 27. 06. 2018, 15:26:33 »

Pokryti testy asi vetsina lidi chape jako (mnozstvi kodu spusteneho behem testovani)/(celkove mnozstvi kodu) a ne jako (mnozstvi testovanych vstupu)/(mnozstvi vsech moznych vstupu).

To, že otestuju tři hodnoty, a prohlásím, že kód je otestovaný, přičemž u čtvrté hodnoty to chcípne, to je poněkud smutné, nemyslíš?

Ale jo, ale to pokryti zajima spis management nez programatory. Je to nejaka metrika ktere si mysli, ze rozumi. Ja na svem projektu rozhodne zadne pokryti nemerim.

Mám na mysli takové to, když vývojář napíše těch pár testů a posílá na produkci. Tím gestem říká, že je to otestované. Nemluvil jsem vysloveně o ceverage.

Doufam, ze ve vetsine pripadu jeste do nejakeho testovaciho prostredi kde se na to koukne nekdo z QA. Ale i tak, mas pravdu. Nemelo by mu to stacit.

Proto me se libi treba clojure.spec. I kdyz je clojure dynamicky jazyk tak spec mu pridava neco jako "velmi silny typovy system" (Neni to primo v jazyku takze jsou potreba nejake nastroje na instrumentaci, proto "neco jako"). A krasne to integruje s testcheckem takze tomu muzu rict aby se pri buildu nahodne vygenerovalo bambilion vstupu odpovidajicich SPECifikaci a projelo se to funkci a vyhodnotilo jestli vystup taky odpovida specifikaci(a do znacne miry i jestli je spravne vzhledem ke konkretnim vstupum). Takze nemusim napsat jedinny unit test a mam pokryto radove lepe nez s unit testy.

Nemuzu. Nerozumim tomu :-). Vychazel jsem jen z toho, ze v matematice lze funkci vyjadrit tremi zpusoby. Dva z nich jsou pouzitelne i v programovani, tak proc ne ten treti?
Jedine co si dovedu predstavit je nejake vzorkovani, ktere problem redukuje na vycet hodnot, takze vlastne nuda.

No já v matematice poněkud plavu, ale měl jsem za to, že ten algoritmus je funkce, která počítá hodnoty, ze kterých se dá udělat taková ta křivka ukazující charakteristiku, jak ty hodnoty jdou.
Asi bych si dovedl představit, že někdo bude "programovat" funkci tím, že ji myší vytáhne v nějakém prostoru, a kompiler z toho odvodí funkci. Ale nedovedu si představit, že by to bylo praktické.

Dovedu si treba predstavit pripad, ze nejaky program generuje jako jeden z vystupu nejaky graf kam vynasi body ktere oznacuji nejaky konkretni pripad pouziti. Prijde business analytik a v grafu za posledni mesic vyznaci body, ktere jsou nezadouci. V pripade, ze se body pripadu pouziti budou shlukovat vhodne podle stejneho kriteria jako pouzije business analytik, muze byt prakticke nakreslit krivku ktera oddeli zadouci a nezadouci body a nechat si vyhodnotit funkci predpis kompilatorem. Ale jak kdysi rekl jeden mudrc: " na prakticnost vam prdim" :-)

663

Vývoj / Re:Typový system versus unittesty

« kdy: 27. 06. 2018, 13:17:55 »

Mohl bych videt prosim nejaky unit test na "funkci" rand?

Psát to sem nebudu, popis musí stačit: Lze testovat např. typ hodnot, interval, rozložení, shodu posloupností v případě implementace se seedem, ...

Nemel by prave typ hodnot podchytit typovy system? To same interval. Shodu s posloupnosti si taky dovedu predstavit.

664

Vývoj / Re:Typový system versus unittesty

« kdy: 27. 06. 2018, 10:11:25 »

Pokryti testy asi vetsina lidi chape jako (mnozstvi kodu spusteneho behem testovani)/(celkove mnozstvi kodu) a ne jako (mnozstvi testovanych vstupu)/(mnozstvi vsech moznych vstupu).

To, že otestuju tři hodnoty, a prohlásím, že kód je otestovaný, přičemž u čtvrté hodnoty to chcípne, to je poněkud smutné, nemyslíš?

Ale jo, ale to pokryti zajima spis management nez programatory. Je to nejaka metrika ktere si mysli, ze rozumi. Ja na svem projektu rozhodne zadne pokryti nemerim.

Funkce se da vyjadrit:

• analyticky - o to se vetsina programatoru snazi
• graficky - o to se vetsina programatoru nesnazi, ale mohlo by to byt zajimave
• vyctem hodnot - o to se vlastne snazi BoneFlute, akorat se mu nechce psat vsechny tak "zneuziva" typovy system

Asi bych se nespokojil s tím, že chápu funkci jen jako výčet hodnot, ale uznávám, že většina mejch ukázek je o tom.

Ale to grafické vyjádření funkce by mě zajímalo. Můžeš to prosím rozvést?

Nemuzu. Nerozumim tomu :-). Vychazel jsem jen z toho, ze v matematice lze funkci vyjadrit tremi zpusoby. Dva z nich jsou pouzitelne i v programovani, tak proc ne ten treti?
Jedine co si dovedu predstavit je nejake vzorkovani, ktere problem redukuje na vycet hodnot, takze vlastne nuda.

665

Vývoj / Re:Typový system versus unittesty

« kdy: 26. 06. 2018, 21:52:40 »

Nicmene tvuj priklad krasne ukazuje, ze pri pouziti vhodnych typu ztraci smysl vsechny negativni testy.

Což je ovšem dost slabé tvrzení oproti původnímu „nejsou potřeba žádné testy“.

Ja ani tak nerikam, nejsou potreba, ale spis nejdou napsat. Je to uplne odlisny vyrok. Nedaval bych to do souvislosti.

Za prvé je z toho hned vidět, že definovat funkce výčtem hodnot je pro reálné programy v drtivé většině případů nepoužitelné. Až začnete psát o tom, že se to přece dá nějak redukovat a nevypisovat všechny hodnoty, ale nahradit to nějakým předpisem – pak právě přijdou na řadu ty testy, které porovnávají, jestli ten předpis pro některé zajímavé hodnoty dává opravdu tu hodnotu, která by měla být v tom výčtu.

A ja myslel, ze sem se vyjadril fakt pochopitelne. Asi ne.

Za druhé, pokud by vám nemožnost udělat úplný výčet připadala jako nějaké dočasné technické omezení, vzpomeňte si třeba na funkce rand() nebo na faktorizaci velkých čísel – kdybychom dokázali ty funkce definovat výčtem hodnot, přestaly by být zajímavé a nikdo by je nepoužíval.

Mohl bych videt prosim nejaky unit test na "funkci" rand?

Za třetí, pořád předpokládáte, že výkonný kód i test vzniká stejným způsobem a píše to ten samý programátor. Ve skutečnosti kdyby vám někdo dal funkci (i se zdrojákem) definovanou výčtem hodnot a tvrdil by vám, že ta funkce dělá X, první co byste udělal, že byste si v tom zdrojáku vyhledal pár hodnot a ověřil byste, že alespoň pro tyhle hodnoty opravdu dělá X.

Urcite ne.

666

Vývoj / Re:Typový system versus unittesty

« kdy: 26. 06. 2018, 17:35:22 »

...v případě Typového systému máme 100% pokrytí z principu vždy...

Nikoho tu tato věta nevydráždila...?

Tak povídej :-)

Pokryti ceho a cim?

Měl jsem na mysli trivialitu v tom, že:

Kód: [Vybrat]

fn foo(Byte: x):

je ekvivalentní:

Kód: [Vybrat]

fn foo(x):

fn test_foo():
    foreach x in [0, 1, 2, 3, 4, 5 , 6, ... 255]:
        foo(x)

fn test_foo_fail_string():
    foreach x in ["a", "b", "c", ... "aa", "bb", ...]:
        exceptedException
        foo(x)

fn test_foo_fail_float():
    foreach x in [1.1, 1.2, 1.3, ...]:
        exceptedException
        foo(x)

a vlastně ten rozvoj je nekonečný...

Pokryti testy asi vetsina lidi chape jako (mnozstvi kodu spusteneho behem testovani)/(celkove mnozstvi kodu) a ne jako (mnozstvi testovanych vstupu)/(mnozstvi vsech moznych vstupu).

Nicmene tvuj priklad krasne ukazuje, ze pri pouziti vhodnych typu ztraci smysl vsechny negativni testy. A nejen smysl, ale vlastne ani nejdou napsat/spustit, protoze ta typovane verze funkce proste nejde zavolat s jinym typem argumentu.

A ted se pokusim odpovedet na otazku zivota vesmiru a vubec (a jelikoz nedelam v haskellu tak by to mohlo trknout i Filipa a Kita)

Funkce se da vyjadrit:

• analyticky - o to se vetsina programatoru snazi
• graficky - o to se vetsina programatoru nesnazi, ale mohlo by to byt zajimave
• vyctem hodnot - o to se vlastne snazi BoneFlute, akorat se mu nechce psat vsechny tak "zneuziva" typovy system

A potom je to uz jasne ne? Kdyz mam uz v definici vstupu a vystupu zakodovano chovani funkce (protoze jsem zapis funkce vlastne nahradil lookup tabulkou) tak prece nepotrebuju zadne unit testy ktere overi vysledek pro nejake mizive promile tech moznych vstupu. To je prece jasna duplicita.

A jako bonus dokonce ani nepotrebuju psat telo funkce, protoze vsechno je uz v podpisu.

667

Vývoj / Re:Typový system versus unittesty

« kdy: 26. 06. 2018, 14:58:01 »

...v případě Typového systému máme 100% pokrytí z principu vždy...

Nikoho tu tato věta nevydráždila...?

Tak povídej :-)

Pokryti ceho a cim?

668

Vývoj / Re:Typový system versus unittesty

« kdy: 26. 06. 2018, 13:30:06 »

Pak je podstatná ještě jedna věc, která tu zatím moc nebyla zmíněna, a to je to, že typový systém může něco užitečného přinést jedině tehdy, když se používá, tedy když ho programátoři chtějí používat. Stačí se podívat na takové malinké vylepšení hloupého typového systému Javy, jakým jsou kontrolované výjimky. Ani tohle drobné typové omezení se prakticky neujalo, a to je velmi jednoduché kontrolované výjimky jak definovat, tak používat. I to připadá většině Java vývojářů jako zbytečně moc práce v porovnání s jejím přínosem. Takže navrhovat nové typy pro masové použití klidně můžete, ale pak se vám také klidně může stát, že budou vznikat a široce se používat knihovny, které budou jako jednu ze svých důležitých vlastností uvádět to, že ruší ten váš typový systém.

Kdyby ten system za neco stal, ve smyslu ze pridana hodnota prevysi overhead ktery prinasi, tak by ho programatori radi pouzivali. Jenze tomu tak v jave prave neni.

669

Vývoj / Re:Typový system versus unittesty

« kdy: 25. 06. 2018, 23:00:56 »

Nejprve spustím test, ten spustí kompilaci jednotky a otestuje ji. Test tedy spouštím při překladu nebo ne?

Ne. Testy se spouští při buildu. Build a compile není to samé.

To bych se načekal. Někdy spouštím testy i 3× za minutu.

Podle me nepoustis testy, ale aparatus. Aparatus zajisti, ze se prelozi "jednotka" (pricemz probehne typova kontrola) pak se prelozi test a nakonec se test spusti. Takze unit test se spusti (tesne) po prekladu, ale rozhodne ne pri nem.

670

Sítě / Re:UBNT - zjištění aktuální dostupné verze firmware

« kdy: 21. 06. 2018, 09:26:08 »

Nebo se da podivat co vola ta hromada javascriptu a zavolat si to se spravnou header:

Kód: [Vybrat]

curl -H "x-requested-with: XMLHttpRequest" https://www.ubnt.com/download/?group=isostation-ac

Taky vraci JSON.

671

Vývoj / Re:Typový system versus unittesty

« kdy: 18. 06. 2018, 10:16:31 »

Zdravím.

Dospěl jsem k nezdravému přesvědčení, že jednotkové testy nejsou potřeba máte-li kvalitní typový systém.

(Teď samozřejmě neřeším který jazyk a zda něco takového má.)

Zajímalo by mě, můžete zkusit uvést nějaký příklad konstrukce, na kterou je nutné napsat test, protože typem to podchytit nejde?

Díky.

Je to kacir. Upalte ho!

A ted vazne. Budeme povazovat napriklad clojure.spec za soucast typoveho systemu, nebo nastroj pro testovani?
A co generativni property based testing (napr. QuickCheck)? Je definice vlastnosti funkce typova zalezitost nebo testovaci?

Btw. diky za to otazku. Samotneho by me ani nenapadlo o tom premyslet a ted mam pocit ze jsem dosahl dilciho osviceni.

672

Vývoj / Re:OOP jazyk - problém klasického stříhu

« kdy: 08. 06. 2018, 15:52:23 »

Jenže co je potom řešení. Viz javascript, ten OOP není a javascriptáři tam píšou procedurálně. Doteď jsem nenašel žádnou JS knihovnu komponent, která by šahala po kotníky třeba Primefaces nebo nějakému jinému komponentově orientovanému frontendovému frameworku (které se přestávají používat).

https://www.primefaces.org/#primeng
https://www.primefaces.org/#primereact

Už je to tady takových 20 let, dělají se s tím weby - typická věc plná různých grafických klikátek - a ti blbci si nebyli schopni za tu dobu udělat unifikovanou, odokumentovanou knihovnu komponent.

Taky delas weby? Jak dlouho? Uz si udelal takovou knihovnu? Nebo se hrde hlasis k tem blbcum co toho nejsou schopni?

Teď je rok 2018 a já nemůžu sehnat pořádného fungujícího emailového klienta, který by uměl 2 věci: email a kalendář (kteý umí nějaký ten standardní protokol, co používá google). Zkoušel jsem Outlook, že by to mohla být kvalita, ale ten nepodporuje otevřený standard pro kalendář, který používá Google - jen uzavřený od Microsoftu. Navíc má různé absurdní bugy. Thuderbird ok, ale nemá kalendář. Tak jsem hledal, až jsem našel vyhlášený eM Client, který je placený. Stáhnul jsem si ho, dal jsem si tam účty a při komunikaci se zákazníkem jsem zjistil, že mi do Odeslaných jednou email uloží, jednou ne - takže nevím, jstli jsem to poslal nebo ne a musím otevířat webový gmail. DPČ ROK 2018 a člověk kuwa nemůže sehnat fungujícího emailového klienta s kalendářem!!! Hlavně že se vymýšlejí a dělají ty krávoviny typu webové aplikace a všichni si stěžují jak je sw vývoj drahý.

Proc ho nenapises? Jsi prece programator nebo ne?

A to bych mohl pokračovat a už to bude fakt dost offtopic. Mohl bych mluvit o tom, jak nemůžu sehnat fungující šlapátka na kolo do 600,- Kč která by nešla za 1500km do kopru. Musel jsem si koupit šlapátka za 1400,- s vyměnitelnými průmyslovými ložisky. Prostě člověk chc takovou kravinu, co se vyrábí už X desítek let, a musí za to uvalit přes 1000,- aby to fungovalo jak má. Koupil jsem si značkovou bluetooth myš za 700,- a seká se ji kurzor - po čtení v recenzích prý běžná věc - myš nepoužitelná. Tachometr na kolo bluetooth za 600,- odešel po roce a nejtých 900km, navíc měl návrhové vady, že si nebyl schopný uložit napevno data, při výmně baterie se vše smaže. A mohl bych pokračovat a pokračovat.

Tady souhlasim. Pricinou je marketing.

673

Studium a uplatnění / Re:Jak pokračovat po Javě SE

« kdy: 07. 06. 2018, 17:19:33 »

Díky za odpovědi. Po velké hromadě rad bych trošku zúžil výběr. Studuji na VŠ první ročník, mám 2 roky dokonce. Takže bych se chtěl naučit věci, které mi pomohou k přijetí na juniorskou java pozici.

Když bych to zobecnil, tak bude mi stačit tento výpis?
Umím: Java SE, SQL na pokročilé urovni, JDBC, MySQL, + Maven
Naučit: Servlet + JSP, Spring, Spring MVC, Spring Security, Hibernate/JPA, Web Services, HTML/CSS (jsem tak napůl cesty momentálně se znalostí) a JS, JSON

Přidal jsem html/css a JS, protože spousta nabídek práce má požadavek na znalosti html/css a JS, i když se jedná o java pozici...

Uz jsem potkal "seniory" kteri neumi ani to co ty popisujes ze umis....(a btw mam 10+ let praxe a stejne si netroufam rict, ze to umim)
Jestli chces pracovat az za dva roky tak bych ted nesepisoval seznam veci ktere se musis naucit.
Co zacit pracovat na part time uz ted? Treba jen na jeden den v tydnu?
Jestli opravdu umis co rikas ze umis tak pri soucasne situaci na trhu prace to podle me nebude problem.
Osahas si realne projekty. Sam uvidis technologie co se pouzivaji v praxi...

674

Studium a uplatnění / Re:Výběr vhodného OOP jazyka

« kdy: 07. 06. 2018, 12:18:53 »

Ano, tak nějak. Zapouzdření a OOP jsou dva ortogonální koncepty. Pojem OOP jako takový jen zastřešuje vlastnosti jako polymorfismus a sloučení dat s relevantními funkcemi. Javistům to ale vysvětlit nejde, protože Dunning-Kruger. O PHPčkářích už vůbec nemluvě...

Tak sem si cetl o te studii a pokusu co Dunning a Kruger udelali. Jestli jsem to pochopil spravne tak prave potom co ty nekompetentni byli pouceni tak se jejich sebehodnoceni i uroven kompetence zlepsily.
Takze jestli radis javisty do skupiny nekompetentnich tak podle Dunning-Kruger by prave vysvetleni melo pomoci.
Pokud radis javisty do skupiny kompetentnich tak to asi vysvetlovat nebudou potrebovat.

675

Vývoj / Re:OOP jazyk - problém klasického stříhu

« kdy: 06. 06. 2018, 22:34:59 »

Ve všech případech to říkám nějaké proxy: database, email, validace, tisk...

Ne, ve všech případech to říkáte objektu User (posíláte mu zprávu „send“). A těžko pokryjete vše, co lze s objektem User dělat, jednou službou send s jedním rozhraním.

Pokud budu potřebovat, tak to rozhraní mohu přetížit. V objektu User je jednořádková metoda send(), která zavolá tu proxy a předá jí data. Na tom není nic složitého, prostě DI.

Co kdyz budu mit v aplikaci dalsi tabulky? Customers, Officers, Managers...
A taky jim chci umet poslat email, ulozit do databaze, vypsat do logu...
Bude mit kazda svou tridu? Kazda metodu save, send, toString?
Budou implementovat stejne rozhrani?
Budou ty proxy umet pracovat se vsemi takovymi tridami? Nebo bude pro kazdy typ jina proxy?