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 - Filip Jirsák

Stran: 1 ... 242 243 [244] 245 246 ... 375
3646
Zapomněl jste napsat, co má být výsledkem. Z nevalidní konstrukce to můžeme jenom hádat… Chcete, aby když nemá fooproperty hodnotu false, aby se do property nastavilo null?

Já si myslím (sic!), že to pomocí reference nejde – kdybyste tam chtěl vložit null přímo, musel byste použít vnořený tag <null/>. Ono by se v tom konfiguračním XML nemělo programovat, podmíněnou konfiguraci je lepší řešit profily nebo konfigurací v kódu.

3647
Vývoj / Re:Dedicnost OOP + biologia
« kdy: 22. 11. 2017, 22:11:10 »
Dědičnost v OOP znamená, že předek má nějaké společné vlastnosti, které má i každý jeho potomek – a potomek má ještě nějaké vlastnosti navíc. V češtině to označuje slovo je – takže třeba strom je potomek rostliny, protože každý strom je rostlina. Máte to naznačené i v zadání – píše se tam „jak se má rostlina chovat“. Strom se asi má chovat jako rostlina, jablko ne. Učitel se má chovat jako zaměstnanec, ale ne jako škola nebo jako matematika.

V tom vašem příkladu tedy máte špatně jablko, protože jablko není rostlina. Otázka, zda každá rostlina má listy, je sice zajímavá, ale nesouvisí se zadáním – zadání se ptá na dědičnost, tedy na je, nikoli na . Podobně není pravda, že učitel je škola, učitel je vzdělání nebo učitel je matematika.

3648
Vývoj / Re:Java vs Kotlin vs ... pro aplikace pro Android
« kdy: 21. 11. 2017, 17:42:13 »
Já bych zvolil Javu. Kotlin obsahuje spoustu „cukrátek“, každý si bude chtít něco vyzkoušet a skončíte s kódem, který bude plný míst, o kterých většina programátorů nebude vědět, co vlastně znamenají. Pro využívání takovéhoto jazyka je podle mne potřeba velká disciplína a někdo s velkými zkušenostmi, kdo rozhodne, co se bude používat a co ne. A obávám se, že takovýchhle lidí s dostatečnou zkušeností s Kotlinem bude dnes jen velmi málo, prakticky jen vývojáři JetBrains a pár dalších.

3649
Vývoj / Re:Stromové struktury a tridici algoritmy
« kdy: 17. 11. 2017, 22:55:01 »
To není úzký výsek, to je něco, čemu se říká základy. Na nich je vybudováno to ostatní.
Ne, to nejsou základy, to je úzký výsek. Základy to nejsou v žádném případě, protože základy jsou část stavby, které je na stejné úrovni detailu, jako jiné části stavby (třeba střecha). Je to, jako kdybyste říkal, že základem stavby je písek, cement a voda. Jistě, jsou to suroviny pro výrobu betonu, ale stavba vzniká až z toho betonu – a stavitel potřebuje znát vlastnosti toho betonu, a jak se jich z toho písku, cementu, vody a dalších příměsí docílí, to je starostí někoho jiného.

Jinak mým oborem je průmyslová automatizace.
Děkuji za potvrzení.

O jejích specialitách a konkrétních technologiích, které člověk musí znát, aby se v tom oboru uplatnil, tu nepíšu nic.
Mýlíte se v tom, že tu o tom nepíšete nic. To, že píšete o programování jednočipů nebo oblasti, kde je v amatérské rovině třeba Arduino, přímo čiší z každého vašeho komentáře.

Ale znovu opakuji, že i když toho je obrovské množství (ne toho, co umím, ale toho, co se v této oblasti vyskytuje), není to nic, co by člověk, který zvládl základy, nepochopil.
Ano, ale ty základy jsou úplně jiné, než základy, které potřebuje znát někdo, kdo programuje GMail nebo Facebook.

