Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 199 200 [201] 202 203 ... 375
3001
Vzdyt je autorem on sam. A o autorstvi se neprichazi nikdy, ani tim, ze pracujes pro nejakou spolecnost.
Tím, že je autorem, má osobnostní autorská práva – to je takové to že má právo být uváděn jako autor, nikdo nesmí jeho dílo kazit atd. Pro kopírování ovšem potřebuje majetková autorská práva, a ty nemá on, ale jeho zaměstnavatel.

3002
Vývoj / Re:Typový system versus unittesty
« kdy: 18. 08. 2018, 09:18:24 »
Ja nechci vyvracet to tvrzeni, ze takove zmeny existuji. To je samozrejme, jelikoz existuji jazyky se slabym typovym systemem.
Ja se snazim jenom rict, ze kdyz budu mit silny typovy system tam muzu napsat funkci tak, ze kazda nekompatibilni zmena nutne zmeni API.
Já jsem ale nepsal o žádných jazycích se slabým typovým systémem. Psal jsem o tom bájném BoneFluteovu jazyku s nejsilnějším možným typovým systémem.

Rozumím tomu, co se snažíte říct. A už po několikáté se vám snažím vysvětlit, že ne každá nekompatibilní změna implementace znamená i nekompatibilní změnu API. Příklad takové funkce už jsem uváděl. Pokud taková změna, která nezpůsobuje nekompatibilní změnu API, vyvolá konflikt (chybu překladu v extra silném typovém systému, selhání testu u slabších typových systémů), je to špatně. Protože pak bude muset programátor neustále řešit tyhle neexistující chyby, bude to dělat automaticky a udělá to i tehdy, když změna vyvolá nekompatibilní změnu API. Mimochodem, to, jestli daná změna je nebo není nekompatibilní změnou API, je v mnoha případech věcí názoru. Takže to opravdu žádný typový systém nevyřeší, protože dva typy nemohou být navzájem kompatibilní u jednoho programátora, a nekompatibilní u jiného, který na to má jiný názor.

3003
Vývoj / Re:Typový system versus unittesty
« kdy: 17. 08. 2018, 21:42:47 »
Jak už jsem několikrát psal, naposledy v komentáři, na který reagujete, ne každá nekompatibilní změna algoritmu je nekompatibilní i z hlediska API.
A to prave nemusi byt pravda.
Asi jste můj komentář špatně přečetl. Psal jsem, že existují takové nekompatibilní změny implementace, které nemění API. Tvrzení o existenci se vyvrací tvrzením, že neexistuje žádný takový případ. Tedy žádné „nemusí“, ale „nemůže existovat“.

Nezapomínejte na to, že definice API nemusí být jenom to, co je v kódu, ale mohou to být další podmínky nebo omezení popsané třeba v dokumentaci. A tu si žádný kompilátor nepřečte.

3004
Vývoj / Re:Typový system versus unittesty
« kdy: 17. 08. 2018, 21:28:16 »
Jen doplním, že ten Elm si zjistí, zda došlo k nekompatabilní změně algoritmu, a tuto změnu propíše do API jako tu major verzi.
Jak už jsem několikrát psal, naposledy v komentáři, na který reagujete, ne každá nekompatibilní změna algoritmu je nekompatibilní i z hlediska API.

3005
Vývoj / Re:Typový system versus unittesty
« kdy: 17. 08. 2018, 21:06:35 »
Pokud je vstupni typ funkce integer 1 - 10
Není. Opravdu je nutné to explicitně psát, není to zřejmé z předchozího komentáře?

3006
Vývoj / Re:Typový system versus unittesty
« kdy: 17. 08. 2018, 19:54:47 »
Mozna proto, ze ten typovy system muze zajistit, ze (breaking) zmena  implementace nepujde udelat beze zmeny API?
Zkusím to ještě potřetí: aby to mohlo nahradit jednotkové testy, musel by ten typový systém zároveň zajistit, že změna implementace, která nezmění používané API, nic nerozbije – tedy že např. nedojde k nekompatibilní změně typů. Pro jistotu ještě explicitně uvedu, že „nemění používané API“ neznamená, že se nijak nezmění chování té funkce navenek. Např. pokud se ta funkce používala jen pro vstupní hodnoty 1–10, když se změní výsledek, který vrací pro 11, není to změna používaného API.

3007
To je legální
Ne, legální to není, vytvořil kopii autorského díla, neměl k tomu ale oprávnění. U autorských děl platí, že ve výchozím stavu nesmíte nic, a teprve nějakým dalším opatřením (zákonem, smlouvou) můžete nějaká práva získat.

3008
Vývoj / Re:Typový system versus unittesty
« kdy: 17. 08. 2018, 18:32:01 »
Kdyz bude funkce ochranena typem tam nepujde ohnout aniz by se zmenil ten typ a tudiz kompilator stejne zarve protoze tam kde ji volam ja bude typ nekompatibilni.
Nechápu, proč to píšete jako reakci na můj komentář, když jste jen znovu napsal to, na co jsem já reagoval. Já jsem psal o opačném případu, kdy používané API funkce zůstane stejné, ale implementace se změní (což nemusí nutně znamenat, že nová implementace bude ekvivalentní té původní – nesmí se změnit API, ale vlastnosti, na kterých nic nezávisí, se změnit mohou).

