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 ... 353 354 [355] 356 357 ... 375
5311
Vývoj / Re:Jak na kontrolu sousedících znaků
« kdy: 04. 04. 2014, 13:16:58 »
Vložit to url do libovolného textového editoru a vyhledat „//“.

Ale možná chcete něco jiného – pak ale budete muset lépe popsat, čeho vlastně chcete docílit.

5312
Vývoj / Re:Začátky v Javě
« kdy: 02. 04. 2014, 23:17:44 »
Kód: [Vybrat]

            for(int v = 0; v < count; v++)
            {
                int distanceThroughU = minDistance + weight[u * count + v];
               
                if(distanceThroughU < distance[v])
                    distance[v] = distanceThroughU;
               
                if(distance[v] < min)
                {
                    u = v;
                    min = distance[v];
                }
            }

Podle mne je v tom kódu chyba. Původně jsem si říkal, že je to nějaká pekelná optimalizace. Ale dává to špatné výsledky, takže se i přes pozdní hodinu přikláním spíš k tomu, že je to chyba. u by mělo být v rámci for cyklu neměnné, protože se používá pro přístup do pole vah (weight[u * count + v]). Zároveň se ale mění v případě, kdy je nalezena kratší vzdálenost (u = v).

Správně by to myslím mělo být takhle:
Kód: [Vybrat]
            int nextU = u;
            for(int v = 0; v < count; v++)
            {
                int distanceThroughU = minDistance + weight[u * count + v];
               
                if(distanceThroughU < distance[v])
                    distance[v] = distanceThroughU;
               
                if(distance[v] < min)
                {
                    nextU = v;
                    min = distance[v];
                }
            }
            u = nextU;

S touhle opravou to má mnohem větší rozptyl výsledků, někdy je to i o dost rychlejší, než s tou chybou, někdy podstatně pomalejší. Každopádně ale to naplnění vah trvá průměrně tak 5× až 10× déle, než výpočet nejkratší cesty - takže je to spíš test použitého generátoru náhodných čísle než co jiného.

Původně jsem to chtěl tedy přepsat do paralelního zpracování, a to u mi tam pořád překáželo. Takhle už to snad půjde líp :-)

5313
Vývoj / Re:Začátky v Javě
« kdy: 02. 04. 2014, 09:42:56 »
Pokud potřebujete systém s garantovanou maximální latencí, nemůžete vzít běžný OS, ale musíte použít realtime OS. Úplně stejně nemůžete použít běžnou desktopovou Javu od Oracle, ale musíte použít realtime JVM. Stop-the-world na potenciálně neomezenou dobu totiž není principiální vlastnost GC, je to vlastnost pouze některých implementací.

Java na tom vlastně není vůbec špatně, když většina její kritiky pramení z neznalosti.

5314
Vývoj / Re:Začátky v Javě
« kdy: 01. 04. 2014, 07:02:22 »
vybral sem úlohu na aplikování teorie grafů z toho důvodu že se jedná o výpočetně složitou operaci která porovná dobře výkon jazyků.
Celou dobu vám tu x lidí tvrdí, že výkon jazyků nezáleží jen na rychlosti výsledné aplikace. A že i rychlost výsledné aplikace je zvoleným jazykem ovlivněna jen málo, daleko větší dopad má třeba zvolený algoritmus.

5315
Software / Re:archivace datove schranky
« kdy: 01. 04. 2014, 06:52:44 »
tak ti zustane, ale stim, ze nejpozdejs za rok bude sice podepsana, ale jiz neplatnym podpisem.
Každá datová zpráva je opatřená časovým razítkem, takže i po delší době než po roce půjde snadno prokázat platnost podpisu. Navíc datové schránky umožňují zprávy přerazítkovat, takže platnost podpisu se dá postupně prodlužovat. A také mají možnost datovou zprávu ověřit, protože metadata o zprávách uchovávají, i když samotnou zprávu smažou.

Problém může být v tom, že obsah datové zprávy vůbec nemusí být podepsán, a také v tom, že datová zpráva sice podle zákona musí být opatřena elektronickou značkou prokazující, že zpráva prošla přes ISDS, ale certifikát k téhle značce není nikde zakotven. Takže to, že je to ten správný, můžete akorát odhadovat podle toho, že ten stejný mají i jiné zprávy z ISDS.