A programátoři se nemusejí vyznat v základech programování, protože ... dnešní programování není založeno na algoritmech a datových strukturách? Tak jste to myslel?  :D
Když chcete dokazovat, že základy programování jsou algoritmy a datové struktury, nemůžete to zároveň použít jako předpoklad. Programování je stále založeno na algoritmech a datových strukturách, akorát ty algoritmy a datové struktury jsou podstatně odlišné od algoritmů a datových struktur, se kterými pracuje třeba quicksort. Datové struktury jsou třeba relační databáze, sloupcová databáze, key-value store, dokumentová databáze, grafová databáze, nebo dokonce REST API, a řešíte například to, jak data ukládat na více uzlů a jak zajistit konzistenci dat v případě, kdy se síť uzlů rozpadne na dva nebo více izolovaných ostrovů. Pořád jsou to datové struktury, ale dost jiného typu, než třeba nějaký spojový seznam. A při řešení těchhle datových struktur vyšší úrovně se někde vespod v implementaci určitě najde i ten spojový seznam – ale jsou to dvě dost odlišné úrovně řešení, a ten, kdo chce používat tu horní úroveň, nemusí vědět vůbec nic o té úrovni spodní. Stejně jako stavař potřebuje vědět, jaké vlastnosti má mít beton, který chce použít, ale neumí takový beton namíchat – a naopak ten, kdo umí ten beton namíchat, neumí postavit železobetonovou budovu.

Já to tušil, hned jak jsem tu odpověď odeslal, že se najde někdo, kdo se bude šťourat v tomto. Děkuji za upozornění na tento Váš cenný postřeh - občas si tu připadám jako mezi frekventanty pomocné školy.
Tak proč takové hlouposti píšete? Samozřejmě, že se vždy řadí podle nějakého kritéria, tak nechápu, proč jste místo toho napsal, že se řadí vždy podle velikosti. Jednodušší to není, srozumitelnější to není – prostě jste akorát napsal hloupost.

Z vašich komentářů je vidět, že máte pocit, že jsou tady jen samí hlupáci – no, jak je vidět, neznamená to, že byste si mohl dovolit psát hlouposti, protože i ti hlupáci na ně přijdou.

přiřadí nějaké číselné hodnoty a dané body potom srovnáme podle velikostí těchto hodnot
No to jistě. Co je to „velikost hodnoty“? Kolik bitů v binárním zápise je potřeba k zápisu té hodnoty? Nebo kolik číslic v dekadickém zápisu? Když už máte něco převedené na číselné hodnoty, porovnává se to v drtivé většině případů podle těch hodnot, ne podle jakýchsi „velikostí“ hodnot. A mimochodem, při řazení se nemusí řadit jen podle číselných hodnot. Text máte sice také zakódovaný do čísel, třeba podle ASCII nebo UTF-8, ale když se text řadí, neřadí se podle těchto číselných hodnot. Třeba už jen proto, že v UTF-8 můžete zapsat texty ve spoustě různých jazyků, ale pravidla pro řazení v těch jazycích jsou různá. Takže třeba znak „c“ má v Unicode hodnotu 99 (dekadicky), znak „d“ má hodnotu 100, ale mezi ně se v češtině řadí znak „č“, který má v Unicode dekadickou hodnotu 269.

Jediný rozdíl vidím čistě jazykový - seřadit = postavit za (vedle) sebe do řady. Když řeknu žákům, aby se seřadili, rozhodně to nemusí znamenat, že se mají seřadit podle velikos... totiž, pardon, nějakého kritéria (věku, hmotnosti, hustoty ranní stolice, velikosti...), ale že mají stát v řadě za sebou (v jídelně) nebo vedle sebe (při nástupu). Žádné pravidlo, podle něhož má zrovna žák B stát za žákem A a před žákem C tu nepozoruji. Řazení nutně nevyžaduje přítomnost nějakého kritéria. Pokud však něco třídím, činím tak zásadně podle nějakého kritéria, což je i podstatou třídicích algoritmů.
Ano, seřadit znamená uspořádat do řady, tedy u každých dvou prvků dokážete říci, jak jsou uspořádané – zda je jeden z nich víc vepředu nebo víc vzadu, než jiný prvek. Tady když budou žáci seřazení, dokážete říct, že např. žák A stojí před žákem B, nebo naopak, že stojí za ním. Mohou být seřazení podle nějakého kritéria, ale klidně mohou být seřazeni i náhodně. I pokud řadíte v počítači, vždy říkáte, podle jakého kritéria se má řadit – a nebo že má být řazení náhodné.

