Update: Výsledky 1. kola .NET Challenge

Tomáš Herceg       27.10.2008       Offtopic       12100 zobrazení

Trvalo to dlouho, dalo nám to hodně práce, zabralo mnoho času, ale nakonec se to povedlo!

Máme tu výsledky 1. kola soutěže .NET Challenge!

Můžete se také podívat na vzorová řešení nejlepších soutěžících:

Pokud jste se zaregistrovali a odevzdali svá řešení, můžete se podívat na body, které jste dostali za jednotlivá hodnotící kritéria, a samozřejmě také na komentáře poroty k vašim řešením, abyste viděli, co se nám líbilo a co by se dalo zlepšit.

Všem soutěžícím děkujeme za odevzdaná řešení a za čas, který psaním soutěžních úloh strávili, všichni beze zbytku oddvedli velmi dobrou práci. Omlouváme se, že nám výsledky tak dlouho trvaly, ale je opravdu časově hodně náročné pečlivě projít 70 odevzdaných prací a porovnat, která z nich je lepší. Samozřejmě se mohlo stát, že jsme nějakou funkci neobjevili nebo nám něco nefungovalo, přečtěte si tedy, prosím, komentáře k řešení, a v případě, že něco nebude souhlasit, určitě nám napište.

Komentáře poroty k řešením z 1. kola

Lehká úloha – Code Snippets

Zadání a výsledková listina úlohy

Přestože tato úloha byla označena jako lehká, nakonec se ukázalo, že vůbec lehká nebyla. Mnoho uživatelů napsalo velmi robustní objektový model, což je na jednu stranu velice dobře, žel bohu na straně druhé jim to často přineslo více problémů než užitku.

Poměrně dost aplikací mělo problémy s mazáním a přejmenováváním placeholderů, pár aplikací při otevření nového snippetu zapomněly vyprázdnit seznam s referencovanými jmenný, takže se smíchaly reference z načítaného souboru s těmi, které tam byly před tím. Občas nějaká aplikace spadla, ale jinak základní funkcionalitu nabízely téměř všechny odevzdané práce.

Ve většině aplikací nám vadilo, že při kliknutí na placeholder v textu či jeho označení se nevybral také v seznamu nebo tabulce placeholderů a člověk ho musel složitě hledat v případě, že jej chtěl změnit. Také mnoho uživatelů nechalo v textovém poli pro zadání kódu obyčejné proporciální písmo místo fontu neproporcionálního, který se pro zobrazování kódu běžně používá. To samozřejmě nevypadá nejlépe a není to moc přehledné, i když je to samozřejmě jen detail.

Jinak musíme všechny soutěžící pochválit za dobře odvedenou práci, většina aplikací byla povedená a funkční.

Těžká úloha – Duplicitní soubory

Zadání a výsledková listina úlohy

Mnoho uživatelů si sice stěžovalo, že lehká úloha není o tolik lehčí než tato, nicméně v této úloze šlo především o správnou volbu algoritmu a nutno podotknout, že jen pár soutěžních prací použilo rychlý a efektivní algoritmus.

Drtivá většina odevzdaných řešení porovnávala soubory ve stylu “každý s každým.” Zkrátka si napsali nějakou metodu, které předhodili dva soubory, metoda si pro každý z nich otevřela FileStream, oba soubory postupně načítala a porovnávala. Jakmile nalezla rozdíl, skončila. Toto řešení ale může být velmi pomalé, souborů může být dost a pokud máte 100 souborů, tak každý z nich čtete od začátku do konce řádově 100x (časová složitost N2). Disk je poměrně pomalé zařízení, takže 100x přečíst dvougigový soubor, to dá trochu zabrat.

Vylepšit to sice můžete tak, že soubory rozdělíte na skupinky podle velikosti a porovnáváte každý s každým jen v rámci té skupinky, ale i tak existuje sada souborů (jakkoliv v praxi neupotřebitelná a nesmyslná), na které bude hledání trvat strašně dlouho. Poslední hřebík do rakve tomu dali ti, kteří soubory porovnávali doslova po bajtech, prostě ve while smyčce četli z každého souboru pomocí ReadByte. Ano, ty streamy si to interně přednačítávají a cacheují, ale i tak, čtení po bajtech má dost velkou režii, takže je daleko rychlejší načítat to třeba po 64kB.

