Příspěvky

31

Vývoj / Re:Programátorský úkol

« kdy: 11. 09. 2017, 18:01:37 »

Byly to http://adventofcode.com a https://www.codingame.com. Ten prvni jsem zkousel predchozi verzi (rok zpet) a je to podobne tomu eurlerovi (navic s tematickym textem). Druhe jsem moc nezkousel a nevim, jestli to bude pro vas, je to mozna pro uplne zacatecniky a mozna cilene spise na mladsi (tematika komisku, her a tak, asi to nemusi kazdemu sednout; ale mozna kecam, moc jsem od tam nezkousel). Na rozdil od codewars ale (minimalne ten advent of code) nemaji zadne srovnavani kodu s ostatnimi lidmi.

Asi jich par zkuste a uvidite, co vam nejvice sedne. Pripadne prostridat, nebo si ty bez vzorovych reseni nechat az udelate par nizsich urovni v codewars, a pak jimi procvicovat spise algoritmy/mysleni nez jazyk/std. knihovnu.

32

Vývoj / Re:Programátorský úkol

« kdy: 11. 09. 2017, 16:40:37 »

Abych byl uprimny, tak si myslim, ze vse bude tezce zaviset na tom, kam a na jakou pozici se clovek hlasi - podle toho budou lepe hodnocena elegantni abstraktni jednoducha reseni (napr. vyssi prog. a FP jazyky) versus rychla ukecana reseni (asi "nizsi" jazyky typu C, programovani krabicek atp.). Mozna by to clovek u pohovoru mel spise brat neutralne (nekdo to uz myslim psal) a dalsi otazka by mela byt na vykon zvoleneho reseni, pobavit se o tom, proc zvolil takovy postup/dat. strukturu/jazyk, atp.

Osobne bych se trosku bal, ze programator, ktery si to zacne vse psat od podlahy bude mit problem v praxi pouzivat knihovny a bude si radeji vse psat sam (nema prehled o std. knihovne ci ekosystemu) a tedy plytvat penize zamestnavateli. Ale to je dost mozna jen muj subjektivni pohled na vec zkresleny z Haskellu, vyssich jazyku a prace, kde se silne preferuje klidne velmi suboptimalni reseni, pokud to usetri cas vyvoje.

Na skolni ulohu bez nastavenych limitu s trivialnimi vstupnimi daty jsou IMO ta jednoducha reseni spravna, v realnem svete bude zalezet na zadani a tedy na projektu, jazyku, povolenych knihovnach a bambilionu dalsich veci.

PS: Ja pridal dve hezke sajty podobne eurlerovi/codewars (nikdo na to myslim nereagoval), asi to zapadlo ve zbytku prispevku. 

33

Vývoj / Re:Programátorský úkol

« kdy: 11. 09. 2017, 16:11:27 »

toto je mozne naozaj len na roote. zacinam pochybovat, ze tu chodia odbornici. skor su to len "odbornici" dokazujuci si ego.

první 3 řešení jsou dobrá. Pokud pracujete jako freelancer je dobré podobné úlohy trénovat, občas se stane, že si vás potenciální zákazník na něčem podobném prověří.

Co se vam nelibi na mem 4tem reseni? Jestli to chapu spravne, tak to dela to stejne*, co treba to treti a ma nizsi wtf-faktor .

*: Teda je to cyklus vs rekurze, kterou asi stejne prekladac transformuje do cyklu, takze tam asi rozdil moc nebude.

34

Vývoj / Re:Programátorský úkol

« kdy: 11. 09. 2017, 10:10:25 »

Ke codewars a project euler bych doplnil jeste https://adventofcode.com (posledni verzi jsem nedelal, ale predposledni se mi hodne libila - kratke pribehy za ulohami byly skvele ) a https://www.codingame.com (to jsem moc nezkousel, ale minimalne zacatky to vypada zajimave).

35

Vývoj / Re:Programátorský úkol

« kdy: 11. 09. 2017, 09:04:44 »

Jak pise cumil, v praxi predcasna optimalizace jen skodi - ve vetsine pripadu je totiz zcela zbytecna, protoze realne bottlenecky byly/jsou jinde (napr. db, disk, sit). Optimalizaci se akorat zavlece spousta chyb a celkove cena bude vyrazne vyssi. Nevim, co resite s knihovnami, me reseni, ktere lze zkratit takto (mozna to pujde i vic):

