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 - Pavel Stěhule

Stran: 1 ... 13 14 [15] 16 17 ... 31
211
Studium a uplatnění / Re:Kvalita české IT literatury
« kdy: 03. 01. 2019, 09:00:49 »

Prostě už pochop, že češtinu chce jen pár neschopných jedinců a ostatní jedou v angličtině. Kdyby to tak nebylo tak české knihy existují, ale nikdo je nevydává protože je lidi nechtěji.

Proč se tedy tady bavíme česky a proč root není v angličtině? ...
Toto fórum přesně potvrzuje co říkám a čeština je známka odpadu. Vem si, kolik je tu zajímavých it témat a kolk procent ej tlachání o platech a nesmysly. Protože sem chodíme tlachat tak se bavíme česky.

A v angličtině se netlachá? Pokud fórum není aktivně a agresivně moderované, tak je jasné, že se plní primárně nesmysly - taková je realita.

212
Studium a uplatnění / Re:Kvalita české IT literatury
« kdy: 03. 01. 2019, 07:18:48 »

Prostě už pochop, že češtinu chce jen pár neschopných jedinců a ostatní jedou v angličtině. Kdyby to tak nebylo tak české knihy existují, ale nikdo je nevydává protože je lidi nechtěji.

Proč se tedy tady bavíme česky a proč root není v angličtině? Proč tu nikdo neprovozuje portály v angličtině nebo němčině? Takže nějaká poptávka tu je (byť malá - v IT v ČR je cca 200 000 osob - a z toho těch kteří jsou proaktivní, tak možná méně než 10000). Chybí autoři - chybí i jakýkoliv ekonomický (i mimo ekonomický) model distribuce. Módní témata (na kterých se dá dobře profitovat) asi více než kde jinde v IT rychle zastarávají - nikdo si v roce 2019 nekoupí "Mistrovství v Office 2012". Vycházejí docela dobrá skripta - ale ty se samozřejmě nedostanou do běžné distribuce.


213
Studium a uplatnění / Re:Kvalita české IT literatury
« kdy: 02. 01. 2019, 20:22:35 »
Českou větu bez skloňování dost dobře napsat nelze. Tudíž buďto bude existovat česká odborná terminologie, včetně počeštěné přebrané, a nebo nebude existovat česky psaná odborná literatura. Souvisí to i s úrovní projevu, kulturou. V hovorové řeči to až tak nebolí, ale věty obsahu "tak tam inkrísni tu memory" vypadají zoufale a smutně.
Bohužel se svět IT vyvíjí rychleji než jazyk, takže vytvořit kvalitní překlad anglických termínů může trvat dlouho nebo se nemusí vůbec podařit. Viz Yuhův český termín plužina. Používá ho někdo?

To není záležitost roku, ale spíš desetiletí než se najdou vhodné překlady, než se stabilizuje terminologie. Souhlasím s tím, že IT je dynamický obor (a hlavně extrémně mladý) a víc než jinde se věci recyklují, znovuobjevují, a znovu pojmenovávají. Dost věcí se ale už stabilizovalo - hromada fundamentálních technologií je už starších 20-40 let.


214
Studium a uplatnění / Re:Kvalita české IT literatury
« kdy: 02. 01. 2019, 20:05:44 »
Pavle a neni uz neco podobneho a jmenuje se to wikipedie? A jak to s ni dopadlo. Banda jesitnych blbcu s patentem na pravdu. Ale bylo by to krasne mit vlastni odborne publikace (do par stran). Jak uz jsem psal chtelo by to mit prelozeny jadro problemu ktere na case nezastarava, ALE kdyz se nemuzou domluvit ani akademici napric vysokyma skolama, aby ten zaklad dali dohromady a misto toho syslej vlastni skripta a knizky (protoze citace na docenturu a autorsky zakon), tak co pak ta skupina co by to mela davat dohromady.

Čtečky jsem uvedl jen jako příklad - jestli to budou tablety nebo něco jiného je technická záležitost.