Pro dlouhodobou archivaci tedy stačí zprávu uložit jako ZFO soubor a ten mít někde spolehlivě uložený. Tím máte zaručenu stejnou právní validitu, jako dokud je zpráva v ISDS (což není mnoho, ale archivací samozřejmě nejde validitu zvýšit).

5316
Vývoj / Re:Začátky v Javě
« kdy: 31. 03. 2014, 23:27:58 »
A proč bych vám to měl říkat, známe se snad?
Čtení PDFek? A co je na tom špatného? Napřed všichni chtěj důkaz, prej že vlastní zkušenosti nejsou důkaz. A když ho dostanou, tvářej se kysele a odmítaj ho akceptovat.
Mohl byste nám to říci proto, abychom mohli pochopit, co se pokoušíte sdělit. Na jednu stranu se totiž tváříte jako zkušený programátor. Na druhou stranu nechápete jeden z elementárních základů výrokové logiky, totiž že tvrzení s velkým kvantifikátorem (všeobecné tvrzení, "pro všechna x platí y"), nelze dokázat příkladem jedné věci x, pro kterou platí y. Přitom už jste na tuhle vaši chybu byl upozorněn různými lidmi asi desetkrát. A vy přijdete po jedenácté, a zase přijdete s příkladem jedné věci, pro kterou vaše tvrzení platí. A strašně se divíte, že jej nikdo nechce akceptovat jako důkaz toho vašeho všeobecného tvrzení.

Pokusím se vám to vysvětlit ještě jednou, naposledy. Zkusím to na něčem úplně jiném, než IT - třeba v jiné oblasti nebudete mít tolik předsudků. Představte si tedy, že tvrdíte "všechny ovce jsou černé". Abyste tohle tvrzení dokázal, nestačí ukázat obrázek jedné černé ovce. Nestačí ukázat ani obrázek jiné černé ovce. Nestačí dokonce ani odkázat na PDF, ve kterém lidé asi z Googlu popisují, že viděli jednu černou ovci. Pořád je totiž možné, že vedle těch vašich tří černých ovcí někde na světě existuje i bílá ovce, nebo dokonce celá stáda bílých ovcí. I jediná bílá ovce přitom stačí, aby vaše tvrzení, že všechny ovce jsou černé, bylo nepravdivé.

Mohu vás ubezpečit, že ovládání elementárních základů výrokové logiky není výsadou javistů, umí to i spousta jiných lidí, dokonce by to měly umět děti na základní škole. Pokud vám zkracuje život to, že po vás ostatní chtějí, abyste svá tvrzení nějak doložil, mám pro vás jednoduché řešení: tvrďte pouze takové věci, které jste schopen i při svých znalostech výrokové logiky doložit.

hejtujete vsetko, co nie je c++, pricom nic ine ste nevideli
Já mám dost silné pochybnosti i o znalostech toho C++. Když se ve vedlejší diskusi objevil velmi neefektivní kód na násobení matic, měl být RAII - podle toho, jak se tady snaží sám sebe prezentovat - kdo proti tomu kódu vystartuje, protože procesorová cache, a kód přepíše. RAII si toho kódu ale vůbec nevšímal, a místo něj to opravovali javisti.

5317
Server / Re:602SQL Server a formát datumu
« kdy: 31. 03. 2014, 12:12:15 »
Takže spoléhá na něco, co všude jinde normálně funguje a je pravda, že asi nehledá problémy tam, kde normálně nejsou.
Spoléhá na něco, co všude jinde funguje, ale je to určené nanejvýš pro prototypování a normálně by se to vůbec nemělo používat. Svědčí to především o nevhodném přístupu aplikace k databázi – kdyby se tam používalo normální bindování proměnných do SQL dotazů, žádný problém tu neřešíte. Zrovna v případě toho data je možné brát to jako prkotinu a omlouvat to, že s podporovanými databázemi to funguje – jenže se dá předpokládat, že se tenhle přístup používá i jinde v aplikaci, a to už má dopady na její bezpečnost.