Našli se i experti, kteří soubory natvrdo načetli do paměti přes File.ReadAllBytes a pak tato pole porovnávali (anebo si ty bajty převedli ještě na string a porovnali tyto stringy). Mimochodem, víte, jak se dá zjistit velikost souboru? No přece File.ReadAllBytes(“soubor”).Length. I tento způsob se objevil, představte si, že chcete zjistit velikost dvougigového souboru. Takhle tento soubor celý načtete do paměti jenom proto, abyste zjistili velikost toho pole. Takhle tedy opravdu ne.

Zarazilo nás, jak málo lidí napadlo použít hashování. Nejznámější hashovací algoritmy jsou třeba MD5 a SHA, pár lidí použilo i CRC. Hashovací algoritmus dostane na vstup libovolně dlouhá data a spočítá z nich hodnotu nějaké pevné délky (MD5 má např. 128 bitů). Mezi základní vlastnosti hashování patří to, že je velice těžké najít takové dva vstupy, které dají jako výsledek stejný hash. I když MD5 se dnes již nemá používat pro zabezpečení dat, pro naše účely se hodí velmi pěkně. Navíc je to standardní algoritmus, takže jej .NET Framework umí a nemusíme nic složitě programovat.

Z každého souboru si stačí tedy spočítat hash (což je krátká hodnota, která se vejde do paměti) a mezi sebou porovnávat jen ty hashe. Pokud jsou stejné hashe, je stejný i obsah souboru (u CRC je to dobré ověřit přečtením binárního obsahu, u MD5 či SHA je to zbytečné, pravděpodobnost kolize je mizivá, u MD5 je to 1 ku 2^128, což je v desítkovém zápisu asi 40ciferné číslo, tolik souborů na disku nikdy mít nebudete). Hashe samozřejmě v rámci skupiny musíme porovnat každý s každým, ale tyto hashe jsou malé a vejdou se nám do paměti. Pravděpodobnost, že by dva soubory daly stejný hash, je opravdu mizivá, takže takové situace nemusíme vůbec řešit.

Samozřejmě není ani nutné počítat hash pro všechny soubory; pokud si soubory rozdělíte na skupiny podle jejich velikosti, není nutné počítat hash u souborů, které jsou ve skupince samy. Navíc je u dlouhých souborů vhodné rozdělit si je na části třeba po 4 MB a kontrolovat postupně hashe těchto bloků (a počítat si je až ve chvíli, kdy jsou skutečně potřeba), abychom nemuseli celé gigové soubory procházet. U každého souboru si pak v paměti držíme jen seznam hashů v jednotlivých 4MB blocích, a nový blok počítáme až v okamžiku, kdy je skutečně potřeba (když mají 2 soubory stejnou sadu hashů předchozích). Tím budeme každý soubor číst maximálně jednou, a to ještě ve většině případů ne celý.

Jinak pokud už používáte vestavěné třídy pro počítání MD5, opět není vhodné předat metodě ComputeHash výsledek volání ReadAllBytes, která celý soubor načte do paměti, metoda ComputeHash bere jako parametr i stream. Tolik k volbě algoritmu a k efektivitě řešení.

Po funkční stránce mnoho prací postrádalo poměrně důležitou možnost smazání nalezených duplicit, hlavním vílem aplikace bylo najít duplikátní soubory a zbavit se jich. Trochu nás také překvapilo, že i ti nejlepší řešitelé často zapomínali na jednu základní věc při procházení souborů - kontrolovat, zda má program vůbec ke složce (potažmo přímo k souboru) práva pro čtení. Velká část aplikací na tom padala.

Pokud se jedná o technologickou stránku věci, tak několik soutěžících využilo WPF, unit testy, efektivně návrhové vzory a dodali nápovědu a dokumentaci, což se samozřejmě promítlo také v celkovém hodnocení.

 

hodnocení článku

0       Hodnotit mohou jen registrované uživatelé.

 

Nový příspěvek

 

Diskuse: Výsledky 1. kola .NET Challenge