Wikipedie nemůže zastoupit odbornou literaturu - je to encyklopedie - souhrn faktů. Chybí mi tam úvod, závěr a díky hypertextu se vlastně dost blbě lineárně čte - mám problém se soustředit, a když už se člověk soustředí, tak zjistí, že většina informací je na úrovni článků ze 100+1 - protože to je ten nejmenší společný průnik, na kterém se všichni shodnou.

U literatury nečekávám pouze fakta, ale i názory autora, zkušenosti, doporučení, závěry - podepřené autorem a jeho jménem. Tohle anonymní prostředí wikipedie neumožňuje, nedovoluje - nefunguje tam ručení jménem za obsah, a zrovna tak kvalitní článek na wiki vám nezvýší reputaci, protože je anonymní.

215
Studium a uplatnění / Re:Kvalita české IT literatury
« kdy: 02. 01. 2019, 17:20:59 »

Jsem si naprosto jisty ze ceskebknizecky do kapsy do sto stranek o it by byl propadak a nevum kdo by mel byt cilovyvzajemce?

A hlavne pro nic na svete nezacit jazykove pracovat s ustalenymi anglickymi terminy. Neni nic horsiho nez treba sklonovani - pocestovani anglickych slov.

Určitě se mi čte / i píše snáz v češtině než v angličtině - a předpokládám, že nebudu samotný. Kvalitních, nepovrchních a ucelených informací je, a to i když vezmu v potaz internet a samozřejmě anglické weby a blogy, překvapivě málo.

Českou větu bez skloňování dost dobře napsat nelze. Tudíž buďto bude existovat česká odborná terminologie, včetně počeštěné přebrané, a nebo nebude existovat česky psaná odborná literatura. Souvisí to i s úrovní projevu, kulturou. V hovorové řeči to až tak nebolí, ale věty obsahu "tak tam inkrísni tu memory" vypadají zoufale a smutně.

216
Studium a uplatnění / Re:Kvalita české IT literatury
« kdy: 02. 01. 2019, 15:04:46 »

Spíš se to motá v kruhu.

Zkus sehnat CZ papírový manuál k Linuxu, kde je systemd. Nikde. A při tom dá sakra hodně práce se mu vyhnout. Vydavatel ti odpoví, že nivá nebude, dokud se nevyprodá stará a stará mu leží ve skladu pět let, protože to nikdo nechce. A nikdo to nechce, protože to není aktuální...

I když mám tištěnou literaturu rád, tak papír je pro odbornou PC literaturu v češtině nedostupné medium. Možná by stálo za úvahu mít edici odborné literatury čistě pro čtečky v rozsahu cca do 100 stránek. Takový objem textu je možné dát za pár měsíců dohromady, je možné jej revidovat a také je možné je přečíst za několik dnů - a neprokousávat se zbytečnou vatou. Možná by to mohlo fungovat, a nemuselo by to být prodělečné. Určitě to nebude výdělečné.

Aby jazyk nestagnoval, tak je důležité psát a mít odbornou literaturu v národním jazyku a pokud možno psanou čitelně, srozumitelně. Je nutné zavádět, stabilizovat terminologii - tak aby se s ní dalo jazykově pracovat - např. v češtině skloňovat, atd. Samozřejmě, že anglickou terminologii zná každý, ale zkuste ji používat v česky psaném dokumentu, aby to nervalo za uši.


217
Server / Re:PostgreSQL: nemůžu se připojit z klienta
« kdy: 10. 12. 2018, 18:45:20 »
je neco v logu postgresu?

218
Vývoj / Re:XML vs YML - svět se zbláznil?
« kdy: 12. 11. 2018, 19:12:17 »
XML by pomohla jedna věc – vydat novou verzi, ve které bychom se vykašlali na DTD a uživatelské entity, a ponechalo by se tam to, co se dnes z XML reálně používá. Problém je, že mnozí by chtěli nejspíš vyházet i XML instrukce a/nebo CDATA, na čemž se nejspíš nikdo neshodne, tak se do toho nikdo raději ani nepouští.