Naproti tomu třídění znamená (jak překvapivé) rozdělování do tříd. Nebo-li do skupin, které mají nějakou společnou vlastnost. Žáky můžete třeba roztřídit na chlapce a dívky. Nebo je můžete roztřídit podle známky z nějakého předmětu na vysvědčení. Ale chybí tam to pořadí – když máte žáky roztříděné, nemáte nijak určeno, zda je žák A před žákem B nebo až za ním.

Takže aspoň nějaký pozitivní výsledek tato absurdní debata pro mě měla - ve výše uvedeném odstavci jsem si aspoň ujasnil, že pojem "třídicí" algoritmy vůbec nebyl zvolen náhodně a že je rozhodně výstižnější než "řadicí".
Spíš jste si měl ujasnit, že „třídit“ znamená rozdělovat do tříd. Třídící algoritmy se tomu někdy chybně říká proto, že některé algoritmy používají pro řazení právě třídění. Například quicksort. Quicksort funguje tak, že prvky roztřídí na ty, které jsou menší než pivot, a na ty, které jsou větší. A rekurzivně pak stejným způsobem roztřídí každou z těch dvou tříd. Když pak seřadí každou tu dvojici skupin (což je triviální, protože ty skupiny se rovnou na začátku třídění vytvářejí tak, aby byly v té dvojici seřazené), máte ve výsledku seřazené všechny jednoprvkové skupiny a tudíž i prvky. Jde tedy o řazení tříděním, nebo-li quicksort je zároveň řadící algoritmus i algoritmus třídící. Akorát my ho používáme pro tu funkci řazení, takže je lepší ho pojmenovávat jako řadící algoritmus.

Nepsal jste tu, že znalost quicksortu je úplný základ? Já teda za znalost quicksortu považuju právě to, že quicksort řadí podle daného kritéria tím způsobem, že na základě pivotu a řadícího kritéria prvky roztřídí do dvou skupin, skupiny seřadí a rekurzivně pak pokračuje seřazením každé skupiny.

Jo. Rozdíl mezi exponenciální a logaritmickou složitostí je podle některých "mikrooptimalizace".
Ano, často to může být mikrooptimalizace. A někdy to dokonce může být antioptimalizace, protože u té logaritmické složitosti můžete mít nějakou vysokou konstantu, takže nakonec zjistíte, že pro typický počet prvků je ten exponenciální algoritmus rychlejší.

pochopení HTTP opravdu není nic, co by nezvládl běžný elektrikář během jednoho sezení v hospodě u píva; to opravdu nepatří mezi znalosti, které by zaměstnavatel musel vyvažovat zlatem
To samé ovšem platí i o quicksortu. I když, no – ale teď už snad po výkladu výše chápete, kde je v tom quicksortu schované to třídění, nebo ne?

3650
Vývoj / Re:Stromové struktury a tridici algoritmy
« kdy: 17. 11. 2017, 17:07:06 »
Připadá mi opravdu tristní, že tak přirozené a jasné věci tu musím psát.
Mně připadá tristní, že tu neustále předvádíte, o jak úzkém výseku programování něco víte, a přesto si myslíte, jak dobře rozumíte celému oboru programování a chcete o tom poučovat ostatní.

A to víte, nebo jen podle sebe usuzujete o schopnostech ostatních?
Já, na rozdíl od vás, neposuzuju ostatní podle sebe. Posuzuju vás podle toho, co jste napsal.

A taky takový forman věděl, co dát tomu koňovi nažrat, jak v závislosti na nákladu a těch koních jet, aby to netrvalo věčnost a přitom ty koně neuštvat, jak poznat, jestli (a co) má s nohou, jestli má zdravé zuby, jestli není nadmutý, uměl rozeznat klisnu od valacha, vyznal se v různých typech sedel a chomoutů a dokázal posoudit jejich vhodnost pro konkrétního koně a účel, vyznal se v základech sedlařiny, když bylo nezbytné něco opravit atd. Podle vás to byly zbytečnosti - koně dostane přece už osedlaného a on je tu jen od toho, aby tahal za opratě, že... Přece není žádný zvěrolékař ani kovář. Problematika koňů je přece tak strašně široká...
Ne, podle mne by to nebyly zbytečnosti. Podle mne to jsou zbytečnosti, dnes, pro inženýra vyvíjejícího robotické auto. Protože vám unikla taková drobnost, že dnes už hlavním prostředkem pro dopravu osob nejsou koně. Robotické auto není založené na koňovi, ani v něm nikde žádný kůň není ukrytý.

