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 - Kamil Podlešák

Stran: 1 ... 7 8 [9] 10 11 ... 13
121
Vývoj / Re:Efektivita MySQL při uložení velkého XML
« kdy: 05. 06. 2017, 12:28:37 »
PS: jestli chces pouzit relacni db a XML tak pouzij PostreSQL (popr. Oracle XE) ty maji podporu pro XQUERY. MySQL si jde vlastni cestou.
Rozhodně, Postgresql je jedna z nejlepších nosql databází :-)

PS: nosql = not only sql :-)

122
Vývoj / Re:Efektivita MySQL při uložení velkého XML
« kdy: 05. 06. 2017, 08:09:02 »
Raději to uloži do databáze ve formě key, value.
No, a tady bacha: EAV je právem považováno za antipattern, a právem. Dnes už je opravdu lepší použít XML nebo JSON, pokud mají nativní podporu (vlastně EAV byl jeden důvod proč se přidávala). Když relační databáze, tak pokud možno nějaká rozumná normální forma (tj. sloupečky).

123
Vývoj / Re:Efektivita MySQL při uložení velkého XML
« kdy: 03. 06. 2017, 10:07:40 »
V původním dotazu není o vyhledávání v tom XML nic, IMO to chce jen ukládat a pak vytahovat.
Jo, to si možná myslí teď, ale podle toho co do nich chce ukládat (cituji: suroviny, budoviny, jednotky) je mi jasné že hned druhý den bude potřebovat najít kolik má prázdných vesnic apod.

124
Vývoj / Re:Efektivita MySQL při uložení velkého XML
« kdy: 02. 06. 2017, 12:26:35 »
XML je obvykle lépe na disku v podobě souboru. Kombinace XML s databází nebývá příliš výhodná.

Naopak, kombinace XML (nebo JSON) s databází je velmi výhodná, pokud daný db engine dokáže s XML/JSON pracovat. Můžeš si nad nimi dělat ad hoc dotazy a dokonce i indexy. Bohužel nevím jak je na tom zrovna MySQL, už přes deset let používám jen DB2 a Postgresql.
Disclaimer: Samozřejmě, neporovnávám XML/JSON s korektní normální formou, ta je vždy pro hledání lepší.

Kombinace souborů na disku s databází je naopak velmi nevýhodná, a to hned z několika důvodů:
  • Buď může existovat jen jeden klient (který má u sebe ty soubory), nebo musí všichni klienti sdílet nějaký filesystém. Ne že by to nešlo, s takovým NFS si člověk užije spousty zábavy když vypadne spojení...
  • Práce se soubory není součástí transakce. Je ošetřit všechny kombinace rollbacku a chyb FS, jinak se bude stávat že chybí soubor odkazovaný z db, nebo naopak na fs nějaký přebývá. O současné změně obsahu souboru ani nemluvě.
  • Pokud už někdy chceš hledat uvnitř (v podstatě nutné při ručním řešení problémů), tak musíš ručně spojovat nějaký grep/xmlstarlet/jq a SQL dotaz.
Samozřejmě, pokud se jedná o významné objemy dat, tak se nedá nic dělat a všechny výše uvedené problémy řešit. A samozřejmě, někdo má rád výzvy :-)

125
Vývoj / Re:Přepsání serveru v Javě
« kdy: 26. 05. 2017, 13:09:00 »
Pokud je čas a chuť to přepsat do něčeho jiného a nebude vadit že to má někdo jiný udržovat, tak by byl hřích to nevyužít.
V tomto případě je Go nejlepší volba, protože je to jazyk (resp. "platforma") přesně pro tento účel.

Něco jiného je někde ve firmě, kde se řeší věci jako náklady nebo zastupitelnost. Tam pak platí, že by se mělo zjistit co je přesně špatně a podle toho pokračovat.

126
Studium a uplatnění / Re:Hlupe otazky HR?
« kdy: 22. 05. 2017, 17:54:10 »
Vidis, a me prijde z toho co rikas, ze ten cil mas.
No, pokud to beres takto siroce, tak asi jo. :-) Ale dalo by se rict, ze si v praci rad nevybiram. Veci, ktere nikdo nechce delat, davaji casto vetsi prilezitost byt tvurci.
To je naprosto krásná odpověď a každá (kompetentní) personalistka to ocení. A hlavně to ocení každý (opět: komententní) šéf.
Zvlášť v porovnáním s frajerem který odpoví "trhni si nohou, krávo" nebo vyplodí nějakou naučenou frázi.

Samozřejmě, jistě jsou i takové které očekávají spíš nějakou tu frázi. No ale pak je dobře v takové firmě nepracovat.

127
Studium a uplatnění / Re:Hlupe otazky HR?
« kdy: 19. 05. 2017, 08:56:10 »
Za prvé se píše milník
Já myslím že mylník (kořen: mýlit se) je zde naprosto správně, byť to asi nebyl záměr.

128
Odkladiště / Re:Nějaké nové objevy ve fyzice?
« kdy: 11. 05. 2017, 13:21:39 »
Je to sice velmi zajímavá a demonstrativní diskuse, ale mám dvě faktické připomínky:
- lidská blbost není podle tradičního dělení vědních oborů fyzikálním jevem
- to že blbost kvete není žádný nový objev
Fix pro fanoušky politické korektnosti: s/lidská blbost/alternativní inteligence/g :-)