Po algoritmické stránce se přece Hash počítá tak, že se načte obsah souboru (celého), tudíž se použije stejné načítání, jako při přímém porovnávání souborů?

Vytvoření hashe je tedy stejně pomalé jako přečíst celý soubor.

Ledaže by tvůrci implementace MD5 v .NETu nepoužívali prostředky .NETu...

:-)

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Můžete si přece soubor rozdělit na bloky po pár MB a hashovat tyto. Navíc každý soubor čtete maximálně jednou (a ani to nemusíte, některé soubory nemusíte číst vůbec, pokud mají unikátní, a u dalších můžete porovnávat hashe jednotlivých bloků, přičemž ty bloky si počítáte, až když je doopravdy potřebujete).

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Jenomze aby se spocital jakykoli hash, tak je potreba soubor nacist uplne cely, a pokud zjistim, ze mam vice souboru se stejnym hashem - coz budou jednak duplicity, ale mohou to byt i ruzne soubory se stejnym hashem (nezapomente, ze na disku lide maji miliony souboru), tak tyto soubory budu muset precist znovu jeste jednou, abych zjistil zda jsou opravdu uplne stejne nebo zda mamji jen stejny hash.

Pokud se podivate jeste jednou na mou praci zjisite, ze tam presne o tomto pisu a zduvidnuji tim sve rozhodnuti hash nepouzivat.

Dobromil Maly.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Upřesnil jsem trochu popis správného algoritmu v článku a odsadil ho, aby byl přesně vidět. Ať už provedete jakékoliv vylepšení s porovnáváním obsahů souborů, stejně některé soubory budete načítat víckrát. Hashování se dá napsat tak, abyste četl každý soubor maximálně jednou a to ještě jen kusy, které jsou potřeba.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

No síce sa nemôžem tu hádať, pretože som na chvoste poradia :), ale názor si poviem.. Ako som tu spomenul ja som použil MD5...a robil som to takto (co tiez nie je moc efektivne :))

  HashAlgorithm my_hash = new MD5CryptoServiceProvider();
            Stream file = new FileStream(file_path,FileMode.Open,FileAccess.Read);
            byte[] arr_hash = my_hash.ComputeHash(file); 
            return BitConverter.ToString(arr_hash);

teda cez stream, pretože funkcia readallbytes sa mi zdala moc náročná...:)a pravdepodobnosť rovnkého MD5 hashu u dvoch rozdielnych vecí (tuším to je napísané hore vyššie je 1 k 2na128 čo je sakra veľké číslo) i ked pri použití lámania hesla a bruteforce by sa nam to mohlo podariť :)

Inak kontrola integrity stiahnutých súborov je najčastejšie takto kontrolovaná.

Pravdu máte, ak chceme 100% istotu vtedy sa skutočne musí porovnať bit po bite a je to jasné, ale efektivita je náročná a pri fakt veľkých súboroch ako su giga a tera ufff... Takže v našom svete nič nie je isté, a musíme sa spoľahnúť, že sme si neobliekli ten miliontý padák :)

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Ale proc stale mluvite o male pravdepodobnosti ze dva ruzne soubory budou mit stejny hash?

Predpokladejme, ze hledame duplicity, ano? Konec koncu to je tema teto ulohy a autori davali body za funkcionalitu ktera je umozni i mazat - takze take predpokladaji, ze se bude pracovat predevsim s duplicitami.

Vychazejme z faktu, ze stejne soubory budou mit i stejny hash => soubory se stejnym hashem MUSIM nacitat cele a budto je cele drzet v pameti, nebo je proste porovnavat mezi sebou stale a stale...

Ano, muze se tim snizit skupina porovnavanych souboru a muze to byt efektivnejsi, ale na jinem vzorku souboru (napriklad projkety Visual Studia, ktere se hemzi uplne stejnymi knihovnami (ICSharpZipLib.dll a pod, ktere nejsou v GAC)) bude porovnavani metodou "nejprve soubor nactu poprve (kvuli spocitani HASHe) a pak ho nactu podruhe, protoze mam jiny soubor se stejnym HASHem" daleko mene efektivni.

Dobromil Maly