Souhlas. Je to jednak problém zpětné kompatibility, druhak u některých technologií je prostě nutné znovu vymýšlet kolo, protože lidi jen lidi. Jednak hromada programátorů bez vysokoškolského vzdělání vůbec netuší rozsah XML, a pak také někdy je jednodušší začít z gruntu znova než se přetlačovat s existujícím kódem, standardy, .. Je to docela problém - někdy je dobře, když funkčně podobné, ale nekompatibilní věci prostě vypadají jinak - a někdy to naštve, protože se člověk musí učit věci víckrát.

219
Vývoj / Re:XML vs YML - svět se zbláznil?
« kdy: 12. 11. 2018, 18:57:17 »
Pokud ale k technologii přistoupíte v pozdějším cyklu, tak komukoliv bez let zkušeností letitá technologie musí přijít jako monstrum - do rozjetého vlaku se dost špatně nastupuje - a začíná se znova s něčím jednoduchým, přehledným, rychlým elegantním, z čehož se za 10-20 let stane monstrum.

Tak proč je Java pořád tak úžasná? Nebobtná, je jednoduchá, přehledná a elegantní. A to není úplně nová.

Jako vtip dobrý. Java je zrovna perfektním ukázkou mého tvrzení - její ekosystém je po cca 20 letech morbidní - desítky knihoven a frameworků jsou legacy, ale stále se aktivně používají (v enterprise prostředí je upgrade až ta poslední věc). Java jako jazyk zůstala jednoduchá, ale o to více se komplikoval její ekosystém. V praxi se asi nepotkáte s tím, že by se programovalo v čisté Javě. Podobný vývoj je vidět i na C# - jelikož si vývoj držel pod palcem Microsoft, tak vývoj nepřipomínal kambrickou explozi, ale tam se zase výrazně bobtnal vlastní programovací jazyk.

220
Vývoj / Re:XML vs YML - svět se zbláznil?
« kdy: 12. 11. 2018, 17:29:48 »
Už spoustu let tu máme XML, které má jmenné prostory, schémata (XSD), transformace (XSLT), ukazatele (XPath, XPointer), dotazovací jazyk (XQuery). Pak ale přišel někdo, že je XML moc ukecané a bůhvíco ještě, a vymyslel JSON, který se prý mnohem lépe čte a píše. No a pro JSON se pomalu vymýšlí to samé, co máme pro XML – schémata (JSON Schema), ukazatele (JSON Pointer). A teď mám i nejnovější objev, dotazovací jazyk – GraphQL. No a do toho přišel někdo s tím, že JSON je moc ukecaný a bůhvíco ještě (kde jsem to jen viděl), a vymyslel YAML, který se prý mnohem lépe čte a píše.

Takže já bych to nijak neřešil. Ti, co potřebují každé tři roky nový formát, je budou vynalézat stále. No a těm ostatním dojde, že problém není ve formátu. Že jakékoli složitější dokumenty jsou prostě bez podpory na straně editorů (zvýrazňování, formátování, doplňování) nepřehledné z principu, a žádným formátem se to nedá ošidit. No a pro ty tu  pořád bude stabilní a prověřené XML, které má dávno vyřešené všechno, co se teď ve světě JSON/YAML s velkou slávou objevuje.

YAML - je vizuální markdown jazyk - a už před nástupem JSONu jsem jej vidět používat pro konfigurace, pro poznámky. V JSONu a XMLku je ta vizuální stránka potlačená.

XMLko je fajn, ale některé z mých nepříjemných zážitků jsou spojené s konfigurací Java aplikací v XML. Případně číst XML logy taky nemusím.

Srovnejte si složitost SOAPu a RESTu - tam mám pocit, že designéři se trochu utrhli s řetězu. Asi by mohl docela dobře existovat REST nad XML, ale k výměně technologie obvykle musí být víc důvodů než jeden - byť některé důvody jsou marketingové nebo podmíněné nástupem nové generace programátorů, která starší technologii nezvládla nebo odmítla.

V programování hraje velkou roli lidský faktor a dochází k cyklické obměně technologii - jednak se mění hw, mění se požadavky zákazníků, a většina technologii má tendence bobtnat - což není problém, když danou technologii zastihnete na začátku cyklu jako junior nebo mladý senior - změny stíháte absorbovat. Pokud ale k technologii přistoupíte v pozdějším cyklu, tak komukoliv bez let zkušeností letitá technologie musí přijít jako monstrum - do rozjetého vlaku se dost špatně nastupuje - a začíná se znova s něčím jednoduchým, přehledným, rychlým elegantním, z čehož se za 10-20 let stane monstrum.