To je právě ten chybějící všeobecný přehled, kdy sice detailně víte, jak se správně starat o koně, ale už vám unikla ta souvislost, že auto sice nahradilo koně, ale auto není vylepšený kůň.

Ale když už to tu tak řešíte a považujete to za tak zásadní, tak bych tedy řekl, že "třídění" je přeci jen obecnější pojem a že řazení je vlastně jenom určitá forma třídění podle velikosti.
Neřadí se jen podle velikosti, třeba slova ve slovníku jsou řazená abecedně. Jména lidí na seznamech také bývají řazena abecedně, ono se v tom pak lépe hledá, než kdyby tam byli lidé podle velikosti. Je pravda, že se dá řadit i tak, že položky nejprve roztřídíte a pak seřadíte třídy. Ale řazení rozhodně není jen třídění – u řazení je podstatné to, že jsou ty prvky nebo třídy v určitém pořadí, tj. že ty prvky jsou na nějaké ose nebo škále a je definováno nějaké pravidlo, podle kterého se určí, že nějaký prvek má být dřív než jiný, nebo více vlevo, vepředu, nahoře. Když řeknete houfu žáků na hřišti, ať se rozdělí do skupin po pěti, tak se vám sice žáci roztřídí, ale ty skupinky nebudou nijak seřazené, budete je mít po tom hřišti různě roztroušené, podle toho, kde se zrovna sešli. Seřadíte je teprve tím, když jim řeknete, aby z těch pětic udělali pětistup.

3651
Vývoj / Re:Stromové struktury a tridici algoritmy
« kdy: 17. 11. 2017, 14:40:27 »
Myslím, že pokračování diskuse je zbytečné. Vy si prostě myslíte, že programování je velice úzký obor, že nejnovější výkřik techniky, se kterým se programátor může setkat, je Pentium, a když bude takový programátor řešit výkon nějakého programu, bude řešit, jak se mu v tom Pentiu ty instrukce poskládají za sebou. Já si zase s dovolením budu dál myslet, že  takové věci jako GMail, Facebook, Google nebo WhatsApp vytvářejí také programátoři, pro které například tou základní znalostí není to, jak pracuje uvnitř počítač, ale jak „uvnitř“ pracuje cloud.

Programování není o nic širší obor, než kterýkoli jiný obor. Ať jde o medicínu, právničinu, matematiku nebo cokoli jiného. Medik taky musí zvládnout celou anatomii, přestože se pak třeba celý život bude vrtat jen v žaludku, právníci se taky učí celé právo, přestože se pak třeba dotyčný bude specializovat jen na daňové právo. Tady jde o všeobecný přehled po oboru, o chápání souvislostí, o znalost společných metodik a principů.
To je právě ten problém, že místo všeobecného přehledu a chápání souvislostí se ten zubař detailně učí celou anatomii. Takže když ukončí školu, neumí ani tu anatomii, souvislosti nechápe vůbec, a tu zubařinu se teprve začíná učit.

K všeobecnému přehledu a chápání souvislostí by mělo patřit i to, že všeobecný přehled a schopnost chápat souvislosti člověk nezíská tím, že se bude učit spoustu detailů – a ten všeobecný přehled a chápání souvislostí z toho už nějak sám vyplyne. Tak to bohužel nefunguje.

Je to prima kritérium na zjištění, zda dnešní vysokoškolsky vzdělaní uchazeči zvládnou alespoň to, co kdysi zvládali středoškoláci, kteří se to učili na í kvé sto padesát jedničkách. Bohužel nikoli.
Představte si, že dnešní vysokoškolsky vzdělaní inženýři, kteří vyvíjejí robotická auta, nezvládnou ani to, co kdysi uměl každej retardovanej sluha – osedlat koně. Cha, chtějí vozit lidi, a neumí osedlat koně, dovedete si to představit?

Ale co je to pro boha za programátora, když netuší nic o paměťové a časové náročnosti algoritmů, když nezná základní techniky algoritmizace, když nikdy neslyšel o základních datových strukturách, když ani v hrubých rysech netuší, jak počítač vlastně funguje, nezná zdaleka nejběžnější způsob reprezentace čísel v něm (ať už jde o FP nebo o dvojkový doplněk)...?
Co jste proboha za programátora, když netušíte nic o tom, jak je algoritmus ovlivněn síťovou latencí? Když neznáte základní síťové protokoly, neznáte základní formáty pro přenos dat, jako XML, JSON, ASN.1? Když ani v hrubých rysech netušíte, jak vlastně funguje cloud, neznáte zdaleka nejběžnější komunikační protokol (HTTP)…?