Hezky si protiřečíte – nejprve odsuzujete předčasnou optimalizaci, a pak hned jednu předvedete (zkracování kódu).

Kdybych chtel jet na delku, tak tohle je kratsi:

Kód: [Vybrat]

import Data.List
snakeWalk2 y = case y of (x:xs) -> x ++ snakeWalk2 (reverse $ transpose xs); [] -> []

Ale asi mate castecne pravdu, moje puvodni reseni je nejlepsi z hlediska udrzovatelnosti a splneni pozadavku zadani. Tohle^ reseni je horsi, prestoze ma mene radku (ma vice znaku na radek, horsi citelnost, ale mozna z pohledu pravdepodobnosti mnozstvi chyb to vychazi lepe). Programator se IMO ma snazit nemit svuj program zbytecne dlouhy (vhodne pouziti podmineneho vyrazu, preferovani fluent interface, pouzivani FP pristupu, kde to dava smysl atd.), smozrejme, se to nesmi prehnat, aby zase neutrpela citelnost. Po pravde vice necitelne mi prijde treba if-else roztahane na 5 radku, prestoze obe vetve vraci trivialni vyraz -> po prevedeni na podm. vyraz v return je to na jeden radek misto 5, kde vice jak polovina jsou zbytecne (priklad z pouzivani JS a bezneho stylu vynucenych slozenych zavorek u if a else). Podobne case classy ve Scale (casto 1 radek) vs. ty hruzy v Jave (desitka radku a vic, protoze fieldy+gettery+settery).

pro zadana data to nebude mit snad ani meritelny horsi vykon oproti tem "optimalnim" necitelnym resenim (v zadani neni pozadavek na rychlost/pametovou narocnost; navic nekdo pokrocilejsi uvdel nejakou knihovnu, ktera mozna resi i ten problem s vykonem).

Vaše řešení je ovšem také nečitelné, zejména proto, že dělá něco úplně jiného, než je v zadání. V zadání není ani slůvko o otáčení matice. Jistě, lze relativně snadno dokázat, že řešení s transpozicí matice je ekvivalentní zadání, ale to už je něco, co v tom vašem řešení není vůbec vidět.

Tohle je nevýhoda školních úloh, že známe jenom malinkou část zadání, takže není možné rozhodnout, které řešení je nejlepší. Možná by to byl jen nějaký prototyp nad malými daty, takže nevadí, že pracuje s daty neoptimálně a není jasné, co dělá. Možná máme k dispozici knihovnu, která transpozici provádí tak, že nechá data na místě a změní implementaci metod, které se nad maticí volají. Nebo je možné, že „šnekovité“ procházení je jen jeden z více požadovaných průchodů maticí a další bude třeba procházení cik-cak, kde transpozice nepomůže, takže je správné implementovat různé způsoby průchodu maticí.

Jak jsem psal - zadani to splnuje, pro zadana data to funguje, o nejakem skalovani ci omzenenich neni v zadani ani slovo. To, co pise nekdo s parserem v Pythonu, to vidim jako chybu zadani - chybela zminka o tom, ze povaha testovacich dat neodpovida datum v produkci a take jak to ma byt rychle (asi se mely dodat testovaci data podobna tem v produkci, pripadne predepsat omezeni - napr. 1GB dat za minutu), nebo chyba na strane programatora - nedodrzeni zadani. V praxi se nesetkavam s tim, ze mam presne predepsany algoritmus (ale priznavam, ze to se muze dost lisit, asi jsem spis dev, nez programator, pracuju v male firme, na projektu doslova par lidi, klient setri jak muze a asi bude hrat roli jeste vice faktoru) - vetsinou jde o vyreseni ukolu, ne o implementaci presne zadaneho algoritmu. Stejne tak nemivam zadane vnitrni struktury, omezeni na pouzivane oprace atp. Pokud knihovna vyrazne zkrati dobu implementace, tak navrhnu jeji pouziti a ve vetsine pripadu je to schvalene (maloco z obecnych veci si opravdu musim implementovat sam).

36

Vývoj / Re:Programátorský úkol

« kdy: 11. 09. 2017, 07:33:39 »