nahlásit spamnahlásit spam 0 odpovědětodpovědět

No logicky máte pravdu, lenže stále nechápem úplne prečo viackrát hash (je to v pohode mám strašne dlhé vedenie).Ja som vytvoril TreeView do ktorého som načítal celú stromovu štruktúru (aby sme videli co je adresár/podadresár a obsahujuce subory) vybraného adresára, súčasne s tým som do dvoch polí ukladal veľkosť súborov cez file.Length a celý názov súboru (aj s cestou).

Následne som zotriedil cez array.sort tie dve polia takže rovnaké veľkosti sa dostali k sebe, následne som vytvoril skupiny súborov s rovnakou veľkosťou, potom som načítal cez stream len hashe pre všetky súbory v danej skupine do dalšieho pola (len string hashu) a následne som tie medzi sebou porovnal a rovnaké súbory som vložil do poľa (teda rovnaká veľkosť rovnaký hash) a následne som to zobrazil.

Na disk sa pristupovalo teda len ked som čítal tú stromovú štruktúru a druhý raz už z vyselektovaných súborov s rovnakými veľkosťami keď sa zisťovali tie hashe... V poliach boli uložené len veľkosť súboru, celá cesta+meno súboru, a hash kód súboru, nikdy som v pamäti nedržal celý súbor...

P.S. pridal som tam right click na subor kde bolo možno, skočiť do daného adresára s vyselektovaním daného súboru, plus aj možnosť mazania :)

P.P.S Neošetril som asi milion+1 možností a moc som sa netrápil s prístupovými právami kontroloval som len read_only attribute, a chyba bola čo som si uvedomil, že ak bolo veľa súborov a veľkých tak sa mohlo zdať, že aplikácia spadla (i keď pekne počítala) len som to mal nejak zobraziť, že pracuje...plus bugy na ktoré som neprišiel takže som na konci, ale mne to nevadi toto beriem ako zábavu....a to ma teší...

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Ahoj Dobro,

nechápu... proč bych měla soubor načítat podruhé pokud má stejný hash?

Přece pokud má stejný hash je stejný a hotovo, uložím si informace o něm do nějaké kolekce identických souborů a nakonec ty kolekce nějak zobrazím.

R.

PS: mimochodem na čem myslíš, že jsem to testovala ;)

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Ahoj Radko,

no to je pravdepodobne cele jadro sporu. I pan Herceg navrhuje soubory se stejnym hashem oznacit za duplicitni a pripadne je nabidnout ke smazani, ale to je velmi nebepecne a hrozi zde riziko ztraty dat, protoze soubory se stejnym hashem nemusi mit nutne jeste stejny obsah.

Hashovani je algoritmus, ktery vezme skupinu znaku a vytvori z ni jakysi kontrolni soucet ze ktereho jiz nelze zpetne rekonstuovat puvodni data (rekneme, ze takovy priklad muze byt proste secteni ascii hodnot jednotlivych znaku). Takovyto algoritmus je tim dokonalejsi cim mene pravdepodobne je ze dva ruzne vstupy daji stejny hash (muj priklad s ascii hodnotami je nefunkcni uz v pripade obsahu "ab" a "ba", protoze oba davaji vysledek ├ (ascii 195)) a take tim cim vice bitu hashe se zmeni zmenou jedineho bitu na vstupu.

Kazdy takovyto kontrolni soucet ma vetsinou pevnou delku a tato delka je zavisla od toho, jaky algoritmus se pouzije (MD5 ma delku 128 bitu, SHA-1 pak 160).

Z logiky veci je tedy jasne, ze soubor zvici nejakych par kB, MB ci GB se kombinaci vsech moznych hodnot bytu do tech nekolika bitu hashe nevejde a je tedy JISTE, ze existuje jina skupina znaku (klidne i stejne delky), ktera dava stejny hash - to je proste FAKT. To, ze se takovou zkupinu pro nektere algoritmy jeste nepodarilo najit neznamena ze neexistuje.

Konec koncu, pro MD4 i MD5 se to jiz podarilo a to dokonze pro texty stejne delky(!) *, pro SHA-1 se AFAIK zatim snad jen nasly nejake slabiny.