3652
Vývoj / Re:Stromové struktury a tridici algoritmy
« kdy: 17. 11. 2017, 10:46:27 »
Pokud jsou prvky seřazené, pak jsou zároveň setříděné
V takovém případě je ale to setřídění dost umělé, protože každý prvek má svou vlastní třídu, a to jenom tak pro nic za nic, protože to jde. Takhle setříděné jsou ale i neseřazené prvky.

Mluvit o setřídění seřazených prvků má smysl tehdy, pokud se více prvků řadí na stejnou pozici, nebo-li jejich vzájemné pořadí bude po seřazení náhodné. Pak má smysl dívat se na to tak, že nejprve setřídím prvky do skupin se stejnou řadící platností, pak seřadím skupiny a pořadí prvků ve skupině už ponechám náhodné. Málokdy to ale má skutečný význam. Ale výjimky se najdou, třeba právě ty hashmapy – pokud se mi velké množství prvků setřídí do několika málo skupin, bude vyhledávání v hashmapě neefektivní.

3653
Vývoj / Re:Stromové struktury a tridici algoritmy
« kdy: 17. 11. 2017, 10:38:00 »
O žádný quicksort mi nikdy nešlo a neznám nikoho, kdo by u pohovoru někoho zkoušel z quicksortu.
Možná by bylo fajn, než se příště zapojíte do diskuse, zjistit si, o čem se diskutuje. Doporučoval bych začít třeba dotazem.

Ale spoustu uchazečů to vůbec netrklo, nač ten který příklad míří.
To jsem ve škole miloval, tyhle otázky „uhodněte, na co myslím“. Zejména v případě, kdy zkoušený odpověděl naprosto správně, ale zkoušený to nezaregistroval, protože to byla odpověď z jiného směru, než kam mířil on.

Mimochodem, příklad na prohledávání do šířky a příklad na dynamické programování jsem dával spíš jako hozenou rukavici, zda se někdo třeba chytne, ale za ty 4 roky, kdy jsem ty pohovory dělal, je zvládlo přesně nula uchazečů.
Hm, to je fakt prima kritérium pro výběr uchazečů, když to zvládnou všichni stejně. Já teda při pohovoru radši používám kritéria, která mi uchazeče rozdělí do dvou skupin – na ty, které nechci, a na ty, které chci pozvat do dalšího kola nebo přijmout.

Vždyť to je podobné, jako by se na zubařské oddělení hlásilo deset lidí, z nichž dva aspoň dokážou poznat kazový zub a opravit ho, další čtyři sice kaz poznají, ale nevědí, co s ním, a zbytek nezvládá ani to. Na zánět kořenových kanálků a jeho řešení se ale raději neptejte nikoho z těch deseti. Tak jestli vám to připadá normální, tak mně to teda připadá šílené!
Ne, není to podobné. Jak jsem psal, programování je dnes široký obor, od programování vypínače žárovky po programování cloudového chatu. Programátor toho vypínače žárovky nebude quicksort potřebovat, protože má k dispozici tak málo paměti, že s emu do ní žádný seznam nevejde, natož aby ho mohl řadit. Programátor cloudového chatu také nebude quicksort potřebovat, protože stáhnout všechny záznamy z distribuovaného úložiště do své aplikace a řadit je tam zkusí jenom jednou.

Takže je to spíš podobné, jako kdyby zubařské oddělení shánělo zubaře, poliklinika si dala inzerát na lékaře a adepty pak zkoušeli z operace slepého střeva.

Mě spíš děsí, když v reálném životě uspěje člověk, který plácá pamětí v ASICu a nevejde se do časování protokolu kvůli tomu, že pomocí floating pointu na železe bez FPU počítá něco, na co stačí pár bitových manipulací, kdyby o nich něco tušil.
Což ale asi nebude programátor Node.js nebo v Javě, o kterých je tu řeč. Programování je široký obor, někde mezi základní znalosti patří to, že je potřeba se vejít na zásobník, někde zase to, že data se třídí a řadí už v datovém úložišti a aplikace už je jenom vhodně prezentuje.