Jak pise cumil, v praxi predcasna optimalizace jen skodi - ve vetsine pripadu je totiz zcela zbytecna, protoze realne bottlenecky byly/jsou jinde (napr. db, disk, sit). Optimalizaci se akorat zavlece spousta chyb a celkove cena bude vyrazne vyssi. Nevim, co resite s knihovnami, me reseni, ktere lze zkratit takto (mozna to pujde i vic):

Kód: [Vybrat]

import Data.List
snakeWalk (x:xs) = x ++ snakeWalk (reverse $ transpose xs)
snakeWalk [] = []

Pouziva to jen std. knihovnu, je to velmi citelne na rozdil od tech rucnich prochazeni matici, a pro zadana data to nebude mit snad ani meritelny horsi vykon oproti tem "optimalnim" necitelnym resenim (v zadani neni pozadavek na rychlost/pametovou narocnost; navic nekdo pokrocilejsi uvdel nejakou knihovnu, ktera mozna resi i ten problem s vykonem). Take k tomuto kodu nemusim pomalu psat testy, nebo jen velmi malo. Kdyz caruji s indexy, bodam na pameti a mam nekolik vetvi, tak bude potreba dost testu, abych si byl jisty, ze to opravdu funguje vzdy. A svete div se, ne vsude se testuje (nekde jsou dokonce testy prisne zakazane jako ztrata casu), tam je pak muj naivni FP pristup nejvhodnejsi, protoze kod je tak kratky, ze sance na chyby je mala (vzpominam na studie, ze pocet bugu roste se delkou [znaky/radky] zdrojaku).

PS: Za nepouziti knihoven a matlani si hranatych kol se bezne vyhazuje. Bavime se snad o praci, ne o skole, ne?

37

Vývoj / Re:Programátorský úkol

« kdy: 10. 09. 2017, 10:04:38 »

Po pravde jsem si nebyl jisty co to Pythoni reseni dela (z fci map a zip bych to moc necekal, ze je to to stejne jako ten snippet z Haskellu). Na to, ze se v Pythonu udajne jede na citelnost, mi tohle jako nezasvecenemu moc citelne neprislo .

38

Vývoj / Re:Programátorský úkol

« kdy: 10. 09. 2017, 09:49:00 »

...
Haskell sice vubec neznam, ale jestli ten zapis znamena: vrat prvni radek pole spojeny s vysledkem rekurzivniho volani na otocenem poli bez prvniho radku, tak je to prudce elegantni a asi nejlepsi (ne nejefektivnejsi, ale to tady neva).

Jop, to to dela. Ne no, neni to asi prehnane efektivni z pohledu vykonu* a asi ne ani nejvice idiomaticky Haskell (tipuju, ze pujde pouzit nejaka higherorder funkce, pripadne prepsat pointfree styl).

*: Pochybuji, ze to prekladac zvladne optimalizovat na uroven pruchodu polem v cyklu a vypisem primo pri provadeni.

PS: Tak nejaky pointfree convertor mi vytvoril tohle monstrum:

Kód: [Vybrat]

snakeWalk = fix ((`ap` tail) . (. head) . flip ((.) . (++)) . (. (reverse . transpose)))

Osobne si myslim, ze neni vsude nutne cpat point-free, pokud to nezlepsi citelnost kodu.

39

Hardware / Re:El. cigareta

« kdy: 10. 09. 2017, 09:37:53 »

taky by jeden mohl mit digitalni zrcadlovku bez displaye na tele nebo v hledacku.

Kdyz to ma display v hledacku, tak to neni zrcadlovka a za spatneho svetla tam je hovno videt.

Ja myslel ten overlay pres obraz ze zrcatka, coz asi mate pravdu, nebude pravy displej.

....nyni si ja noob jen nastavim foceni do raw a vetsinu za me udela automatika (expozici lze pak bez ztrat ladit pri "vyvolavani", ale i tam je vetsinou vysledek automatiky velice dobry a nemusim ani nic stelovat rucne).

Az jednou clovek narazi na to, ze bez rucniho ostreni a expozice fotku neudela. A oboji na tech kramech teoreticky jde, ovsem treba ostreni podle displaye jaksi neni to same, jako ostreni podle zaostrovaciho hranolu, zejmena znovu za tech spatnych svetelnych podminek.