Takze se ted modlim, aby Total Commander, ktery pouzivam pracoval alespon tak, jako algoritmus muj ;-)

*) http://www.mscs.dal.ca/~selinger/md5coll...

PS: Nevim, na cem jsi to testovala, ale jsem v pokuseni zkusit prohledat vsechny mozne disky a najit dva ruzne soubory se stejnym hashem, ale to bych se dostal zpet do problemu, kvuli kterym jsem ze souteze hned po vyhlaseni zadani pro druhe kolo odstoupil - tim byl nedostatek casu.

Dobromil Maly

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Ano, u MD5 byly nalezeny kolize, ale ty se nenašly náhodou, ale cíleným hledáním a snahou prolomit tento algoritmus. 2^128 je asi 3,4x10^38, to je opravdu strašně velké číslo, pravděpodobnost, že se tohle stane, je fakticky malá, asi jako když vyjdu ven z domu a spadne mi z nebe na hlavu tramvaj. I když MD5 se už v kryptografii nedoporučuje, ostatní algoritmy (např. SHA) se používají a možnost kolize se prostě zanedbává, nemá smysl se jí zaobírat. Jistěže existuje možnost, že k ní dojde, ale já bych se jí rozhodně nebál. Na disku můžete mít miliony souborů, ale to je 10^6. Možností je řádově 10^38, to je propastný rozdíl, asi jako když plivnete do rybníka. Pokud by taková situace nastala a opravdu na svém disku najdete dva soubory s různým hashem, budete slavný. S MD5 asi ne, ale s SHA512 určitě.

Je mi líto, že nemáte čas na další kola soutěže, je to určitě škoda, ale i tak děkujeme za účast.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

> Pokud by taková situace nastala a opravdu na svém

> disku najdete dva soubory s různým hashem, budete slavný.

Pravdepodobne jste chtel rici "dva ruzne soubory se stejnym hashem" - Ale ja na disku dva takove soubory mam - hello.exe a erase.exe s MD5 souctem CDC47D67159EEF6916CA3A9D4A07.

Ano, jedna se o cileny utok na MD5ku, ale zkratka a dobre i mala pravdepodobnost je IMHO dostatecnym duvodem k tomu, abych soubory pro jistotu kontroloval i podle obsahu a to znamena, ze je musim cist znovu a znovu* a i presto, ze ze skupiny o sto kusech (podle velikosti) je 99,99999% z nich stejnych (podle hashe) a jen ten jeden z nich je ten, ktery mne ma ucinit slavnym - takze tady zadna uspora proste nebude.

PS: Muj oblibeny Total Commander hello.exe i erase.exe oznacil za ruzne, takze je take (diky Christianu Ghislerovi) porovnava podle obsahu.

*) nikdo nerika, ze se musi cist byte po byte, ale lze nacitat treba bloky po 512bytech a ty pak porovnavat uz jen v pameti...

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Omlouvam se, zapomnel jsem se podpsat (nejsem registrovanym clenem).

Dobromil Maly

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Však já jsem psal, že s MD5 už slavný nebudete, se SHA512 byste byl. Ale pořád nechápete jeden základní princip - v algoritmech jde o složitost. Jestli soubor přečtu jednou nebo dvakrát, je jedno, jestli soubor přečtu jednou nebo Nkrát už jedno není. Pokud budete mít 100 různých, stejně velkých souborů a dva z nich budou různé, ale budou mít stejné hashe, pak všechny soubory přečtu 1x a ty dvě potvory nepravděpodobné teda 2x. Vy budete porovnávat "každý s každým", i když je budete číst jen do prvního rozdílu a ne celé, tak v průměru každý přečtete 50x (první 99x, druhý 98x, atd., poslední 1x). Stejně jako velikost souboru drasticky rozdělí obrovskou skupinu všech souborů na mnoho skupin malých, mezi nimiž porovnávat každý s každým je daleko rychlejší, tak hash toto udělá s těmi skupinami znovu a pak už řešíte pouze jednotky případů.