Chápu, že si to chcete vyzkoušet a nechci vás od toho nijak odrazovat. Jenom jsem chtěl upozornit, že jste tím odhalil temná zákoutí té aplikace.

5318
Server / Re:602SQL Server a formát datumu
« kdy: 31. 03. 2014, 10:06:33 »
Pokud vím, 602SQL Server neumí změnit formát pro implicitní konverzi data nebo času. Podle mne je to ale dost velký nedostatek té aplikace Docházka 3000 – pokud spoléhá na implicitní konverzi mezi datem a textem, a ještě navíc očekává jeden konkrétní formát zápisu data…

5319
Vývoj / Re:Hromadné nahrazení kódu v HTML
« kdy: 31. 03. 2014, 07:19:25 »
KWrite to neumí, ale pokročilejší programátorské editory (já používám jEdit) umějí nahrazovat hromadně ve více souborech. Není tedy nutné je všechny otvírat a něco klikat, jenom se zvolí, že nahrazování se má provést třeba pro všechny *.html soubory v adresáři a podadresářích.
Pokud je text opravdu všude stejný, může se použít i obyčejné vyhledávání bez žolíků, pak ani nebude potřeba nic escapovat.
V Perlu by se to neřešilo použitím regulárního výrazu a escapováním, ale napsal by se na to krátký skriptík, který by vstupní text hledal na přesnou shodu (pomocí index a substr) a načítal by jej ze souboru.

5320
Vývoj / Re:Hromadne nahrazeni kodu v HTML souborech
« kdy: 30. 03. 2014, 20:18:39 »
Pokud chcete jen nahrazovat text za text, pak sed. Pokud chcete mít přístup ke stromové struktuře XML, pak je nejlepší použít XSLT transformaci - třeba Saxon. Ale možná byste nejprve musel HTML převést do XHTML.

5321
Vývoj / Re:Začátky v Javě
« kdy: 30. 03. 2014, 15:27:37 »
pokud si neakceptoval můj důkaz (dokonce vytvořen lidma z googlu, pokud se nemýlím)
Jako důkaz, že netušíte, o čem píšete, jsem to akceptoval. Ale že by byla Java poražená v jakémkoli rychlostním testu, to ten dokument nijak nedokazuje.

Když nechápete, proč je nesmyslné tvrzení, že je nějaký jazyk rychlý nebo pomalý, v dříve odkazované diskusi jste měl konkrétní příklad s čísly. Nechápu, proč se neustále snažíte dokazovat obecné tvrzení, na které už jste dostal protipříklad.

Skusim nacat debatu trochu inym smerom ....

Ja uz Javu ako tak ovladam a zacinam pozerat na ine jazyky nad JVM. Co si o nich myslite? Najma o stvorici Scala, Ceylon, Groovy a Clojure.
Z těch čtyřech jazyků bych dnes doporučil především pátý - Javu 8. Je to zatím největší změna ve vývoji Javy, a bude nějakou dobu trvat, než se jí naučíte používat efektivně.

Určitě se vyplatí umět pracovat s Groovy. Pokud narazíte na něco, co běhá nad JVM a není to Java, s největší pravděpodobností to bude používat Groovy. Vyplatí se to znát už třeba jenom kvůli Gradlu. Mně se Groovy taky nelíbí, ale je populární a s tím nic nenadělám.

Jinak bych neřekl, že některý z těch jazyků vyroste tak, že by to bylo něco jiného než zajímavost. Spíš se věci, které se v nich ukážou zajímavé, budou integrovat zpět do Javy.

5322
Vývoj / Re:Začátky v Javě
« kdy: 30. 03. 2014, 13:19:04 »
Nejdůležitější je rychlost běhu programu, a ta je u Javy prostě mizerná no ... smiřte se s tím

Co? Odkdy? To jsi trochu zaspal dobu.
Prosím, neprogramuj.
První Pentia (procesory od Intelu uvedené na trh začátkem devadesátých let) měla chybu v operacích s plovoucí řádovou čárkou. Tenkrát se vyprávěl tenhle vtip:

