Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Péťa 28. 04. 2017, 15:13:11
-
Dobrý den,
Dostal jsem takový domácí úkol, který viipadá následovně:
Vytvořte aplikaci, která vypíše do konzole strukturu nějakého zip souboru, a to takto:
A.zip
soubor0.txt
B.zip
C.zip
soubor1.txt
V C# se dá rekurzivně soubor A.zip procházet takto:
ZipArchive([b]Stream[/b])
Inicializuje novou instanci ZipArchive trídy ze zadaného datového proudu.
ZipArchiveEntry ZipArchive.Entries
Získá kolekci položek, které jsou aktuálne v archivu zip.
[b]Stream [/b]ZipArchiveEntry.open()
Otevre položku z archivu zip.
Já se však rozhodl, že raději pužiju Javu, protože je lepší. V Javě ovšem je pouze tato varianta:
ZipFile(File file)
Enumeration<? extends ZipEntry> ZipFile.entries()
InputStream ZipFile.getInputStream(ZipEntry entry)
To samozřejmě nikterak neumožní, získat v A.zip pomocí třídy ZipFile soubor B.zip a ten si opět otevřít a procházet třídou ZipFile, neboť ZipFile umí vzít pouze File, tedy soubor, který musí existovat na disku. Jak jsem dále pátral, v Javě není možné vytvořit virtuální File a provézt tedy celou operaci přes paměť. Není zde tedy jiné možnosti, než B.zip a C.zip rozbalit, uložit separátně na disk, a poté opět otevřít v ZipFile.
Celá záležitost je v případě Javy o to, kulantně řečeno, podivnější, protože jak je známo, výstupní artefakty .jar a .war jsou v podstatě ZIP soubory. Bystrý člověk by tedy očekával, že práce se ZIP soubory by měla být v Javě více než bezproblémová.
Konzultoval jsem to proto s panem Filipem Jirsákem, který je zkušený Javista a Javě se věnoval převážnou část svého života. Podle něj se má věc takto:
Zvolil jste si špatný formát souboru. ZIP není urcený k ukládání na pásku (na rozdíl treba od gzip nebo bzip2), k jeho dekompresi potrebujete náhodný prístup k souboru. Proto to nefunguje se streamem, ale je potreba predat soubor. S Javou to nijak nesouvisí, takhle byste to musel udelat s každou knihovnou v libovolném jazyce.
Z názoru odborníka, pana Jirsáka, jsem však poněkud zmaten. Jednak Java sama produkuje ZIP soubory při sestavování aplikace, do kterých hierarchicky umístí další ZIP soubory v závislostech, které pak obsahují další a další ZIP soubory. Moc tedy nerozumím, proč jsem si vybral špatný formát. Druhý důvod je ten, že podstata Streamu, ve smyslu, jak je používán v .NET nebo v Javě, nemá nutně co dělat s formátem, ve kterém je zdroj uložen - obojí je zkrátka abstraktně představuje tok dat, který může procházet jistou transformací. Domnívám se proto, že sučíp pan Jirsák nemá tak úplně pravdu.
Chtěl bych se proto zeptat vás zkušenější (než já), zdaž-li jde o chibu návrhu standardný knihovny v Java ecčars a pokud ano, zda biste mi to mohli vysvětlit. Myslel jsem si, že Java je velice úspěšná a má za sebou 20 let vývoje a podle některých webů jde dokonce o nejpouživánější jazyk na světě. Používají ho dokonce lidi jako je pan Jirskák, a ti by určitě nedělal v ničem, co by bylo hned ve standardní knihvě Jazyka implementováno poněkud nelogicky.
Děkuji za odpověď.
Péťa.
-
Use google, Luke
http://stackoverflow.com/questions/35336870/java-utility-library-for-nested-zip-file-handling
Apropos, Java v zakladmin JDK spoustu veci neumi. A to je dobre, nema smysl cpat do zakladu kazdou kravinu, kterou pouzije jeden clovek ze sta.
Od toho jsou tu externi knihovny, ktere pomoci mavenu seamless zakomponujes do sveho projektu. Sila javy je hlavne v jejim ekosystemu.
Tj. kdyz tvuj projek postavis na mavenu, do pom.xml si pridej zavislost na Apache Commons a opajcuj ten example ze Stac Overflow
-
Chtěl bych se proto zeptat vás zkušenější (než já), zdaž-li jde o chibu návrhu standardný knihovny v Java ecčars a pokud ano, zda biste mi to mohli vysvětlit.
Ano, jedná se o špatný návrh, pro součásti standardní knihovny z původní verze 1.0 je to poměrně typické.
Většina byla nahrazena něčím lépe navrženým, ale v tomto případě ne.
Jinak samozřejmě existuje ZipInputStream a nad ním se dá rekurzivní procházení postavit. Poměrně jasně si pamatuji že jsem kdysi dělal patchování souborů uvnitř warů uvnitř earu (tj. dvě úrovně zipu a ještě modifikace), streamově... Hledat to nikde v hluboké VCS historii nebudu (nikoho to stejně nězajímá), ale vím že to rozhodně nebyla sranda (teda sranda ve smyslu jednoduché, jinak to naopak sranda docela byla).
Každopádně, standardní řešení je: použít lepší knihovnu. Opensource.
PS: Tak, jeden člověk už se tady vytahoval, vlákno je možné zamknout.
-
Use google, Luke
http://stackoverflow.com/questions/35336870/java-utility-library-for-nested-zip-file-handling
Apropos, Java v zakladmin JDK spoustu veci neumi. A to je dobre, nema smysl cpat do zakladu kazdou kravinu, kterou pouzije jeden clovek ze sta.
Od toho jsou tu externi knihovny, ktere pomoci mavenu seamless zakomponujes do sveho projektu. Sila javy je hlavne v jejim ekosystemu.
Tj. kdyz tvuj projek postavis na mavenu, do pom.xml si pridej zavislost na Apache Commons a opajcuj ten example ze Stac Overflow
A proč to teda ten C# umí hned v té základní knihovně a Java to má tak složité? Navíc jsme se ještě před pár dny učili, že nemáme používat standardní Logger, protože spoustu věcí neumí a že prý se stejně používá v praxi Slf4J, log4J nebo Logback a pak je ještě jedna. Já jsem si právěže mislel, že standardní knihovna Jazyka by měla být něco jako základ, ve kterém by všechno mělo fungovat a mělo by to být udělané dobře, protože všichni ostatní programátoři pak na tu budou navazovat. A proč to tam teda není za tolik let opravené nebo nějak vylepšené? V té Javě. Díky
-
Chtěl bych se proto zeptat vás zkušenější (než já), zdaž-li jde o chibu návrhu standardný knihovny v Java ecčars a pokud ano, zda biste mi to mohli vysvětlit.
Ano, jedná se o špatný návrh, pro součásti standardní knihovny z původní verze 1.0 je to poměrně typické.
Většina byla nahrazena něčím lépe navrženým, ale v tomto případě ne.
Jinak samozřejmě existuje ZipInputStream a nad ním se dá rekurzivní procházení postavit. Poměrně jasně si pamatuji že jsem kdysi dělal patchování souborů uvnitř warů uvnitř earu (tj. dvě úrovně zipu a ještě modifikace), streamově... Hledat to nikde v hluboké VCS historii nebudu (nikoho to stejně nězajímá), ale vím že to rozhodně nebyla sranda (teda sranda ve smyslu jednoduché, jinak to naopak sranda docela byla).
Každopádně, standardní řešení je: použít lepší knihovnu. Opensource.
PS: Tak, jeden člověk už se tady vytahoval, vlákno je možné zamknout.
Ale já jsem se díval i na ten ZipInputStream a nim to taky nemuze jit. On totiz neumi pro zadnou ZipEntry v zip souboru vytahnout jeji InputStream.
-
Druhý důvod je ten, že podstata Streamu, ve smyslu, jak je používán v .NET nebo v Javě, nemá nutně co dělat s formátem, ve kterém je zdroj uložen - obojí je zkrátka abstraktně představuje tok dat, který může procházet jistou transformací.
Problém je právě v tom, že je to tok bajtů. Když se podíváte na strukturu formátu ZIP, zjistíte, že přehled toho, co je v ZIPu uloženo, je až na konci souboru (což umožňuje soubor aktualizovat, aniž byste ho musel přepsat celý od začátku). Takže jak byste s tím pracoval, když máte k dispozici jenom tok dat? Začnete číst od začátku, budete přeskakovat v tu chvíli nezajímavá data (protože jim nerozumíte a nevíte, co znamenají), až se konečně dostanete k adresáři na konci souboru, ten přečtete a zjistíte, že požadovaná data byla v tom, co jste zahodil. Ale máte smůlu, je to stream, vrátit se nemůžete.
Poučen tímto nezdarem budete příště stream zpracovávat jinak – při procházení si data budete někam odkládat, když se to nevejde do RAM, odložíte si je na disk. Až se propracujete k závěrečnému adresáři, konečně se dozvíte, co je kde v souboru uložené, vrátíte se k těm datům, co jste si uložil, a konečně je můžete zpracovat.
Trošku divné je, když takhle budete zpracovávat ZIP jako soubor na disku – budete ho načítat jako stream a data si bufferovat do druhého souboru. Proč, když už je jednou v souboru máte? Nehledě na to, že když budete mít velký ZIP a z něj potřebovat vytáhnout malý soubor, můžete klidně skončit na tom, že vám dojde místo na disku.
Když ZIP nedostanete jako stream bajtů, ale jako pole bajtů s náhodným přístupem, můžete s ním pracovat úplně jinak. Prostě si nejdřív přečtete z konce souboru adresář, a podle něj si najdete třeba ten jediný soubor, který chcete rozbalit. Nemusíte nic bufferovat, nemusíte vytvářet zbytečné dočasné soubory.
Java je nízkoúrovňový nástroj, takže vám poskytuje jen ty základní nástroje, abyste mohl něco udělat. Takže pokud chcete rozbalovat ZIP v ZIPu, standardní knihovna Javy vám k tomu dává nástroje, akorát si to budete muset naprogramovat sám. A nebo použijete nějakou knihovnu, která už to má v sobě – třeba zt-zip, zp4j nebo TrueZIP.
Je klidně možné, že C# má už ve standardní knihovně nějakou nadstavbu, která interně řeší to bufferování. Což ale nemění nic na tom, že je to nutné udělat – a můžete jen doufat, že je ta implementace tak chytrá, že zjistí, když je za streamem schovaný soubor, a vykašle se v tom případě na stream a použije náhodný přístup.
-
Use google, Luke
http://stackoverflow.com/questions/35336870/java-utility-library-for-nested-zip-file-handling
Apropos, Java v zakladmin JDK spoustu veci neumi. A to je dobre, nema smysl cpat do zakladu kazdou kravinu, kterou pouzije jeden clovek ze sta.
Od toho jsou tu externi knihovny, ktere pomoci mavenu seamless zakomponujes do sveho projektu. Sila javy je hlavne v jejim ekosystemu.
Tj. kdyz tvuj projek postavis na mavenu, do pom.xml si pridej zavislost na Apache Commons a opajcuj ten example ze Stac Overflow
A proč to teda ten C# umí hned v té základní knihovně a Java to má tak složité? Navíc jsme se ještě před pár dny učili, že nemáme používat standardní Logger, protože spoustu věcí neumí a že prý se stejně používá v praxi Slf4J, log4J nebo Logback a pak je ještě jedna. Já jsem si právěže mislel, že standardní knihovna Jazyka by měla být něco jako základ, ve kterém by všechno mělo fungovat a mělo by to být udělané dobře, protože všichni ostatní programátoři pak na tu budou navazovat. A proč to tam teda není za tolik let opravené nebo nějak vylepšené? V té Javě. Díky
No opravene/vylepsene to neni asi z toho duvodu, ze to nikdo neudelal. V kazdem frameworku mas nejake diry, nelogicnosti.
Jestli se chces vazneji zabyvat Javou, zacni pouzivat Maven, pak te nezajima, jestli je dana class soucasti oficialni JDK, nebo je to nejake rozsireni od Apache Foundation nebo Google vystavene na Maven Central.
Rozvoj Javy je decentralizovany, neco nacpe Oracle primo do JDK, neco zustane jenom venku na Maven central. Treba Java EE 7 je pomerne tezkopadna, vetsina vyvojaru pouziva konkurencni Spring Framework aniz by to necemu vadilo.
C# ma vsecko primo v base frameworku proto, ze krom MS jenom malokdo externi pro .Net vyviji knihovny. Existuje jakysi pokus NuGet - ale je to v zacatcich a hodne syrove.
-
Use google, Luke
http://stackoverflow.com/questions/35336870/java-utility-library-for-nested-zip-file-handling
Apropos, Java v zakladmin JDK spoustu veci neumi. A to je dobre, nema smysl cpat do zakladu kazdou kravinu, kterou pouzije jeden clovek ze sta.
Od toho jsou tu externi knihovny, ktere pomoci mavenu seamless zakomponujes do sveho projektu. Sila javy je hlavne v jejim ekosystemu.
Tj. kdyz tvuj projek postavis na mavenu, do pom.xml si pridej zavislost na Apache Commons a opajcuj ten example ze Stac Overflow
A proč to teda ten C# umí hned v té základní knihovně a Java to má tak složité? Navíc jsme se ještě před pár dny učili, že nemáme používat standardní Logger, protože spoustu věcí neumí a že prý se stejně používá v praxi Slf4J, log4J nebo Logback a pak je ještě jedna. Já jsem si právěže mislel, že standardní knihovna Jazyka by měla být něco jako základ, ve kterém by všechno mělo fungovat a mělo by to být udělané dobře, protože všichni ostatní programátoři pak na tu budou navazovat. A proč to tam teda není za tolik let opravené nebo nějak vylepšené? V té Javě. Díky
No opravene/vylepsene to neni asi z toho duvodu, ze to nikdo neudelal. V kazdem frameworku mas nejake diry, nelogicnosti.
Jestli se chces vazneji zabyvat Javou, zacni pouzivat Maven, pak te nezajima, jestli je dana class soucasti oficialni JDK, nebo je to nejake rozsireni od Apache Foundation nebo Google vystavene na Maven Central.
Rozvoj Javy je decentralizovany, neco nacpe Oracle primo do JDK, neco zustane jenom venku na Maven central. Treba Java EE 7 je pomerne tezkopadna, vetsina vyvojaru pouziva konkurencni Spring Framework aniz by to necemu vadilo.
C# ma vsecko primo v base frameworku proto, ze krom MS jenom malokdo externi pro .Net vyviji knihovny. Existuje jakysi pokus NuGet - ale je to v zacatcich a hodne syrove.
Ale tak prece minymalne ten ZipArchive nikdo nemusel znovu vytvaret v komunitni verzi, kdyz uz dobre funguje v te zakladni. A Logger je v C# taky lepsi nez ten v Jave, nebo ten uz je taky nic moc a vsichni programatori musi v C# pouzivat nejaky externi? A proc je v Jave tolik ruznych externich loggeru, co se pouzivaji, a ne jen jeden? Prece kdyz by byly vsechny napsane poradne a dobre, tak by se nepouzivaly hned 4 najednou, ale nejaky jeden, co bude dobry, ne? Neni to zbytecne umet pracovat se 4 loggery?
-
A naco by meli v tom C# teda taky ten Maven, kdyz zadne externi knohovny importovat nemusi, prOtoze uz vsechno ma C# v zakladni verzi? Je to jeste k necemu dobre ten Maven? Nebo to ma Java prave proto, abi se treba daly naimportovat veci, ketere v zakladni Jave budto vubec nejsou nebo tam nejsou udelane moc dobre?
-
Já jsem si právěže mislel, že standardní knihovna Jazyka by měla být něco jako základ, ve kterém by všechno mělo fungovat a mělo by to být udělané dobře, protože všichni ostatní programátoři pak na tu budou navazovat.
Právě proto tam nemůžou být komplexní operace jako rekurzivní rozbalování ZIP souborů, protože ty bude chtít každý udělat trochu jinak. Má tam být právě jen ten základ.
A proč to tam teda není za tolik let opravené nebo nějak vylepšené? V té Javě.
Java drží extrémní politiku zpětné kompatibility – ze standardní knihovny nebylo od verze 1.0 nic odstraněno, včetně věcí, které byly opravené hned v následující verzi (třeba java.util.Date – teď už máme ve standardní knihovně 3. generaci tříd pro práci s datem a časem, ale předchozí generace tam stále zůstávají). Takže některé věci se sice „opravují“, ale takovým způsobem, že se ponechá ta stará „chybná“ verze a vedle ní se přidá nová.
Na tom ZipFile není co opravovat, to, co má dělat, dělá správně. A vylepšovat – proč cpát do standardní knihovny něco, co využije jen málokdo? Ve standardní knihovně má být jen základ.
S tím logováním je to podobné – nějaký základ ve standardní knihovně je, pokud někdo chce něco lepšího, má možnost použít rozšiřující knihovny. Které se mimochodem stále vyvíjí, takže by nebylo rozumné je cpát do standardní knihovny, protože pak byste stejně chtěl používat ty novinky a stejně byste si k aplikaci připojoval externí knihovny. Tohle už bylo s XML knihovnami (ve standardní knihovně byl vložený Xerces a Xalan, které se vedle dál vyvíjely), a byly z toho jen samé problémy a neustále se řešilo, jak z běhového prostředí vyštípat ty staré verze knihoven, které byly součástí JRE, a místo nich použít novější verze. (Tam to navíc bylo dané tím, že autoři Xercesu a Xalanu byli schopni psát C++ v jakémkoli jazyce, takže ty knihovny nebyly se světem Javy moc kompatibilní – a abych jim jen nekřivdil, nutno podotknout, že to bylo už hodně dávno a zdaleka ještě nebylo známo tolik best practices, jak některé věci dělat.)
-
Ale já jsem se díval i na ten ZipInputStream a nim to taky nemuze jit. On totiz neumi pro zadnou ZipEntry v zip souboru vytahnout jeji InputStream.
Ze ZipInputSream nemusíte žádný InputStream vytahovat, ZipInputStream už sám implementuje InputStream.
-
Use google, Luke
http://stackoverflow.com/questions/35336870/java-utility-library-for-nested-zip-file-handling
Apropos, Java v zakladmin JDK spoustu veci neumi. A to je dobre, nema smysl cpat do zakladu kazdou kravinu, kterou pouzije jeden clovek ze sta.
Od toho jsou tu externi knihovny, ktere pomoci mavenu seamless zakomponujes do sveho projektu. Sila javy je hlavne v jejim ekosystemu.
Tj. kdyz tvuj projek postavis na mavenu, do pom.xml si pridej zavislost na Apache Commons a opajcuj ten example ze Stac Overflow
A proč to teda ten C# umí hned v té základní knihovně a Java to má tak složité? Navíc jsme se ještě před pár dny učili, že nemáme používat standardní Logger, protože spoustu věcí neumí a že prý se stejně používá v praxi Slf4J, log4J nebo Logback a pak je ještě jedna. Já jsem si právěže mislel, že standardní knihovna Jazyka by měla být něco jako základ, ve kterém by všechno mělo fungovat a mělo by to být udělané dobře, protože všichni ostatní programátoři pak na tu budou navazovat. A proč to tam teda není za tolik let opravené nebo nějak vylepšené? V té Javě. Díky
No opravene/vylepsene to neni asi z toho duvodu, ze to nikdo neudelal. V kazdem frameworku mas nejake diry, nelogicnosti.
Jestli se chces vazneji zabyvat Javou, zacni pouzivat Maven, pak te nezajima, jestli je dana class soucasti oficialni JDK, nebo je to nejake rozsireni od Apache Foundation nebo Google vystavene na Maven Central.
Rozvoj Javy je decentralizovany, neco nacpe Oracle primo do JDK, neco zustane jenom venku na Maven central. Treba Java EE 7 je pomerne tezkopadna, vetsina vyvojaru pouziva konkurencni Spring Framework aniz by to necemu vadilo.
C# ma vsecko primo v base frameworku proto, ze krom MS jenom malokdo externi pro .Net vyviji knihovny. Existuje jakysi pokus NuGet - ale je to v zacatcich a hodne syrove.
Ale tak prece minymalne ten ZipArchive nikdo nemusel znovu vytvaret v komunitni verzi, kdyz uz dobre funguje v te zakladni. A Logger je v C# taky lepsi nez ten v Jave, nebo ten uz je taky nic moc a vsichni programatori musi v C# pouzivat nejaky externi? A proc je v Jave tolik ruznych externich loggeru, co se pouzivaji, a ne jen jeden? Prece kdyz by byly vsechny napsane poradne a dobre, tak by se nepouzivaly hned 4 najednou, ale nejaky jeden, co bude dobry, ne? Neni to zbytecne umet pracovat se 4 loggery?
Porad nechapes, ze v Jave je uplne jedno, jesdli dana funkcionalita je soucasti JDK, nebo je externi vystavena v Maven central. Jediny rozdil je v tom, ze v pom.xml (konfigurak mavenu) je zapsany tag <Dependency> ktery odkazuje na prislusnou knihovnu prislusne verze na Maven Central. Pri spusteni maven buildu maven sam knihovny stahne, nastrka je do vysledkeho JAR/WAR.
Kdyz nekdo pozdeji udela lepsi implementaci dane knihovny (napr. Apache CXF nahradila Apache Axis2), no tak se do pom.xml prida odkaz na jinou knihovnu a hotovo.
Neni potreba zasirat JDK prave modnimi funkcemi, po kterych za 5 let nestekne pes, zato budou v JDK strasit naveky.
Zminovany logging je presne ten pripad, puvodni Java Logger je uz davno nahrazeny lepsimi variantami, musi tam ale porad strasit z compatibility duvodu. Dnesni programamator do pom.xml prida:
<!-- https://mvnrepository.com/artifact/org.slf4j/slf4j-api -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.25</version>
</dependency>
A hotovo.
A pokud nekdo udela pozdeji lepsi implementaci, rezidua nebudou v JDK strasit naveky.
Pokud ti mentalni blok nedovoluje pouzivat knihovny mimo base SDK, pak zkratka zustan u C#, tam budes mit lepsi podminky.
-
Ale já jsem se díval i na ten ZipInputStream a nim to taky nemuze jit. On totiz neumi pro zadnou ZipEntry v zip souboru vytahnout jeji InputStream.
Nehovor ze to nemoze ist, lebo sa najde blbec, ktory nevie, ze to nemoze ist a spravi to.
Ja som riesl podobnu ulohu do vedlajsieho vlakna a aspon na mojom PC mi to funguje. Prikladam riesenie. Sorry za code-style, islo mi len o to to rychlo nabusit.
-
Ale já jsem se díval i na ten ZipInputStream a nim to taky nemuze jit. On totiz neumi pro zadnou ZipEntry v zip souboru vytahnout jeji InputStream.
Nehovor ze to nemoze ist, lebo sa najde blbec, ktory nevie, ze to nemoze ist a spravi to.
Ja som riesl podobnu ulohu do vedlajsieho vlakna a aspon na mojom PC mi to funguje. Prikladam riesenie. Sorry za code-style, islo mi len o to to rychlo nabusit.
Dival jsem se na to a moc to nechapu. Proc jsi to udelal tak slozite?
-
Už u toho předchozího trolení stačilo napsat mu těch 10 řádků a neřešit nesmysly. Tady diskuze o ničem a řešení se čtyřma třídama. :-\ :-\
-
Už u toho předchozího trolení stačilo napsat mu těch 10 řádků a neřešit nesmysly. Tady diskuze o ničem a řešení se čtyřma třídama. :-\ :-\
Napsal bi si mi tech 10 radku, co rekurzivně projdou nějaký zip soubor a vipíšou jeho obsah do konzole, přičemž budeš používat pouze sdk?
-
Tak trošku víc než 10.
public static void dump(String pad, ZipInputStream zis) throws Exception {
ZipEntry ze;
byte[] data = new byte[128];
while ((ze = zis.getNextEntry()) != null) {
String name = ze.getName();
System.out.println(pad + "name: " + name);
if (name.endsWith(".zip")) {
dump(pad + " ", new ZipInputStream(zis));
} else {
System.out.print(pad + "data: ");
System.out.write(data, 0, zis.read(data, 0, data.length));
}
}
}
public static void main(String[] args) throws Exception {
dump("> ", new ZipInputStream(new FileInputStream("a.zip")));
}
> name: a.txt
> data: [data a.txt]
> name: b.zip
> name: b.txt
> data: [data b.txt]
> name: c.zip
> name: c.txt
> data: [data c.txt]
-
Už u toho předchozího trolení stačilo napsat mu těch 10 řádků a neřešit nesmysly. Tady diskuze o ničem a řešení se čtyřma třídama. :-\ :-\
Napsal bi si mi tech 10 radku, co rekurzivně projdou nějaký zip soubor a vipíšou jeho obsah do konzole, přičemž budeš používat pouze sdk?
Mrkni se do .Net SDK, jestli tam neni pribaleny nejaky checker ceske gramatiky.
Ja teda nejsem grammar nazi, ale z tveho psaneho projevu mi krvaceji oci.
-
A naco by meli v tom C# teda taky ten Maven, kdyz zadne externi knohovny importovat nemusi, prOtoze uz vsechno ma C# v zakladni verzi? Je to jeste k necemu dobre ten Maven? Nebo to ma Java prave proto, abi se treba daly naimportovat veci, ketere v zakladni Jave budto vubec nejsou nebo tam nejsou udelane moc dobre?
No napriklad, pokud chci z .Net poslat SNMP trap, base SDK to neumi.
Umi to knihovna http://sharpsnmplib.codeplex.com/
Jenze neni v mavenu, takze si to hezky manualne stahni, pridej do projektu a jednou za cas se mrkni na stranky, jestli neexistuje nejaka nova verze.
-
Ten moment, kdy si chces nad krb povesit hlavu trolla :D
-
.NET a Java ma inu filozofiu a ekosystem. .NET Framework je v mnohom cistejsi a elegantnejsi, je vacsia sanca, ze priamo v zakladnom frameworku najdes peknu triedu na to, co potrebujes. V Jave ju vacsinou najdes v nejakom apachovskom alebo podobnom projekte ako malu a samostatnu kniznicu, pripadne na to najdes kniznice rovno 4 a rozhodni sa. Toto .NET-aci, ktori prechadzaju na Javu moc radi nemaju a ked sa pozru na JDK, biju si hlavu o stenu, kolko malych a zakladnych veci musia tahat niekde z vonka, na zaklade coho sa maju rozhodnut pre nejake jar-ko, ktore implementuje "zakladne veci", preco sa vobec musia rozhodovat a dohadovat sa kolegami, ktora je lepsia a preco sa kazda prkotina da riesit na 5 sposobov.
-
O co, že se vám nepodaří rekurzivně projít tenhle zip.
http://swtch.com/r.zip (http://swtch.com/r.zip)
-
Tak trošku víc než 10.
public static void dump(String pad, ZipInputStream zis) throws Exception {
ZipEntry ze;
byte[] data = new byte[128];
while ((ze = zis.getNextEntry()) != null) {
String name = ze.getName();
System.out.println(pad + "name: " + name);
if (name.endsWith(".zip")) {
dump(pad + " ", new ZipInputStream(zis));
} else {
System.out.print(pad + "data: ");
System.out.write(data, 0, zis.read(data, 0, data.length));
}
}
}
public static void main(String[] args) throws Exception {
dump("> ", new ZipInputStream(new FileInputStream("a.zip")));
}
> name: a.txt
> data: [data a.txt]
> name: b.zip
> name: b.txt
> data: [data b.txt]
> name: c.zip
> name: c.txt
> data: [data c.txt]
Takže mýlka vznikla z toho důvodu, že ten ZipInputStream je Stream a zároveň iterátor. Je to špatný OOP návrh, který porušuje Single responsibility princip, v dokumentaci třídy není uvedeno, že se jedná o kočkopsa a proto mi nedošlo, jak se to má používat. Správné by bylo, kdyby ZipInputStream byl iterátor nad ZipEntry, a na ZipEntry by mělo getInputStream(). Ale pokud dělali Javu stejní kokodi, jako dělali SQL Developera, Eclipse a podobné, tak se není moc čemu divit.
-
Tak trošku víc než 10.
public static void dump(String pad, ZipInputStream zis) throws Exception {
ZipEntry ze;
byte[] data = new byte[128];
while ((ze = zis.getNextEntry()) != null) {
String name = ze.getName();
System.out.println(pad + "name: " + name);
if (name.endsWith(".zip")) {
dump(pad + " ", new ZipInputStream(zis));
} else {
System.out.print(pad + "data: ");
System.out.write(data, 0, zis.read(data, 0, data.length));
}
}
}
public static void main(String[] args) throws Exception {
dump("> ", new ZipInputStream(new FileInputStream("a.zip")));
}
> name: a.txt
> data: [data a.txt]
> name: b.zip
> name: b.txt
> data: [data b.txt]
> name: c.zip
> name: c.txt
> data: [data c.txt]
Takže mýlka vznikla z toho důvodu, že ten ZipInputStream je Stream a zároveň iterátor. Je to špatný OOP návrh, který porušuje Single responsibility princip, v dokumentaci třídy není uvedeno, že se jedná o kočkopsa a proto mi nedošlo, jak se to má používat. Správné by bylo, kdyby ZipInputStream byl iterátor nad ZipEntry, a na ZipEntry by mělo getInputStream(). Ale pokud dělali Javu stejní kokodi, jako dělali SQL Developera, Eclipse a podobné, tak se není moc čemu divit.
Nic to neporusuje, iterator je normalny navrhovy vzor a pouziva sa bezne pri streamoch. Vratte diplom prosim.
-
Běžně kde? V Javě? Uvedte priklad.
Správně to ma udělané C#.
-
Běžně kde? V Javě? Uvedte priklad.
Správně to ma udělané C#.
Bezne je to napriklad v smalltalku.
r := ReadStream on: (1 to: 1000).
r next. -→ 1
r next. -→ 2
r atEnd.-→ false
-
Běžně kde? V Javě? Uvedte priklad.
Správně to ma udělané C#.
Bezne je to napriklad v smalltalku.
r := ReadStream on: (1 to: 1000).
r next. -→ 1
r next. -→ 2
r atEnd.-→ false
Omg no ty budeš inteligent, to je ale naprosto jinaci situace, tam je samotny Stream implementovany formou iteratoru... Nejdrive se podivej, o cem je tady rec, a nebo pokud to vis, vrat diplom.
-
Běžně kde? V Javě? Uvedte priklad.
Správně to ma udělané C#.
Bezne je to napriklad v smalltalku.
r := ReadStream on: (1 to: 1000).
r next. -→ 1
r next. -→ 2
r atEnd.-→ false
Omg no ty budeš inteligent, to je ale naprosto jinaci situace, tam je samotny Stream implementovany formou iteratoru... Nejdrive se podivej, o cem je tady rec, a nebo pokud to vis, vrat diplom.
A v jave nie je stream iplementovany ako iterator? Situacia je inaksia? V com?
-
Takže mýlka vznikla z toho důvodu, že ten ZipInputStream je Stream a zároveň iterátor. Je to špatný OOP návrh, který porušuje Single responsibility princip, v dokumentaci třídy není uvedeno, že se jedná o kočkopsa a proto mi nedošlo, jak se to má používat. Správné by bylo, kdyby ZipInputStream byl iterátor nad ZipEntry, a na ZipEntry by mělo getInputStream(). Ale pokud dělali Javu stejní kokodi, jako dělali SQL Developera, Eclipse a podobné, tak se není moc čemu divit.
Neumíte naprogramovat domácí úkol, který je možná i na dvacet řádků, neumíte si přečíst dokumentaci, ale hlavně že víte, jak by to mělo vypadat a co dělají všichni ostatní špatně.
Pro vaší informaci, ZipInputStream je potomek třídy FilterInputStream, která (překvapivě) funguje jako filtr, tj. na vstupu dostane jeden InputStream, vy s ní pracujete zase jako s InputStreamem a ta třída uvnitř provádí nějaké filtrování toho streamu. Chápu, že je to napsané až na pátém řádku dokumentace, a tak daleko jste nedočetl.
Ta třída existuje pravděpodobně „do počtu“ s ostatními třídami, které dělají (de)komprimaci nad streamy. Nejhorší na té třídě je, že vůbec existuje, nebo že u ní není uvedeno důrazné varování, že její použití je jen na vlastní nebezpečí a podrobné vysvětlení, co ta třída vlastně dělá. Protože ta třída čte jednotlivé položky ZIPu tak jak jsou v souboru uvedeny za sebou, a ignoruje adresář uložený na konci souboru. Přitom ale v tom adresáři je uvedeno, co je v tom ZIPu doopravdy. Když budete ZIP procházet pomocí ZipInputStreamu, můžete klidně rozbalit smazané soubory, starou verzi souboru nebo soubor budete mít špatně pojmenovaný. Což je podle mne mnohem horší než to, že si neumíte přečíst dokumentaci a nechápete, jak se ta třída používá.
-
Tam je totiž základní kravina v tom, že je tam vůbec nějaká třída umožňující procházet zip soubor implementovaná jako nějaký potomek InputStream, protože to má být spíše potomek Iterator. Toť věc první. Druhý problém, podstatně základnější, tam je v tom, že InputStream není napsán dostatečně abstraktně. Proto vůbec vznikla taková kravina, jako je FilteredInputStream.
InputStream by se totiž měl správně jmenovat ByteInputStream. Je to totiž, stejně jako v C#, proud nad typem byte. Správně, abstraktně implementovaná třída Stream, by měla být generická, s možnosti vybrat si, nad jakou jednotkou to stream vlastně je. Protože proud může být nad byte, nad soubory, nad ip pakety, nad tenisovými míčky nebo nad molekulami vody.
Takže tam je základní problém už v architektuře a C# to pak z Javy blbě okopíroval, takže svůj Stream impplementuje stejně blbě.
Podstatně blíže abstraktnímu pojetí streamu je totiž v podstatě Iterator. To je správně abstraktně napsaný Stream.
A teď k vám, pane Jirskáku. Nikdo netvrdí, že něco, co je Stream nad zip souborem, musí procházet i smazané soubory,. Stream je abstraktní věc. ValidZipInputStream by byl taky stream a vracel by klidně jen validní soubory podle té vaší zip složky. Na disku máte taky data fyzicky zapsány různě napřeskáčku a některé z nich jsou smazané, připadá vám však ale, že nad soubory pak fungují streamy nějak blbě? Takže si v tom udělajte pořádek pane Jirskáku, zamyslete, co jsou to vlastně streamy, máte už na to věk.
A teď zpátky od pana Jirsáka k Javě. Pokud to, co tvrdí trochu pomýlený pan Jirsák o ZipInputStream, je pravda, totiž že čte i nevalidní soubory v zip archivu a není to ani uvedeno v dokumentaci, tak je to, obávám se, ještě větší sračka, než si všichni mysleli, a nechci ani domýšlet, kolik tento paskvil, kterých je v Javě povícero, způsobil, za dobu své existence, škod v řádech milionů dolarů, a to na jen nejrůznějších chybách v produkci.
-
A teď zpátky od pana Jirsáka k Javě. Pokud to, co tvrdí trochu pomýlený pan Jirsák o ZipInputStream, je pravda, totiž že čte i nevalidní soubory v zip archivu a není to ani uvedeno v dokumentaci, tak je to, obávám se, ještě větší sračka, než si všichni mysleli, a nechci ani domýšlet, kolik tento paskvil, kterých je v Javě povícero, způsobil, za dobu své existence, škod v řádech milionů dolarů, a to na jen nejrůznějších chybách v produkci.
Trošku off topic, než se do sebe zase pustíte - tohle fakt znamená, že Java dokáže číst data ze zip souboru, který nemá konec? To by se mohlo hodit.
-
Trošku off topic, než se do sebe zase pustíte - tohle fakt znamená, že Java dokáže číst data ze zip souboru, který nemá konec? To by se mohlo hodit.
Ano, znamená. Ale také to znamená, že ten soubor je poškozený, a že tím pádem můžete přečíst něco, co v tom ZIPu vůbec není. Je to podobné, jako když si u souborového systému omylem smažete hlavičku – existují nástroje, které se pokusí z něj zachránit data, ale musíte počítat s tím, že dostanete spoustu souborů na jedné hromadě, kterou si pak budete muset ručně roztřídit na to, co je správné a platné, a na smetí, které se tam připletlo omylem.
-
Trošku off topic, než se do sebe zase pustíte - tohle fakt znamená, že Java dokáže číst data ze zip souboru, který nemá konec? To by se mohlo hodit.
Ano, znamená. Ale také to znamená, že ten soubor je poškozený, a že tím pádem můžete přečíst něco, co v tom ZIPu vůbec není. Je to podobné, jako když si u souborového systému omylem smažete hlavičku – existují nástroje, které se pokusí z něj zachránit data, ale musíte počítat s tím, že dostanete spoustu souborů na jedné hromadě, kterou si pak budete muset ručně roztřídit na to, co je správné a platné, a na smetí, které se tam připletlo omylem.
Díky za odpověď, tohle jsem pochopil. Nicméně v typickém případě se zip dělá sekvenčně a nemodifikuje, nebo ne?
-
Tam je totiž základní kravina v tom, že je tam vůbec nějaká třída umožňující procházet zip soubor implementovaná jako nějaký potomek InputStream, protože to má být spíše potomek Iterator. Toť věc první. Druhý problém, podstatně základnější, tam je v tom, že InputStream není napsán dostatečně abstraktně. Proto vůbec vznikla taková kravina, jako je FilteredInputStream.
InputStream by se totiž měl správně jmenovat ByteInputStream. Je to totiž, stejně jako v C#, proud nad typem byte. Správně, abstraktně implementovaná třída Stream, by měla být generická, s možnosti vybrat si, nad jakou jednotkou to stream vlastně je. Protože proud může být nad byte, nad soubory, nad ip pakety, nad tenisovými míčky nebo nad molekulami vody.
Názorná ukázka toho, že čím méně toho člověk ví, tím méně informací má o tom, co všechno neví – a má pak pocit, že rozumí skoro všemu. Vaše poučování o tom, jak by něco mělo být správně architektonicky navržené, je zábavné – když si uvědomíme, že neumíte naprogramovat triviální domácí úkol, a neumíte vlastně ani správně číst a psát. Navíc celý balíček java.util.zip byl do Javy přidán v JDK 1.1, která byla vydána před dvaceti lety – takže jdete trošku s křížkem po funuse.
Podstatně blíže abstraktnímu pojetí streamu je totiž v podstatě Iterator. To je správně abstraktně napsaný Stream.
To, že vy máte jakousi mlhavou představu, co by měl dělat váš stream, vůbec neznamená, že jsou ostatní povinni to slovo používat stejně. Java prostě na začátku zavedla pro proud bajtů označení „stream“, protože se to hodilo a slovo „stream“ v té době bylo ve světě programování volné.
Nikdo netvrdí, že něco, co je Stream nad zip souborem, musí procházet i smazané soubory,.
Netvrdím to ani já. Kdybyste si přečetl pořádně, co jsem napsal, dozvěděl byste se, že ZipInputStream, tak, jak je implementován v JRE, nutně prochází i smazané soubory nebo staré verze souborů. A že se tak nutně musí chovat každá implementace, která bude zip soubor načítat z proudu bajtů a nebude ho někde bufferovat. Plyne to z toho, jakou má zip formát strukturu – že „hlavička“ souboru s informacemi, kde co v souboru je, je uložená až na konci souboru.
Asi vám formát toho souboru připadá hloupý, protože abyste s tím souborem mohl rozumně pracovat, musíte mít k jeho obsahu náhodný přístup. Jenže ten souborový formát vznikl už v době pevných disků, které náhodný přístup umožňují – a tahle struktura formátu má tu obrovskou výhodu, že můžete ze zip souboru získat jeden soubor, aniž byste musel procházet vše, co je před ním. A zároveň to umožňuje vytvořit zip soubor na jediný průchod.
ValidZipInputStream by byl taky stream a vracel by klidně jen validní soubory podle té vaší zip složky.
Akorát že takový stream by si nutně musel někam bufferovat načítaná data. Což není nic, co by mělo být ve standardní knihovně, protože je to velmi implementačně závislé. Někdy budete vědět, že stačí bufferovat do RAM, někdy budete vědět, že je potřeba použít disk, někdy budete vědět, že můžete disků použít víc, někdy, že stačí bufferovat jen některé položky. To si můžete implementovat v nějaké knihovně, ale nemá to co dělat v nízkoúrovňové základní knihovně.
Na disku máte taky data fyzicky zapsány různě napřeskáčku a některé z nich jsou smazané, připadá vám však ale, že nad soubory pak fungují streamy nějak blbě?
Máte zmatek v základních objektech, o kterých se tu bavíme. Souborový systém odpovídá zip souboru, jednotlivé soubory na tom souborovém systému odpovídají jednotlivým souborům v zipu. Ostatně existují různé nástroje, které se umí k zip souboru chovat, jako by to byl souborový systém. Streamy nad soubory v Javě (FileInputStream, FileOutputStream) operují nad jednotlivými soubory, ZipInputStream ale operuje nad celým zip souborem, tedy nad kolekcí souborů – tedy by to odpovídalo streamu nad celým souborovým systémem. Kdybyste implementoval nějaký třeba (pro jednoduchost) FATInputStream, který by měl na vstupu proud bajtů, měl byste s tím úplně stejný problém – musel byste data bufferovat (a to by vám u FAT stačilo bufferovat jen hlavičku, protože u FAT je na začátku diskového oddílu).
Takže si v tom udělajte pořádek pane Jirskáku, zamyslete, co jsou to vlastně streamy, máte už na to věk.
Děkuji za péči. Souhlasím s tím, že jeden z nás v tom má velký guláš. A myslím si, že je to ten, kdo neumí naprogramovat takovou trivialitu, jako je rekurzivní výpis seznamu souborů v zip souboru.
Pokud to, co tvrdí trochu pomýlený pan Jirsák o ZipInputStream, je pravda, totiž že čte i nevalidní soubory v zip archivu
Já jsem se díval do zdrojáku té třídy a na specifikaci zip formátu. Odkud své informace čerpáte vy? Navíc já jsem nepsal, že čte nevalidní soubory v zip archivu – napsal jsem, že čte i položky, které mohly být později upravené nebo smazané.
tak je to, obávám se, ještě větší sračka, než si všichni mysleli, a nechci ani domýšlet, kolik tento paskvil, kterých je v Javě povícero, způsobil, za dobu své existence, škod v řádech milionů dolarů, a to na jen nejrůznějších chybách v produkci.
Nemyslím si, že by vás pustili k něčemu, kde by mohly vzniknout škody v řádech milionů dolarů. A lidé, kteří umí aspoň trochu programovat, nebudou používat FileInputStream, který je k ničemu, ale použijí ZipFile nebo rovnou nějakou knihovnu. A taky si zjistí něco o formátu zip a ověří si, jestli je v souladu zadání a to, co chtějí použít při implementaci.
-
Nicméně v typickém případě se zip dělá sekvenčně a nemodifikuje, nebo ne?
Pravděpodobně ano. Nicméně vždycky je možnost, že ten zip někdo dodatečně upraví (dělal jsem to mnohokrát), taky je možné, že se někomu z důvodu snazší implementace hodí vytvořit ho „modifikovaný“ rovnou. A pak je tu samozřejmě možnost, že někdo vytvoří nějaký záškodnický plně validní zip záměrně.
Což je potřeba brát docela vážně, když uvážíte, že moderní souborové formáty kancelářských balíků (OpenDocument od OpenOffice.org a Office Open XML od Microsoftu) jsou zip archivy, zip archivy jsou třeba i binární balíčky Java programů. Takže když to rozbalíte špatně, můžete dostat jiný dokument nebo jiný program. Všechny zmíněné formáty umožňují dokument/balíček i podepsat, ale podepisuje se jen vnitřek zipu. Takže některým chybným implementacím rozbalení zipu (které by ignorovaly „hlavičku“ souboru) by bylo možné podstrčit dokumenty nebo balíčky, které by byly validním zipem, ta chybná implementace by je bez problémů rozbalila, seděly by všechny podpisy – akorát by tam bylo něco jiného, než kdybyste ten zip rozbalil správně.
-
Paneboze, tak toto je novy level, porovnavat jazyky podlepodpory archaickeho archivu.
C# implementace si to nacte do bufferu v pameti, coz je zrovna tak spatne reseni, co kdyz budu po tcp socketu chtit nacist 100 gb zip stream?))) Hlavne uplne umele vykonstruovany problem, od kdy je podpora zip v standardni knihovne ukazka kvality jazyka? Co jazyky,co ji nemaji zadnou?
-
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ě.
Takže si to vezměme hezky popořádku. Stream je v Javě implementován dost blbě a nikdo se nad tím očividně řádně nezamyslel. Ve světě OOP mi opravdu označení pro Stream - tedy obecně proud něčeho - nepříjde vůbec nějak volné, ale naprosto jednoznačně se odkazující ke specifikaci, nad jakým typem dat to má vlastně proud má být. Viz Java 8 - Streamy.
Takže takový příklad, který vám poslouží jako taková berlička, pane Jirsáku, abyste konečně vymanil z te nevědomosti a pochopil, že bufferování nehraje roli při rozhodování, zda-li něco je stream nebo není:
class CommandInputStream extends BufferedInputStream<Command,KeyStroke> { ... }
class CompositeCommand extends Command { // ctrl+alt+del ? }
class ZipInputStream extends BufferedInputStream<ZipEntry,Byte>
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. Takto se to rozhodli udělat v Javě a je to samozřejmě špatně, protože to neuvedli v dokumentaci.
Dále, je-li v nějaké knihovně třída pro práci se zip archivy, pojmenujme ji teď lépe ZipArchive, očekává se od ní, že uživatelům umožní rozbalit soubor, který chtějí. Když nějaký uživatel bude používat tuto třídu ZipArchive, očekává, že bude správně fungovat, ne, že fungovat nebude. Je takový problém, aby se v případě, že dochází paměť, začalo prostě bufferovat na disk? Nic jiného k zajištění správné funkce ani není možné, takže proč vy vlastně tvrdíte, že je to problematické a že si to musí každý naimplementovat sám podle svých potřeb? Implementace ZipArchive je naprosto jednoznačně daná.
Pane Jirsáku, vemte si někdy taky dovolenou, oddechněte si, sportujte, nechoďte tolik na sluníčko a bude to zase fajn.
-
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?
-
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ě.
Takže si to vezměme hezky popořádku. Stream je v Javě implementován dost blbě a nikdo se nad tím očividně řádně nezamyslel. Ve světě OOP mi opravdu označení pro Stream - tedy obecně proud něčeho - nepříjde vůbec nějak volné, ale naprosto jednoznačně se odkazující ke specifikaci, nad jakým typem dat to má vlastně proud má být. Viz Java 8 - Streamy.
Takže takový příklad, který vám poslouží jako taková berlička, pane Jirsáku, abyste konečně vymanil z te nevědomosti a pochopil, že bufferování nehraje roli při rozhodování, zda-li něco je stream nebo není:
class CommandInputStream extends BufferedInputStream<Command,KeyStroke> { ... }
class CompositeCommand extends Command { // ctrl+alt+del ? }
class ZipInputStream extends BufferedInputStream<ZipEntry,Byte>
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. Takto se to rozhodli udělat v Javě a je to samozřejmě špatně, protože to neuvedli v dokumentaci.
Dále, je-li v nějaké knihovně třída pro práci se zip archivy, pojmenujme ji teď lépe ZipArchive, očekává se od ní, že uživatelům umožní rozbalit soubor, který chtějí. Když nějaký uživatel bude používat tuto třídu ZipArchive, očekává, že bude správně fungovat, ne, že fungovat nebude. Je takový problém, aby se v případě, že dochází paměť, začalo prostě bufferovat na disk? Nic jiného k zajištění správné funkce ani není možné, takže proč vy vlastně tvrdíte, že je to problematické a že si to musí každý naimplementovat sám podle svých potřeb? Implementace ZipArchive je naprosto jednoznačně daná.
Pane Jirsáku, vemte si někdy taky dovolenou, oddechněte si, sportujte, nechoďte tolik na sluníčko a bude to zase fajn.
Nevim, jake ma Filip Jirsak nazory na politiku, pokud ma Merkel za dobrou politicku, tak se asi neshodneme, nicmene to:
* je uplne jedno
* nesouvisi s Javou
* nemeni nic na faktu, ze Jirsak je jeden z mala slusne a vecne diskutujicich v tehle zumpe, ktera si v nicem nezada s vykvety na novinkach
Zpatky k Jave. Evidentne v tom mas hokej, pokud michas Streams API a IO streamy. Oboji je jasne definovane, oboji k necemu uplne jinemu a hlavne to spoku vubec nesouvisi.
IO Stream, ktery prvne nacte vsechna data do pameti a jeste mozna neco zapise na disk, je opravdu skvela defininice streamu a uzasne pouzitelne pro proudove zpracovani zprav, DoS funkci programator dostane jako bonus...
Tvuj problem je, ze chces produove zpravovavat format, ktery na to neni urceny a nadavas Javu, ze nedela spatny workaround, ktery by byl skodlivy, jen pro tve pohodli.
-
Hokej v tom máš ty. Já jsem tady mluvil o Streamech abstraktních, řekl jsem, že Java 8 Stream api tuto abstraktnost cti ale InputStream a Jirsák ji nectí. To je jedna věc.
Druhá věc je, že nechci proudově zpracovávat formát, který proudem není, jen tvrdím, že je možné ho proudově zpracovat, ikdyž to znamená, že se musí nejprve celý načíst. To, že se musí celý načíst, neznamená, že to nemůže být proud.
Dokonce jsem jak pro debily uvedl příklad, že běžně existují streamy, které musí bufferovat, aby vytvořily správnou transformaci na výstupu. Ale je to marné, je to marné, je to marné.
-
Takže si to vezměme hezky popořádku. Stream je v Javě implementován dost blbě a nikdo se nad tím očividně řádně nezamyslel. Ve světě OOP mi opravdu označení pro Stream - tedy obecně proud něčeho - nepříjde vůbec nějak volné, ale naprosto jednoznačně se odkazující ke specifikaci, nad jakým typem dat to má vlastně proud má být. Viz Java 8 - Streamy.
Vezměte to popořádku. Nejprve získejte nějaké znalosti, a pak o tom něco pište. InputStream a OutpuStream jsou v Javě od verze 1.0, tedy od roku 1996. Stream API bylo přidáno do Javy ve verzi 8, tedy v roce 2014. Spletl jste se jenom o 18 let.
Takže takový příklad, který vám poslouží jako taková berlička, pane Jirsáku, abyste konečně vymanil z te nevědomosti a pochopil, že bufferování nehraje roli při rozhodování, zda-li něco je stream nebo není:
Kde jsem psal, že bufferování hraje roli při rozhodování, že je něco stream? Aha, nikde, to vy jenom neumíte číst. Zkusím vám to vysvětlit ještě jednou. Některé formáty dat jsou uspořádané tak, že k interpretaci dat, které jsou v proudu dat dříve, potřebujete informaci, která je v proudu dat až později. Pokud máte náhodný přístup ke všem datům, není to žádný problém – prostě si nejprve přečtete ten konec, zjistíte potřebné informace a na jejich základě pak přečtete začátek. Pokud ale ta data dostáváte od začátku do konce, tenhle postup použít nemůžete – když dostanete ta data na začátku, ještě nevíte, co s nimi máte dělat, musíte si je odložit někam stranou (do nějakého bufferu) a později se k nim vrátit.
Zkusím vám to uvést na takovém příkladu, jde jen o sčítání a odčítání malých čísel, to už jste snad ve škole bral. My jsme zvyklí používat infixovou notaci, kdy jsou tyto matematické operátory uvedené mezi operandy, třeba 5 + 3 - 7. Zkuste si, jak byste naprogramoval výpočet, kdybyste měl na vstupu stream operandů a operátorů zapsaných v tomhle pořadí (tedy byste měl stream 5, +, 3, -, 7). Dá se to udělat tak, že nemusíte nic bufferovat, pouze si budete pamatovat aktuální mezivýsledek a prováděnou operaci (což by se také dalo chápat jako buffer, ale nebudu vám to komplikovat).
Pro zápis matematických operací se dá ale použít také třeba postfixová notace, nebo-li reverzní polská notace (RPN). V té se zapisují nejprve operandy a teprve za nimi je operátor. Ten výše uvedený příklad můžete v RPN zapsal jako 5 3 7 - +6. (Ty dva zápisy nejsou ekvivalentní, tohle odpovídá v infixové notaci zápisu 5 + (3 - 7). Ale pro ulehčení jsem zvolil jen sčítání a odčítání, které mají stejnou prioritu, tudíž ani v infixové notaci nejsou závorky potřeba.) Opět máte na vstupu stream operandů a operátorů, tentokrát tedy 5, 3, 7, -, +. Dokážete naprogramovat výpočet jenom na základě toho streamu, aniž byste si musel bufferovat přicházející hodnoty, tj. ukládat si je do nějakého zásobníku?
Vám totiž nejde do hlavinky, že i input stream, který musí načíst nejprve celý vstupní stream, je rovněž stream.
Napsal jsem někde něco, z čeho by toto plynulo? Aha, nenapsal, to jenom vy neumíte číst. Napsal jsem, že aby bylo možné s tím zip archivem pracovat správně, musíte stejně celý ten stream přečíst a nabufferovat si ho, tj. zapsat někam, kde k němu budete mít přístup pro náhodné čtení – třeba do RAM nebo na disk.
A v tom je ten problém, který vy stále nechápete. Protože to bufferování může být operace velmi náročná na zdroje. Ano, nějaká knihovna to před vámi může skrýt, aby to mohli používat i takoví neumětelové, jako vy. Jenže to vám bude fungovat jen v jednoduchých případech. Když vám pak někdo pošle 100 GB zip („prosím vypal mi tenhle Blue-ray“) a ta vaše knihovna se ho pokusí celý načíst do paměti, nedopadne to moc slavně.
Takže ne, není pravda, co tvrdíte, že každá implementace ZipStreamu musí nutně na výstup posílat rovněž nevalidní soubory.
Což jsem opět nikde netvrdil, to jenom vy neumíte číst. Já jsem napsal, že pokud nemám přístup k datům zipu pro náhodné čtení (tj. mohu si kdykoli zvolit, kterou část zipu přečtu), ale mám k dispozici jenom proud bajtů, musím si ten proud bajtů odkládat někam, kde budu mít ten náhodný přístup – protože jedině tak dokážu zajistit, že ten příchozí zip archiv zpracuju správně.
Takto se to rozhodli udělat v Javě a je to samozřejmě špatně, protože to neuvedli v dokumentaci.
Jak už jsem psal, ta třída je velmi stará a dokumentace ještě pochází z doby, kdy programátoři rozuměli tomu, co dělají. Programátor, který zná formát zip archivu a přečte si tu dokumentaci, pochopí, jaká to má úskalí. Dneska už programují lidé jako vy, takže by v té dokumentaci mělo být uvedeno, ať se té třídě obloukem vyhnou lidé, kteří o formátu zip nic nevědí.
Dále, je-li v nějaké knihovně třída pro práci se zip archivy, pojmenujme ji teď lépe ZipArchive, očekává se od ní, že uživatelům umožní rozbalit soubor, který chtějí. Když nějaký uživatel bude používat tuto třídu ZipArchive, očekává, že bude správně fungovat, ne, že fungovat nebude.
Což je přesně to, co dělá třída java.util.zip.ZipFile. Nebo vy snad máte nějaký příklad, kdy funguje špatně?
Je takový problém, aby se v případě, že dochází paměť, začalo prostě bufferovat na disk?
Ano, je to problém třeba v případě, kdy nemáte k dispozici disk, na který můžete zapisovat. Nebo v případě, kdy na disku nemáte volné místo.
Nic jiného k zajištění správné funkce ani není možné
Ale je to možné. Víte, občas někdo přijde s takovou školní úlohou, že má vypsat názvy souborů v tom zipu. Proč by pak rozbaloval ty soubory na disk, když je vůbec nepotřebuje? Když vám pošlu po síti 100 GB zip s úkolem, že máte vypsat názvy souborů v něm obsažených, a vy máte aplikaci spuštěnou na bezdiskovém počítači se 4 GB RAM, je to bez problémů splnitelný úkol. Akorát to musí naprogramovat někdo, kdo aspoň trochu ví, o co jde.
takže proč vy vlastně tvrdíte, že je to problematické a že si to musí každý naimplementovat sám podle svých potřeb?
Protože o té problematice alespoň něco malilinko vím. Vám, který o tom nevíte vůbec nic, se to samozřejmě všechno zdá snadné. Jenom se to naučit a mohl byste to naimplementovat.
Pane Jirsáku, vemte si někdy taky dovolenou, oddechněte si, sportujte, nechoďte tolik na sluníčko a bude to zase fajn.
Mám pro vás špatnou zprávu. Pokud byste se někdy skutečně naučil alespoň základy programování, pochopíte, jak hloupé byly vaše komentáře v této diskusi. Teď to vědět nemůžete, protože když nevíte vůbec nic, nemáte ani znalosti na to, abyste pochopil, jak málo toho víte.
Já jsem tady mluvil o Streamech abstraktních, řekl jsem, že Java 8 Stream api tuto abstraktnost cti ale InputStream a Jirsák ji nectí. To je jedna věc.
Už jsem vám vysvětloval, že IO streamy v Javě tento název ctít nemohou, když vznikly asi tak 15 let před tímto názvem.
Druhá věc je, že nechci proudově zpracovávat formát, který proudem není, jen tvrdím, že je možné ho proudově zpracovat, ikdyž to znamená, že se musí nejprve celý načíst. To, že se musí celý načíst, neznamená, že to nemůže být proud.
Akorát když ten proud načtete do paměti s náhodným přístupem a pracujete pak s tou pamětí, nepracujete už s proudem dat, ale s pamětí s náhodným přístupem. Ten postup „načíst do paměti“ není možné provést vždy – proud je potenciálně nekonečný, a to se vám do paměti fakt nevejde.
Ale je to marné, je to marné, je to marné.
Není to marné. Naučili se to jiní před vámi, není důvod, proč byste se nenaučil programovat i vy. Není to těžké.
-
Není to marné. Naučili se to jiní před vámi, není důvod, proč byste se nenaučil programovat i vy. Není to těžké.
Já tedy nevím, nechci nikomu brát iluze o snadnosti programování. Programováním se živím už 10 let, mám tento obor i vystudovaný. S přestávkami programuji od třinácti let, od dob osmibitů. Postupem doby si začínám říkat, že programovat v podstatě pořádně vůbec neumím (tj. vím že nic nevím). Existuje tam TOLIK záludností, jazyků a stylů programování a dost těžké teorie... Samozřejmě jde o to, co pro koho znamená umět programovat. Pro mě například to znamená vytvoření vlastního interpretru, rozumět pořádně paralelnímu programování atp.
-
Já tedy nevím, nechci nikomu brát iluze o snadnosti programování. Programováním se živím už 10 let, mám tento obor i vystudovaný. S přestávkami programuji od třinácti let, od dob osmibitů. Postupem doby si začínám říkat, že programovat v podstatě pořádně vůbec neumím (tj. vím že nic nevím). Existuje tam TOLIK záludností, jazyků a stylů programování a dost těžké teorie... Samozřejmě jde o to, co pro koho znamená umět programovat. Pro mě například to znamená vytvoření vlastního interpretru, rozumět pořádně paralelnímu programování atp.
Souhlasím, nemyslel jsem to tak, že je lehké naprogramovat cokoli. Chtěl jsem tím říct, že naprogramovat jednoduché věci není složité. Nejtěžší na tom je poznat, kdy nejde o jednoduchou věc :-)
-
Souhlasím, nemyslel jsem to tak, že je lehké naprogramovat cokoli. Chtěl jsem tím říct, že naprogramovat jednoduché věci není složité. Nejtěžší na tom je poznat, kdy nejde o jednoduchou věc :-)
Souhlasím, ale jak nám říkal jeden vyučující - musíte chápat i složitější věci, aby se vám zdály ty snadné skutečně snadné. Jak je vidět z průběhu tohoto tématu, někteří se ještě nedostali ani do této fáze. ;)
-
Souhlasím, ale jak nám říkal jeden vyučující - musíte chápat i složitější věci, aby se vám zdály ty snadné skutečně snadné. Jak je vidět z průběhu tohoto tématu, někteří se ještě nedostali ani do této fáze. ;)
A nebo nevědět nic, pak se zdá snadné všechno :-)
-
prave jsem se vystrikal. to bylo semena.
-
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ě.
Nicméně taky umí hezky manipulovat, zastírat celek, vybrat si jen tu část, která se mu k argumentaci hodí, to co se mu nehodí mlátí lidem arogantně o hlavu ap. Co potom z toho, když je vidět, že intelekt má, když ho neumí používat tak jak by mohl?
-
Nevim, jake ma Filip Jirsak nazory na politiku, pokud ma Merkel za dobrou politicku, tak se asi neshodneme, nicmene to:
* je uplne jedno
* nesouvisi s Javou
* nemeni nic na faktu, ze Jirsak je jeden z mala slusne a vecne diskutujicich v tehle zumpe, ktera si v nicem nezada s vykvety na novinkach
K tomu poslednímu... Otázka je, jestli to nasírání ostatních nedělá úmyslně, např. s potřebou falešného pocitu, že má navrch (což ovšem samozřejmě neznamená, že ti co se nechají vytočit to mají správně).
-
prave jsem se vystrikal. to bylo semena.
Gratuluji. Mohlo to byt celkem vtione vlakno o neznalostech nekterych lidi a Jave, takhle to tu predpokladam za chvili zamknou...
Hokej v tom máš ty. Já jsem tady mluvil o Streamech abstraktních, řekl jsem, že Java 8 Stream api tuto abstraktnost cti ale InputStream a Jirsák ji nectí. To je jedna věc.
Druhá věc je, že nechci proudově zpracovávat formát, který proudem není, jen tvrdím, že je možné ho proudově zpracovat, ikdyž to znamená, že se musí nejprve celý načíst. To, že se musí celý načíst, neznamená, že to nemůže být proud.
Dokonce jsem jak pro debily uvedl příklad, že běžně existují streamy, které musí bufferovat, aby vytvořily správnou transformaci na výstupu. Ale je to marné, je to marné, je to marné.
Pletes si pojmy s dojmy.
1. Zadna formalni, obecna, presna definice toho, co je abstraktni stream neexistuje, pojem se pouziva obecne
2. Produove zpracovani IO a nacteni celeho obsahu do pameti je logicky nesmysl. Pokud by tomu tak bylo, tak muzeme i DOM API povazovat za streamove
3. Porad nedokazes pochopit rozdil mezi InputStream pro proudovou abstrakci IO a praci s kolekcemi (kde ma vyraz stream uplne jiny vyznam). Nemaji spoli spolecneho vubec nic, krom toho slovicka stream.
4. Pojmy stranou, InputStream je v Jave exaktne zdokumentovany a jasny, jeho vlastnosti vylucuji nacteni zip jinak, nez to dela ZIS. Nacteni do pameti je nesmysl a prave proto je tam ZIS a ZF. ZIS vyuziji presne tam, kde porrebuji to zpracovar proudove, tzn. efektivne
5. IS je od zacatku definovany jako stream bytu pro binarni IO, nacitani jinych datovych typu resi jeho nastavby. Je to IO trida, k nicemu jinemu neslouzi. Specializace typu u ni nema smysl, musel by se definovat serializer a deserializer. A to se realizuje prave jinymi tridami.
6. Kdybys znal poradne aspon ten .net, tak vis, ze tam Stream je taky nad byte. Akorat k tomu ma balast, ze micha zapisy,seeky, cteni nad jedne tride. Java to oddeluje typove, coz se mi libi vic, ale jinak je to fuk.
-
Nevim, jake ma Filip Jirsak nazory na politiku, pokud ma Merkel za dobrou politicku, tak se asi neshodneme, nicmene to:
* je uplne jedno
* nesouvisi s Javou
* nemeni nic na faktu, ze Jirsak je jeden z mala slusne a vecne diskutujicich v tehle zumpe, ktera si v nicem nezada s vykvety na novinkach
K tomu poslednímu... Otázka je, jestli to nasírání ostatních nedělá úmyslně, např. s potřebou falešného pocitu, že má navrch (což ovšem samozřejmě neznamená, že ti co se nechají vytočit to mají správně).
At si ma Jirsak ci kdokoliv treba pocit,ze je reditel zemekoule, me je to fuk. Bud je to k veci, nebo ne. Bud je to pravda (i kdyby castecna), nebo neni. A koho to nasira a nedokaze slusne a vecne argumentovat fakty, tak by se mel nechat lecit. Diskuse tu by mela byt imho vecna, fakticka a technicka. A trolling pozoruju u jinych lidi, kteri naopak na Jirsaka i sproste utoci, coz je opravdu uroven 4. cenove...
-
Nevim, jake ma Filip Jirsak nazory na politiku, pokud ma Merkel za dobrou politicku, tak se asi neshodneme, nicmene to:
* je uplne jedno
* nesouvisi s Javou
* nemeni nic na faktu, ze Jirsak je jeden z mala slusne a vecne diskutujicich v tehle zumpe, ktera si v nicem nezada s vykvety na novinkach
K tomu poslednímu... Otázka je, jestli to nasírání ostatních nedělá úmyslně, např. s potřebou falešného pocitu, že má navrch (což ovšem samozřejmě neznamená, že ti co se nechají vytočit to mají správně).
At si ma Jirsak ci kdokoliv treba pocit,ze je reditel zemekoule, me je to fuk. Bud je to k veci, nebo ne. Bud je to pravda (i kdyby castecna), nebo neni. A koho to nasira a nedokaze slusne a vecne argumentovat fakty, tak by se mel nechat lecit. Diskuse tu by mela byt imho vecna, fakticka a technicka. A trolling pozoruju u jinych lidi, kteri naopak na Jirsaka i sproste utoci, coz je opravdu uroven 4. cenove...
S tím souhlasím. Ale co se týká Jirsáka, tak třeba manipulaci v diskuzi za slušnou nepovažuji ani omylem a netroufám si hodnotit, co je lepší jestli 4. cenová nebo zdánlivá 1. cenová s takovými svinstvy :). Diskutovat se dá podle mě ještě mnohem lépe...
-
S tím souhlasím. Ale co se týká Jirsáka, tak třeba manipulaci v diskuzi za slušnou nepovažuji ani omylem a netroufám si hodnotit, co je lepší jestli 4. cenová nebo zdánlivá 1. cenová s takovými svinstvy :). Diskutovat se dá podle mě ještě mnohem lépe...
Definujte "manipulace v diskuzi", nejlépe i s konkrétními příklady... A jak se dá diskutovat lépe než slušně, bez osobních výpadů a argumenty?
A na závěr:
Nejhorší je hádat se s tím, kdo má v podstatě pravdu...
-
S tím souhlasím. Ale co se týká Jirsáka, tak třeba manipulaci v diskuzi za slušnou nepovažuji ani omylem a netroufám si hodnotit, co je lepší jestli 4. cenová nebo zdánlivá 1. cenová s takovými svinstvy :). Diskutovat se dá podle mě ještě mnohem lépe...
Definujte "manipulace v diskuzi", nejlépe i s konkrétními příklady... A jak se dá diskutovat lépe než slušně, bez osobních výpadů a argumenty?
A na závěr:
Nejhorší je hádat se s tím, kdo má v podstatě pravdu...
Nezlobte se, ale nemám o diskuzi podobného typu moc zájem, obzvlášť o víkendu :). Berte to tak, že je to prostě můj názor, na který mám právo. Mnohem raději se budu bavit třeba o něčem z IT, OK? ;)
-
S tím souhlasím. Ale co se týká Jirsáka, tak třeba manipulaci v diskuzi za slušnou nepovažuji ani omylem a netroufám si hodnotit, co je lepší jestli 4. cenová nebo zdánlivá 1. cenová s takovými svinstvy :). Diskutovat se dá podle mě ještě mnohem lépe...
Definujte "manipulace v diskuzi", nejlépe i s konkrétními příklady... A jak se dá diskutovat lépe než slušně, bez osobních výpadů a argumenty?
A na závěr:
Nejhorší je hádat se s tím, kdo má v podstatě pravdu...
Pod to cele bych se podepsal, naprosty souhlas....
S tím souhlasím. Ale co se týká Jirsáka, tak třeba manipulaci v diskuzi za slušnou nepovažuji ani omylem a netroufám si hodnotit, co je lepší jestli 4. cenová nebo zdánlivá 1. cenová s takovými svinstvy :). Diskutovat se dá podle mě ještě mnohem lépe...
Viz jak psal Nemo, pojdme do konkretnich prikladu, treba ma Jirsaka zmenim nazor ))
Ale na druhou stranu manipulaci je skoro kazda diskuse, kde nekoho o necem presvedcujes, coz je dle meho nazoru v poradku. V poradku neni kdyz treba pritom vedome lzes, napadas lidi, shazujes jejich vecne argumenty bez faktickych protiargumentu atd. U Jirsaka to nejak nepozoruji, sle klidne sem hod nejake priklady, ja se silnymi, objektivnimi a nevyvratitelnymi argumenty nechava, manipulovat nechavam celkem rad))))
Ale i tak, Jirsak tu pise sve soukroke nazory, stejne jako ja ci ty. A kdokoliv s nimi muze nesouhlasit, ci je vyvratit. Dulezite je, aby ta diskuse zustala vecna a argumentacne bohata, jinak je to hospodske plkani...
-
S tím souhlasím. Ale co se týká Jirsáka, tak třeba manipulaci v diskuzi za slušnou nepovažuji ani omylem a netroufám si hodnotit, co je lepší jestli 4. cenová nebo zdánlivá 1. cenová s takovými svinstvy :). Diskutovat se dá podle mě ještě mnohem lépe...
Definujte "manipulace v diskuzi", nejlépe i s konkrétními příklady... A jak se dá diskutovat lépe než slušně, bez osobních výpadů a argumenty?
A na závěr:
Nejhorší je hádat se s tím, kdo má v podstatě pravdu...
Nezlobte se, ale nemám o diskuzi podobného typu moc zájem, obzvlášť o víkendu :). Berte to tak, že je to prostě můj názor, na který mám právo. Mnohem raději se budu bavit třeba o něčem z IT, OK? ;)
Vyborne! Ja jsem pro ))) pojdme resit treba ten navrh java api, to je rozhodne zakimavejsi nez Jirsak (nic ve zlem) :)))
-
Nezlobte se, ale nemám o diskuzi podobného typu moc zájem, obzvlášť o víkendu :). Berte to tak, že je to prostě můj názor, na který mám právo. Mnohem raději se budu bavit třeba o něčem z IT, OK? ;)
OK, ale já zase nemám rád argumentační fauly. Pokud někdo na "diskuzního protivníka" nestačí někdy odborně, začne se uchylovat právě k "nefér" záležitostem tohoto typu. Přímo v této diskuzi se dá najít dost těchto faulů. O IT rád diskutuji (diskutuji rád o čemkoli), ale ještě radši čtu odborné diskuze ostatních - zvlášť o věcech, kde mám slabší znalosti. Tam se nemůžu moc zapojovat, když nemám nic podnětného k tématu. :)
Argumentační klam (též řečnický trik nebo argumentační faul) je v řečnictví takový výrok, jehož smyslem je porazit či přesvědčit oponenta bez ohledu na pravdivost zastávaných názorů. Podstatou argumentačního klamu bývá nenápadné porušení pravidel logického důkazu, působení na emoce místo na rozum, případně obojí. Argumentační klamy bývají oblíbenou součástí argumentace propagandy a manipulátorů.
Útok na člověka (argumentum ad hominem)
Zlehčování oponentova tvrzení poukazem na jeho osobní vlastnosti nebo konflikt zájmů, případně obojí.
- To se dalo od recidivisty čekat.
- Té práci se nedá věřit, napsal ji jen proto, aby ho nevyhodili ze školy.
- Jsi mladý a nemá smysl o tom tématu s tebou jakkoliv diskutovat!
-
Nezlobte se, ale nemám o diskuzi podobného typu moc zájem, obzvlášť o víkendu :). Berte to tak, že je to prostě můj názor, na který mám právo. Mnohem raději se budu bavit třeba o něčem z IT, OK? ;)
OK, ale já zase nemám rád argumentační fauly. Pokud někdo na "diskuzního protivníka" nestačí někdy odborně, začne se uchylovat právě k "nefér" záležitostem tohoto typu. Přímo v této diskuzi se dá najít dost těchto faulů. O IT rád diskutuji (diskutuji rád o čemkoli), ale ještě radši čtu odborné diskuze ostatních - zvlášť o věcech, kde mám slabší znalosti. Tam se nemůžu moc zapojovat, když nemám nic podnětného k tématu. :)
Argumentační klam (též řečnický trik nebo argumentační faul) je v řečnictví takový výrok, jehož smyslem je porazit či přesvědčit oponenta bez ohledu na pravdivost zastávaných názorů. Podstatou argumentačního klamu bývá nenápadné porušení pravidel logického důkazu, působení na emoce místo na rozum, případně obojí. Argumentační klamy bývají oblíbenou součástí argumentace propagandy a manipulátorů.
Útok na člověka (argumentum ad hominem)
Zlehčování oponentova tvrzení poukazem na jeho osobní vlastnosti nebo konflikt zájmů, případně obojí.
- To se dalo od recidivisty čekat.
- Té práci se nedá věřit, napsal ji jen proto, aby ho nevyhodili ze školy.
- Jsi mladý a nemá smysl o tom tématu s tebou jakkoliv diskutovat!
To se plně shodneme, taky to nemám rád. Takže jsme zajedno :)
-
Souhlasím, nemyslel jsem to tak, že je lehké naprogramovat cokoli. Chtěl jsem tím říct, že naprogramovat jednoduché věci není složité. Nejtěžší na tom je poznat, kdy nejde o jednoduchou věc :-)
Souhlasím, ale jak nám říkal jeden vyučující - musíte chápat i složitější věci, aby se vám zdály ty snadné skutečně snadné. Jak je vidět z průběhu tohoto tématu, někteří se ještě nedostali ani do této fáze. ;)
Čím méně člověk ví, tím víc si myslí, že ví všechno.
-
Nezlobte se, ale nemám o diskuzi podobného typu moc zájem, obzvlášť o víkendu :).
To je škoda. Nejsnazší způsob, jak může člověk zjistit, že dělá chybu, je ten, když ho na to někdo jiný upozorní. Když na to má přijít sám, trvá to mnohem déle. Nejsem si vědom toho, že bych v nějaké diskusi začal jednat nefér jinak, než jako reakci na nefér diskusi z druhé strany. Ale samozřejmě je možné, že se mýlím – pak bych to rád věděl. Nebo považujete za špatné i to oplácet druhému stejnou mincí?
-
Nezlobte se, ale nemám o diskuzi podobného typu moc zájem, obzvlášť o víkendu :).
To je škoda. Nejsnazší způsob, jak může člověk zjistit, že dělá chybu, je ten, když ho na to někdo jiný upozorní. Když na to má přijít sám, trvá to mnohem déle. Nejsem si vědom toho, že bych v nějaké diskusi začal jednat nefér jinak, než jako reakci na nefér diskusi z druhé strany. Ale samozřejmě je možné, že se mýlím – pak bych to rád věděl. Nebo považujete za špatné i to oplácet druhému stejnou mincí?
ByCzech je místní šašek, doporučuji ignorovat.
-
Filipe - ztracis cenny cas a energii - nema to smysl
-
Souhlasím, nemyslel jsem to tak, že je lehké naprogramovat cokoli. Chtěl jsem tím říct, že naprogramovat jednoduché věci není složité. Nejtěžší na tom je poznat, kdy nejde o jednoduchou věc :-)
Souhlasím, ale jak nám říkal jeden vyučující - musíte chápat i složitější věci, aby se vám zdály ty snadné skutečně snadné. Jak je vidět z průběhu tohoto tématu, někteří se ještě nedostali ani do této fáze. ;)
Čím méně člověk ví, tím víc si myslí, že ví všechno.
Ale nesmíš to moc přehánět, protože jinak dopadneš jako pan Jirsák - ztracen ve svých vlastních složitostech.
-
Nezlobte se, ale nemám o diskuzi podobného typu moc zájem, obzvlášť o víkendu :).
To je škoda. Nejsnazší způsob, jak může člověk zjistit, že dělá chybu, je ten, když ho na to někdo jiný upozorní. Když na to má přijít sám, trvá to mnohem déle. Nejsem si vědom toho, že bych v nějaké diskusi začal jednat nefér jinak, než jako reakci na nefér diskusi z druhé strany. Ale samozřejmě je možné, že se mýlím – pak bych to rád věděl. Nebo považujete za špatné i to oplácet druhému stejnou mincí?
ByCzech je místní šašek, doporučuji ignorovat.
doporučuji ignorovat doporučení idiota zboje.
-
Tak snad abychom to tu zamkli ne...
-
Uf - proč? Já se bavim.
Peťane - pokud jde o odborné věvi okoli IT, tak v tom je F. J. jak ryba ve vodě, narozdíl od tebe.
S tou jirsakovskou demagogií, co třeba toto:
http://www.abclinuxu.cz/zpravicky/rozsudek-soudniho-dvora-ve-veci-c-527-15
D. Ježek - " Prodej nožů, s nimiž lze následně vraždit, by měl být také nelegální. A jak prokázaly poslední měsíce, též prodej kamionů. Bude snad muset Tescoma či Scania "zavřít krám"? "
F. Jirsák - "To je ale pěkná demagogie. Podle té tiskové zprávy byl ten přehrávač předkonfigurován tak, aby umožňoval snadný přístup ke stránkám s nelegálním obsahem, a navíc se tím chlubili v reklamě. Pokud to chcete přirovnávat k noži, pak k takovému, který je pro vraždění speciálně upraven a v reklamě propagován jako nůž vhodný pro vraždy. "
A co je podle pana Jirsáka toto:
http://www.vlkodlak.cz/noze/bojove
-
Nikdo neni 100%ni piicus
-
A co je podle pana Jirsáka toto:
http://www.vlkodlak.cz/noze/bojove
Nikde tam nevidím žádný nůž, který by byl propagován jako nůž speciálně určený pro vraždy.
Považuju za demagogii v diskusi o něčem nelegálním argumentovat přirovnáním k něčemu legálnímu. Proto jsem na tu demagogii upozornil a to přirovnání jsem upravil tak, aby se týkalo také něčeho nelegálního.
-
Bohužel, pan Jirsák má pravdu. Důležitý je totiž úmysl. Ten se ale mnohdy nedá dokázat. V tomto případě to však šlo. Nůž, který by byl přímo propagován k vraždění jsem totiž ještě neviděl - bylo by to totiž smozřejmě nelegální. Je třaba navíc rozlišovat zabíjení a vraždění. Zabít jaksi někdo může i v sebeobraně. Proto nůž propagován k zabíjení lidí nemůže těžko může být označen za nelegální. Zkuste si ale udělat webku a propagovat nůž určený k vraždění - zcela jistě budete trestně stíháni, pokud vás někdy ohlásí.
-
hoši lepší je java protožese zní vyvynul js a udělal tuhle diskuzi zbytečnou 8)
na ty vaše zipy bude stačit nějakej ten framework a každýmu bude jedno jesli to tam napozadí chroupe java nebo c# 8) 8)
programátor má programovat ane přemýšlet nad hloupostma co je lepší. tohle jednou provždy vyřeší masový rozšíření jska 8) 8)
-
A co je podle pana Jirsáka toto:
http://www.vlkodlak.cz/noze/bojove
Nikde tam nevidím žádný nůž, který by byl propagován jako nůž speciálně určený pro vraždy.
Považuju za demagogii v diskusi o něčem nelegálním argumentovat přirovnáním k něčemu legálnímu. Proto jsem na tu demagogii upozornil a to přirovnání jsem upravil tak, aby se týkalo také něčeho nelegálního.
Tak název "Útočný nůž" hovoří za vše, navíc podobné věci využívaj vojáci, kteří jsou občas posíláni s cílem někoho zavraždit (BinLádínek). Můj názor ale je, že každá věc se dá použít legálně i nelegálně jako třeba torrenty.
Nehledě na fakt, že všichni platíme výpalné z médií. To výpalné je odůvodňováno právě tím, že si na ta média lidé často ukládají autorsky chráněný obsah. Takže tímto je to v podstatě legalizováno. Zaplatil jsem výpalné, mohu si tam stáhnout co chci. Alespoň tak to chápu já.