Ano, každý algoritmus se dá nachytat na nevhodné zadání, ale hashování má takových zadání řádově méně než porovnávání obsahů. Nehodlám to už dále rozebírat, pokud uživatel schválně nepodstrčí sadu souborů zkonstruovanou tak, aby zmátla MD5ku, funguje to. Anebo můžete použít SHA512, které je o trochu pomalejší, ale pravděpodobnost kolize je ještě mnohem větší a žádná zatím, pokud vím, není známa.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

S tou tramvají bych byl opatrnej :-) Tuším, v Rakousku šel muž do banky a u přepážky ho přejela tramvaj :-)

Sice nepřilítla z nebe jak bylo tebou požadováno, ale zase onen muž nemusel ani vycházet z domu :-)

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Když jsem volila algoritmus uvažovala, jsem o tom pro koho je aplikace určená. Podle mě pro běžného uživatele, který ji použije k tomu, aby uřídil množství kopií svých souborů (myslím tím např. dokumenty, fotky, filmy, postahované soubory, přílohy atd.) Takový uživatel nebude aplikaci spouštět nad celým diskem a i kdyby náhodu to udělal tak se mu nejspíš nebude chtít buď čekat nebo procházet výsledek. Soubory ke smazání si musí v mém řešení uživatel označit.

Tedy k tomuto účelu, kdy je pravděpodobné že se budou zároveň procházet tak max. tisícovky souborů, mi hash nepřipadal ani trochu rizikový. Nicméně mě napadlo, že by v sadě souborů na kterých se bude testovat mohly být nějaké kolizní soubory k MD5 schválně takže jsem použila SHA256.

Pokud by šlo o kritickou aplikaci např. pro nemocnice, NASA nebo podobně, asi bych zvolila jiný přístup.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

No vidis, a ja nevychazel z zadnych predpokladu, ale z faktu a ze zadani, podle ktereho - cituji: Soubory jsou shodné v případě, že jejich binární obsah je totožný. A to bez ohledu na jméno, umístění, či příponu..

Hash pro mne zkratka neni zarukou toho, ze dva soubory se stejnym hashem maji stejny i binarni obsah a proto myslim, ze v teto diskusi uz nema cenu dal pokracovat - muzeme se verbalne poprat osobne az se potkame ;-)

PS: Pravdepodobnost, ze muj SW (klidne i za 10 let) pouzije nejaky matematik, ktery travi poslednich 20 let zivota nejruznejsimi vypocty a jehoz disk se hemzi hokusy a pokusy -vysledky jeho prace- a kteremu zrovna doslo misto na disku, neni IMHO tak mala jako zminovany pad tramvaje z oblohy (nebo odkud to bylo).

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Souhlasim ze nema cenu pokracovat tady, tak nekdy treba u piva :)

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Výsledky 1. kola .NET Challenge

> Pokud jsou stejné hashe, je stejný i obsah souboru

> (u MD5 či SHA je to zbytečné, pravděpodobnost kolize

> je mizivá, u MD5 je to 1 ku 2^128, což je v desítkovém

> zápisu asi 40ciferné číslo, tolik souborů na disku

> nikdy mít nebudete).

Platí, že pokud je stejný obsah souborů, tak jsou stejné hashe. Opačná implikace neplatí. A pokud je v zadání, že se mají zjistit soubory se stejným obsahem, tak z toho nevyplývá, že stačí, když je to hodně pravděpodobné, ale program se může v některých případech splést. Proto pro dodržení zadání považuji za nezbytné ověřit shodnost nejen hashem, ale "byte po bytu".

> Hashe samozřejmě v rámci skupiny musíme porovnat každý

> s každým, ale tyto hashe jsou malé a vejdou se nám do

> paměti.

To také není pravda. Každý s každým je ~(n^2). Ale pokud např. seznam hashů setřídíme, můžeme najít duplicity v čase ~(n*log(n)), protože třídění lze zajistit v čase ~(n*log(n)) a potom stačí jednou projít seznam od začátku do konce a koukat se, zda dva sousedící hashe nejsou shodné.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Koukam, ze jsem si mel precist nejprve diskusi, kde uz stejnou pripominku melo vice lidi.