221
Server / Re:Optimalizacia a performance SQL dotazov
« kdy: 11. 11. 2018, 18:54:53 »
Aby som bol uplny a predisiel zbytocnemu neporozumeniu, toto je ta veta, s ktorou nemozem principialne suhlasit (s p. Stehulem).

Výkonnostní problémy s databázemi většinou nejsou o tom, jak jsou napsaná SQLka (což neznamená, že se SQL nedá napsat blbě, když se chce)

Samozřejmě, že každý můžeme mít vlastní názor - a vlastní zkušenosti :).

Ono také extrémně záleží na kvalitě optimalizace té či oné databáze. S "ideálním" optimalizátorem by mělo být úplně jedno, jak dotaz napíšete. Ideální optimalizátor nemáme, ale zas pokud se trefí predikce, tak jsou dnešní optimalizátory poměrně slušné. Nesmíte brát v potaz starší verze MySQL - fakticky až do 8čky MySQL optimalizátor za moc nestojí.

Další věcí jsou mýty z dob, kdy optimalizátory byly rule based. Tam skutečně záleželo, jak se dotaz zapíše. Pokud ale vím, tak dnes se takový nikde masověji nepoužívá.

V prvom rade, neznasam myty a tie v IT (kde prakticky vsetko je trasovatelne a meratelne) nemaju co hladat. Napriek tomu je ich v tomto odvetvi mnoho. Napriklad jeden z najstarsich, ze je potrebne indexovat vseko to com mam v predikatoch alebo ze full table scan je zly...
...

Já tu nevidím rozpor - přijde mi, že možná jinými slovy tvrdíte totéž co já. Nestačí jen umět psát dotazy, ale je potřeba umět správně pracovat s relační databází. Výkonnostní problémy Oracle a Postgresu jsou někdy hodně podobné - tam kde je podobná implementace. U Oracle mám ale pocit, že je jakoby úzus, že za ty peníze by to ta databáze měla dát sama a podceňuje se vývoj, a relativně hodně se klade důraz na administraci. U Postgresu se rovnou říká, že vývojář by měl být inteligentní, a pokud nemá základní znalosti, tak to nedopadne dobře. Také u Postgresu jsou spíš vyjímkou databázoví admini, a tudíž si vývojář musí většinou tuning udělat sám, případně si performance problémy vyžrat sám. Naopak u Oracle je častější striktní dělení mezi adminy a vývojáře - a také nasledné konflikty a osočování. U Oracle (a v korporátním prostředí) je vývojář dost často perfektně izolován od produkce, a vůbec netuší, jak co produkčně funguje nebo nefunguje.

222
Server / Re:Optimalizacia a performance SQL dotazov
« kdy: 11. 11. 2018, 13:19:57 »
Aby som bol uplny a predisiel zbytocnemu neporozumeniu, toto je ta veta, s ktorou nemozem principialne suhlasit (s p. Stehulem).

Výkonnostní problémy s databázemi většinou nejsou o tom, jak jsou napsaná SQLka (což neznamená, že se SQL nedá napsat blbě, když se chce)

Samozřejmě, že každý můžeme mít vlastní názor - a vlastní zkušenosti :).

Ono také extrémně záleží na kvalitě optimalizace té či oné databáze. S "ideálním" optimalizátorem by mělo být úplně jedno, jak dotaz napíšete. Ideální optimalizátor nemáme, ale zas pokud se trefí predikce, tak jsou dnešní optimalizátory poměrně slušné. Nesmíte brát v potaz starší verze MySQL - fakticky až do 8čky MySQL optimalizátor za moc nestojí.

Další věcí jsou mýty z dob, kdy optimalizátory byly rule based. Tam skutečně záleželo, jak se dotaz zapíše. Pokud ale vím, tak dnes se takový nikde masověji nepoužívá.

223
Server / Re:Optimalizacia a performance SQL dotazov
« kdy: 11. 11. 2018, 07:47:35 »
Vdaka, pozriem materialy co ste sem postli