Potká se Pentium a čtyřiosmšestka (předchozí generace procesorů), a 486 povídá:
486: Slyšela jsem, že jsi mnohem rychlejší než já. Tak schválně, jak rychle spočítáš, kolik je 4195835,0 děleno 314­5727,0?
Pentium vypálí: 1,3337390689
486 chvíli počítá, a pak řekne: To je ale přece špatně!
Pentium: Ale rychle!

Akorát že nic z toho nevypadá jako posraná hajzlmísa na japonské skalce, narozdíl od "GUI" produktů napsaných v Javě. Naposled Javě v tomto ohledu konkuroval Motif  ::)
Aha, takže vy jste nikdy žádnou GUI aplikaci v Javě neviděl.

5323
Vývoj / Re:Začátky v Javě
« kdy: 30. 03. 2014, 13:04:45 »
To bude nádhera, jak krásně to zapadne do prostředí...
Škoda, že to vůbec nesouvisí s programovacím jazykem. MS Word, Google Chrome, Mozilla Firefox, WinAmp - nic z toho není napsané v Javě, a přitom to používá jiné než nativní prostředí. Qt aplikace pod Gnome, GTK+ aplikace pod KDE také nezapadají do prostředí. vadí to někomu?

Jinak Jirsáku, důkaz už si dostal,
Dostal, a ne jeden. Ale já jsem nechtěl další důkaz toho, že vůbec netušíte, o čem píšete. Já jsem chtěl důkaz některého z vašich tvrzení.

5324
Vývoj / Re:Začátky v Javě
« kdy: 30. 03. 2014, 12:43:41 »
Pokud se jedná o alternativu k NetBeans, tak si zkuste třeba C++Builder nebo Delphi, to jsou RAD prostředí s vizuálním návrhem, jinak další je třeba CodeBlocks.
Mne zajímalo, s čím NetBeans srovnáváte ze stejné kategorie. C++ Builder nebo Delphi jsou sice také RAD nástroje, ale je to jiná liga. Je to jako srovnávat KOffice a OpenOffice. Obojí má své využití, ale je logické, že když jedno je spíš jednoúčelový nástroj a druhé komplexní systém, to druhé bude mít větší nároky.

Pokud se podívát například na TotalCommander, tak je napsaný buď v C++Builderu nebo v Delphi, proč to asi tak nepsali v Jave?
Protože jeho autor dobře zná Delphi, tak to naprogramoval v Delphi. Na rozdíl od některých místních totiž asi věděl, že na volbě jazyka moc nezáleží, že mnohem podstatnější je, jak s tím jazykem a souvisejícími nástroji umí zacházet.

GUI aplikacie, co nemusia bezat na viacerych platformach, je zbytocne pisat v Jave.
Pokud někdo umí Javu, je naopak velmi vhodné, aby to napsal v Javě, než aby to bastlil v něčem jiném.

To, že je zbytečné psát v něčem jiném, než ve vašem oblíbeném jazyce, můžete napsat o kterémkoli jiném jazyce. Akorát že ostatní lidé mají jiné preference, a zvolí si zrovna jazyk, který vy považujete za zbytečný. Někoho napadne psát serverové aplikace v JavaScriptu, někoho psát multiplatformní GUI aplikace v C -a je jim docela jedno, že vy to považujete za zbytečné.

Windows Vista měly mít nový souborový systém a další věci. Díky zdržení, pak neobsahovaly slibované věci.
Chybějící WinFS nebyl důsledek zpoždění, naopak jeho špatný výkon byl jednou z příčin zpoždění.

5325
Vývoj / Re:Začátky v Javě
« kdy: 29. 03. 2014, 22:59:31 »
Java je poražena v jakémkoli rychlostním testu. Zde http://developers-beta.slashdot.org/story/11/06/15/0242237/c-the-clear-winner-in-googles-language-performance-tests je důkaz. Teď ty.
Na té odkazované stránce není nic o tom, že je Java poražena v jakémkoli rychlostním testu. Jinak kdybyste si v té sousední diskusi přečetl ty dvě stránky, kterým se pořád nějak vyhýbáte, dozvěděl byste se příklad toho, na čem rychlost programu opravdu záleží.

Stran: 1 ... 353 354 [355] 356 357 ... 375