Presto bych rad podotknul, ze da problem resit i bez nacitani souboru opakovane. Kdyz napr. neleznu 10 dvougigabytovych souboru, tak muzu cist po blocich stridave z kazdeho souboru a porovnat je mezi sebou v pameti. Pokud pomer velikosti dostupne RAM ku poctu souboru stejne velikosti bude prilis maly, tak bloky take musi byt male a u pevnych disku a podobnych zarizeni, kde je drahy seek, cely algoritmus nemusi byt prilis efektivni. I kdyz i v tomto pripade by se to resit dalo. Ale mam jistotu, ze oznacim jako stejne opravdu stejne soubory. A take v beznych podminkach bude algoritmus efektivni.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Výsledky 1. kola .NET Challenge

Drtivá většina asi našla tohle: http://support.microsoft.com/kb/320348 tj. to první co mi vyhodil google na "compare file C#" ;)

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Jako ono to ve své podstatě není špatně, jen je to neefektivní a v jistých situacích to může být velmi pomalé.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

No ja som to tiez pozeral (priznavam sa, ale najma praci so subormi), ale ako napisal velky sef je to strasne neefektivne. Pri malych suboroch to moze byt fajn ale pri 500MB je to hroza. Ja som pouzil MD5 hashovanie ( napadlo ma to tak, ze v Linuxe s tym kontrolujem validitu stiahnutych suborov :) ), a viem ze dva subory su rovnake ak maju rovnaku velkost a rovnaky obsah... Len prva uloha bol aj prvy program co som napisal v C#, takze som bol rad ze to aspon trochu fungovalo....

Mam otazku WPF je asi Windows Presentention Foundation? a co su to tie unity testy?... Dikes...

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Windows Presentation Foundation je alternativa (ne náhrada) Windows Forms. Jedná se o nový, plně vektorový a hardwarově akcelerovaný systém uživatelského rozhraní, který je použit například ve Windows Vista. Jdou pomocí toho dělat sice úchvatné věci, ale pracuje se s tím daleko hůř než s Windows Forms (můj názor).

Unit Testing je metodika vytváření testů pro udržení integrity aplikace. Například máte-li metodu pro sčítání dvou čísel, napíšete test který bude volat tuto metodu, předávat všechny myslitelné kombinace hodnot a kontrolovat, zda-li je výstupní hodnota správná. Unit Testing podporuje Visual Studio 2008 Professional nebo lepší, ale specializuje se na to hlavně Visual Studio 2008 Team System. Pro Unit Testing lze použít také aplikace třetích stran (NUnit) ale tyto většinou nedosahují možnostem VS ani po kotníky.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Dakujem, za odpoved. Ale vzhladom na to, ze mam len express edition 2008 tak je to potom v pohode...:)

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Mě se naopak ve WPF pracuje daleko líp než ve winforms... pominu-li grafické věci a hezky lehce měnitelný layout tak zvlašť oceňuju třeba (data)binding skvěle a jednoduše řeší spoustu komunikace s GUI za me... Ale je pravda že práce ve WPF je dost jiná než ve winforms takže se v podstatě musí člověk všechno naučit znovu...

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Vzhledem k tomu, že je třeba naučit se celý grafický subsystém WPF zcela od začátku a nelze použít znalosti z Windows Forms, je používat toto zcela neefektivní. Kromě toho se počítá s tím, že na vývoji WPF aplikace se bude podílet designér (Expression Blend) a programátor (VB.NET/C#) což si spousta firem nemůže dovolit a vše dělá programátor, čehož výsledkem je mimořádně hnusné a odfláknuté uživatelské rozhraní.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Výsledky 1. kola .NET Challenge

Chcel by som sa spýtať, či budú aspoň najlepšie zdrojové kódy(riešenia) súťaže zverejnené. Aby sme sa mohli všetci od najlepších "čo to" priučiť.

Ďakujem

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Budou, až najdu chvilku času na zkontaktování prvních 5ti soutěžících z každé úlohy a podaří se mi získat mailem jejich svolení.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Za mě nemám problém se zveřejněním úlohy. Dokonce jsem uvažoval, že řešení popíši na blogu, avšak nenašel jsem odvahu se do toho pustit, především s ohledem k možnému porušení podmínek soutěže.

-- J.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Pokud byste to zveřejnil až po termínu odevzdání úloh, tak to proti pravidlům samozřejmě není. Mohl jste kdyžtak napsat e-mail a zeptat se :-)

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Výsledky 1. kola .NET Challenge