3009
Vývoj / Re:Typový system versus unittesty
« kdy: 17. 08. 2018, 16:32:30 »
Například jazyk Elm by toto mohl dát. Jakmile někdo vezme funkci, a ohne si ji, tak se změní major verze té funkce a už nepůjde napasovat, a celé to nepůjde zkompilovat. Což je IMHO právě ta ochrana (ochrana rozhodně užitečná), o které mluvíš.
Při popisu toho, proč se používají testy, jste popsal jenom jednu možnou změnu. Druhá možná změna je, že někdo vezme funkci, zachová její API na kterém závisí ostatní a které testují testy, ale upraví její implementaci (např. funkci optimalizuje). Užitečnost ochrany testy spočívá i v tom, že testy dále úspěšně procházejí, přestože se implementace změnila. Testy nejsou určené k tomu, aby nacházely změny, ale aby nacházely takové změny, které něco rozbijí.

3010
Vývoj / Re:Jak aktivovat Java Console
« kdy: 15. 08. 2018, 21:55:32 »
Musíte mít JDK ve stejné architektuře, pod jakou se spouští ta aplikace (32 bit / 64 bit). A doporučuju stejnou řadu Javy (tj. pokud aplikace používá JRE/JDK 8, použít JConsole také z JDK 8 ) – mezi různými řadami to nemusí vždy fungovat. V adresáři bin toho JDK najdete normálně jconsole, když ji spustíte, zobrazí se vám seznam procesů běžících pod stejnou architekturou. Tedy pokud je to aspoň Java 8, možná Java 7 – to vyhledávání podle procesů je relativně nové, starší verze to neuměly a bylo nutné JMX explicitně zapnout při startu aplikace.

3011
Software / Re:Chrome neuložil otevřený PDF, síť odpojena
« kdy: 15. 08. 2018, 09:06:04 »
jste všichni vedle, až se práší, sněží a létají vidličky
To je ale dané tím, že vy nejste schopen popsat, co vlastně děláte.

Pokud s eten soubor vůbec nepodaří stáhnout ani se nezobrazí, je logické, že nejde ani uložit. Akorát to vůbec není problém s ukládáním, ale s tím stažením. Problém může být třeba v nevalidním certifikátu, nepodporovaných šifrovacích algoritmech, server posílá nějaké špatné hlavičky… Ideální by bylo otevřít si v Chrome vývojářské nástroje a zobrazit přesný HTTP požadavek a odpověď na ten PDF soubor.

3012
Software / Re:Chrome neuložil otevřený PDF, síť odpojena
« kdy: 15. 08. 2018, 08:27:18 »
Ale podle mě jde o něco jinýho - Ty bys rád uložit to, co Ti momentálně Chrome zobrazuje bez ohledu na to, zda to ještě na původním umístění existuje nebo ne. Řekněme, že by mohlo jít třeba o jednorázově generovanou fakturu s omezenou dobou platnosti. Nevím, jak na to, ale nebylo by marné, kdyby někdo věděl a napsal to sem.
Pokud jde o Chrome a PDF dokument otevřený přímo v prohlížeči, pak je postup jednoduchý. Nahoře je taková lišta, kde jsou vpravo tři tlačítka – pro otočení, pro uložení a pro tisk. Stačí kliknout na to prostřední tlačítko a PDF soubor se uloží. I když je prohlížeč v offline režimu. Když je online, nic se nestahuje znova. Ten případ, kdy Chrome stahuje nějaký rozsah, nastane podle mne jenom v případě, kdy ten dokument nemá načtený celý. Při zobrazení se to nemusí poznat, protože můžete zobrazovat jen stránky, které jsou už načtené, ale pro uložení do souboru je samozřejmě nutné ten soubor stáhnout celý.

3013
proč to čachruje s range???
Jak to máme vědět, když jste z komunikace neuvedl skoro nic? Třeba se podařilo část souboru stáhnout a pokouší se dotáhnout zbytek – lepší než tahat celý soubor znova.

3014
Sítě / Re:IPtables a zařízení za NAT
« kdy: 14. 08. 2018, 10:23:46 »
Navic nemyslim si, ze kdyz se nekdo nevyzna v siti, tak bude mit nekde zapnuty RP filtr (myslim, ze to ani defaultne nema zadny router).
Navíc pokud se někde dělá NAT a paket se bude vracet jinou cestou (třeba přímo), tak nebude problémem ani tak RP filtr, jako hlavně to, že paket má změněné adresy, tudíž nezapadne do existujícího spojení a bude zahozen jako nevalidní. Fungovat to bude maximálně u jednoduchých protokolů jako ICMP nebo některých jednoduchých a nezabezpečených UDP protokolů, kde se neřeší, kdo odpověď poslal.

3015
Sítě / Re:IPtables a zařízení za NAT
« kdy: 13. 08. 2018, 21:14:52 »
Avsak pri zariadeniach so zlozitejsim routingom  a zlozitejsej topologii siete by som ho odporucal robit (ak nevadi, ze stratime informaciu o zdrojovej IP povodneho paketu), pretoze sa lahko moze stat, ze odpoved na presmerovany paket pomocou DNAT sa bude vracat inou cestou a teda bude zahodeny reverse path filteringom.
Já bych spíš doporučil do routování složitějších topologií se pouštět teprve tehdy, až bude mít nějaké znalosti o sítích. A pak bude i sám schopen posoudit, zda tam ten SNAT musí být, nebo tam být nemá. Dávat někam preventivně NAT je akorát cesta do pekel, protože to zbytečně komplikuje návrh sítě a také samotný provoz, protože ten NAT se obvykle stane úzkým hrdlem. Někdy opravdu vyjde přidání SNATu k DNATu jako nejlepší řešení, to nepopírám, ale chce to k tomu přistupovat s rozmyslem. Dnes si spousta „síťařů“ nedovede síť bez NATů představit, a zapomínají při tom na to, že NAT je jenom dost ošklivý hack pro řešení nedostatku veřejných IPv4 adres.

Stran: 1 ... 199 200 [201] 202 203 ... 375