učit někoho programovat během zkušební doby, když to nezvládl za předchozí roky studia, to teda good luck.
Během zkušební doby se samozřejmě nikdo programovat nenaučí. Málokdo se to naučí během studia, protože tady školy zaměřené na programování nemáme (jeden semestr kódování nikoho nenaučí programovat, pár dalších semestrů zaměřených na jiný jazyk nebo nějakou technologii to moc nevylepší), a samostudium není cesta pro každého.

Pro zajímavost, zažil jsem i člověka, který ani po upozornění na konkrétní řádek nechápal, v čem má chybu ("nulovost" doublu testoval pomocí ==) a rozčiloval se, že máme asi nějakou chybu v překladači, protože v těch proměnných jsou nějaká trochu jiná čísla, než jaká do nich přiřazuje.
Je hezké, že nejprve odsoudíte to, když se někdo ptá na konkrétní implementace či specifikace, a následně se sám hrozně pohoršujete nad tím, že někdo nezná konkrétní specifikaci.

A to upozornění na konkrétní řádek je přesně to „uhodněte na co myslím“. Když dotyčný neví, jak fungují čísla s plovoucí řádovou čárkou, tak to samozřejmě nemůže vymyslet, v čem je ta chyba.

Ale podle zdejších diskutérů programátor přece nemusí nic vědět o tom, jak jsou v počítači reprezentována čísla.
Pro mne osobně je nezajímavý člověk, který bude znát reprezentaci čísel v jednom nebo několika jazycích nebo podle nějakého standardu, a bude o tom tvrdit, že je to jak „jsou v počítači reprezentována čísla“. Já raději takového programátora, který bude chápat, že čísla jsou v počítači reprezentována tak, jak se někdo rozhodne, že je bude reprezentovat – a že to vždy bude mít nějaké výhody a nevýhody. Takových špeků, jako že čísla s plovoucí řádovou čárkou nemůžu porovnávat na rovnost, jsou v programování miliony, a nemůžu po nikom chtít, aby je všechny znal. Já potřebuju, aby uměl přijít na to, že na takový problém narazil, aby si pak uměl nastudovat, jak to tedy funguje a jak to má použít – a ideálně aby měl cit pro to takováhle místa odhalit ještě před tím, než to začne používat a na chybu narazí.

Vám možná stačí, když programátor ovládá pár konkrétních technologií – OK, může být. Pak to ale nemůžete zevšeobecňovat, protože jiní programátoři potřebují úplně něco jiného.

3654
Vývoj / Re:Stromové struktury a tridici algoritmy
« kdy: 17. 11. 2017, 09:55:38 »
Je věcí uchazeče, jak to rozjede. Měl by mluvit hlavně on. Pokud mi bude vyprávět o […] Mě osobně až tak úplně nezajímá, co umí (samozřejmě, že potřebné základy musí mít), ale spíš jestli uvažuje logicky a pracuje dobře s informacemi, které už má, a ví, jak se dostat k dalším... Jestli neblábolí a nebo dokonce nelže. I za upřímné "nevím" dávám bod.
Na tom se shodneme. Akorát mi připadá neefektivní, abych já střílel nejrůznější technologie tak dlouho, dokud se netrefím do něčeho, co uchazeč zná – zvlášť když takováhle přehlídka všeho, co dotyčný neví, povede akorát k tomu, že ho vystresuju a zapomene i to, jak se jmenuje. Proto se ho radši zeptám, co zná on nebo co zajímavého dělal, a pak se bavíme o tom. Pokud sám uvede quicksort a vybere si ho, OK, budeme se bavit o quicksortu – ale v žádném případě nemám quicksort jako požadavek a je mi jedno, zda ho dotyčný zná nebo nezná, protože to vůbec nevypovídá o tom,zda z něj bude dobrý programátor.

3655
Vývoj / Re:Stromové struktury a tridici algoritmy
« kdy: 16. 11. 2017, 21:58:42 »
vis jak urezat kus dreva, ok muzes studovat na truhlare, ne tak jdi na popelare.
Ono je to spíš: „Víš, jak uříznout kus dřeva? OK, můžeš jít dělat zedníka.“ Vždyť přece domy se dříve dělaly ze dřeva, a postupným vývojem se výstavba domů dostala do dnešního stavu. Tak přijmeme někoho, kdo umí se dřevem, a taky se asi postupným vývojem dostane od dřeva k dnešním železobetonovým stavbám…