1. Když použijete cizí kód, je to poznat.

2. Použití cizího kódu, pokud to licence umožňuje, je OK. Pokud to někde oznámíte, třeba v komentáři.

3. Pokud zanoříte do sebe 7 if, je třeba se zamyslet, zda to nejde jinak.

4. Nikdo nepoužil na práci s XML LINQ.

5. Nesnáším RAR, prosím zipujte :-).

6. Velmi málo lidí píše ve VB.

7. Obecně se používalo minimum nových technologií, jako WPF a zmiňovaný LINQ.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Nějak mě to odhlasilo, takže není vidět, kdo to psal.

Štěpán Bechynský

nahlásit spamnahlásit spam 0 odpovědětodpovědět

4.,5.

robil som to v VS2005 cize asi tazko ;-)

6.

vo vb6 som programoval 3 roky. potom som si povedal ze treba "ist vyssie" tak som presiel na C#. pacila sa mi c-like syntax, a vb syntaxi som uz mal po krk :-) Tak uz 1 rok robim v C# :-)

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Ono není vždy vhodné za každou cenu používat nejnovější technologie, například to WPF se nehodí všude. Ovšem co mě překvapuje je, že málo lidí píše ve VB (v soutěži pořádané serverem se zaměřením na VB), zajímavé by bylo zveřejnit kolik z odevzdaných řešení bylo ve VB a kolik v CS.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

4., 7.: Linq To XML jsem nepoužil, protože mi pro načítání XML přišlo snadnější použít XPath. Jinak ve třetích úlohách používám Entity Framework, Linq To Entities a ASP.NET MVC, tak snad tím vynahradím tu absenci nových technologií v prvních úlohách ;-)

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Ad 4) to neni pravda. Pokud se podivate jeste jednou na mou praci zjistite, ze pouzivam tridy System.Xml.Linq. Pokud mate na mysli konkretne dotazovaci jazyk (select, where, ...), tak se domnivam, ze v tomto zadani neni co dotazovat...

Dobromil Maly

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Výsledky 1. kola .NET Challenge

Byť jsem byl nedočkaví, musím před porotci smeknout a obdivuji jejich práci. Porovnat tolik prací nemohlo být jednoduché a to si myslím, že se nejednalo o nikterak těžkou úlohu. Navíc velice snadno otestovatelnou, i když po přečtení hodnocení již rozumím, proč hodnocení zabralo více času :)

Přeji všem málo napsaných řádků kódu s bezchybnou implementací algoritmů.

-- J.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Výsledky 1. kola .NET Challenge

super, len cakam uz na dalsie kolo, len dufam ze ked budete davat vstupne udaje mojmu parsovacu tak ze to nespadne :-)

nahlásit spamnahlásit spam 0 odpovědětodpovědět
                       
Nadpis:
Antispam: Komu se občas házejí perly?
Příspěvek bude publikován pod identitou   anonym.

Nyní zakládáte pod článkem nové diskusní vlákno.
Pokud chcete reagovat na jiný příspěvek, klikněte na tlačítko "Odpovědět" u některého diskusního příspěvku.

Nyní odpovídáte na příspěvek pod článkem. Nebo chcete raději založit nové vlákno?

 

  • Administrátoři si vyhrazují právo komentáře upravovat či mazat bez udání důvodu.
    Mazány budou zejména komentáře obsahující vulgarity nebo porušující pravidla publikování.
  • Pokud nejste zaregistrováni, Vaše IP adresa bude zveřejněna. Pokud s tímto nesouhlasíte, příspěvek neodesílejte.

přihlásit pomocí externího účtu

přihlásit pomocí jména a hesla

Uživatel:  
Heslo:  

zapomenuté heslo

 

založit nový uživatelský účet

zaregistrujte se

 
zavřít

Nahlásit spam

Opravdu chcete tento příspěvek nahlásit pro porušování pravidel fóra?

Nahlásit Zrušit

Chyba

zavřít

feedback