Priklad s fotakem moc nesedi. Nekdy se automatika hodi, nekdy je na obtiz.

Souhlasim, ze ne vzdy je automatika lepsi (proto se casto pouzivaji ty poloautomaticke rezimy, kdy nastavite jednu/dve veci a fotak nastavi zbytek), ale co jsem cetl nazory profiku, tak vetsine ta automatika znacne ulehcuje a tim zrychluje praci (treba mereni svetla a rucni pocitani se ve spouste pripadu nemusi vybec resit). Proste vetsinou ta automatika funguje a resi se akorat vyjimecne pripady, kdy nefunguje. U te cigarety je to jeste vyhrocenejsi, protoze tam snad nevyhody nejsou (mozna vyssi moznost, ze se neco polame na tom pidi disapleji ci elektronice?). Tam je vzdy vyhoda vedet teplotu ci stav baterie, takze IMO je to velmi vyhodny tradeoff - mnoho uzitecnych ficur za trosku zvysenou sanci rozbiti (zvlast kdyz OP neresi cenu).

Kdysi jsem chvili pouzival "hloupou" ecigaretu, takovou tu vse v jednom pro zacatecniky. A prestoze jsem to nepouzival moc dlouho, tak treba to zobrazeni stavu baterie mi dost chybelo.

40

Hardware / Re:El. cigareta

« kdy: 10. 09. 2017, 08:55:25 »

ma to OLED displej, jde konfigurovat parametry "spalovani"...

Wow! Je ten display aspon HD, s 16 milionama barev? Je dotykovy? Ma to GUI s dlazickama?

Mozna vam to prijde jako prehanane, ale nemyslim si. Sam to nemam, ale vim, ze existuji unverzalni "gripy" na kterych lze nastavit vykon (zalezi jaky atomizer pouzijete, jake spiralky, jaky eliquid [mozna v necem kecam, je to z druhe ruky]), tepelny management, videt stav nabiti baterky, odpor spiralky, cas atp. Vse je to IMO uzitecne. Je to podobne jako s fotakem - taky by jeden mohl mit digitalni zrcadlovku bez displaye na tele nebo v hledacku. Ale neni duvod to nemit - prinasi to moznosti, ktere  vyrazne usnadnuji pouzivani, zlepsuji vysledek, zkracuji praci. Videt nahled fotky, historgram, hodnoty ruznych nastaveni (expozice, uzaverka, clona, iso) - kdyz jsem cetl, jak se driv slozite muselo merit svetlo ci resit vyvazeni bile a nyni si ja noob jen nastavim foceni do raw a vetsinu za me udela automatika (expozici lze pak bez ztrat ladit pri "vyvolavani", ale i tam je vetsinou vysledek automatiky velice dobry a nemusim ani nic stelovat rucne).

41

Vývoj / Re:Programátorský úkol

« kdy: 10. 09. 2017, 08:24:30 »

Hezky ukol, donutil me si zase sahnout na Haskell. Tady je moje ctvrhodinka snazeni:

Kód: [Vybrat]

import Data.List

snakeWalk :: [[Integer]] -> [Integer]
snakeWalk (x:xs) = x ++ snakeWalk (reverse $ transpose xs)
snakeWalk [] = []

42

O serveru Root.cz / Re:Nový Root již dnes?

« kdy: 12. 08. 2017, 08:12:31 »

Redakce optimalizuje pro bezne parametry mobilu a jinych zarizeni pro prohlizeni webu. Jednoduse proto,ze se jim to vyplati. Vyplati se jim platit vyvojare pro optimalizace na neco,co pouziva rekneme 0.1% lidi? Urcite ne, to se nikdy nezaplati..

Aha, takze Android 6 ve full HD s Chromem pouziva min nez 0.1% lidi? Myslim, ze neni treba hledat zadne statistiky abych vedel, ze to bude mnohem vice nez 0.1% .