Zkus na se na věc podívat z druhé strany. Máš 10 uchazečů na jedno místo a všichni jsou mistři světa.
Máš na každého pár minut. Co se jich chceš ptát, abys do dalšího kola nepustil vyložené podvodníky?
Já myslím, že zeptat se, co vědí o řadicích algoritmech, je dobrá metoda jak to pročistit :)
Jako metoda jak rychle zmenšit počet uchazečů je to jistě skvělé. Nicméně já, když budu investovat několik měsíců nebo let do toho, abych si vychoval nějakého junior programátora, se nechci co nejrychleji zbavit co největšího počtu uchazečů, ale chci si vybrat toho nejlepšího, který zapadne do týmu.

A upřímně řečeno, dneska mne u juniora zajímá hlavně to, jestli už má s programováním nějaké zkušenosti, aby věděl, do čeho jde – aby po půl roce nezjistil, že ho to vlastně nebaví. Když ho to bude bavit, tak se to naučí – a vlastně jsem na pohovoru nikdy neměl absolventa, který by ze školy uměl programovat. Buď se to naučil ještě někde jinde, a nebo ze školy uměl napsat kód, který šel přeložit, ale o moc dál nebyl. Dál se s ním radši bavím o tom, co zná, a zajímají mne jeho názory – proč si to vybral, co mu na tom vyhovovalo, co se mu nelíbilo. Podle toho poznám, jaký má přístup a jestli má pro programování nějaký cit.

Ale je pravda, že někteří kolegové uchazeče zkouší třeba ze standardní knihovny, to si vždycky říkám, že bych u nich nejspíš neprošel :-) Mně ale nikdy nezajímalo, co dotyčný neví, naopak mne zajímá, co ví.

3656
Vývoj / Re:Stromové struktury a tridici algoritmy
« kdy: 16. 11. 2017, 21:33:35 »
To je snad přirozené, že se na školách učí principy a v praxi se používá něco praktického, ne?
To ale není podstata toho, o čem jsem psal. Problém je v tom, že ve školách se jako „programování“ učí principy algoritmů jako quicksort, ale v praxi pak dotyčný bude řešit, jak data uspořádat tak, aby je mohl zpracovávat paralelně (a to ne na úrovni datových struktur v paměti, ale na úrovni datových struktur v databázi); nebo jak navrhnout architekturu aplikace tak, aby horizontálně škálovala přidáváním dalších serverů; nebo aby tušil něco o UX; a nebo, pokud už se bude zabývat quicksortem, tak bude řešit to, že O(n log n) je sice hezká věc, ale v praxi bude propastný rozdíl v tom, když se bude pohybovat v jednom řádku cache RAM, nebo když přístup ke každému prvku bude znamenat výpadek stránky a čekání na nahrání z hlavní paměti.

Pokud jde o obecná data, tak si troufám tvrdit, že v reálném světě o moc lepší algoritmus než quicksort zatím nalezen nebyl. Třeba takový std::sort je intrasort
Takže jste si na tohle odpověděl sám.

A proto dnes taky nikdo normální žádné řadicí algoritmy nepíše.
A proto dnes taky nedává smysl zkoušet z nich nastupující programátory. Jistě, když to bude vypadat, že nízkoúrovňové algoritmy jsou silná stránka dotyčného, zeptám se ho na to – ale pak bych stejně nechtěl, aby mi na papíře implementoval quicksort, ale zajímalo by mne právě to, co ví o těch novějších upravených algoritmech. Protože z toho poznám právě to, jestli o tom jenom slyšel ve škole, nebo o tom opravdu ví něco víc.

3657
Software / Re:Náhrada za DSM
« kdy: 16. 11. 2017, 16:03:11 »
Řekl bych, že Jan Forman je vlastník Synology NAS. Já jsem také vlastník několika NAS od Synology, a také si myslím, že si můžete jedině výrazně pohoršit. A moc nechápu, na co se vlastně ptáte – DSM je založený na Linuxu a můžete ho samozřejmě nahradit jiným linuxovým systémem.