129
Odkladiště / Re:Nějaké nové objevy ve fyzice?
« kdy: 11. 05. 2017, 10:59:53 »
Je to sice velmi zajímavá a demonstrativní diskuse, ale mám dvě faktické připomínky:
- lidská blbost není podle tradičního dělení vědních oborů fyzikálním jevem
- to že blbost kvete není žádný nový objev

130
Mimochodem, nedávno jsem psal jednoduchého http klienta v C++ , měl 160 řádků i s komentářema. Nedokážu si představit, že bych psal http/2.0 klienta.
To asi bylo bez keepalive, co?

Pokud takové http stačí, tak je skutečně nesmysl byť jen uvažovat o http2.

131
Tento potřeh je tak zásadní, že bych ho přirovnal k objevení celého nového kontinentu.

No ale bez srandiček: takhle skutečně ten trh funguje a v podstatě ani nemůže jinak. Podrobnou analýzu dodá Ivan Nový.

PS: Nějak mi to předsevzení "bez srandiček" nevyšlo... tak snad příště.

132
Software / Re:Vyplnění přehledu ČSSZ v Linuxu
« kdy: 03. 05. 2017, 18:22:10 »
Já nevím co blbnete. U počítačů a browserů dřepíte po celý pořád, tak můžete být rádi že si jednou za rok odpočinete u papíru s propiskou.

133
Vývoj / Re:Webova aplikacia v PHP
« kdy: 30. 04. 2017, 15:41:20 »
Pokusím se o bonmot: Hlavním problémem PHP je, že se porovnává s Javou.
Takové diskuse byly zajímavé někdy v roce 2002 (jo, to byly časy...), ale dnes je to prostě absurdní.

134
Vývoj / Re:Java a C# - porovnání práce se Zip souborem
« kdy: 29. 04. 2017, 12:36:12 »
Pane Jirsáku, ja vždy na root.cz obdivuji vaši vytrvalost a vervu s jakou dokazujete, že jste dost podivný člověk. Kdo jiný by taky na Twitteru likoval Merkelovou jako největšího státníka v Evropě.
Pan Jirsák je jistě podivný člověk a je možné že má i podivné politické názory, ale na druhou stranu dokáže bez zbytečného rozčilování argumentovat a psát věci které jsou v podstatě pravdivé a mají hlavu a patu, maximálně jsou někdy trochu offtopic nebo to jsou osobní názory (které jsou z principu subjektivní). Ještě jsem ale neviděl, že by napsal něco skutečně špatně.

Tradičním oponentem je pak někdo, kdo ho z nějakého důvodů nesnáší tolik, že prostě vidí jenom rudou mlhu.
... bufferování nehraje roli při rozhodování, zda-li něco je stream nebo není...
...Vám totiž nejde do hlavinky, že i input stream, který musí načíst nejprve celý vstupní stream, je rovněž stream....
...Takže ne, není pravda, co tvrdíte, že každá implementace ZipStreamu musí nutně na výstup posílat rovněž nevalidní soubory....
Hezky vyvrácené, bohužel obě dvě tvrzení jsou naprosto vymyšlené, Filip Jirsák nic takového netvrdil.

Je takový problém, aby se v případě, že dochází paměť, začalo prostě bufferovat na disk?
Jenom pro pořádek: ano, je. Nebudu vysvětlovat proč - koho to zajímá tak si to dá jako domácí úkol.

Vlastně když nad tím tak přemýšlím - tohle je taková krásná otázka na pohovor. Jaké jsou problémy té jdk implementace a API, jak by to vypadalo lépe, a jakým špatným nápadům se vyhnout. Minimálně se tím roztřídí lidi na nudné praktiky, tlučhuby a ty co skutečně dokáží někam dohlédnout. Navrhnout dobře API a vůbec knihovnu je prostě něco, co každý nezvládne na první pokud (koneckonců, příkladem je jak Java, tak C# nebo třeba Python)

Pane Jirsáku, vemte si někdy taky dovolenou, oddechněte si, sportujte, nechoďte tolik na sluníčko a bude to zase fajn.
To je asi to nejrozumnější co tady padlo. Ale platí to pro tebe, a případně další individua s pěnou u huby.

Otázka do pléna: proč někteří tolik nesnáší Filipa Jirsáka, že se sebe dělají takové kretény?

135
Vývoj / Re:Java vs. Swift
« kdy: 28. 04. 2017, 18:19:50 »
Jako prvni pokus bych to skusil predelat do Apache Camel spousteneho ze Spring Boot.
Rovnou přeskočit. Rozdíl je hlavně v tom že místo "enteprise byrokracie" je tam "hip magie" - z hlediska performance jsou oba dva koncepty jsou srovnatelní žrouti.

Je tu ale ještě jedna věc, kterou bych tipnul - možnáje tam docela dost zpracování jednoduchých dat, od dekódování nějakého binárního protokolu až po nějaké nějaké konverze, agregace a podobně, možná i nějaké maticové operace? Pokud tam někdo naivně použije něco typu Map<Integer, List<List<Double>>> tak se GC (a tedy i CPU) fakt pěkně zapotí. A bohužel, takové věci opravdu efektivně a zároveň elegantně to prostě v Javě udělat nejde a nepůjde.

Nicméně, to jsou jenom takové špekulace.

Stran: 1 ... 7 8 [9] 10 11 ... 13