Jiste, nemusi to delat, ja to resim adblockem a vlastnim skinem = zadne skakani + pro me pouzitelny vzhled. Drive jsem reklamy mival zaple. Po redesignu, kdy se vykvakli ve velkem na komunitu a meli jeste tu drzost v clanku se vychloubat s tim, jak skvele spolupracuji s komunitou (jak budou podporovat alt. skiny*, jak vyresili vsechny nahlasene problemy**), jsem ty reklamy na desktopu vypnul celkem rychle (stravil jsem dost casu hranim si s vlasnim skinem, protoze ten jejich byl otresny => nebudu je podporovat reklamami; kdyby meli jednoduche zasilani prispevku za jednotlive clanky, ktere jde do kapsy primo autorum, tak klidne nejakou korunu prispeju, ale nebudu podporovat tenhle bordel). Na mobilu roota moc nectu, ale po tom, co jsem se dozvedel, ze zakazani reklam opravi stranku, jsem je take zacal blokovat.

*: To byla lez. Nejaky jejich webdev napsal, jak hrozne spatne je ten alt. skin udelany a po zadosti o dokumentaci/changelog, aby se to teda mohlo predelat spravne, se zacali cukat a nic dalsiho se nestalo.

**: Opravili akorat ty nejvice amaterske problemy, jako treba rusiva animace v headru. Poskakovani kvuli reklamam je tu mesice, nebo snad uz rok? Osobne se mi nelibi ani lazy loading na obrazcich - na mobilu skroluju a misto toho, aby se vse nacetlo po otevreni stranky, musim u kazdeho obrazku pockat az se nacte po naskrolovani. BTW uz konecne opravili ty styly, aby to nebylo nekolik souboru, navic neminifikovanych? Mam pocit, ze stary design byl pro mobil mnohem lepsi, nez tahle kul verze.

Asi bych se mel zase podivat na ten rozdelany prepis front-endu pro roota. Sice to nejak funguje, ale je to dost zakladni - pouze cteni clanku (zadne komentare, starsi clanky atd.). Mozna kdybych to dodelal, tak by zbystrili a konecne dodelali tu jejich verzi.

43

Vývoj / Re:Funkcionální programování a mainstream

« kdy: 23. 07. 2017, 06:45:19 »

(Kdyz jsme tak u toho - nemam moc rad, kdyz se FP "prodava" s tim, ze pomuze paralelismu - ve skutecnosti to prekladace funkcionalnich jazyku zatim moc neumi, a je to trochu zavadejici argument, ktery muze vzbudit prehnana ocekavani. Mam FP rad, ale IMHO hlavni duvod je vyssi abstrakce a lepsi vysledna citelnost, nicmene technologie prekladacu jeste nedosahla dostatecne urovne, aby tohle dostatecne vykompenzovala.)

Pokud se bavime o FP namixovane s OOP, tak treba ve Scale to bylo o pouhem pridani volani par do chainu (priklad z doc list.par.map(_ + 42)). Pripadne pouzivani knihovny jako Akka - pokud mate stavajici kod FP, tak IMO nebude obtizne to preklopit do Akka a ziskat tak skoro zadarmo paralelni zpracovani. Nebo mate na mysli nejake implicitni paralelni zpracovani, ktere na zaklade neceho pouzije prekladac/runtime?

(Jinak za me by stacila i jen ta vyssi abstrakce, ale moznost jednoduse paralelizovat stavajici FP kod neni take k zahozeni.)

44

Vývoj / Re:Funkcionální programování a mainstream

« kdy: 22. 07. 2017, 20:55:14 »

+1

plus to má další více či méně teoretické výhody.

Jeste bych doplnil, ze moznost "zadarmo" psat kod pripraveny pro paralelni zpracovani je IMO velke plus. To se v popularnich implementacich OOP jaksi nenosi. Dalsi vyhoda je, ze psani testu pro FP kod je velmi jednoduche - zadne mocky a jine berlicky, proste mam vstup (parametry funkce) a vystup (jedna hodnota, ktera bude vzdy zaviset pouze na vstupu a ne na cemkoliv ve svete).

45

/dev/null / Re:Jak neposílat faktury aneb dement v akci

« kdy: 19. 07. 2017, 06:56:33 »

Mozne je to i pod Tuxem, minimalne to se spustitelnosti souboru. Staci ho ulozit z mailoveho klienta do primounteneho NTFS, kde ma vse executable flagy (alespon myslim, ze je to vychozi chovani v Ubuntu, kdyztak me opravte). Ale osobne bych to teda nebral jako chybu Linuxu, kdyz je to v podstate zpusobene cizim fs/os.