3658
Vývoj / Re:Stromové struktury a tridici algoritmy
« kdy: 16. 11. 2017, 15:30:50 »
Já zase nechápu uchazeče o místo, kteří mají potřebu potenciálního zaměstnavatele poučovat o tom, co vlastně potřebuje a co ne a na co se jich má ptát.
Já nejsem uchazeč o místo. A zaměstnavatele nepoučuju, jenom jsem podotkl, že tenhle typ testu zpravidla zjišťuje něco jiného, než zaměstnavatel od programátora potřebuje.

Zaměstnavatel si ověřuje, zda uchazeč o místo programátora umí programovat - no co si to dovoluje!
Právě že tak to není. „Umět programovat“ může znamenat spoustu různých věcí, a ve většině případů to není „umět z paměti napsat quicksort“. Naopak pro většinu programátorů dnes platí, že „umět programovat“ mimo jiné znamená vědět, že quicksort nebudu implementovat sám, protože existuje spousta implementací, které jsou lepší než to, co bych naimplementoval sám. V lepším případě pak platí také to, že „umět programovat“ znamená vědět, že dnešní počítače jsou mnohem složitější, než byly počítače v šedesátých letech minulého století, takže naivní implementace quicksortu může být velmi pomalá v porovnání s jinými implementacemi, pokud nebude brát v úvahu třeba různě rychlý přístup k různým keším RAM, zamykání paměti, vícevláknové procesory, více pipline v jednom vlákně procesoru, predikci skoků apod.

Mimochodem, je hezké, jak akademici pořád uvádějí quicksort, i když v reálném světě jsou někdy efektivnější jiné algoritmy. Což je mimochodem další z dovedností, které by měla mít většina programátorů – nespoléhat na to, že nejrychlejší je přece quicksort, protože se to tak učí ve škole – ale umět posoudit, jaké vlastnosti mají data, která chci řadit, a podle toho vybrat vhodný řadicí algoritmus. A také posoudit, zda vůbec je nutné ta data řadit…

Programátor, který neumí programovat, je totiž i zadarmo drahý.
Akorát že programátor, který neumí programovat, klidně může z paměti vystřihnout quicksort. Protože „umět programovat“ právě znamená něco jiného.

3659
Vývoj / Re:Stromové struktury a tridici algoritmy
« kdy: 16. 11. 2017, 11:44:11 »
Přesně jak píše Whoever – máte v tom pěkný hokej. Pro začátek vůbec nemusíte studovat, jak které algoritmy fungují – bude stačit, když si zjistíte, k čemu slouží, co je to třídění, co je řazení, co je vyhledávání, co je metoda „rozděl a panuj“. HashSet sice interně používá třídění, ale je to třídění na základě hashe, takže je to jen interní implementace. Uživatel HashSet používá pro vyhledávání hodnot, řazení hodnot v HashSetu je „náhodné“. K vyhledávání v HashSetu ani ve vyváženém binárním stromu se nepoužívá metoda rozděl a panuj, poněkud tam schází ta fáze „rozděl“. Tvrzení, že LinkedList je rychlejší než ArrayList, také není pravdivé – ono těch několik implementací Listu v Javě není proto, že by jedna byla dobrá a ostatní špatné a neměly by se používat. Ty různé implementace jsou tam proto, že se v různých situacích chovají různě, takže pro některá využití je vhodnější LinkedList a pro některá zase ArrayList.

Nechápu, proč se zkoušení z algoritmů dává do vstupních pohovorů pro programátory, protože drtivá většina programátorů řeší jiné typy úloh a opravdu nepotřebují znát, jak je implementován quicksort nebo ArrayList – ale měli by vědět, jaké jejich charakteristiky jsou důležité a umět si je zjistit, když to budou potřebovat. Ale evidentně takový test odhalí aspoň případy, kdy někdo ani neví, k čemu které datové struktury slouží a jak se používají.

3660
Sítě / Re:Volba DNS pro jednotlivé interface
« kdy: 15. 11. 2017, 15:48:56 »
to znamena ze v pripade VPN se vzdy defaultnim DNSkem stane DNS uvedene ve VPN?
Ne vždy, ale často. Záleží na tom, jak je nakonfigurované to připojení k VPN.

Stran: 1 ... 242 243 [244] 245 246 ... 375