Citace
Mozes byt kludny, na ziadnej VS sa ladit DB nenaucis. Mimochodom je lahsie/casovo kratsie sa naucit riadne pisat optimalne SQL ako naucit sa troubleshooting, pretoze to prve je pre to druhe prerekvizitou.
Tvoja otazka vsak obsahuje vela nepodstatnych informacii, ale tie zasadne si neuviedol vobec, napr. Vendor a verzia DB.

pracujem primarne s postgresom, ale tak mal som namysli skor efektivne pisanie sql dotazov pomocou zakladnych klauzul, ako nejake speci prvky niektorej z db

Tam moc prostoru pro nějaké triky není - každá klauzule má přesně svůj význam - a stačí ji používat podle významu. Je zásadní si uvědomit, že pracujete s relační databází a používat ji jako relační databázi (to se týká hlavně návrhu schématu). Je dobré si něco přečíst o SQL antipatternech (pokusy o dědičnost, EAV) a nepoužívat je. Zbytečně nepoužívat korelované poddotazy (tam kde je databáze neumí převést na joiny), preferovat joiny.

Cílem je napsat čitelné SQL u kterého je zřetelné, co dělá, a které je na dané platformě dostatečně rychlé. Výkonnostní problémy s databázemi většinou nejsou o tom, jak jsou napsaná SQLka (což neznamená, že se SQL nedá napsat blbě, když se chce), ale jak se databáze jako celek používá. Pro Postgres jsem před lety napsal článek, který pořád platí - https://postgres.cz/wiki/Desatero

224
Vývoj / Re:Proč nefunguje tento SQL dotaz
« kdy: 14. 10. 2018, 22:44:34 »
JOIN … ON je akorát modernější zápis podmínky ve WHERE pro spojování tabulek. Takže na tom, kam tu podmínku napíšete, nezáleží.
....
Zase Jirsak meles o vecech o kterych vis kulovy? Ten select se chova uplne jinak. Kdyz se podminka napise rovnou do join, tak se spojovani provadi uz nad omezenym poctem zaznamu, vs where, kde se nejdriv spoji vsechno a teprve pak se to omezuje, coz bude v drtivy vetsine pripadu radove pomalejsi.

Určitě není jedno, kam se zapíše predikát - v případě OUTER JOINů to může mít vliv na výsledek - je tam jiná sémantika. Zrovna tak ale není pravda, že by se napřed vyhodnocoval JOIN a poté WHERE. Databáze se snaží o push down predikátů - tj jakékoliv filtry - bez ohledu na to jestli jsou v JOINu nebo ve WHERE natlačit co nejhlouběji v prováděcím plánu - snažíte se omezit data ještě než s nimi cokoliv začnete dělat, případně se díky predikátům na úrovni listu stromu prováděcího plánu mohou vybrat indexy, které mohou rovnou vracet data po aplikování filtru.

225
Vývoj / Re:Staticky typovaný skriptovací jazyk pro rok 2018
« kdy: 14. 10. 2018, 06:49:57 »
Já jsem v poslední době spokojen s Elixirem. Snažím se jím nahrazovat Python a celkem se mi to daří. Díky tomu, že lze používat knihovny pro erlang, tak není problém s tím udělat téměř cokoliv.
Pravda, není staticky typovaný, ale zrovna v tomhle případě to fakt není problém.

Souhasim, jako priznivec Ruby musim rict ze i Elixir se mi libi :-) zvlast treba frameworky pro vyvoj webovych aplikaci jsou zajimave. Napr. takovy Phoenix framework, nicmene dosud nevim jak moc se osvedcil v produkci a v CR moc velka poptavka neni po vyvojarich - tipuju daleko mensi nez po vyvojarich v RoR (a ta je velmi mala, pac kdyz jsem po skole zkousel najit praci jako vyvojar v RoR musel jsem vynalozit nadlidske usili a nakonec jsem stejne skoncil po par mesicich jako Javista v jine firme).

Altworx v Brně jedou nad elixírem

Stran: 1 ... 13 14 [15] 16 17 ... 31