Editorial: Mozilla vítězí

Jsem velmi příjemně překvapen. Za měsíc květen hlásí log soubory, že na tento weblog přistupuje nejvíce (52.36 %) čtenářů pomocí některého prohlížeče z rodiny Gecko. Nejrozšířenějším zástupcem této poměrně velké rodiny jsou prohlížeče Mozilla a Thunderbird Firefox (ta změna nazvu z Firebird mě pořád mate). Mozillu v české verzi sám používám a podle mého názoru je to již pěkných pár verzí zpět, kdy o koňskou délku předstihla doposud nejrozšířenější prohlížeč MSIE. Za květen je na tomto weblogu MSIE na ostudném druhém místě s 36.9 procenty. Zajímavé je možná ještě třetí místo: Opera, 7 procent. Z agregátorů (RSS/Atom) vede zcela jednoznačně MagpieRSS. Ostatní agregátory jsou zcela minoritní. Z toho vyplývá, že většina čtenářů navštěvuje tento weblog bez agregátoru, pouze pomocí prohlížeče.

Microsofte, Microsofte, nějak ztrácíš půdu pod nohama. To se stane každému, kdo usne na vavřínech. Nemohu si pomoci, mám chuť se trochu zlomyslně zašklebit směrem k Redmondu, USA. Je mi jasné, že tento weblog je specializovaný a čtou ho lidé, kteří počítačů většinou dost rozumějí. Jistě není vhodným průřezem celé populace, ale spíše lidí v oboru znalých. Není ale právě toto důkazem toho, že technicky je na tom Mozilla mnohem lépe než MSIE? Myslím, že ano.

Jak jsem zlehka zkoušel Mono 1.0 Beta

Jak jsem již psal, Novell uvolnil beta verzi 1.0 Open Source implementace technologie .NET jménem Mono. Pokusil jsem se jí vyzkoušet. Test proběhl na neznačkovém osobním počítači MS Windows XP, SP1, AMD 1.2, 512 MB RAM.

Vybral jsem instalaci pro MS Windows a stáhl ji ze stránky http://go-mono.org/download.html. Proč jsem vybral MS Windows? Důvody byly dva. Za prvé si myslím, že právě na MS Windows je možné Mono podrobit důkladnější kritice a to především srovnáním s implementací .NET technologie od Microsoftu. Druhý důvod je prozaičtější. Na pracovní stanici jsem mnohem lépe schopen pracovat s MS Windows. Nechci se připojit k názoru, že Linux je dnes pro pracovní stanice horší variantou, než MS Windows. Prostě já jsem v případě pracovní stanice na MS Windows více zvyklý a především více znalý. Rozdíly u verze pro Linux by měly být víceméně minimální. Pouze instalace probíhá na Linuxu dle dokumentace jinak:

$ tar xzf mono-0.91.tar.gz
$ cd mono-0.91
$ ./configure
$ make install

Verze 0.91 je právně. Beta verze 1.0 je ve skutečnosti verzí 0.91.

Vrátím se zpět k MS Windows. Soubor mono-Beta1-win32-2.exe, který jsem stáhnul byl velký 12 957 979 byte. Po spuštění se rozeběhl kvalitní Open Source Windows instalátor NullSoft Install System v2.0, který pro Mono vyžadoval 36.6 MB prostoru na disku. Implicitně se instaluje do adresáře C:\Program Files\Mono-0.91. Instalace proběhla bez jakýchkoliv problémů. Nikde na ploše, ani na v menu Start se ovšem neobjevil žádný nový zástupce. Je to zřejmě proto, že všechny nainstalované nástroje se spouštějí z příkazové řádky. 

Bohužel se nenainstalovala žádná dokumentace. Musel jsem se tedy vydat hledat na Internet.

I když se oficiálně jedná o beta verzi 1.0, je po spuštění příkazem mono -V zobrazena verze Mono JIT compiler version 0.91, (C) 2002-2004 Novell, Inc and Contributors. www.go-mono.com. Tato informace se již zobrazí při instalaci a to buď jménem implicitního adresáře (Mono-0.91), v případě instalace verze pro MS Windows, nebo jménem instalačního balíku (mono-0.91.tar.gz), v případě Linuxu. Verze 1.0 je tedy spíše marketingovou, než technickou informací.

První co jsem dále zkusil, byla klasická konzolová aplikace  Ahoj světe. Vše, kompilace i spuštění, proběhlo dle očekávání bez problémů.

Dále jsem vytvořil jednoduchou WinForms aplikaci, která pouze zobrazí Windows okno a zkompiloval ji příkazem mcs MainForm.cs /r:System.Windows.Forms.dll /r:System.Drawing.dll. Program MainForm.cs se bez problémů zkompiloval do souboru MainForm.exe. Nyní jsem ovšem narazil. Při spuštění hlásilo Mono chybu Could not load winelib.exe.so a okno se nezobrazilo. Zkusil jsem ještě jednodušší aplikaci:

class HelloWindowsForms	{
  static void Main()	{
    System.Windows.Forms.MessageBox.Show("Zkompilováno pod Mono, běží pod Mono");
    }
}

Zde byl výsledek o něco lepší. Chybové hlášení se sice objevilo znovu, ale společně s požadovaných hlášením v MessageBoxu. Čeština nebyla v pořádku a nepodařilo se mi jí opravit. Zkusil jsem na Internetu hledat chybové hlášení a pár výsledků mi to dalo. Zjistil jsem, že stejný problém jako já někdo řešil v Japonsku a Polsku. Nalezl řešení problému, pokud se toto chybové hlášení zobrazí na Linuxu. Chyba nebyla ve zkompilovaném souboru, protože když jsem použil Microsoft .NET, tak program proběhl a okno se zobrazilo.

Zkusil jsem ještě další testy, tentokrát pro konzolové aplikace a zde žádný problém nenastal. Vše běželo jak mělo. Bohužel nejsem webový vývojář a nemohl jsem vyzkoušet web aplikaci napsanou v Mono a spuštěnou pod Apache serverem.

Testy rychlosti jsem sice původně plánoval, ale neprovedl jsem je. Bylo by to to vůči Monu nekorektní. Jde o první betu, která obsahuje spoustu ladicího kódu a ten pochopitelně chod programu zpomaluje. Tedy pouze jedno konstatování: Mono je v této verzi nepochybně pomalejší než implementace .NET od Microsoftu. Co přinese budoucnost uvidíme a jakmile bude k dispozici ostrá verze Mono, provedu testy výkonnosti. Pokud bych měl tuto budoucnost předvídat, tak jedině na základě nějakého srovnatelného produktu. Tím je například Open Source gcc C/C++ kompilátor. Ten je dnes, co se týče rychlosti, naprosto srovnatelný s MS C++ Win32 kompilátorem. Stejné to snad v budoucnosti bude i u Open Source NET technologie.

Co bych beta verzi Mono 1.0 vytknul:

• Součástí instalace není žádná dokumentace.
• Verze by měla být 1.0 a ne 0.91.
• Nefunkční WinForms aplikace.

Tyto nedostatky nepovažuji za podstatné. Jde přece o beta verzi a mnoho práce mají vývojáři ještě před sebou. Celkové jsem vděčen, že se podařilo toto dílo dotáhnout tak daleko. To, že nefungují WinForms aplikace, není pro mne překvapením. Podpora pro ně by měla být dokončena až ve verzi 1.2. K té má současná beta 1 verze 1 ještě dost daleko.

Editorial: omezení RSS - přechod na atom.xml (II.)

Jak jsem již psal, přešel jsem s tímto weblogem na Blogger.com. Bohužel Blogger aktuálně nepodporuje agregátor zpráv ve formátu RSS, ale pouze ve formátu Atom. Podařilo se mi díky Jirkovi Hradilovi najít veřejnou službu, která převádí informace ze souboru ve formátu Atom na formát RSS 2.0. Pokud ovšem vaše čtečka podporuje formát Atom, doporučuji ho používat. Je to rychlejší a spolehlivější. Ne snad proto, že by formát Atom 0.3 byl lepší, to nejsem schopen posoudit, ale především proto, že nedochází ke zbytečné konverzi dat, která není vůbec rychlá a vaši čtečku bude při každé kontrole nových zpráv zbytečně zpomalovat dlouhou komunikací se sítí.

Soubor ve formátu atom lze najít na adrese http://www.neo.cz/~tomas/java.net/atom.xml. Pokud vaše čtečka Atom formát nepodporuje, použijte RSS zde. Tyto informace jsou samozřejmě dostupné i úvodní stránky tohoto weblogu pod nadpisem Odkazy.

Hledal jsem na Bloggeru důvod, proč RSS vůbec nepodporují, ale nic jsem nenašel. RSS bylo podporováno pouze u placených služeb, ale ani ty již nelze předplatit. Moc tomu nerozumím. Atom je zatím pouze ve verzi 0.3, kdežto RSS se přes lehké zmatky se tváří mnohem dospěleji. Uvidíme, co nám přinese budoucnost.

Všiml jsem si, že v poslední době je více článků jako editorial. Doufám, že se to časem převáží zpět na články k tématu Javy a C#.

Mono 1.0 Beta 1

Novell představil v květnu první betu Mono verze 1.0, které je Open Source implementací .NET Frameworku. Betu lze provozovat na MS Windows, Linuxu a Max OS X. K dispozici jsou samozřejmě kompletní zdrojové kódy. Největší zájem lze jistě očekávat na Linuxu, ale pro testování a vývoj i na MS Windows. V USA a některých dalších zemích bude nepochybně též velký zájem i o implementaci na Mac OS X. Přímo podporovány jsou distribuce Linuxu SuSe 8,9 a Fedora. Beta zahrnuje mimo jiné kompilátor pro C#, implementaci CLI (Common Language Infrastructure). Kompilátor obsahuje i technologii Just-in-Time. API podporuje ASP.NET (web services a web form) ADO.NET a spoustu dalších komponent.

Na adrese http://www.go-mono.com/beta1- press.html je velký seznam internetových periodik, které se této události věnovaly. Je vidět, že Novell s koupí Ximianu neudělal chybu. Pokud se mu nepodaří to zkazit, což by u něj nebylo nic nového, má velkou šanci se vrátit na výsluní. Po dlouhé době může být na něco pyšný.

Formátovací řetězce pro String.Format (.NET)

Pokud někomu unikl spot Martina Vobra, tak si dovolím upozornit na velmi užitečnou tabulku formátovacích řetězců pro .NET. Pro každého programátora je k dispozici na adrese http://www.stevex.org /dottext/articles/158.aspx.

Editorial: změna adresy RSS

S přechodem na Blogger.com jsem byl nucen změnit i URL RSS souboru rss.xml.Blogger.com totiž nepodporuje RSS soubory, ale jiný typ agregátoru, soubor ve formátu atom. Rád bych do starého, nepoužívaného souboru rss.xml umístil upozornění, že jsem přešel na atom.xml. Bohužel nevím jak. Může mi nějaký laskavý čtenář napovědět. Děkuji.

Doplněno 25.5.04 15:33 Všem děkuji za pomoc, již je to funkční

Editorial: EasyBlog končí, co dál? Blogger?

Tak jsem byl v pátek velmi nepříjemně překvapen, že Libor Krayzel (eLKa) končí s vývojem programu EasyBlog, ve kterém byl dosud tvořen tento weblog. V první řadě bych chtěl eLKovi poděkovat. Program jsem při psaní prvních spotů vyhodnotil pro mne jako nejlepší a protože jsem po celou dobu, kdy tvořím tento weblog tento názor nezměnil, tak musím říci, že pro mne pořád nejlepší je. Samozřejmě, má nějaké nedostatky a chyby, ale jediné, co mě v podstatě chybělo, byla možnost příspěvků na jednotlivých stránkách (tzv. SEO příspěvky). Tento nedostatek byl u EasyBlogu již odstraňován (v beta verzi) a těšil jsem se, že už budu naprosto spokojen. Teď už se asi nedočkám.

Přiznávám, že jsem dosti bezradný. eLKa doporučuje přechod na Nucleus CMS eXtreme Edition, kterému se v Česku věnuje Radek Hulán. To je pro mne ovšem trochu kanón na vrabce. Pro mé zhruba dva příspěvky týdně je to nástroj pře-mocný a zbytečný a pro čtenáře mi připadá zoufale nepřehledný. Sám občas čtu Občasný o'blog již zmíněného Radka Hulána a mám potíže rozlišit co je příspěvek, co je komentář, kdo co napsal, kdo na co reaguje a kde je jaké menu. Tvůrci Nucleusu by si měli nad postel pověsit heslo v jednoduchosti je síla. Možná je to jenom moje tupost, ale myslím, že nejsem sám takovým tupcem. Na konec k Nucleusu musím uvést, že jsem se s ním seznámil pouze z rychlíku a možná se pletu, ale v každém případě to pro mne není vhodný nástroj.

V Česku máme několik pěkných služeb (např. bloguje.cz a blog.lide.cz), ale já bych rád zůstal na svém URL. Proto jsem si žádnou z nich nevybral.
Jinak se mi nepodařilo nikde na Internetu najít program, který by měl zhruba stejnou funkčnost jako EasyBlog a dále se vyvíjel. Je to velmi zajímavé, už jenom proto, že eLKa uvádí, že měl víceméně pouze 36 aktivních uživatelů. To je nás takových exotů jako jsem já tak málo?

Problém s komentáři

Zkusil jsem klasiku, Blogger.com a celkem je myslím pro mé účely dostačující. Některé možnosti mne dokonce příjemně překvapily. Například možnost zasílání příspěvků emailem je moc fajn. Jediné, co je Blogger.com opravdu špatné jsou komentáře. Sice jsem je zatím na Java.NET neměl, ale když už dělám změny, tak ať je také něco nového. Jirka Hradil mi sice velmi ochotně poradil, abych použil on-line službu Haloscan.com, ale raději bych měl komentáře čtenářů na svém serveru. Když už si někdo dá práci a napíše nějaký komentář, tak bych ho rád zachoval. Našel jsem několik zajímavých PHP skriptů, které tento problém řeší, ale bohužel je nemohu použít. Proč? Blogger.com totiž není u některých souborů schopen změnit jejich příponu na php. Jde o soubory, které zobrazují články samostatně. Zde bohužel zůstává standardní přípona html. Můj provider, Globe Internet, se kterým jsem jinak celkem spokojen, pokud vím, neumí zařídit aby byly parsovány pro PHP zpracování  i soubory s příponou html. Tedy alespoň slečna na technické podpoře mi neuměla odpovědět.

Potřeboval bych tedy, pro zařazení kvalitních komentářů, jednu z těchto možností:

• Přesvědčit providera, aby jako PHP zpracovával i soubory s příponou html.
• Přesvědčit Blogger.com, aby i soubory se samostatnými příspěvky mohly mít příponu php. Je zajímavé, že u souboru index.html a souborů archivu to jde.
• Najít takový skript pro obsluhu komentářů, který nebude muset vkládat PHP kód do HTML souboru.
• Použít jiný nástroj/skript pro tvorbu blogu než je Blogger.com. Moje požadavky myslím nejsou složité: je jednoduchý, napsán v PHP, nepoužívá databázi a umí alespoň to, co Blogger.com. Když už jsem ten Blogger.com rozchodil, tak se mi moc nechce přecházet, ale nedá se nic dělat.

Pokud by nějaký laskavý čtenář tohoto článku měl pro mě dobrou myšlenku, prosím, aby mi napsal nebo napsal svůj nápad nebo názor do prozatimních komentářů od Blogger.com. Předem děkuji.

Prodám levně počítačové knihy

Prodám levně použité knihy, které již nepotřebuji. Seznam je zde: http://neo.cz/PouziteKnihy.html.

Knihy zašlu na dobírku s poštovným 60,- Kč nebo osobní odběr.

Láska k C#?

Dostal jsem dva (slušně psané) emaily, jejichž pisatelům se nelíbilo, že jsem Sun označil ve vztahu k Javě, především v případě GUI knihovny Swing, za impotentní. Jeden pisatel se mě ptal, proč mám tak rád Microsoft a C#. Musím mu odpovědět zde, protože mám podezření, že má neschopnost se jasně vyjádřit, mohla vést k omylu i jiné laskavé čtenáře. 

Microsoft nemiluji. Můj vztah k němu je spíše záporný, ale na druhé straně ho sám před sebou obhajuji: tato velká a především úspěšná společnost nevznikla a není provozována proto, aby ji lidé milovaly. Vznikla a je řízena, aby pro své akcionáře vytvářela zisk. Tento v kapitalismu bohulibý smysl její činnosti dělá dobře a akcionáři jsou dozajista spokojeni. 

Co se týká prostředí .NET a programovacího jazyka C#, o kterém bude mimo jiné pár dalších řádek, je to stejné. Pro potěchu programátorů byl vytvořen pouze proto, že programátoři obchodních aplikací přinášejí Microsoftu zisk. Ne tím, že pro něj programují, ale jejich výtvory navádějí jejich zákazníky, aby si kupovali operační systém od Microsoftu.

Proč se C# tolik podobá Javě? Protože Java se osvědčila. Osvědčila se ale bohužel pouze u aplikací určených pro servery. Na desktopu moc úspěšná není a pokud se něco zásadního, dovolím si říci zázračného nestane, lepší to pro Javu na desktopu nikdy nebude. To, že Microsoft část .NET a C# standardizoval byl velmi chytrý marketingový a politický tah. Nemá nic společného s tím, že by byl z Microsoftu nějaký zájem na tom, aby byl .NET a C# kvalitně přenesen na Linux a další operační systémy, jak se úspěšně  pokouší projekt Mono. Také v tom byl kus alibismu chránit Microsoft před protimonopolními úřady ve Spojených státech a Evropě. "Co jsme to za monopol, když svou klíčovou technologii necháme nezávisle standardizovat a umožníme každému, aby si ji vytvořil na své platformě?!", mohou hlásat právníci Microsoftu před těmito úřady.

Nyní se mi v hlavě objevila klíčová otázka: Co udělá Microsoft, až se Open Source vývojářům a Novellu podaří zprovoznit .NET a C# na Linuxu a dalších operačních systémech? Co udělá, až Mono umožní provozovat obchodní aplikace vyvinuté pro Windows na Linuxu? Nevím, může udělat cokoliv. Může jenom prohlašovat, že .NET je na jeho operačních systémech mnohem stabilnější a rychlejší. To minimálně ze začátku nepochybně bude pravda. Později tento argument ztratí na váze, protože stabilita se při troše dobré vůle doladí a pokud by snad problémem mohla být rychlost, tak nebude. Proč? Zeptejme se, která obchodní aplikace využije dnešní počítače alespoň z 10-ti procent? Myslím, že žádná. Na počítačích se kterými pracuji já osobně, je pouze zpracování zvuku a videa to, co potřebuje dnes dostupný výkon. Samozřejmě ještě hry, ale to je úplně jiná kapitola.

Microsoft může platformu .NET změnit a mít nějaký nějaký měsíc náskok před Open Source vývojáři. Nemyslím, že by tato strategie měla nějaký zásadní význam. Další co mě napadá jsou patenty. To strašidlo, která dnes buší vývojářům Open Source na dveře a ptá se: Máš na právníky? Máš na patentové poplatky? Máš na patentové rešerše? Odpovídat snad nemusím. Microsoft dnes vlastní desítky tisíc patentů a to může být pro další vývoj především ve Spojených státech pro ostatní pěkná brzda. V Evropské unii se zatím o patentech na software jedná, ale moc dobře to nevypadá.

Je to v podstatě jedno. .NET není Java. Není to proto, že by technologie byla tak rozdílná, je to proto, že .NET je určen pro operační systémy MS Windows a bylo by od Microsoftu hloupé, aby to bylo jinak. Java je multiplatformní a snaží se taková být od svého vzniku. Nepochybně měla být i solí do očí Microsoftu a podařilo se jí to. Ona ovšem přerostla sama sebe a dokonce Microsoft začala významně štvát a tím dala popud vzniku .NET platformy.  Java měla velkou šanci se stát sjednotitelem minimálně Linuxu a MS Windows. To vše ovšem pro desktop Sun zahodil. Swing, ve kterém se mají psát GUI aplikace, je špatnou knihovou, která je složitá, rychle zastarává a navíc jsou "Swingové" aplikace pomalé. Že to jde jinak dokazuje IBM se svých SWT. O tom jsem již několikrát psal a nebudu se opakovat. Zde jsem pouze chtěl vysvětlit proč jsem na Sun naštvaný. Je zahozená velká příležitost a ta mě vždy mrzí.

Přidáno 21.5.2004 23:05 - Slavo Furman napsal zajímavou poznámku k tomuto spotu.

Root.cz a Mono

Na root.cz dnes vyšel velmi zajímavý článek Stane se Mono nejžádanější platformou pro vývoj Linuxu?. Doporučuji k přečtení i když pro spoustu mých známých je implementace Microsoft .NET technologie na Linuxu těžko stravitelná.

Jak jsem již několikrát psal, kdyby Sun nepředvedl při implementaci grafického uživatelského prostředí v Javě (Swing) naprostou impotenci a především neschopnost přiznat chybu, mohlo dnes být vše úplně jinak. Dnes už je zřejmě pozdě. Pokud se Novellu a především panu Migueli de Icaza podaří dotáhnout Mono dokonce, což je dnes velmi pravděpodobné, tak bude mít Sun a Javou především na desktopu vážné problémy. Je to ovšem trochu eufemizmus, protože Java se na desktopu mimo vývojová prostředí používá minimálně. To dokazuje špatný návrh Swingu mnohem více než moje osobní názory.

Otevřený dopis ministru Mlynářovi (patenty)

Vzhledem k současnému vývoji ve schvalování rozšíření patentového systému v Evropské unii v Evropském parlamentu a toho, že naši nezvolení představitelé též hlasovali pro umožnění patentů na software, jsem napsal následující otevřený dopis ministru informatiky, Vladimíru Mlynáři.

Vážený pane ministře,

reaguji na Váš dopis, který jste odeslal panu Marku Červenkovi a byl zveřejněn na serveru root.cz (http://www.root.cz/clanek/2212 ).

Jsem osobně přesvědčen, že se mýlíte. Vše, čím bych mohl argumentovat již bylo mnohokrát řečeno. Proto si dovolím pouze stručně a neobratně uvést několik myšlenek:

Mám obavy, že patenty jsou v současnosti u složitých technologií udělovány a na naprosté triviality. Důvodem je často neznalost v oboru pracovníka patentového úřadu spojená s vysokou erudicí právníků a specialistů podávajících patentové přihlášky. Podle mne Vaše přirovnání k patentování kola jako každé přirovnání trochu kulhá. Kolo je schopen každý pochopit, ale zcela obecný softwarový algoritmus lze při určité snaze a znalosti popsat tak, aby se zdál jako nová převratná myšlenka.

Patenty celkově měly původně chránit vynálezcová práva k jeho vynálezu. V dnešní době ale chrání především velké společnosti, protože podání patentu, jeho správa, rešerše a případné patentové spory jsou únosné pouze pro velké společnosti.

Software je v tomto směru asi nejohroženější. Jde o jednu z posledních možností, kde jednotlivý tvůrce, nebo malá skupina tvůrců, je schopna vytvořit a uvést v život nový a převratný vynález. Bohužel velké společnosti jako je např. IBM, Microsoft, Nokia a mnohé další vlastní každá desítky tisíc patentů, které mohou poměrně snadno pomocí patentového práva znemožnit uvést takové vynálezy v život nebo vynálezci klást vlastní podmínky.

Jsem osobně přesvědčen, že v konečném důsledku budou v blízké budoucnosti patenty, tak jak je dnes známe, škodlivé i pro velké společnosti, protože začnou "žít vlastní život" a jediný, kdo z nich bude mít prospěch budou právníci ve svých nekonečných a nákladných sporech.

Jinak Vám přeji mnoho úspěchů v osobním i pracovním životě a hlavně hodně zdraví.

Kouba Tomáš, ředitel společnost Neocortex s.r.o.

Java Desktop System

Dříve se tento projekt firmy Sun jmenoval Mad Hatter (bláznivý kloboučník), což je zřejmě parafráze na distribuci Linuxu firmy Red Hat (červený klobouk). Jde o balík programů včetně operačního systému Linux určených pro osobní počítače založené na bázi procesorů x86.

Java Desktop System (JDS) si lze zakoupit za předplaté 100$ ročně. Obsažený software: operační systém Linux - GNOME 2, browser Mozilla, kancelářský balík OpenOffice 1.1, groupware Evolution, několik Java aplikací jako například jDictionary a spoustu dalších aplikací, např. Real Player, Adobe Acrobat Reader, Macromedia Flash Player, instant Messaging klient Jabber pracující s AIM, MSN, Yahoo, Project Management a další.

Podporované jazykové varianty: angličtina, francouzština, němčina, italština, švédština, španělština, zjednodušená a tradiční čínština. To, že chybí čeština mě nijak neudivuje, chybějící ruština je větším překvapením. Je vidět, že Sun je nucen šetřit všude.

Název Mad Hatter se mí líbí mnohem více než Java Desktop System. Není totiž tolik zavádějící. JDS totiž zase tolik s Javou nemá společného, jde pouze o novou distribuci Linuxu a Java je zde spíše použita jako marketingový název. To vše potvrzuje můj názor, že se blíží doba, kdy na firmě Sun bude Java to nejcennější co má.

Na první pohled sice vypadá projekt JDS dosti nesmyslně, ale pouze na první pohled. Jiné distribuce Linuxu se sice dají legálně sehnat zdarma, ale mají jednu nevýhodu: nestojí za nimi velká obchodně úspěšná firma, která mu zkušenosti s poskytováním kvalitní a široké podpory a zaručuje se za funkčnost. O to tady jde především.

JDS je určeno především větším firmám, které chtějí produkt nasadit a pracovat. Zde je hlavní význam této zprávy - konkurence vůči řešením na bázi Microsoftu. Jde také samozřejmě o velké peníze a zákazníků je hodně. Microsoftí balík operační systém MS Windows + kancelářský balík MS Office je mnohem dražší. Navíc JDS je založeno na Open Source standardech a to má proti uzavřeným firemním standardům Microsoftu také silnou váhu. Po nové licenční politice Microsoftu nebude zákazníky na JDS odpuzovat ani forma ročního předplatného - vše je proti Microsoftu levnější. Přeji firmě Sun s JDS mnoho úspěchů.

Vlastní produkt bude k dispozici k zakoupení v USA v prosinci letošního roku. Minimální požadavky na počítač jsou na dnešek snadno splnitelné, procesor PII-266, 4GB HD, 128 MB RAM.

Pár úvah k refaktorování

Rád bych navázal na svůj spot Kniha: Refaktoring - Zlepšení existujícího kódu. Úvodem stručně co to refaktorování je, kdyby to ze čtenářů náhodou někdo nevěděl. Podle definice uvedené v knize: refaktorování je změna ve vnitřní struktuře softwaru, vedoucí k jeho snazšímu pochopení a usnadnění dalších úprav bez změny jeho vnějšího chování. Jako mnohem lepší popis refaktorování se mi jeví metafora dvou klobouků se kterou přišel Kent Beck. Při programování si nasazujete dva klobouky, které lze velmi často střídat:

1. První klobouk používáte pouze pro přidávání nové funkcionality. Pokud ho máte na hlavě, nesmíte měnit stávající kód, lze pouze přidávat další schopnosti. Práci v tomto klobouku lze sledovat a kontrolovat vytvářením nových testů a jejich prováděním.
2. Při nasazení druhého klobouku - refaktorování, žádné nové schopnosti nepřidáváte, pouze se mění struktura kódu. Nepřidávají se ani testy s výjimkou, kdy nějaký chybí. Změny v testech se provádí pouze v nejnutnějších případech, např. při změně rozhraní objektu.

I když klobouky velmi často střídáte, musíte si pro začátek před sebe postavit zrcadlo a stále se do něj dívat, který klobouk máte na hlavě. Stále je nutné přesně vědět, kdy refaktoruji a kdy přidávám nové vlastnosti programu. Pokusíte se například přidat novou metodu k objektu a zjistíte, že by to šlo mnohem snáz, kdyby měl kód jinou strukturu. Vezmete si druhý klobouk a budete krátce refaktorovat. Po úpravě kódu opět klobouky vyměníte a přidáte inkriminovanou novou metodu. Celé to bude trvat pár minut, ale neustále by jste měli vědět, který klobouk máte na hlavě.

Nakonec popisu refaktorování ještě jedna poučka: kód kterému rozumí jen počítač, dokáže napsat každý. Dobří programátoři píší kód, kterému rozumí lidé.

Refaktorování popisované v uvedené knize je nepochybně velmi přínosné a zajímavé. Občas se ale ve mě něco zpříčí. Já patřím do pravěké školy, kde každý programátor automaticky dbá na zachování vysoké rychlosti výsledného programu. Je to intuitivní chování a těžko se ho zbavuje. Který kód se vám více líbí?

Varianta 1:

int citac = nejakaMetoda();
for (int k=0; k < 1000; k++)    {
    vysledek += citac * k;
}

Varianta 2:

for (int k=0; k < 1000; k++)    {
    vysledek += nejakaMetoda() * k;
}

Pokud se vám líbí více varianta 1, tak jste na tom stejně jako já. Intuitivně uvažujete nad rychlostí. Z hlediska refaktorování je ovšem upřednostňována varianta 2. Z uvedeného primitivního příkladu vyplývá, že problém refaktorování není tak jednoduchý a jednoznačný, jak vypadá na první pohled.

V knize se argumentuje: refaktorování chod programu zpomalí, ale zároveň umožní snadnější ladění výkonnosti. To je asi pravda. Je známou skutečností, že rychlost programu ovlivňuje 5-10% kódu, ostatní kód na rychlost provádění programu nemá téměř žádný vliv. Pro urychlování refaktorovaného kódu a nejen jeho, je téměř nezbytný profiler. S jeho pomocí najdete u pomalého a "žravého" programu místa, která nejvíce ovlivňují rychlost a spotřebovávají paměť. Soustředíte se na tato ohniska a použijete stejné optimalizace, jaké byste používali intuitivně starým způsobem. Protože se však věnujete pouze nejkritičtějším oblastem kódu, je výsledek lepší a celý kód je především mnohem přehlednější. Podle Fowlera pomáhá refaktorování psát rychlý software. Během refaktorování je program dočasně pomalejší, ale výsledný kód lze lépe optimalizovat. Konečný výsledek je pak (mnohem) rychlejší.

Refaktorování také může být riskantní (kniha se tím netají), protože do programu dokáže zanést velmi záludné chyby. Naštěstí právě tato kniha se svých katalogem refaktorování dokáže velmi efektivně toto riziko snížit nebo možná dokonce vyloučit. Myslím, že v jednom se kniha mýlí. Refaktorování je sice skutečně určeno ke změnám stávajícího kódu, ale všechna refaktorovací pravidla je nutné mít na paměti nejen při opravování již napsaného kódu ale, a to možná ještě důrazněji, při psaní kódu nového.

Windows Template Library jako Open Source

Před čtyřmi dny Microsoft na serveru SourceForge.net uvolnil své Windows Template Library (WTL) jako Open Source. Není to poprvé. Již v březnu tohoto roku pod stejnou licencí Microsoft uvolnil zdrojové kódy Windows Installer XML (WiX). Použitá licence je Common Public Licence. Common Public Licence je Open Source licence společnosti IBM. Byla oficiálně schválena sdružením Open Source Initiative a je uvedena na jeho oficiálním webu. Je podobná známé licenci GPL. Programátoři mohou bez omezení modifikovat zdrojové kódy, lze je použít v komerčních produktech, ale všechny změny musí být zveřejněny.

Bez mučení se přiznám, že tento překvapivý krok jsem od Microsoftu neočekával. Windows Template Library je totiž úplně něco jiného než dříve uvolněný Windows Installer XML. Co to vlastně je Windows Template Library? Jde o knihovnu šablon rozšiřující ATL třídy pro vytváření oken. Je v podstatě o COM objekty pro tvorbu User Interface, tedy téměř všech potřebných prvků pro tvorbu vzhledu tlustých MS Windows programů. Sice proti MFC některé třídy chybí, třeba napojení na OLE dokumenty nebo dokovatelná okna, ale to myslím není žádným zásadním problémem. Dokumentaci je sice nutno hledat po Internetu, ale to, že výsledné aplikace jsou proti použití MFC rychlejší, méně náročné na systémové prostředky a nepotřebují žádné další dll knihovny stojí za to. WTL je naprogramováno v C++ a jeho poslední verze k dnešnímu dni je 7.5.4133.0. Je trochu úsměvné, že na SourceForge.net je uvedeno jako Alpha verze. Pokud se chcete s Windows Template Library seznámit podrobněji, doporučuji navštívit CodeProject.com.

Kniha: Refaktoring - Zlepšení existujícího kódu (Martin Fowler)

Do knihy přispěli mimo Martina Fowlera i Kent Beck, John Brant, William Opdyke a Don Roberts. Je bohužel pravdou, že někteří tito pánové sice podle všeho umějí dobře programovat a analyzovat, ale spisovatelé dobří nejsou. Jejich schopnost vyjadřování o mnoho nižší, než Martina Fowlera. Přesto jde bez pochyby o velmi zajímavou knihu. Jednu z nejlepších, která o teorii objektového programování v Česku vyšla.

Kniha je poměrně dobře přeložena a měl jsem z ní dobrý pocit. Každý, kdo se zajímá o objektové programování, by si ji měl přečíst. Uvedené zdrojové kódy jsou sice v Javě, ale kniha může dobře sloužit i programátorům v dalších objektově orientovaných jazycích, třeba v C#.

V prvních částech po povinném úvodu kniha ozřejmuje smysl a principy refaktorování. Další kapitola je věnována tzv. "pachům v kódu", jako je duplicitní kód, dlouhé metody a seznamy parametrů, datové shluky a podobně. Další dvě kapitoly jsou věnovány vytváření testů a úvod do vlastního katalogu refaktorování. Vlastní katalog se dělí na tyto kapitoly:

• úpravy metod,
• přesouvání prvků mezi objekty,
• organizace dat,
• zjednodušování podmíněných příkazů,
• zjednodušování volání metod,
• generalizace.

Poslední kapitoly v knize jsou velká refaktorování; refaktorování, opětovné použití a realita; nástroje pro refaktorování. Tyto tři poslední kapitoly považuji za velmi slabé. Jejich informační hodnota je sice možná vysoká, ale čtivost velmi nízká. Pokud to nejde číst, tak se tam může psát třeba o absolutní pravdě, ale nic z toho nemám.

Závěr: knihu doporučuji všem, kdo přicházejí do styku s objektovým programováním a to především v Javě a C#.

Martin Fowler: Refaktoring - Zlepšení existujícího kódu; www.grada.cz; 390,- Kč; 394 stran.

Open Source/GNU

V poslední době jsem v českých spotech a článcích měl možnost číst různá, většinou negativní stanoviska k Open Source projektům. Open Source se vyčítá, že u programů jde z hlediska programátora o výtvory zmatené s nesystematickým API a z pohledu uživatele o programy zastaralé, kopírující komerční produkty, především Microsoft. Jsou nestabilní, protože minimálně části Open Source programů nejsou kvalitně napsané a především jsou nedostatečně testované. Nemají vlastní vizi, pohled do budoucnosti a postrádají koncepci. Jejich autoři neprovádějí žádný výzkum a doplňují pouze  funkce, které sami považují za důležité a ignorují požadavky většiny uživatelů.

Na to musím zareagovat trochu nepopulárně: ano většina těchto negativních názorů na Open Source programy je pravdivá. Ovšem jako u všeho, není to černobílé. Existují Open Source projekty,  které mají většinu těchto nedostatků, existují projekty, které mají některé nedostatky a existují Open Source projekty, které jsou skvělé, dokonce mnohem lepší, než komerční produkty. Není jich většina, ale je jich dost. Nesmíme zapomenout, že také existuje obrovské množství velmi špatných komerčních programů. Jsou tak špatné, že se o nich nikdy ani nedovíme. Trh je vymazal ze světa. Špatný Open Source program si můžeme stáhnout, používat ho a potom ho zklamaně odinstalovat. Se špatným komerčním produktem se nikdy nesetkáme, protože zmizel z trhu nebo sice ještě na trhu je, ale mi si ho nikdy nekoupíme.

K dnešnímu spotu, mě ale inspirovalo trochu něco jiného, než kvalita Open Source programů. Byl tím článek na Živě.cz: Wikipedia už má čtvrt milionu článků. Nechci zde Wikipedii popisovat, kdo neví o co jde, ať si uvedený článek přečte. S Wikipedií stojí za to se seznámit. Jde mi o něco jiného, o pohled na Open Source z obecného lidského hlediska.

Prostě a jednoduše, fascinuje mě to. Jsem uchvácen tím, že mnoho tisíc inteligentních a vzdělaných lidí je ochotno věnovat svou energii a čas pro práci pro ostatní, bez ohledu na vlastní prospěch. Jediný zisk, který ze své práce mají, je uznání ostatních. To je sice pro spoustu lidí velká odměna, ale v tržním hospodářství, ve kterém dnes žije naprostá většina vyspělého světa jde o odměnu nedostatečnou a neuznávanou. Občas mám trochu deprese. Jak z lidí se kterými musím jednat, tak sám ze sebe. Zisk, bezohlednost a egoismus, to přece není náplň a smysl života.

Nejsem už žádný kluk, abych mohl chtít uvěřit komunistických lžím a přesto bych rád doufal  a věřil v lidské dobro. Tuto naději mi projekty jako je Wikipedia dávají a jsem za ní vděčen. Neznám jiný obor mimo informatiky, kde část lidí pracuje zadarmo, pouze pro užitek ostatním. Samozřejmě, jsou mezi nimi i amatéři, ale to nic nemění na tom, že je to skvělé. Někde jsem dokonce četl, že Open Source je pouze odporem proti Microsoftu. To je samozřejmě nesmysl. Existuje spousta GNU projektů, které nemají s Microsoftem nic společného, Wikipedia je dobrým příkladem. Existuje ale mnohem podstatnější důvod, proč odpor k Microsoftu není motorem Open Source/GNU: z nenávisti lze pouze bořit a ničit, nelze z ní nic postavit.

Rozhovor s Jamesem Goslingem

Na ACW vyšel krátký rozhovor s Jamesem Goslingem, jedním z tvůrců Javy. Vyjadřuje se v něm k relativní složitosti Java API. Podle něj je základní API v dobrém stavu a ostatní části jednoduché být nemohou, protože "vesmír je také složitý". Svět se stává dramaticky komplikovaným, mobilní telefony, automobily, ledničky, to vše může být spojené a programováno v Javě.

Dále podle Jamese Goslinga není možné, aby Java byla více otevřená. Dnes je k dispozici každá řádka zdrojového kódu Javy. Pokud by Java byla i z hlediska licence Open Source, Javě by to uškodilo. Gosling uvádí, že Linux má dnes téměř 300 distribucí a ty jsou v některých aspektech nekompatibilní. Programátoři s tím mají nemalé problémy. Sun tím, že má Javu pod kontrolou zajišťuje, že programy, které programátor napsal pod Linuxem, spolehlivě poběží třeba pod MS Windows i pod Mac X.

Jak zpracovávat velké XML soubory (MSDN)

Na MSDN Dare Obasanjo napsal článek jak editovat velké XML soubory (Efficient Techniques for Modifying Large XML Files). Pokud upravujeme velké XML soubory, můžeme se snadno dostat do velkých problémů. Standardní cestou je načíst je do XmlDocument, modifikovat je v paměti a potom je uložit zpět na disk. V tomto případě ovšem může být problém s paměťovou náročností tohoto postupu.

První řešení tohoto problému je použitelné, pokud pouze potřebujeme přidat další položku nebo položky do XML souboru, například v případě přidání dalšího záznamu do log souboru. Tento postup zahrnuje použití dvou souborů. První soubor je validní XML dokument, druhý pouze XML fragment. Validní XML soubor zahrnuje XML fragment buď jako e xterní entitu deklarovanou v DTD nebo použitím elementu x i:include.

Další řešení problému jak zpracovat velký XML soubor je číst ho s použitím XmlReaderu a průběžně ho zpracovávat a ukládat pomocí XmlWriteru. Takto není nikdy celý XML soubor v paměti a lze v XML v podstatě udělat jakékoliv změny.

V originálním článku jsou ke všem navrženým řešením k dispozici přehledné zdrojové kódy.

České zdroje o C# a .NET

Zde je pár zajímavých českých zdrojů o programovacím jazyku C# a platformě MS .NET:

• Diskusní fórum na emwac.cz. Pro programátory je toto fórum povinností. Příspěvky jsou kvalitní, účastníků přibližně 600. Bohužel správce konference, EMWAC CZ, který je přímo sponzorován společností Microsoft, neodvádí zrovna dobrou práci. Archiv donedávna neexistoval, museli ho zřídit sami účastníci na pandora.cz nebo na vyvojar.cz. Jako příklad špatné práce správce konference je třeba to, že webová stránka konference je přístupná pouze přes MSIE.
• aspnetwork.cz: zajímavé články, bohužel ne často.
• Weblog rebex.cz: občas zajímavé překlady a postřehy.
• Weblog vyvojar.cz: téměř denně krátké články.
• Weblog ISlavoF.Save(): slovensky, v poslední době téměř žádné nové články.
• Weblog Radin.NET: občas krátké články.

Je zajímavé, že proti Javě je úroveň a především periodicita zdrojů o technologii .NET a C# mnohem horší. Možná je to tím, že ti kteří se živí Microsoft technologiemi mají méně času. Buď je to proto, že programovat pro Microsoft je mnohem náročnější než pro Javu, nebo jsou to obecně komerčněji zaměření lidé. Psaní spotů a článků vyžaduje značnou míru entuziasmu a ten možná Microsoft oblíbencům chybí. Každý máme své priority a na penězích není nic špatného.

Data do databáze nebo do XML

Zvažme toto jednoduché zadání aplikace:

• platforma .NET;
• aplikace typu Win Form - tlustý klient;
• práce v malé síti, maximálně 10 současně pracujících uživatelů.
• účel aplikace: například sledování projektů a projektový a časový management.

Jedna z otázek, kterou si architekt takového projektu musí položit: kam ukládat data? Na první pohled je situace jasné, do nějaké embed databáze, například Jet (MS Access), SQL lite, Firebird, HyperNet. Na druhý pohled už situace nemusí být tak úplně jasná. Existuje ještě jedno řešení. Pokud dat není hodně, je možné data ukládat do samostatných souborů ve formátu XML. Proč? Protože embed databáze mají některé nevýhody:

• Vyžadují ovladač, například v případě Jet a .NET musí být nainstalováno MDAC ve verzi 2.6 a vyšší.
• Každá databáze, kterou lze v tomto případě použít je "černou skřínkou". Data v ní uložená si nelze prohlížet než pomocí aplikace a formát dat je přinejmenším neprůhledný, často veřejně neznámý.
• Aplikace rychleji startuje, protože není nutné otevírat databázi.
• Nejsou problémy s konzistencí dat. Při narušení dat dojde maximálně k poškození jednoho XML textového souboru, který jde snadno opravit. V případě poškození binárního souborů, třeba souboru mdb databáze Jet, je poškození často neopravitelné.

XML soubory mají samozřejmě proti embed databázím také nevýhody:

Složitější programování

Při použití XML uložení dat je nutné naprogramovat mezivrstvu. Tu je sice velmi praktické naprogramovat i při použití embed databáze, ale není to nutné. Dále .NET má sice kvalitní třídy pro zpracování XML souborů, ale nikdy to nebude jednoduché, tak jako položení SELECT dotazu do databáze. Tento problém považuji za nejvážnější. Aplikace se díky složitějšímu programování prodraží a její uvedení do provozu bude později. Na základě mých zkušeností to může být pro aplikaci a celý projekt fatální problém.

Rychlost

Práce s XML je a bude vždy pomalejší než práce s binárním formátem embed databáze. S tím nelze nic dělat. Položme si však otázku o jakou aplikaci jde a především jak velké množství dat bude aplikace zpracovávat, resp. jak velké množství dat bude načítat? V našem zadání aplikace nebude mít velké množství dat a ještě méně jich bude načítat. Pak je rozdíl minimální a rozdíl v rychlosti zpracování pomocí lidských smyslů neměřitelný.

Problémy při práci v síti

Při práci v síti je práce s XML soubory samozřejmě složitější než práce s embed databází. Ten rozdíl ovšem není tak velký, jak by se zdálo na první pohled. Dovolím si vložit jednoduchou tabulku, která jednotlivé rozdíly popíše:

Data uložená v XML souboru	Data uložená v embed databázi
	Otevření spojení do databáze
Načtení XML souboru	Položení SELECT dotazu
Zpracování XML dat
Editace dat ve formuláři
Zjištění, zda někdo v síti nezměnil XML soubor (např. kontrola času změny soubory)	Zjištění, zda někdo v síti nezměnil zpracovávaný řádek v tabulce (SELECT)
Uložení do XML souboru	Uložení do databáze

Komentář k tabulce: tato tabulka samozřejmě popisuje práci s jednoduššími daty dle našeho zadání. Pokud by data byla "příliš relační/strukturovaná" nebo by jich bylo moc, XML řešení by rychle ztrácelo dech. V případě, kdy by současně pracujících uživatelů bylo také hodně, situace by začala být kritická dříve u XML řešení, než u embed databáze. U databáze bychom při dobrém návrhu a dodržování některých zásad při programování, mohli snadno přejít na "dospělejší" SQL databázi, např. Oracle.

Problémy s právy a s kontrolou přístupu

U mnoha embed databází lze snadno upravovat práva jednotlivých přistupujících uživatelů. Lze zadat různé typy práv k různým částem databáze. Podle mých zkušeností ovšem u desktop aplikací se tento přístup moc nepoužívá. Mnohem rozšířenějším způsobem je kontrolovat práva k různým akcím v databázi pomocí oprávnění, které nastavuje a uplatňuje sama desktop aplikace. Zde je tedy v tomto případě rozdíl mezi řešením pomocí XML a embed databáze zanedbatelný.

Podobný problém je kontrola přístupu. Uživatel aplikace by mohl oprávněně chtít, si do dat aplikace uložit data, ke kterým lze omezit nebo znemožnit ostatním uživatelům přístup. Pokud u embed databáze neudržujeme kontrolu přístupu pomocí oprávnění nastavených přímo v databázi, tak jsme na tom stejně jako u XML souborů. Každý si může databázi otevřít mimo aplikaci, tím obejít oprávnění, která jsou implementována v aplikaci a číst si libovolná data. Zbývá zde jediná možnost a tou je šifrování. To můžeme použít u textových dat jak u databáze, tak u XML souboru. Implementace řešení je zhruba stejně náročná.

Tedy z hlediska práv a kontroly přístupu má embed databáze výhodu pouze v případě, kdy se použijí práva implementovaná přímo v databázovém souboru(ech). V tomto případě ovšem je nutné počítat s náročnější implementací. Nejsem schopen posoudit jak náročné je "prolomit" ochranu například v Jet databázi. Myslím, že to bude snazší, než prolomení některého ověřeného šifrovacího algoritmu.

Závěr

Použití XML řešení je možné za těchto předpokladů (jde pouze o mé kvalifikované odhady):

• Vývojový tým je schopen zvládnout vyšší nároky v nákladech i ve zvýšené složitosti přístup k datům.
• Data nejsou příliš relační, ale spíše textového charakteru.
• Práce v síti je malá, počet současně pracujících uživatelů by neměl významně překročit počet 10.
• Množství dat není velké. Pokud by počet XML souborů stejného typu měl překročit 1.000, není toto řešení vhodné. Vyhledávání a vytváření seznamů by bylo příliš náročné. tento nedostatek XML řešení lze obejít vytvořením pomocných binárních souborů, které seznamy poskytují.

Konference

O problému, který řeším v tomto spotu jsem položil dotaz do konference na VSNET-L@LIST.EMWAC.CZ a reakce byly v podstatě jednoznačné. V případě nasazení v síti i u malého počtu uživatelů je jednoznačně lepším řešením použití embed databáze. Spíše je ovšem upřednostňovaná polo-dospělá MSDE databáze. Jet není považovaná za dostatečně spolehlivou. MSDE má bohužel jednu zásadní nevýhodu: její instalace a správa není triviální a pro laického uživatele může použití této databáze zkazit dojem z celé aplikace. Je otázkou, zda odpor odborné veřejnosti k ukládání dat do XML souborů je zapříčiněn kvalifikovanými názory na nedostatky tohoto řešení nebo určitou setrvačností v myšlení.

Pokud budete mít jakékoliv připomínky k tomuto textu, neváhejte mi napsat.

České zdroje o Javě

Zde je pár zajímavých českých zdrojů o Javě:

• Weblog jAblok: kvalitní články, frekvence téměř denní.
• Weblog Dagblog: kvalitní články, frekvence většinou denní.
• Weblog Jirka Hradil: kvalitní články, frekvence bohužel sporadická.
• Studentský informační sever Dioné: Základní informace a manuály.
• Diskusní fórum Builder.cz: je možné diskutovat jak pomocí www, tak se přihlásit pro email odběr příspěvků.
• Konference na java.cz: zřejmě největší česká konference o Javě. Pro programátory povinnost.

Kniha: C# - programujeme profesionálně (kolektiv)

Kolektiv autorů (Simon Robinson, K. Scott Allen, Ollie Cornes, Jay Glynn, Zach Greenvoss, Burton Harvey, Christian Nagel, Morgna Skinner, Karli Watson), který tuto knihu napsal, odvedl dobrou práci. Nejvíce pozoruhodné mi připadá, že přes nezvykle velké množství autorů má kniha celkově vyváženou úroveň a tato úroveň není nijak nízká. Nakladatelství Wrox, které v anglickém originále knihu vydalo, sice již udělalo bankrot, ale jeho edice Programmer to Programmer, ze kterého kniha pochází, měla vždy vysokou úroveň a tato kniha není výjimkou.

Kniha je rozdělena celkem na 23 kapitol a dvě přílohy: Jazyk C# a architektura prostředí .NET, Základy jazyka C#, Objektově orientovaný jazyk C#, Pokročilá témata (výjimky, delegáty, události, atributy a nebezpečný kód), Jazyk C# a bázové třídy, Programování v prostředí .NET, Aplikace pro systém Windows, Co jsou sestavení, Přístup k datům v prostředí .NET (ADO.NET a něco málo o XML), Prohlížení dat v prostředí .NET, Pracujeme s jazykem XML, Souborový systém a registr, Pracujeme s Active Directory, Stránky ASP.NET, Webové služby, Uživatelské a vlastní ovládací prvky, Interoperabilita s komponentami COM, Služby modelu COM+, Grafika v objektovém modelu GDI+, přístup k Internetu, Distribuované aplikace a služby vzdálené komunikace, Služby systému Windows, Zabezpečení platformy .NET Framework, Základy objektově orientovaného programování, Možnosti překladače jazyka C#.

Rejstřík knihy je v dostatečné velikosti. Překlad je na české poměry dobrý. Zdrojové kódy jsem nekontroloval, ale je hodně chyb v diagramech. To je zřejmě nějakým prokletím nebo neschopností pracovníků Computer pressu. Přesto jde o užitečnou knihu, protože většina témat je velmi dobře vysvětlena. Musím přiznat, že jsou věci, které jsem pochopit teprve díky této knize.

Závěr: knihu doporučuji těm, kteří potřebují pracovat s jazykem C#. Myslím, že jde spolu s knihou Programujeme .NET aplikace (Kačmář) o nejlepší knihu, která o C# v česku vyšla. Není levná, ale vyplatí se.

Kolektiv autorů: C# - programujeme profesionálně; www.cpress.cz; 890 Kč, 1130 stran. 

Kniha: Naučte se ADO.NET za 21 dní (Fox D.)

Pokud si tuto knihu zakoupíte a přečtete dojdete k několika závěrům:

1. ADO.NET je velmi složitá technologie.
2. Dan Fox (autor knihy) napsal několik skvělých knih o Visual Basicu.
3. Jiné úložiště dat než MS SQL server a XML jsou nezajímavé a nevýznamné.
4. Nejvýznamnější jazykem MS .NET technologie je Visual Basic NET.

Jde pravděpodobně o jednu z nejhorších knih, kterou jsem o IT četl. Často kritizuji překladatele, ale u této knihy jde viditelně i o neschopnost autora se jasně, srozumitelně a přehledně vyjádřit. Překlad také není ideální, kniha se hemží výrazy jako polymorfistické chování apod., ale viditelně i původní originální kniha není dobrá. Edice "... za 21 dní" není pro tento znalostní typ vhodná. Některé kapitoly jsou nesmyslně dlouhé, některá témata se naopak prostě do jedné kapitoly nevejdou.

Co se týká obsahu knihy, kniha je jak je zvykem v této edici rozdělena na 21 kapitol a ty na tři týdny. Je zajímavé, že každý týden je také kapitolou, která se jmenuje Letmý pohled. Tomu moc nerozumím, ale na knize mi to vadí ze všeho nejméně.

Závěr: Knihu nedoporučuji nikomu.

Dan Fox: Naučte se ADO.NET za 21 dní; www.cpress.cz, 425,- Kč; 508 stran.

Java 1.5 Alfa k dispozici

Sun uvolňuje alfa verzi Java 1.5 k poloveřejnému testování. Každých 14 dnů bude uvolněna nová verze alfy pro operační systémy Linux, Solaris a MS Windows. Tato alfa verze je určena pro testování nových rysů a API tohoto programovacího jazyku. Pro zápis do testovacího programu je nutné poslat email Ingrid.Yao@sun.com a požádat (v angličtině) o připojení k CAP programu. Emailem obdržíte zpět dokument o utajení, který musíte odfaxovat do Sun. Potom je přidělen přístup na webové stránky CAP programu s alfa verzí Java 1.5.

Avalon

O Avalonu ještě mnoho uslyšíme ještě mnohem více ho uvidíme. Jde totiž o grafický subsystém nového operačního systémy Microsoftu s pracovním názvem Longhorn. Na root.cz vyšel zajímavý článek, který se mimo jiné věnuje Avalonu. Asi především proto, že na root.cz přispívají většinou odpůrci produktů firmy Microsoft, je i tento článek laděn spíše negativně. Je to škoda především proto, že v z článku jsem měl pocit několika nepřesností. Ještě více než vlastní článek, kde autor ví co píše, protože tématu rozumí, jsou zajímavé některé reakce v diskusi pod článkem. Pro některé lidi i kdyby Microsoft udělal cokoliv, je to špatné. Pár zastánců Microsoftu je i častováno hrubými urážkami a jejich argumenty jsou zcela opomíjeny. Pokud se chcete seznámit s příkladem fanatizmu, jsou některé tyto příspěvky krásným příkladem.

Avalon se snad nikdy nebude snažit o konec webu v jeho dnešní podobě. Microsoft už se několikrát spálil s podobnými pokusy. Naposledy třeba s technologií ADS (Active Data Services), která byla později přejmenována na RDS (Remote Data Services). Neříkám, že by Microsoft nechtěl ovládnout celý Internet. Určitě ano a v podstatě mu není co vyčítat. Je akciovou společností a ta existuje proto, aby pro své akcionáře produkovala zisk. Na druhé straně naprosto uzavřené technologie jsou minulostí. I Microsoft to pochopil a akceptuje. Orientace na formát XML a standardizace části .NET platformy je toho důkazem. Já v žádném případě nejsem zastánce Microsoftu. Mám k této firmě nejméně sto a jednu kritickou připomínku, ale buďme prosím rozumní.

Pokud Microsoft skutečně uvede na trh Avalon s tím, že bude schopen nahradit dnešní HTML web webem aplikačním, bude to asi jeho největší dar světu. Bude to změna zásadní a velmi užitečná. Užitek přinese nejen ergonomický, ale i v úsporách datových přenosů.

Dnešní internet je založen na značkovacím jazyku HTML, který nikdy nebyl navržen jako aplikační platforma. Dnes je ovšem velká část webů aplikacemi, které produkují HTML, které se zobrazí klientovi na prohlížeči. Tak to ale nikdy být nemělo! HTML a dnes XHTML je značkovací jazyk, který je snadno naučitelný a umí dobře strukturovat a provazovat dokumenty. I když k němu přidáme pro zlepšení vzhledu CSS a pro zlepšení ovládání JavaScript, stále je to kombinace pro jenom trošku náročnější aplikace velmi slabounká. Ovládání je zoufale neergonomické, přenášejí se zbytečná data a uživatelský komfort veškerý žádný. Nijak nechci význam HTML snižovat a kritizovat ho. Jenom stačí ho používat v tom, v čem je opravdu silný a proč byl vyvinut.

To, že je dnes přes 60% (podle GIG v roce 2002 64%) aplikací vyvíjeno pro provoz na webu pomocí (X)HTML je jenom zoufalé volání po jednoduchém přístupu k aplikacím. Uživatelé nechtějí nic instalovat, konfigurovat a vůbec se zabývat provozem programů. Chtějí kvalitní aplikace používat, když je potřebují a když je nepotřebují, tak na ně zapomenout. Pokud toto Avalon splní, bude to pro Microsoft nejen zasloužený obchodní úspěch, ale i velký krok dopředu v celé informatice. Slíbená standardizace této technologie vyrazí zbraně z rukou odpůrcům Microsoftu. Pro konkurenci bude nesmírně důležitá implementace .NET knihoven a CLR. Kdo ji za pár let mít nebude, bude velmi těžko na desktopech konkurovat.

Samozřejmě je možné, že vše bude úplně jinak, kdo ví...

SwingWT

Na sourceforge.net je k dispozici 0.73 verze zajímavého produktu SwingWT. Tato knihovna dokáže spojit svět Swingu a SWT. Sám jsem v září letošního roku věnoval spot tomu, které z těchto dvou GUI řešení pro Javu vybrat. SwingWT tento problém řeší tak, že preprocesor projde zdrojový kód a dle přání programátora se rozhodne, zda bude aplikace běžet pod Swing nebo pod SWT. Java bohužel preprocesor nepodporuje a proto je nutné použití nějaký produkt třetí strany.

Jde o čistou Java knihovnu, která je svým návrhem velmi podobná Swingu. Při jejím použití je dokonce možné zkompilovat Java aplikaci jako nativní pod Linux pomocí gcj.

Kniha Programujeme .NET aplikace ve Visual Studiu .NET (Kačmář D.)

Autor je nepochybně odborníkem v popisované technologii. Kniha je erudovaná a text knihy netrpí chybami. Naopak je zajímavé, že zdrojové kódy jsou chyb plné - jako by je psal jiný autor. Asi by to i u autorských knih chtělo odborného korektora! Je to chyba jak autora, tak vydavatele.

Kniha se dělí na několik částí. První dvě popisují architekturu .NET platformy, třetí je úvodem do jazyka C#. Čtvrtá kapitola popisuje ASP.NET, pátá Web služby, šestá ADO.NET a poslední sedmá Windows Forms. Vzhledem k rozsahu knihy je samozřejmé, že jde pouze o první, poměrně stručné seznámení s technologií .NET a jednotlivé kapitoly nesou moc dlouhé. Tím vůbec nechci říci, že jsou probíraná témata pro začátečníky. Autor předpokládá nejen znalost programování, ale i dobrou znalost objektového programování a operačního systému MS Windows. V textu se většinou nezdržuje žádnou omáčkou a jde přímo k věci. Témata jsou probrána odborně a hutně a stačí jako první seznámení pro nováčky s platformou .NET.

Ač se podle názvu knihy může zdát, že kniha bude plná obrázků obrazovek MS Visual Studia, není tomu naštěstí tak. Je jich zde pouze pár a kniha není manuálem pro používání tohoto vývojového nástroje.

Závěr: kniha je vhodná pro ty, kteří se potřebují seznámit s platformou .NET, ale znají poměrně dobře objektově orientované programování a OS MS Windows. Celkově knihu hodnotím poměrně pozitivně.

Kačmář Dalibor: Programujeme .NET aplikace ve Visual Studiu .NET, www.cpress.cz, 390,- Kč, 335 stran. 

Kniha C# v kostce (P. Drayton, B. Albahari & T. Neward)

Jde o překlad knihy z anglického jazyka z nakladatelství O'Reilly z oblíbené řady "...v kostce". Kniha je poměrně rozsáhlá a v prvních 23 kapitolách, tj. 256 stranách velmi kvalitně popisuje programovací jazyk C#. Jde v podstatě o referenční příručku tohoto nového programovacího jazyku. Téměř u každého probíraného tématu je uveden stručný a jasný příklad, který problém dobře popisuje a ozřejmuje. Bohužel je tato část knihy poměrně stručná a některé oblasti nejsou vysvětleny dostatečně.

Dalších část knihy, kapitoly 24 až 46 (tj. 416 stran) popisují  API .NET Frameworku. Tuto část knihy nepovažuji za moc podařenou. Rozsah .NET knihoven je obrovský a nelze ho na 400 stranách popsat. Jde tedy o popis stručný, až nedostatečný. Myslím, že pokud se má vydat referenční příručka, o což se nepochybně tato kniha pokouší, má být dostatečně podrobná.

Přílohy jsou v kapitolách regulární výrazy, specifikátory formátu, převádění dat, klíčová slova C#, obory názvů a sestavy a seznamy typů, metod, vlastností, událostí a proměnných.  Zajímavé jsou pouze regulární výrazy a specifikátory formátu. Ostatní informace jsou spíše zbytečné.

Bohužel kniha, jak je v českých krajích a luzích zvykem, je velmi špatně přeložena. Vím, že nelze najít funkčního překladatele, který dobře rozumí takovým odborným výrazům, ale máme přece odborného korektora. Zde je ovšem v knize utajen nebo se nikdo takový knihou nezabýval. Tomu by kvalita odpovídala nejspíše. Četl jsem sice hůře přeložené knihy knihy, když už jsme u C#, tak třeba Programování MS Windows v jazyce C#, ale to není pro Gradu omluva. Chválím Gradu za vydání takto dobré a odborné knihy, ale prosím příště o dobrého odborného korektora. Myslím, že by se do ceny knihy schoval a pokud ne, tak bych si klidně pár desetikorun připlatil za kvalitu.

Závěr: knihu doporučuji pouze pro ty, kteří se potřebují naučit C# a .NET a jejich angličtina není dostatečná pro čtení odborných manuálů v tomto jazyku. Myslím, že čeština ještě na kvalitní referenční příručku C# a .NET čeká. Třeba jako dvě samostatné knihy.

Petr Drayton, Ben Albahari & Ted Neward: C# v kostce - Pohotová referenční příručka, www.grada.cz, 790,- Kč, 788 stran

Čína koupila od Sunů 200.000.000 Linux desktopů

Když Scott McNealy oznámil v pondělí tuto skutečnost během zásadního projevu na na Comdexu, celé publikum v Las Vegas zatajilo dech. "To nás dělá okamžitě číslem jedna v Linux desktopu na planetě", řekl dále McNealy. Cena této velké zásadní obchodní dohody pro Sun nebyla bohužel oznámena.

V rámci této dohody China Standard Software Co., společenství společností podporované čínskou vládou, koupí Java desktop System od společnosti Sun. Sun zpočátku dodá 500.000 až 1 milion licencí do konce příštího roku, ale to číslo se pravděpodobně změní na více než 200 milionů, uvedl McNealy. O Java desktop System jsem již psal 23.9.

Toto je velmi špatným znamením pro expanzi Microsoftu do Číny. Nejde samozřejmě pouze o operační systémy Microsoft Windows, ale také balík kancelářských programů MS Office, především MS Excel a MS Word. "Čína se rozhodla přejit na Linux. To nám říká, že je v Číně velmi silné anti-Microsoft smýšlení", to jasně řekl Steve Allen, analytik z Sierra Tech research ze San José. "Myslím si, že Microsoft musí mít obavy o svoji obchodní pozici mimo USA".

V září, Čína, Japonskou a Severní Korea oznámili, že společně budou pracovat na vývoji open-source alternativu operačnímu systému Microsoftu - MS Windows. Jeden z hlavních důvodů je, že MS Windows jsou příliš náchylné proti virům a hakerským útokům.

Zdroj: SF Gate

Novinky v C# IDE Whidbey

Scott Wiltamuth na PDC oznámil nové rysy v C# IDE:

1. Uživatelem definované "šablony kódu". Fungovat budou podobně jako Cut/Paste, ale lze definovat pole, která budou za pomocí IDE doplněna.
2. Formátování kódu. Formátování kódu je velmi individuální záležitostí a spornou otázkou. Předchozí verze C# IDE nedávají moc svobodu nad nastavením, jak kód formátovat. Ve Whidbey je vyvinut zcela nový výrazně jemnější systém kontroly, jak kód formátovat. Lze nastavit 80 různých voleb, kterými lze dosáhnout toho, aby kód byl formátován přesně tak, jak si přejete.
3. Refactoring: Whidbey obsahuje podporu pro běžně užívaný refactoring. Zakomponovaný refactoring je velmi spolehlivý a používá přímo kompilátor.
4. Debug vizualizer: IDE nyní dokáže použít formuláře pro zobrazení uživatelských hodnot. Pokud jste někdy ladili formulář, který zobrazuje hashtable nebo dataset, víte, že stávající model není ideální. Nové možnosti ladění programu velmi usnadní.

Novell koupil SuSE

Novell tiskovou zprávou v úterý oznámil velmi zajímavou zprávu: odkupuje za 210 milionů německou linuxovou distribuční firmu SuSE. Je to velmi zajímavá zpráva, která hodně vypovídá o skutečných záměrech Novellu do budoucna. Nedávno, jak jsem již psal, Novell zakoupil významnou vývojářskou firmu Ximian, která je tvůrcem nejen jedné ze dvou významných grafických knihoven pro Linux, GTK, ale co víc, aktuálně vyvíjí i portaci .NET platformy a programovacího jazyku C# pro Linux - Mono.

SuSE dlouhodobě spolupracovalo s IBM a tak se nám tady vytváří jedna silná opozice proti Microsoftu. Je zajímavé, že se jim podařilo se sjednotit až okolo tohoto Open Source operačního systému. Trochu je z touto tendencí v rozporu tvrzení ředitele Red Hat pana Matthewa Szulika, který Linux považuje pro desktop uživatele za nedozrálý. Na serverech ovšem bude horko a každé procento na trhu bude stát desítky milionů dolarů v marketingu.

Kdyby Novell před lety, když koupil operační systém Unixware, s tímto operačním systémem provedl to, co  bude dělat s Linuxem v kabátě SuSE, možná by dnes byl Microsoft nevýznamnou regionální firmou. Bohužel pro Novell: dvakrát do stejné řeky vstoupit nelze.

Java: TableLayout, zajímavý správce rozvržení

Java obsahuje několik správců rozvržení. S některými je práce snadná, ale mají omezené možnosti, u některých, třeba GridBagLayout, je to obráceně. Existují ovšem i jiní správci rozvržení, kteří sice nejsou přímo součástí JRE. S jedním takovým vás chci ve svém dnešním spotu seznámit.

Sun dodává jako externí JAR zajímavého a kvalitního správce rozvržení: TableLayout. Je nutné ho sice do aplikace importovat a přidat ho k ní (není součástí JRE), ale jeho výhody, především jednoduchá práce s ním, stojí za to. TableLayout pracuje tak, že plocha je rozdělena do sady řad a sloupců stejně jako u tabulkového procesoru. Komponenty se přidávají do buněk (cells). Samozřejmě při změně formuláře se přeformátují i buňky. Každá řádka může mít různou výšku. Podobně, každý sloupec může mít různou šířku. TableLayout je souměrný v ose X a Y. Vše co bude v následující textu řečeno o šířce, může platit i o výšce buněk a naopak.

Při přeformátování okna lze specifikovat, jak tím bude ovlivněna šířka a výška buněk. Například každý sloupec bude mít stejnou šířku nebo lze preferovat, že první tři sloupce budou fixovány a čtvrtý, poslední obdrží všechen zbývající prostor. Je pět způsobů, jak definovat šířku sloupce:

1. absolutní šířka v pixelech;
2. v procentech prostoru, který je k dispozici;
3. celý zbývající prostor;
4. určená preferovanou velikostí obsažených komponent v buňce;
5. určená minimální velikostí obsažených komponent v buňce.

Pro příklad přepokládejme, že chceme mít všechny sloupce se stejnou šířkou, první řádka se bude přeformátovávat s formulářem, ostatní budou mít fixní velikost:

public static void createFrame ()    {
    Frame frame = new Frame();
    frame.setBounds(100, 100, 300, 300);
    frame.show();

    double size[][] =
        {{0.25, 0.25, 0.25, 0.25},
        {50, TableLayout.FILL, 40, 40, 40}};

    frame.setLayout(new TableLayout(size));
}

Všimněte si, že vytvoření TableLayout má dva kroky. V prvním se vytvoří dvourozměrné pole typu double ve které jsou specifikovány šířky sloupců a výšky řádek. Ve druhém se vytvoří TableLayout pomocí tohoto pole. První rozměr pole obsahuje šířku každého sloupce, druhý rozměr výšku každé řádky. Šířka sloupce je specifikována jako 25% hodnotou 0.25. Všechna reálná čísla v rozsahu 0.0 až 1.0 reprezentují procenta. Pozor! Hodnota 1.0 nepředstavuje 100%, ale 1 pixel. Hodnota 0, znamená 0% nebo 0 pixelů.

Řádka 0 (první řádka), má přiděleno přesně 50 pixelů. Všechna celá nezáporná čísla odkazují na absolutní hodnotu v pixelech. Řádky 2 až 4 mají 40 pixelů. Řádka 1, určená konstantou TableLayout.FILL, vyplní tuto řádku zbývajícím prostorem.

Je možné také použít konstantu TableLayout.PREFERRED. Takový sloupec je potom široký tak, aby se do něj vešly všechny komponenty se svojí preferovanou šířkou. Například, pokud sloupec obsahuje dvě tlačítka, jedno s preferovanou velikostí 80x25 a druhé s preferovanou velikostí 50x25, sloupec bude mít šířku 80 pixelů.

Co se týká šířky/výšky při uvedení absolutní a preferované šířky/výšky buněk, tak pokud je suma měřitelných buněk menší než 100%, je zbytek rozdělen rovnoměrně mezi FILL buňky. Pokud máme tuto definici buněk:

double size[][] =
    {{100, 0.50, 0.20, TableLayout.FILL, 200, TableLayout.FILL},
   {TableLayout.FILL};

Řekněme, že formulář je 500 pixelů široký, pak budou šířky sloupců:

sloupec 0: 100 pixelů;
sloupec 1: 100 pixelů;
sloupec 2: 40 pixelů;
sloupec 3: 30 pixelů;
sloupec 4: 200 pixelů;
sloupec 5: 30 pixelů.

Měřitelné sloupce mají celkem 70% a zbývajících 30% je rozděleno mezi dva FILL sloupce.

Doufám, že jsem trochu pomohl při seznámení s tímto méně známým správcem rozvržení. Není sice přímo součástí Javy, ale díky tomu, že je s ním práce tak snadná, myslím, že stojí za to ho používat.

Pokles HTML aplikací?

Dostala se mi do rukou zajímavá studie od Giga Information Group, Inc. (GIG) pod názvem Return of the Rich Clients (česky Návrat silných/bohatých klientů). Tato studie předpokládá, že během příštích tří let poklesne zájem o HTML aplikace a stoupne zájem o tzv. Rich Clients (RC). Tyto předpoklady jsem shrnul do tabulky:

Typ klienta	2002	2005
1st Generation Rich Client	24%	6%
Stand-Alone Rich Client	7%	30%
Browser Rich Client	5%	18%
HTML	64%	46%

Tabulku je samozřejmě nutné vysvětlit. Důležité je, co GIG považuje za Stand-Alone Rich Clients. Jde o tyto technologie:

• Microsoft: Windows Forms .NET;
• Sun: J2SE/Webstart;
• Macromedia: Macromedia Central.

Browser-Based Rich Clients jsou tyto:

• Macromedia: FlashMX;
• Altio: AltioLive Platform;
• Droplets: Droplets User Interface Server;
• Curl: Curl Surge.

GIG tvrdí, že investice do aplikací, které pracují s HTML uživatelským rozhraním se stanou ztrátové, protože je převálcují technologie postavené na RC. Aplikační složitost, jako jsou nespojité operace, real-time validace a manipulace, vizualizace procesů a dat a web služby si vyžádají opět návrat RC. GIG ústup HTML aplikací o 20 procent vysvětluje neschopností vytvořit pro složité aplikační prostředí kvalitní uživatelské rozhraní. I při použití DHTML uživatelé neuspokojuje.

V jednom s s GIG shoduji, je nutné okamžitě zastavit investice do RC první generace jako jsou Delphi, VB, FoxPro, PowerBuilder apod. Zde se budoucnost jasně nevyskytuje. Tyto technologie mají jenom nevýhody, které jsou důvodem úspěchu HTML aplikací, ale žádné výhody.

GIG nabízí též alternativní pohled, ve kterém ovšem prognózu nemění, ale pouze posouvá. V případě, že ekonomické klima nebude vstřícné zavádění nových technologií, vyberou si manažeři to co vidí, že funguje a je ekonomické. To je ve většině případů HTML řešení založené na Microsoft ASP nebo Java JSP technologii. Nástup Rich Clients by to podle GIG pouze odložilo o 12-24 měsíců.

Je to samozřejmě koncepční otázka. Nejsem zdaleka tak jasně přesvědčen o tak razantním ústupu HTML aplikací. Je sice pravda, že pokud zahodíme aplikace na bázi VB a Delphi, tak v čem vlastně nové aplikace budou. Pouze HTML nestačí. Na kolbišti potom podle mne zůstanou pouze Java a NET. Macromedia technologie sice umí pěkné věci, ale myslím, že moc dobré jméno nemá. Je spojená s barevnými třpytivými graficky bohatými stránkami, kde nejčastější reakcí uživatelů je kliknutí na "Skip Intro". Já osobně mám v prohlížeči (Mozilla) FlashMX vypnuté, protože jediné co se mi pomocí této technologie zobrazuje jsou reklamy a ty nesleduji. Macromedia Central je sice schopna práce mimo prohlížeče, ale "starého psa novým kouskům nenaučíš".

GIG neuvedl u HTML jeden důležitý aspekt. Je jím schopnost HTML uživatelské rozhraní kvalitně zobrazit i na mimo-PC zařízeních. Pokud dojde v blízké budoucnosti k masivnímu nástupu zařízeních, na kterých nebude implementována Java/NET, HTML technologie naopak vzroste.

Položme si také otázku: co vlastně chtějí uživatelé? Jednoduché, až primitivní rozhraní pomocí HTML nebo vyspělé klienty? Zpravodajský server Lupa ve svém článku Freemaily pod lupou uvedl, že u freemailu Atlas.cz 75 procent uživatelů čte své emaily přes web (15% pomocí POP3 a 10% přes IMAP). Proč? Každý přece může zdarma používat velmi kvalitní email klienty.

Java a hry

Rád bych upozornil na velmi zajímavou hru Yohoho! Puzzle Pirates. Je to sice dost stahování (funguje i přes Java Web Start), hra je v angličtině, ale je na ní něco velmi zajímavého: je totiž celá v Javě a je nejen velmi hezká, ale dokonce i dobře hratelná. Názory, že pomocí Swingu nelze napsat použitelný a hezký program jsou nepravdivé. Zde je důkaz. Java je dnes nejen dobrou platformou pro psaní web aplikací, ale dají se v ní psát i hry a to nejen pro mobilní zařízení, ale i pro PC.

Novinky v C# - generické typy

Více sofistikovaní programátoři potřebují prostředky k lepšímu opětovnému použití již napsaného kódu. Aby kód bylo možno znovu použít, programátoři typicky užívají rys, kterému se říká generické typy. C# bude v příští verzi obsahovat typově bezpečné vysoce výkonné generické typy, které se mírně liší v syntaxi a velmi v implementaci od šablon, jaké používá programovací jazyk C++ a generické typy, které budou obsaženy v nové verzi jazyku Java.

Dnes mohou programátoři v C# použít omezenou verzi generických typů ukládajících data v instancích založených na objektových datových typech. Bohužel tam jsou výkonové sankce za konverzi mezi referenčními, hodnotovými objektovými datovými typy. Pro ilustraci necháme vytvořit jednoduchý  datový typ zásobník se dvěmi akcemi: Push a Pop:

public class Stack    {
    private object[] items = new object[100];

    public void Push(object data)    {
    ...
    }

    public object Pop()    {
    ...
    }
}

Do zásobníku potom můžeme ukládat náš vlastní datový typ, například Customer. Pokud potřebujeme data získat ze zásobníku zpět, musíme data přetypovat ze základního typu object na typ Customer.

Stack s = new Stack();
s.Push(new Customer());
Customer c = (Customer) s.Pop();

Jestliže do zásobníku uložíme hodnotový typ, například integer, dojde k automatické přeměně na objektový referenční typ. Tomuto procesu se říká boxing. Podobně, když chceme získat ze zásobníku zpět hodnotový typ, například stejně jako před tím integer, obdržíme od metody Pop(), hodnotový datový typ. Tomuto se říká unboxing.

Stack s = new Stack();
s.Push(3);
int i = (int) s.Pop();

Boxing a Unboxing operace mohou být v některých případech velmi nevýhodné a nákladné. V současné implementaci C# není možné zjistit typ dat uložených v zásobníku. Následkem toho můžeme například do zásobníku uložit data typu Customer a pokusit se z něj vybrat data jiného typu:

Stack s = new Stack();
s.Push(new Customer());
Employee e = (Employee) s.Pop();

Výše uvedený kód sice znamená nesprávné použití třídy Stack, ale z hlediska kompilátoru jde o platný kód a kompilátor nebude při překladu nijak protestovat. Teprve při běhu programu aplikace selže.

Generické typy poskytnou možnost k vytvoření výkonných datových struktur, jejichž použití bude schopen kontrolovat již kompilátor. Tyto takzvané parametrizované typy jsou vytvořené tak, že jejich vnitřní algoritmy zůstávají stejné, ale vlastní typ dat je specifikován programátorem. Aby se programátoři nemuseli učit novou syntaxi, generické typy v C# jsou deklarovány velmi podobně jako v C++. Třídy a struktury se vytvářejí stejně jako před tím a mezi znaky < a > se uvádějí typové parametry. Když jsou potom použity, každý tento parametr je nahrazen příslušným datovým typem, který zadal programátor.

V následujícím příklady vytváříme zásobníkovou třídu, kde specifikujeme typový parametr ItemType. Je deklarován v závorkách < a > jako součást deklarace třídy.

public class Stack<ItemType>    {
    private ItemType[] items;

    public void Push(ItemType data)    {
    ...
    }

    public ItemType Pop()    {
    ...
    }
}

Když použijeme třídu Stack jako v krátkém příkladu níže, můžeme specifikovat aktuální datový typ, který má být užit touto třídou používající generické typy. V tomto případě instruujeme třídu Stack použít primitivní datový typ integer.

Stack<int> stack = new Stack<int>;
stack.Push(3);
int x = stack.Pop();

Použitím generických typů jsme získali několik velmi významných výhod. Vyhnuli jsme se nákladnému boxingu a unboxingu a kompilátor zachytí chybu při  vložení/vyjmutí dat nesprávného typu - nemusíme čekat až tato situace nastane při vlastním chodu aplikace.

V případě, že do zásobníku nechceme ukládat primitivní data typu integer, ale třeba objekty typu Customer, stačí změnit kód takto:

Stack<Customer> stack = new Stack<Customer>;
stack.Push(new Customer());
// stack.Push(3); // vyvolá kompilační chybu
Customer c = stack.Pop(); // žádné přetypování není zapotřebí

Generické typy programátorům dovolí vytvořit a testovat kód pouze jednou a znovu použít pro jakékoliv typy. Navíc v případě hodnotových typů je použití generického uložení dat mnohem výkonnější, protože se vyhneme boxingu a unboxingu a přetypování. Generické typy vedou k rychlejšímu a přehlednějšímu kódu.

Generické typy mohou užívat jakékoliv množství typů. V našem příkladu jsme použili pouze jeden datový typ. Předpokládejme, že jsme vytvořili jednoduchou Dictionary třídu, ukládající hodnoty klíčů. Nyní můžeme definovat generickou verzi třídy s deklarací pro dva parametry, které jsou oddělené čárkami uvnitř lomených závorek:

public class Dictionary<KeyType, ValType>    {
    public void Add(KeyType key, ValType val)    {
    ...
    }

    public ValType this[KeyType key]    {
    ...
    }
}

Při instanci třídy Dictionary musíme předat dva parametry uvnitř lomených závorek, které jsou odděleny čárkami. Tím stejně jako u jednoho parametru předáváme skutečné typy pro použití třídy:

Dictionary<int, Customer> dict = new Dictionary<int, Customer>;
dict.Add(3, new Customer());
Customer c = dict.Get[3];

Design těchto rysů ještě není dokončený a mohou se změnit. Podle Microsoftu budou generické typy zřejmě obsaženy ve verzi Visual Studio Yukon.

Porovnání rychlosti Javy na MS Windows a Linuxu a srovnání s C# a C

Zajímalo mne jak je na tom ve skutečnosti Java s výkonností na Linuxu a MS Windows. Provedl jsem proto spoustu testů a aby to nebylo málo, zahrnul jsem i programovací jazyky C a C#. Testy nejsou odtržené od skutečných aplikací. Nejde o žádné teoretické matematické výpočty, ale o příklady ze skutečných aplikací. Byly převzaty ze serveru http://dada.perl.it/shootout/ a zahrnují různé výpočty od Ackermannovy funkce, přes  heše po implementaci Spell Checkeru. Myslím, že tyto testy měří skutečnou rychlost zvolené technologie.

Pokud má někdo zájem o zdrojové kódy pro kontrolu, stačí mi napsat. Každý test byl proveden 3x a výsledek byl vypočítán průměrem z těchto tří hodnot. Měření délky chodu programu bylo prováděno pomocí GNU utility time, která je k dispozici pro oba použité operační systémy. Tento způsob měření samozřejmě nejvíce znevýhodňuje Javu, která je známa svou delší dobou startu programů.

Testy vždy zobrazují délku jejich provádění v sekundách a potom procentuální výsledek dvou technologií. Pod každou tabulkou najdete podrobnější vysvětlení - doufám, že dostatečné. Zajímavý výsledek je například u Ackermann funkce. Zde je Java na platformě MS Windows naprosto nepřekonatelná a je zdaleka nejrychlejší ze všech technologií včetně jazyka C. Vysvětluji si to tak, že je použito některé z navrhovaných typů kešování výsledků funkce v rámci JVM. Nečiním si nároky na univerzální výsledky, ale žádné velké chyby v testování doufám nejsou - věnoval jsem tomu spoustu času.

Použitý software:

• MS Windows 2000 SP 4;
• Linux Mandrake 9.1;
• MS Windows - java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode);
• Linux - java version "1.4.2_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06) Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode)
• gcc version 3.3.1 (cygming special).
• GNU time 1.7

Použitý hardware:

Neznačkový počítač, 512 MB RAM, AMD Athlon 1200 MHz, DRAM 133 MHz, HD WDC WD400BB.

MS Windows Java vs. Linux Java
Test	MS Windows (s)	Linux (s)	Linux (%)
Ackerman	0.25	0.83	336.49
Array access	0.30	0.26	87.64
Count Lines/Words/Chars	0.21	0.20	93.75
Echo client/server	7.55	4.30	56.98
Exception	1.55	2.45	157.73
Fibonacci numbers	0.26	0.26	100.00
Hash (Associative Array) Access	2.52	3.65	144.65
Hashes, part 2	1.31	1.28	97.71
Hello world	0.21	0.19	90.48
List Operations	8.32	8.81	105.89
Matrix Multiplication	7.85	8.33	106.16
Method Calls	8.35	9.09	108.86
Nested Loops	5.54	5.17	93.32
Object Instantiation	7.67	8.07	105.17
Producer/Consumer Threads	6.47	16.17	249.79
Random Number Generator	7.97	8.68	108.95
Reverse a File	3.52	3.58	101.70
Sieve of Erathostenes	8.27	8.11	98.07
Spell Checker	0.78	0.76	97.44
Statistical Moments	0.37	0.27	72.97
String Concatenation	0.82	0.81	98.78
Sum a Column of Integers	0.30	0.23	76.67
Word Frequency Count	0.54	0.56	103.07
Průměr			117.05
Průměr bez Ackerman			107.08

Poznámky k tabulce:

• MS Windows (s): doba provádění programu v Javě na MS Windows v sekundách.
• Linux (s): doba provádění programu v Javě na Linuxu v sekundách.
• Linux (%): procentuální rychlost provádění programu v Javě na Linuxu vůči Javě na MS Windows. Hodnota menší jak 100 znamená kratší čas provádění a tedy vyšší rychlost provádění programu v Javě na Linuxu.

Java versus C# (MS Windows)
Test	Java (s)	C# (s)	C# (%)
Ackerman	0.25	0.71	289.19
Array access	0.30	0.24	80.90
Count Lines/Words/Chars	0.21	0.13	62.50
Echo client/server	7.55
Exception	1.55	2.75	176.82
Fibonacci numbers	0.26	0.16	62.82
Hash (Associative Array) Access	2.52	0.90	35.54
Hashes, part 2	1.31	2.82	215.27
Hello world	0.21	0.10	46.03
List Operations	8.32	0.25	2.96
Matrix Multiplication	7.85	14.24	181.48
Method Calls	8.35	4.24	50.74
Nested Loops	5.54	5.16	93.08
Object Instantiation	7.67	1.47	19.11
Producer/Consumer Threads	6.47	9.89	152.73
Random Number Generator	7.97	6.16	77.32
Reverse a File	3.52	1.04	29.45
Sieve of Erathostenes	8.27	14.70	177.75
Spell Checker	0.78
Statistical Moments	0.37	0.15	39.64
String Concatenation	0.82	0.29	35.37
Sum a Column of Integers	0.30	0.11	35.56
Word Frequency Count	0.54
Průměr			93.21
Průměr bez ackermana			82.90

 Poznámky k tabulce:

• Java (s): doba provádění programu v Javě na MS Windows.
• C# (s): doba provádění programu v C#.
• C# (%): procentuální rychlost provádění programu v C# proti programu v Javě na MS Windows. Hodnota menší jak 100 znamená kratší čas provádění a tedy vyšší rychlost programu v C#.
• U prázdných políček nebyl test proveden. Většinou proto, že jsem neměl k dispozici zdrojové kódy.

Java a C# versus C (MS Windows)
Test	Java (s)	C# (s)	C (s)	Java (%)	C# (%)
Ackerman	0.25	0.71	0.40	61.67	178.33
Array access	0.30	0.24	0.04	741.67	600.00
Count Lines/Words/Chars	0.21	0.13	0.02	1 066.67	666.67
Echo client/server	7.55		9.85	76.62
Exception	1.55	2.75	0.05	3 106.67	5 493.33
Fibonacci numbers	0.26	0.16	0.51	50.98	32.03
Hash (Associative Array) Access	2.52	0.90	0.77	327.71	116.45
Hashes, part 2	1.31	2.82	0.69	189.86	408.70
Hello world	0.21	0.10	0.02	1 050.00	483.33
List Operations	8.32	0.25	0.10	8 320.00	246.67
Matrix Multiplication	7.85	14.24	2.36	332.49	603.39
Method Calls	8.35	4.24	9.78	85.38	43.32
Nested Loops	5.54	5.16	2.33	237.77	221.32
Object Instantiation	7.67	1.47	19.04	40.30	7.70
Producer/Consumer Threads	6.47	9.89	8.51	76.07	116.18
Random Number Generator	7.97	6.16	1.22	653.01	504.92
Reverse a File	3.52	1.04	0.12	2 933.33	863.89
Sieve of Erathostenes	8.27	14.70	4.27	193.68	344.26
Spell Checker	0.78		0.14	557.14
Statistical Moments	0.37	0.15	0.06	616.67	244.44
String Concatenation	0.82	0.29	0.15	546.67	193.33
Sum a Column of Integers	0.30	0.11	0.06	500.00	177.78
Word Frequency Count	0.54		0.06	905.56
Průměr				985.65	577.30
Průměr bez Object Instantiation				1 026.75	607.28

Poznámky k tabulce:

• Java (s): doba provádění programu v Javě na MS Windows v sekundách.
• C# (s): doba provádění programu v C# v sekundách.
• C (s): doba provádění programu v C na MS Windows v sekundách.
• Java (%): procentuální rychlost provádění programu v Javě na MS Windows vůči C na MS Windows. Hodnota menší jak 100 znamená kratší čas provádění a tedy vyšší rychlost provádění programu v Javě.
• C# (%): procentuální rychlost provádění programu  v C# vůči C na MS Windows. Hodnota menší jak 100 znamená kratší čas provádění a tedy vyšší rychlost programu v C#.
• U prázdných políček nebyl test proveden. Většinou proto, že jsem neměl k dispozici zdrojové kódy.

Závěr: Java provozovaná na počítači s operačním systémem Linux je dnes naprosto plnohodnotnou alternativou. Jediným kazem na tomto tvrzení jsou vlákna. Zde by ovšem verze 1.5 Javy pro Linux měla být mnohem lépe navržená. Pokud vím, tak Sun spolupracuje s Red Hat na nové verzi implementaci vláken u Linuxu. Uvidíme.

Překvapením je pro mne dobrý výkon Javy proti C#. Je vidět, že technologie jako Hot-Spot a JIT kompilace u Javy skutečně poskytují výsledky. Java je sice pomalejší než program napsaný v C#, ale rozdíl není ani 20%. To musí být pro vývojáře Microsoftu velkým zklamáním. Nesmíme zapomenout na to, že Java programy běží v rámci tzv. virtuálního počítače, který sice usnadňuje implementaci JRE na různé platformy, ale z pochopitelných důvodů jsou programu pomalejší.

Programy v C jsou většinou rychlejší. Jakékoliv zprávy, které uvádějí, že Java dohání a předhání jazyk C jsou nepravdivé a tendenční. Ještě asi pár let ovladače a operační systému budou psány v tomto na rychlost nepřekonatelném jazyku. Zdrojové kódy v jazyce C ale mnohem rozsáhlejší a samozřejmě mnohem nepřehlednější než zdrojové kódy v Javě a C#. V C bych velký projekt dnes psát nechtěl. Byl by sice rychlejší, oproti Javě dokonce 10x, ale nevím zda bych ho byl schopen dokončit a odladit.

Editorial: velký test Javy na Linuxu a Windows

Dnes žádný spot nebude. Mám moc práce s přípravou testu ve kterém srovnávám Javu na Linuxu a MS Windows z hlediska rychlosti. Aby bylo porovnání co nejvíce užitečné zahrnuji i stejné testy pomocí programovacího jazyku C a C#. Test bude pravděpodobně zveřejněn zítra, tj. v pátek.

Novinky v Javě 1.5 (Tiger)

Stručná historie Javy:

• JDK 1.0: uvedení jazyku na trh;
• JDK 1.1: vnitřní třídy, nový model událostí;
• JDK 1.4: asserce, minoritní změny;
• JDK 1.5 (ve vývoji): největší změny jazyka od uvolnění.

To, že Javě vyrostla konkurence v jazyce C# v oblastech ve kterých se nakonec po hledání vlastní tváře etablovala je zřejmé. Zřejmé je také to, že vývojáři firmy Sun, kteří mají Javu na starosti si to uvědomují také. Java 1.5 s pracovním označením Tiger se tedy bude především vyrovnávat s Microsoft platformou .NET a snažit se nenechat si ji přerůst přes hlavu. Přenositelnost na jiné operační systémy je sice velmi zajímavá, ale stále zde máme dobu, kdy na 98 % osobních počítačů je nainstalován některý z operačních systémů firmy Microsoft. Přenositelnost Javě pro úspěch nestačí.

Podívejme se tedy na hlavní novinky v Javě verzi 1.5:

Automatické převody (autoboxing primitivních typů)

Jazyk bude doplněn o automatické převody mezi primitivními typy a jejich objektovými ekvivalenty.

Integer intObj = 22;     // Nový typ převodu
int i = (int)intObj;     // Starý typ převodu
ArrayList al = new ArrayList();
al.add(22);          & nbsp;   // Nový typ převodu

Proměnný počet parametrů u metod

Metody nyní budou moci mít proměnný počet argumentů. Poslední argument v seznamu argumentů v deklaraci metody bude mít v tomto případě tvar Typ...JmenaParametru. V případě, že parametry budou mít rozdílný typ, stačí použít společného předka, např. Object.

Typově bezpečný enum (výčtový typ)

V podstatě jde pouze o nový typ třídy, která v deklaraci obsahuje klíčové slovo enum. Tato třída obsahuje definici jednotlivých hodnot výčtového typu a samozřejmě může obsahovat navíc další metody a vlastnosti. enum je jediné nové klíčové slovo, které v zřejmě v Javě přibude.

Převzatý příklad na americké mince z java.sun.com:

public enum Coin {
    penny(1), nickel(5), dime(10), quarter(25);
    Coin(int value) { this.value = value; }
    private final int value;
    public int value() { return value; }
}
public class CoinTest {
    public static void main(String[] args) {
        for (Coin c : Coin.VALUES)
            System.out.println(c + ":   \t"
                   + c.value() +"¢ \t" + color(c));
    }
    private enum CoinColor { copper, nickel, silver }
    private static CoinColor color(Coin c) {
        switch(c) {
          case Coin.penny:   return CoinColor.copper;
          case Coin.nickel:  return CoinColor.nickel;
          case Coin.dime:
          case Coin.quarter: return CoinColor.silver;
          default: throw new AssertionError("Unknown coin: " + c);
        }
    }
}

Vylepšení práce s kolekcemi

Kolekce neboli kontejnery jsou velmi důležitou součástí každého vyššího programovacího jazyku. Kontejnery známe statické (v Javě pole) a dynamické (v Javě např. HashMap). Do kontejneru se v Javě a dalších jazycích neukládají objekty se kterými pracujeme, ale jejich super-předci, v Javě objekt typu Object. Toto řešení má bohužel několik problémů z nichž hlavní je ten, že kolekce pak nemůže umět provádět typovou kontrolu a při práci s objektem uloženým v kolekci je nutné ho na správný typ přetypovat. Java sice umí toto přetypování kontrolovat, ale pouze při chodu programu. To není moc výhodné: chod programu je pomalejší a programátor není upozorněn na chybu již při kompilaci.

V Javě 1.5 je tento problém řešen generickými typy. Tyto generické typy se syntakticky budou zapisovat pomocí hranatých závorek < a > a při chybě přetypování tuto chybu zachytí již kompilátor. Například Iterator bude označen typem Integer:

Iterator<Integer> listIterator = integerList.iterator();

V případě, že potom přiřadíte listIterator jinému objektu než typu Integer (a obráceně), vyvolá překladač chybu.

Starý kód:
List l = new LinkedList();
l.add(new Integer(0));
Integer i = (Integer)l.iterator.next();


Nový kód:
List<Integer> l = new LinkedList<Integer>();
l.add(0); // Použití automatických převodů
Integer i = l.iterator.next();

Bude vytvořen nový cyklus založený na cyklu for, který dovolí procházet kontejnery včetně polí bez použití přetypování:

Starý kód:

void cancelAll(Collection c) {
    for (Iterator i = c.iterator(); i.hasNext(); ){
        TimerTask task = (TimerTask)i.next();
        task.cancel();
    }
}

Nový kód:

void cancelAll(Collection<TimerTask> c) {
    for (TimerTask task : c)
        task.cancel();

Metadata

Při vytváření určitého typu kódu je nutné mechanicky vytvářet podpůsrný kód. Například je často nutné vytvářet definice rozhraní a při změně kód se musí opravit i toto rozhraní. Metadata by tuto práci měla zautomatizovat. Toto rozšíření Javy je zatím nejméně jasné a veřejně není k dispozici žádný kód, který by prezentoval jeho možnosti.

@remote getPrice(Product p);

Sun slibuje ještě tyto další vylepšení:

• 25-ti procentní zrychlení startu programů proti verzi 1.4.0;
• asynchronní I/O;
• nesynchronizovaná třída StringBuffer;
• neblokující ekvivalent tříd SSLSocket a SSLServerSocket;
• snížení paměťové náročnosti JVM;
• zvýšení rychlosti classloaderu;
• souběžně běžící Java aplikace budou sdílet JVM.

Celkově lze hodnotit novinky Javy ve verzi 1.5 pozitivně. Myslím, že je to velký krok kupředu tohoto skvělého programovacího jazyku. Čím více práce je přesunuto z programátora na kompilátor, tím lépe. 

Sun Tech Day

Sun pořádá dne 18. listopadu 2003 v Kongresovém centru Praha Sun Tech Day Praha.

Na adrese http://www.sun.cz/techday se lze zaregistrovat a získat další informace. Vzhledem k tomu, že účast je zdarma, doporučuji se zúčastnit. Žádné daší informace určitě neuškodí a tohle je jeden z nekvalitnějších zdrojů o Javě.

Kniha: Programování Microsoft Windows v jazyce C# (Petzold Ch.)

Kniha je zajímavá tím, že je vydána v takové zvláštní krabici z tvrdého papíru, která obsahuje dvě knihy a další papírovou krabici s CD-ROM. Na CD-ROM jsou zdrojové příklady ke knize a je na něm 4.28 MB dat. Dnes v době Internetu považuji takovéto CD-ROM, které jehož obsah si každý může stáhnout z Internetu, za nesmysl. Kniha je potom zbytečně drahá a navíc, CD-ROM se dobře ztrácejí, kdežto z Internetu si zdrojové kódy mohu kdykoliv stáhnout.

Charles Petzold je zkušeným autorem o programování v operačním systému MS Windows. Má velmi dobré pero a navíc problematice viditelně dobře rozumí a dokáže ji srozumitelně vysvětlit.

Kniha se velmi podrobně věnuje programování v MS Windows od od základního textového výstupu až po tvorbu vlastních komponent. Nejde ani tak o manuál programovacího jazyku C#, ale především o programování pod MS Windows. Velmi detailně je vysvětleno kreslení jako čáry, křivky, výplně ploch, obrázky, křivky, štětce, pera, písma, tisk a podobně. Samozřejmě jsou věnovány kapitoly i textu, tvorbě menu a jednotlivým komponentám od tlačítek přes posuvníky až po TreeView. Samozřejmě není zapomenuto na ovládání myši a klávesnice. Nechci zde vyjmenovávat všechny kapitoly, ale problematika MS Windows je vysvětlena naprosto dostatečně a do velké hloubky. Kniha navíc obsahuje tři dodatky popisující programování souborů a proudů, třídu Math a teorii řetězců. Kniha není popisem jak přetahovat na formuláře jednotlivé komponenty a programovat pomocí myši. Jde minimálně o jednu úroveň hlouběji a obsahuje proto velmi důležité informace a postupy.

Bohužel jsem z knihou nemohl být spokojen. Překlad je neuvěřitelně špatný. Místy tématika nedává smysl a některé věty jsou nerozluštitelné. Používat například místo přetížení funkce výraz převážení funkce svědčí o tom, že překladatel a odborný korektor o objektovém programování vůbec nic netuší.

Závěr: knihu bohužel přes její kvality nemohu doporučit. Překlad a odborná korektura je tak zoufalá, že místy znemožňuje knihu použít jako kvalitní zdroj informací, což v originálu nepochybně je. Na Amazon.com stojí kniha v originále $41.99 a pokud dobře vládnete anglickým jazykem, nebude to špatná investice. Doufal jsem, že nakladatelství Softpress touto knihou vylepší mé mínění o jejich knihách, ale nestalo se.  Výběr titulu byl sice špičkový, ale zpracování je amatérské.

Charles Petzold: Programování Microsoft Windows v jazyce C#, www.softpress.cz, 990 Kč, 600 + 608 stran + CD ROM

Binární data v XML

Na zajímavý článek Akta X 0309 o binární verze XML na Root.cz mne přivedl Roman Pichlík ve na svém weblogu Dagblog. Asi jsem na článku něco významného nepochopil, ale myslím, že se jedná u binárních dat ne o jeden, ale o dva samostatné problémy.

1. Jak vložit do XML souboru binární data.
2. Jak převést XML soubor na binární formát.

První problém je možná významnější. Samozřejmě lze každý binární formát převést na XML. Je otázkou zda je to potřebné a především efektivní. Například u vektorové graficky mi to připadá velmi rozumné, ale u bitmapové už vůbec ne. Na druhé straně je ovšem nutné nějak binární data uložit. Mám trochu pocit, že se dělá velbloud z komára. Stačí přece data uložit do externího souboru a do XML souboru na ně dát odkaz. Pak už je pouze problém v rozšíření XML standardu při komunikaci třeba mezi službami, které si XML data předávají.

Druhý problém nepovažuji za významný. Je fakt, že nám XML data kynou a jejich zpracování může být pro počítače náročnější. Vlastní velikost nepovažuji za významnou. Již jsem viděl několik programů, z nejznámějších OpenOffice.org, které data uloží do XML a potom je zkomprimují třeba pomocí ZIP algoritmu. Vlastní rychlost zpracování pomocí XML parseru (třeba SAX) je věcí druhou. U rozsáhlých dokumentů se jedná o věc výpočetně náročnou a pokud je tok XML dokumentů ke zpracování větší, mohou nastat problémy. To se ovšem u tak lidsky čitelného formátu jako je XML dalo při tvorbě standardu očekávat. Pokud W3C konsorcium nyní "objeví Ameriku" a vytvoří formát standard binárního XML, rád je uvítám u nás v Kocourkově.

Já bych raději upřednostnil zůstat u lidsky čitelného formátu, než binárního. Těch pár aplikací, které mají nepřekonatelný problém s rychlostí parsování XML bych přepsal na použití nějakého speciálního binárního formátu . Myslím, že ve skutečnosti jich moc nebude. Bohužel na to mám vliv asi stejný jako na otáčení zeměkoule.

Co dnes využít pro tvorbu web aplikace? Javu nebo C#?

Pokračování spotu: Co dnes použít při vývoji desktop aplikace? Javu nebo C#? U web aplikací je úplně jiná situace než u aplikací určených pro desktop. Web aplikace běží oproti desktop aplikaci na serveru a klient ji ovládá pomocí browseru (prohlížeč Internetu). Obě řešení mají své výhody:

Desktop aplikace má oproti web aplikaci tyto výhody:

• Klientský počítač nemusí být neustále připojen k síti a k serveru.
• Vzhled aplikace může být mnohem bohatší a především ovládání aplikace může být mnohem intuitivnější a snadnější. I při použití prostředků DHTML jsou web aplikace mnohem hůře ovladatelné.

Naopak web aplikace má proti desktop aplikaci tyto výhody

• Klientský počítač může být jakékoliv zařízení na kterém lze spustit browser. Nemusí jít vůbec o PC, ale třeba o mobilní telefon nebo televizi. V případě mimo PC nasazení ovšem nastávají problémy s rozlišením a schopností dodržet potřebné standardy ((X)HTML, Javascript, cookies,...).
• Snadnější operativnost pro aplikace provozované pomocí outsourcingu.
• Na počítači může být nainstalován libovolný operační systém, na který byl portován alespoň jeden kvalitní browser. Všechny rozšířené (pokud vím) operační systémy tuto vlastnost splňují. V současné době je nejrozšířenějším browser Microsoft Internet Explorer a nejvíce podporuje standardy Mozilla. Lze dokonce napsat takovou web aplikaci, která bude schopna pracovat i s textovými browsery, jako například Links.
• HW nároky na klientský počítač jsou mnohem nižší než u desktop aplikace.

Každé z těchto dvou řešení je je velmi závislé na mnoha otázkách. Zde jsou některé důležité:

1. Jaký je typ aplikace (textový editor, hra, jednoduchý formulář, redakční systém, účetnictví, email klient,...)?
2. Jaké jsou pracovní stanice (staré PC, nové a dobře vybavené PC, tablety, mobilní telefony,...)?
3. Odkud budou klienti přistupovat (kancelář, výrobní hala, hotel mimo areál, vozidlo mimo areál, ...)?
4. Budou klienti přistupovat k aplikaci pouze z jednoho zařízení nebo z více?
5. Jaké jsou ergonomické nároky uživatelů?

Rychlost aplikace: v případě, že web aplikace běží v rámci Internetu a klientská stanice je výkonný osobní počítač, bude se chovat rychleji desktop aplikace. V případě, kdy aplikace běží v rámci intranetu, kde lze zajistit vysokou propustnost a server je výkonný počítač a naopak pracovní stanice má slabý HW, bude web aplikace významně rychlejší. Další, zde neřešený aspekt rychlosti je způsob uložených dat (SQL server, lokálně apod.).

Podrobně jsem se tímto rozhodováním zaobíral ve spotu Desktop (Swing) versus web aplikace. Pro dnešní spot předpokládejme, že vybrána byla web aplikace. Nyní je na čase vybrat kterou technologii zvolit. Dle titulku tohoto spotu se budeme rozhodovat mezi web aplikací pomocí Microsoft .NET nebo pomocí Javy. Java má v tomto ohledu mnohem delší tradici. Microsoft přišel s .NET technologií teprve v roce 2001 a tehdy již spousty bank a velkých a malých firem měly postavené své informační systémy na bázi J2EE, což je implementace Javy technologií pro server.

Obě technologie, Java i .NET (C#) jsou moderní. Mají všechny potřebné prvky a vymoženosti, které lze při současném stupni poznání a znalostech o efektivitě nabídnout. Obě technologie mají za sebou silné a zkušené firmy. Sun má sice dnes jisté potíže, ale i v nejhorším případě je v záloze IBM a Apple.

Výhody Javy

• Jde o ověřené a spolehlivé řešení.
• Existuje několik konkurenčních aplikačních serverů, z nichž jeden (JBoss), který je velmi kvalitní, je dokonce Open Source.
• Existuje několik kvalitních vývojových prostředí a nichž jich je valná část Open Source.
• Celá technologie je dostupná pro všechny operační systémy, které přicházejí jako web servery v úvahu. Operační systémy MS Windows nemají na serverech zdaleka takovou převahu jako na desktopech. Vlastní technologie Javy je například pro Linux k dispozici dokonce ode dvou výrobců: Sun Microsystems a IBM.
• Jednotlivá sezení lze předávat nejen pomocí cookies, ale i pomocí URL. .NET v této verzi umí pouze pomocí cookies.
• .NET neumí vytvářet obdobu .war souborů Javy.

Výhody .NET a C#

• "Velmi lehce" kvalitnější programovací jazyk C# proti Javě.
• Pokročilejší programování na straně serveru: existují komponenty, které mapují jednotlivé HTML a ověřovací prvky. Dle prohlížeče se dynamicky zvolí, zda použít HTML 3.2 nebo DHTML. Tato výhoda může být pro někoho nevýhodou, protože toto rozhodování se nemusí chovat spolehlivě pro různé browsery a doba dominance MSIE se rychle blíží ke konci.

V případě řešení na bázi Microsoftu zcela jasně vybírám programovací jazyk C#. Visual Basic je pozůstatkem minulosti a byl zachován především, aby v něm zkušení programátoři nezměnili platformu. C++ není zdaleka z hlediska produktivity programování tak efektivní jako C# a J# je výkřikem proti Javě. C# není ovšem žádným ořezávátkem. K dnešnímu dni ho lze považovat za nejpokročilejší jazyk pro platformu PC. Java mu sice šlape na paty, ale v některých drobnostech je pozadu.

Závěr: pro mne je v tuto chvíli pro programování web aplikací jednoznačným vítězem Java. Situace je mnohem jasnější, než u desktop aplikací. U těchto aplikací je pro Javu nejslabším článkem Swing, který u web aplikací nehraje roli. Pro mne jsou dvěmi hlavními důvody dokonalá přenositelnost a ověřená spolehlivost řešení. Konkurence Java technologií včetně Open Source variant je velmi pěknou třešničkou na dortu.

Avalon a Java

Nový operační systém od Microsoftu - Longhorn obsahuje nové API, které má programátorům usnadnit práci. Počet volání API oproti Win32 bude zeštíhlen zhruba ze 70.000 na 8.000. Toto nové API má pracovní název Avalon. Avalon má být také založen na XML, ale přiznávám, že si nějak nedovedu představit co to přesně znamená. Samozřejmě se tím zásadně změní vzhled operačního systému i nejpoužívanějšího kancelářského balíku Office, jehož nová verze bude napsána též pomocí Avalonu.

Jaký to bude mít dopad na Javu? Bohužel asi nepříjemný. Pro programování na desktopu se Swing vzhled Javy stane ještě více staromódní, než je dnes. Uživatelům nejen, že bude připadat staromódní, ale budou jím zaskočeni a práce s programy ve Swingu se pro ně může stát nepříjemnou.

Sun má vážné potíže, co bude s Javou?

Je veřejným tajemstvím, že firma Sun Microsystems má vážné potíže. Její akci klesly dokonce na $3.31 a to samozřejmě pro Sun není dobré. Analytici doporučují výrazné šetření a propouštění. Nejsem finanční analytik, ale ptám se co bude s Javou a odpovídám si, že není třeba mít o tento programovací jazyk strach. Sice se objevilo několik veřejných výzev, hlasovaní, bojkotů a podobných akcí, které všechny mají jedno společného: firmo Sun, uvolni Javu jako Open Source. Myslím, že vedení Sun Microsystems by bylo šílené, kdyby něco takového udělalo. Java je dnes pro Sun když ne to nejcennější, tak alespoň rodinné stříbro. Třeba se bude slučovat, třeba ji někdo koupí a teď dávat z rukou Javu by byl velmi špatný obchodní tah. Takto cenná věc se nezahazuje, vždyť se dá třeba prodat.

Může firma Sun Microsystems zaniknout? Myslím, že ne. Vzpomeňte na Lotus, Netscape, Informix. Všichni byli zakoupeni nebo převzati, tak funguje kapitalismus. Dokonce Enron a Worldcom jako korporace stále fungují.

I kdybychom přesto předpokládali, že Sun Microsystems zanikne, je zde IBM, HP, Apple a tisíce dalších společností, které investovali obrovské částky do Javy a nikdo rozumný přece nebude předpokládat, že oni jen tak tyto investované peníze odepíšou. Akcionáři těchto společností by takové vedení okamžitě odvolalo. Kolik velkých světových bank má napsáno své systémy v Javě? Kolik společností majících cenu miliard dolarů mají technologie založené na Javě? Budou se jenom dívat a za svými penězi jenom spláchnou. Všechno zahodí a přejou na Python nebo C#? Zánik Sunu, pokud nastane, bude jenom obrovskou příležitostí pro další firmy jak vydělat další peníze. Tak také funguje kapitalismus.

Nezapomeňme prosím také na OpenOffice.org. Tento skvělý kancelářský balík, jehož nová verze 1.1 byla v těchto dnech uvedena, je aktuálně jedinou reálnou konkurencí pro kancelářský balík Microsoftu - Office. Také bude také jenom zahozen a zanikne? To by přece nedávalo smysl.

Editorial: spoty a je to vůbec weblog?

Tak jsem se dozvěděl, že to co píšu nejsou články, ale spoty. To jsou věci. Do teď jsem si myslel, že spoty je něco v televizi. Asi se budu muset podívat do slovníku.

Také prý to co píši není weblog. Články, tedy vlastně spoty jsou moc dlouhé. Kašlu na to, je mi to jedno. Je to jako ty neustálé připomínky ke gramatice. Někde chybí čárka, někde je místo tvrdého měkké. Vážení Phd. českého jazyka, nechci vás urážet, ale důležitý je obsah. Forma je dalece za ní. Čím je gramatika složitější, tím větší energii a duševní úsilí musím vynaložit na to, abych to napsal dobře a ne na to co píši. Zlaté programovací jazyky. Tam je vše (většinou) logické a (většinou) tam není nic zbytečného. U češtiny není (většinou) logické nic a zbytečností je tam (většinou) většina.

Java na AbcLinuxu a testy rychlosti Javy

Na AbcLinuxu vyšel zajímavý článe k o Javě. Je poučný a doporučuji ho k přečtení. Bohužel uvádí několik malých nepřesností a rád si rýpnu a něco doplním.

Uvedené testy rychlosti Javy jsou sice zajímavé, ale jejich vypovídací hodnota je (bohužel) poměrně malá. Jde o testy typu FFT, SOR, Monte Carlo apod. Tyto testy sice velmi přesně spočítají výkon procesoru a optimalizace pro něj pomocí různých programovacích jazyků, ale jsou silně odtržené od skutečného života. Skutečné programy počítají něco úplně jiného. Pro studim doporučuji zatím nejlepší testy, které jsem viděl na adrese http://dada.perl.it/shootout/ pro MS Windows a http://www.bagley.org/~doug /shootout/ pro Linux. Jinak testy provedené autorem článku panem Davidem Michalíkem se mi nějak nezdají. To, že Java je rychlejší než programovací jazyk C mi nepřipadá u těchto typů testů možné.

Dále autor tvrdí, že Microsoft platforma NET nepoužívá u managed kódu garbage collector. To není pravda, sice to u NET nefunguje úplně vnitřně stejně jako u Javy, ale to je významné pro tvůrce Javy a NET a ne pro programátory, kteří tyto platformy používají.

Jinak je článek zajímavý a doporučuji ho k přečtení.

Kniha: C# pro zelenáče (Virius M.)

Kniha známého českého odborníka na objektové programování, Ing. Miroslava Viriuse je přesně tím, co popisuje její název. Seznamuje s novým jazykem C# firmy Microsoft a nic víc. Vysvětluje všechny důležité prvky tohoto jazyku od komentářů přes proměnné a příkazy až po třídy, vyjímky a soubory. Samozřejmě se věnuje i obecně objektům a jsou zde i základy do programování grafického uživatelského rozhraní Windows pomocí .NET., ale od toho tato kniha není. Kniha je napsána srozumitelně a přesně tak jak lze očekávat u knihy pro začátečníky.

Závěr: knihu doporučuji těm, kteří se potřebují naučit programovací jazyk C#.

Virius Miroslav: C# pro zelenáče, www.neo.cz, 249 Kč, 255 stran

Editorial: přidání C# do weblogu

Vzhledem k tomu, že jsem nucen se věnovat i programovacímu jazyku C# a platformě .NET firmy Microsoft, rozhodl jsem se proto i rozšířit záběr tohoto weblogu o spoty o programovacím jazyku C# a věcí souvisejících. Weblog byl proto přejmenován na Java.net a bylo mírně změněno URL. Mělo by to (snad) fungovat transparentně.

Co dnes použít při vývoji desktop aplikace? Javu nebo C#?

Rád bych pokračoval ve svém článku Java versus C# v příštích letech. Dostal jsem na něj spoustu dotazů a připomínek. Dnes se budu věnovat otázce, co vybrat dnes za prostředek na navržení a naprogramování desktop aplikace? Javu nebo programovací jazyk C#? Programovacím jazykem C# samozřejmě myslím prostředí platformy Microsoft NET.

Je to samozřejmě důležitá otázka a lze na ni odpovědět jednoduše: pokud bude aplikace běžet pouze pod některým z operačních systémů Microsoft Windows, je nelepším řešením C#. Pokud požaduji multiplatformnost, třeba běh aplikace též pod operačním systémem Linux, musím použít Javu.

To je jednoduchá odpověď a navíc ještě pravdivá. Trochu si ji ovšem zkomplikujeme: víme jaký operační systém používají naši zákazníci dnes, ale nevíme jaký budou používat za 5 let. Rádi bychom dělali upgrade aplikace - to jsou přece zaručené příjmy. Pokud vybereme nevhodné technické řešení můžeme mít velké problémy: zákazník přejde jinam - horší varianta, nebo budeme muset celou aplikaci přeprogramovat a zahodit veškeré dosavadní znalosti, zkušenosti a školení - také žádná radost.

Představme si nějaké zadání. Na tom se budou všechny aspekty nejlépe demonstrovat. Použiji zadání ze svého článku Desktop versus web aplikace: napsat aplikaci pro řízení projektů, jejich zaznamenávání a sledování.

Přenositelnost

Potřebujeme přenositelnost? Dnes asi ne. 99 procent našich uživatelů používá některý z operačních systémů z rodiny Windows firmy Microsoft. Nevíme ale zda ji budeme potřebovat za 5 let? Pokud přenositelnost za 5 let budeme potřebovat, budeme s největší pravděpodobností chtít naši aplikaci provozovat na operačním systému Linux. Již dnes jde o operační systém, který je plně srovnatelný s MS Windows a může ho v 95 procentech zastoupit. Existují sice desítky a možná i stovky dalších operačních systémů, ale ty naši zákazníci nepoužívají.

Java je na Linuxu bez problémů provozovatelná. Úplně jiná je ovšem situace u C#. Ten je aktuálně schopen práce pouze na počítačích na kterých je nainstalován .NET Framework. Jde o operační systémy Windows 98, ME, NT, 2000, XP.

Pokud budeme chtít naši aplikaci napsanou pomocí C# provozovat na Linuxu, je naší jedinou šancí projekt Mono. Mono projekt založený v roce 2001 je Open Source iniciativa podporovaná firmou Ximian. Jde o Unix verzi Microsoft NET platformy (Frameworku). Projekt se snaží na Unixu a především na Linuxu realizovat technologie, které byly Microsoftem předloženy ECMA (European Computer Manufactures Association) pro standardizaci. Z programovacích jazyků MS NET se věnuje C#, ale do budoucna nelze vyloučit rozšíření kompilátoru i na jiné programovací jazyky. Mono je v současné době ve vývoji a mělo by být dokončeno na přelomu roku 2003/2004. V této době by měla být uvolněna verze 1.0, která ovšem nebude obsahovat System.Windows.Forms a Enterprise.Services. Verze 1.2 se očekává zhruba v polovině roku 2004 a bude doplněna o všechny zbývající části. Bude tedy plně kompatibilní s NET 1.0. Firma Ximian není v Linuxu žádný nováček. Vytvořila grafické prostředí Gnome a skvělý nástroj pro instalaci odinstalaci aplikací Red Carpet a nedávno byla zakoupena firmou Novell.

To jsou vše samozřejmě pouze plány. Mono má dnes již k dispozici plně hodnotný kompilátor jazyku C#, ale programovací jazyk nedělá kompilátor, ale knihovny. V tomto případě jde právě především o knihovny Windows Forms, které zajišťují zobrazování okének a souvisejících věcí. Není k přehlédnutí, že projekt Mono sám uvádí, že v první verzi tyto knihovny nebudou k dispozici. Sám Microsoft investoval stovky milionů dolarů do vývoje platformy NET a myslím, že Ximian/Novell nebude něčeho takového schopen a ani ochoten. Podle mého názoru nebude firma Ximian schopna tak velký úkol zvládnout. Podporu od Microsoftu očekávat nelze. Ten na portaci NET platformy na Linux nemá žádný zájem, spíše bych řekl naopak. Celkově tedy zřejmě nelze očekávat rozšíření C# a NET mimo operační systémy MS Windows. Samozřejmě vyloučit nelze nic a mohu se plést.

Přenositelnost Javy je proti tomu špičková. Naprostou většinu aplikací lze bez jakýchkoliv změn přenést na libovolný operační systém, na kterém je k dispozici JRE. Někdy jsou drobné problémy s formátem souborů a souborových cest, ale pokud programátor dodržuje elementární pravidla psaní přenositelného kódu, na žádné problémy se nenarazí.

Závěr: pokud očekáváte, že aplikace bude běžet na jiném OS, než MS Windows, je nutné zvolit Javu. Vše záleží na tom, jak úspěšný bude Linux. Pokud během příštích let dosáhne pozice na desktopech v řádu desítek procent, stane se přenositelnost klíčovou vlastností programovacího jazyku.

Nutno podotknout, že přenositelnost minimálně na Linux lze zajistit i jinými programovacími jazyky, především u GUI programů pomocí jazyku C++. Zde je nutné ovšem použít speciální knihovny, které tuto přenositelnost zajišťují, např. wxWindows.

Rychlost provádění

Dle testů na serveru The Great Win32 Computer Language Shootout jsem provedl některé z porovnání a s výjimkou testů pro zpracování výjimek, vláken a hešů je jazyk C# významně rychlejší. I pokud započítám výše uvedené výjimky je rozdíl 10 % ve prospěch C#. Domnívám se ale, že v testu vláken je chyba, protože podle testu je při práci s vlákny C# o 600% pomalejší a to se mi nezdá. Nechci se Microsoftu zastávat, ale zrovna vlákna běží na MS Windows poměrně efektivně.

V každém případě má jazyk C# velkou výhodu ve vykreslování formulářů a oken. Bohužel se mi nepodařilo najít žádný věrohodný test, který by porovnával rychlost vykreslování grafických komponent, formulářů a oken pomocí Javy a C#. Na první pohled je zřejmě, že Java používající Swing je pomalejší -  přenositelnost a zajištění stejného vzhledu na všech platformách něco stojí.

Závěr: v kritériu rychlosti aplikace vítězí C#. Je samozřejmě otázkou, zda je to pro Javu nějaký problém. V uvedeném zadání lze očekávat, že aplikace bude čekat na vstup uživatele, přístup na disk nebo do databáze. Vlastní rychlost vykreslování grafických komponent není významná. Paměťová náročnost bude přibližně srovnatelná.

Vývoj

Z hlediska programových konstrukcí jsou oba jazyky naprosto srovnatelné. Zkušený programátor bude v obou jazycích programovat stejně rychle a nezkušený programátor se oba jazyky bude učit stejně dlouho. Samozřejmě zde máme několik méně, či více významných rozdílů. C# proti Javě podporuje tyto konstrukce a vlastnosti:

• atributy;
• delegáty;
• enum (zřejmě bude v Javě 1.5);
• multidimenzionální pole;
• parametry metodám (primitivní typy) lze předávat jak odkazem, tak hodnotou (v Javě pouze hodnotou);
• příkazy preprocesoru;
• properties (zřejmě budou v Javě 1.5);
• přetížení operátorů;
• struct;
• verzování;

Java proti tomu má tyto výhody:

• anonymní vnitřní třídy;
• kontrolované výjimky (checked exceptions);
• není nutné u přetěžovaných metod psát identifikátor virtual, resp. override. Toto ovšem může mít u Javy negativní dopad na výkon;

Co se mi osobně nejvíce líbí na C# proti Javě jsou příkazy preprocesoru. To myslím Javě chybí. Znám argumenty, které se uvádí proti této vlastnosti jazyka, ale považuji je za minoritní proti výhodám, které přinášejí. Výhody Javy nepovažuji za důležité až možná na anonymní vnitřní třídy, které jsou dobré pro automatický návrh formulářů pomocí IDE nástrojů.

Pro vizuální tvorbu formulářů existují pro oba programovací jazyky kvalitní nástroje (Visual Studio, JBuilder, NetBeans).

Provoz aplikace

• V obou případech je nutné zajistit, aby na cílovém počítači bylo k dispozici běhové prostředí. Do budoucna u operačních systémů MS Windows bude tato platforma ve výhodě, protože NET Framework bude na vše k dispozici ihned po instalaci. JRE se bude muset doinstalovávat.
• Start aplikace je rychlejší na platformě NET.

Ostatní

• Údržba aplikace by měla být pro obě platformy srovnatelná.
• Cena vývojového prostředí není významná. Pro Javu jsou k dispozici komerční i Open Source velmi kvalitní nástroje, pro C# je k dispozici Visual Studio, které sice není k dispozici zadarmo, ale jeho cena není nijak závratná. MS Visual Studio má již dnes kvalitní Open Source ekvivalent - SharpDevelop. Tento produkt je sice zatím ve verzi 0.97, ale již se s ním dá dobře pracovat.

Celkový závěr: v případě, že potřebujete přenositelnost na jiný operační systém, doporučuji Javu. V případě, že aplikace pracuje a bude pracovat pouze na operačních systémech MS Windows, doporučuji použít C#. Je to zásadní rozhodnutí - nezapomeňte, že největší investice je vaše energie.

Kniha: Java - servlety a stránky JSP (Hall M.)

Kniha velmi detailně na 586 stranách popisuje jak Javu použít pro vytváření web aplikací.

První část knihy se věnuje servletům. Popisuje vše od výhod servletů proti standardním CGI programům přes jejich konfiguraci na jednotlivých web serverech, které je podporují, až po sledování sezení (session). Druhá část knihy se věnuje JSP stránkám stejně podrobně jako předchozí. Od skriptovacích značek přes použití JavaBeans po integrování servletů a JSP. Třetí část popisuje zbývající technologie jako HTML, aplety jako uživatelské rozhraní servletů a JDBC. Překlad je poměrně dobře proveden, kniha má pevnou vazbu.

Závěr: kniha je velmi kvalitní a je povinou četbou pro všechny, kdo v Javě tvoří web aplikace.

Hall Marty: Java - servlety a stránky JSP, www.neo.cz, 597 Kč, 586 stran

Swing versus SWT

Nejdříve trocha historie. Když firma Sun dala na trh první verzi programovacího jazyku Java, vybavila ho i grafickým uživatelským rozhraním (GUI) Abstract Window Toolkit (AWT). Sun zcela nepochybně první verzi AWT uvolnil příliš brzy. AWT bylo tak nedokonalé, že bylo nutno v další verzi 1.1 Javy ho významně přepracovat. Nový návrh byl mnohem přehlednější, objektově orientovaný a dal se již skutečně použít.

Stále to ovšem nestačilo, AWT nebylo příliš hezké a sice bylo funkční na všech platformách, které byly Javou podporovány, ale bylo na nich vzhledově spíše podprůměrné. Java 2 přišla s novou GUI knihovnou Java Foundation Classes (JFC), jejíž grafická část se nazývá Swing. Swing má velmi dobrý programovací model. Má všechny komponenty, které by mělo mít každé moderní uživatelské rozhraní. Příklady povedených Swing aplikací lze najít třeba na Sun serveru nebo zde. Při vývoji Swingu byl ovšem obětován výkon. Všechny komponenty jsou "lehké" a tak bylo možno dosáhnout toho, že na všech platformách Swing aplikace vypadají stejně, protože každá komponenta je napsána v Javě. AWT oproti tomu využívá nativních služeb daného operačního systému a na každém OS vypadá jinak.

SWT je základní grafická knihovna po Javu, která nemá žádnou závislost na standardním grafickém API Javy. Jeho výkladní skříň je vývojové prostředí Eclipse a je IBM iniciativou. Je sice napsáno v Javě, ale nesmí používat ochranou známku Java IDE. Proč? Protože není Java pure. To znamená, že v sobě obsahuje nativní kód z jednotlivých operačních systémů, na které je portováno. SWT lze s určitou nadsázkou považovat za knihovnu, která leží mezi AWT a Swingem. Komponenty jsou "vybavenější" než u AWT, ale nemají takové množství vlastností jako u Swingu.

SWT má podobný přístup jako AWT. Všechny komponenty jsou svázány s nativními službami příslušného operačního systému. Pouze v případě, kdy příslušný operační systém danou službu nepodporuje, SWT ji emuluje. Zřídka užívané vlastnosti jsou vynechané.

Velkou výhodou SWT je, že GUI vypadá na všech platformách jak je jejich uživatel zvyklý a nic ho nepřekvapuje. Když Microsoft uvolnil XP verzi Windows, SWT automaticky převzalo jeho nový vzhled, Swing toho není schopen. V SWT není možné u alokovaných zdrojů jako jsou fonty a barvy se spolehnout na automatickou správu paměti pomocí garbage collection, ale tyto zdroje je nutné uvolňovat ručně. Většinu SWT tříd nelze dědit.

Swing je oproti SWT flexibilnější a snadněji použitelný. Podle některých testů, s jejichž výsledky jsem se seznámil (nedělal jsem je), je dnešní Swing asi 2x rychlejší než byl při prvním uvedení v roce 1998 ve verzi 1.2.0.

Závěr: pokud bych byl nucen dělat rozhodnutí které GUI zvolit pro novou aplikaci programovanou v Javě, měl bych jasno. SWT má dvě významné výhody. Těmi je přebírání vzhledu od příslušného operačního systému - uživatel programu není zaskočen překvapujícím vzhledem Swingu a větší rychlost. Druhý důvod nepovažuji dnes za významný. Programy většinu času čekají na diskové operace, přístup k databázi nebo vstup od uživatele. Rychlost GUI není významná, pokud to nezdržuje. Koho z uživatelů zajímá, že komponenta se vykreslila o 5 milisekund rychleji.

Proti tomu má ale SWT několik významných nevýhod:

• Neexistuje žádný funkční návrhář pro tvorbu formulářů. Pomocí správců rozvržení se toto ale dá zvládnout.
• Není k dispozici kvalitní komponenta pro zobrazení většího množství dat v mřížce. Jediné řešení je napsat si ji sám a to je myslím nad možnosti (časové i intelektuální) většiny programátorů včetně mě.
• Vyřazení automatické správy paměti. To je závažný problém. Proč potom neprogramovat raději v C++?!
• Stabilita SWT je dobrá na MS Windows, na dalších platformách už to tak slavné není.

Pro mne je Swing vítězem. Kdyby před lety vývojový tým, který přešel od Smalltalku k Sun vytvářet Swing, zvolil variantu rozšiřování AWT a ne "lehkých" komponent myslím, že by to bylo lepší rozhodnutí, ale svět je takový jaký je a ne takový jaký bychom ho chtěli mít.

Kniha Java - Programujeme profesionálně (Spell Brett)

Velmi objemná kvalitní kniha, která je překladem z amerického nakladatelství Wrox, edice Programmer to programmer. Je určena pro programátory v Javě, kteří již mají nějaké zkušenosti. Nevysvětluje základy, ale několik důležitých aspektů programování v tomto jazyku. Co vysvětluje, vysvětluje podrobně a dobře. Jde především o témata architektura Javy, jak navrhovat vlastní knihovny, třídy a metody, práce s vlákny, swing (události, správci rozvržení, JTable, JTree, schránka, přetažení myší), tisk, JDBC, ukládání dat , sokety, Corba, RMI, optimalizace, tvorba nápovědy, mezinárodní podpora, nativní kód. Kniha je dobře přeložena a někdo si dal práci i s odladěním zdrojových kódů. I velmi obtížné pasáže jsou vysvětleny srozumitelně. Kniha je velmi kvalitní.

Závěr: doporučuji, ale kniha není vhodná pro začátečníky.

Spell Brett: Java - Programujeme profesionálně, www.cpress.cz, 890 Kč, 1021 stran

Desktop (Swing) versus web aplikace

Pomocí Javy je dnes možné napsat aplikaci nejméně dvěma způsoby. Jako desktop aplikaci pomocí AWT/Swingu/SWT nebo jako web aplikaci ovládanou přes web prohlížeč, jako jsou například skvělá Mozilla nebo MSIE. Oba způsoby mají své výhody a nevýhody.

Desktop/Swing aplikace běží na počítači jako jakákoliv jiná aplikace. Musí být nainstalováno JRE odpovídající verze a počítač musí mít dostatečný výkon, aby na něm Swing aplikace mohla běžet. U dnes prodávaných počítačů by s výkonem neměl být problém. Aplikace oproti nativně psaných programům, jako třeba pomocí Win32 a C++, bude pomaleji startovat a bude mít větší paměťové nároky.

Web aplikace běží na serveru pod servlet/JSP engine. Přistupuje se na ní pomocí web prohlížeče, který může běžet na různých zařízeních, nejen PC. Komunikace je bezestavová a proto se na serveru musí sledovat jednotlivá sezení (session). Pro práci je nutný neustálý přístup k síti na které je server. Preferovaná je práce v rámci intranetu, kde lze zajistit dostatečnou propustnost sítě.

Představme si, že máme například takovéto zadání: napsat aplikaci pro řízení projektů, jejich zaznamenávání a sledování. Požadavky jsou tyto:

1.Bude pracovat jednotlivě, v lokální síti i v rámci Internetu.
Tento požadavek lépe splňuje web aplikace. U desktop/Swing aplikace je nutné naprogramovat i modul pro server, což u web aplikace je zcela automatické. Web aplikace je v podstatě aplikací lokální a pouze výstupy se přenášejí k uživateli a vstupy od uživatele do aplikace. U web aplikace je práce na samostatném počítači nemožná. Je vyžadován neustálý přístup k serveru.

2.Budou s ní pracovat laici v oblasti výpočetní techniky, kteří mají zkušenosti se standardními kancelářskými aplikacemi a prací s Internetem.
Zde jsou pro obě řešení výhody zhruba vyrovnané. Web aplikace má výhodu v tom, že s nějakou uživatel již pracoval a ví co má očekávat. Swing vzhled může být nezvyklý. Na druhé straně HTML aplikaci nelze naprogramovat tak dobře, aby byla stejně snadno ovladatelná jako desktop program.

3.Musí zvládnout větší množství dat.
Záleží na konkrétním řešení. V obou případech lze použít SQL server.

4.Minimálně sdílená data musí mít možnost být uložena zabezpečeně.
Záleží na konkrétním řešení. Lépe zabezpečitelná jsou spíše data uložená na serveru, což ovšem může být u obou variant.

5.Naprogramovat co nejrychleji a nejlevněji (jak jinak).
Nejsem schopen přesně posoudit, které řešení je z hlediska nákladů programování efektivnější. Programování web aplikace bude náročnější z důvodu nutnosti ladění vzhledu pod různými prohlížeči. Na druhé straně desktop/Swing aplikace vyžaduje naprogramování síťové komunikace mezi desktop klientem a serverem na kterém jsou uložena data. Programování této síťové komunikace musí brát na zřetel bezpečnost, která je u web aplikace bezproblémová (SSL).
Předpokládám, že programování web aplikace bude mírně náročnější Tento rozdíl ale nepovažuji za významný.

6.V případě web aplikace lze zjistit prohlížeče poslední generace. Nelze zajistit jeden typ prohlížeče - aplikace musí dodržovat W3C standardy.

7.V případě desktop/Swing aplikace lze zajistit dostatečně výkonné počítače, pro chod Java/Swing.

8.V případě práce v síti je nutné kontrolovat oprávnění jednotlivých uživatelů k jednotlivým akcím a projektům.
Viz bod č.1. Zde má výhodu web aplikace.

Desktop aplikaci lze napsat pomocí několika grafických knihoven: Swing, AWT nebo SWT. Rozdíly mezi nimi nebudu v dnešním textu rozebírat, ale určitě se k tomu v budoucnu chci dostat. V tuto chvíli budu počítat s použitím Swing GUI.

Výhody desktop/Swing aplikace:
* Vzhled bude pro uživatele příjemnější a bude se lépe programovat. Dosáhnout hezkého vzhledu u web aplikace je mnohem náročnější a některé věci pomocí HTML nelze naprogramovat vůbec. Interaktivita vstupních formulářů je významně lepší oproti web aplikaci.
* Pro práci nevyžaduje server.
* Aplikaci lze jednoduše spouštět pomocí Java Web Start.
* Není vyžadován stálý přístup k síti na které je server s daty. Data lze například odesílat v dávkách.
* V případě, kdy se na server s uloženými daty bude přistupovat z Internetu, bude desktop/Swing aplikace rychlejší, protože přenos dat v rámci Internetu je pomalejší než odezva místního počítače.
* Lepší dostupnost nástrojů pro návrh vzhledu (Netbeans, JBuilder, ...)

Výhody web aplikace:
* Vyžaduje HW méně náročnějšího klienta. Stačí takový na kterém poběží libovolný prohlížeč poslední generace.
* Přístup je množný odkudkoliv a proto není nutné programovat žádnou síťovou komunikaci.
* Na počítači klienta nemusí být nainstalováno JRE.
* Není nutné programovat síťovou komunikaci - celá aplikace běží v podstatě lokálně.
* Ve většině případů je na server nasazován výkonnější hardware a tedy web aplikace bude poskytovat rychlejší odezvu. Tato výhoda se projeví pouze v nasazení v lokální síti - intranetu.

Za nejdůležitější kritérium považuji cenu práce programátora(ů). To jsou největší náklady pro vznik jakékoliv aplikace včetně aplikací Open Source. Zde je v mírné výhodě, v tomto případě, web aplikace. Web aplikace ovšem v současné verzi (X)HTML trpí jedním velmi závažným nedostatkem a tím je neschopnost kontroly vkládaných dat do formulářů. Je nutné využívat služeb Javascriptu a to není příliš systémové. Navíc Javascript existuje v několika verzích, které netrpí přílišnou kompatibilitou a někteří uživatelé si Javascript nebo některé jeho části ve svých prohlížečích z různých důvodů vypínají.

V případě, kdy je nutné zajistit i práci počítače bez přístupu na server, je nutné zvolit desktop/Swing variantu.

Pro výše uvedené zadání (řízení projektů) bych po úvaze zvolil variantu desktop/Swing. Sice bych musel programovat i serverovou část, ale (X)HTML uživatelské rozhraní není ideální a pro některé typy aplikací, třeba jako je toto zadání, ho považuji za zcela nevhodné. Za velmi významné plus pro desktop/Swing řešení dále považuji technologii Java Web Start, která by se dala použít pro klienty. Dnešní nástroje pro tvorbu uživatelského rozhraní jako je JBuilder nebo Netbeans jsou velmi kvalitní, že programátorovi velmi pomohou při tvorbě. Něco takového pro web aplikace psané pomocí JSP/servletů, co by bylo v praxi použitelné, neexistuje nebo o tom alespoň nevím.

Kniha Java efektivně - 57 zásad softwarového experta (Bloch J.)

Touto knihou dalo nakladatelství Grada do rukou programátorům velmi užitečnou pomůcku. Má sice jenom 230 stran, ale napsal ji jeden z autorů jazyku Java a to velmi fundovaně. I pro pokročilé programátory je text velmi hutný a musím přiznat, že jsem měl často problémy informace vstřebat. Některé výrazy nevím, zda byly přeloženy úplně šťastně, ale dá se přes to přenést. U mnoha probíraných příkladů je nejen uvedeno jak konstrukci napsat, ale také, jak by se psát neměla a proč.

Kniha je rozdělena do několika částí, které popisují jednotlivé problémy programování a jak je z hlediska efektivity chodu programu vyřešit. Jde o tyto části: vytváření a rušení objektů, metody společné všem objektům, třídy a rozhraní, náhrady konstrukcí jazyka C, metody, obecné programování, vyjímky, vlákna a serializace.

Nejsem si úplně jist, zda některé rady pro zvýšení efektivity programování je dobré používat, ale v každém případě je dobré se s nimi seznámit. Řízením se podle těchto rad sice asi zvýšíte efektivitu programu, ale občas program zamlžíte pro čtenáře zdrojového kódu.

Kniha je v každém případě pro české programátory Javy přínosem. Závěr: doporučuji pro pokročilé programátory.

Bloch Joshua: Java efektivně - 57 zásad softwarového experta, www.grada.cz, 290 Kč, 230 stran

Garbage collector

Garbage collector, doslova sběrač smetí je vlastnost několika nejmodernějších programovacích jazyků. Mimo Javy Garbage collector (dále GC) používá například i nový programovací jazyk od Microsoftu - C#.

O co jde? V programovacích jazycích, jako je C, C++, Pascal je nutné dynamické objekty zřizovat například operátorem newa po jejich použití odstranit například operátorem delete. Pokud na to proramátor zapomene, často docházelo k zaplnění celé operační paměti počítače a poté ke zhoucení aplikace a někdy dokonce k pádu celého operačního systému. Podle mne šlo o nejčastější závadu programů. Tato chyba se navíc velmi špatně u větších projektů hledá a slyšel jsem termín - brodit se krvní.

Java a některé další programovací jazyky tento problém řešení pomocí GC. Jednou za čas se v aplikaci spustí vlákno s nízkou prioritou, které projde všechny objekty a zjistí, zda je někdo použivá. Pokud na ně neexistují žádné odkazy (nikdo je nepoužívá), je objekt vymazán. Tím pádem může programátor objekty vytvářen a o jejich odstranění se nestarat. Je to obrovská úspora práce. Dnes je zdaleka nejdražší položkou tvorby software práce programátora a takově věci jako GC ji dokážou velmi zefektivnit.

I pro jazyky jko je C++ existuje GC. Například na straně http://www.hpl.hp.c om/personal/Hans_Boehm/gc/ najdete jeden z nich. Nevím ovšem, zda potom není lepší programovat v Javě.

Dovolím si upozornit na dvě věci v Javě, které s GC souvisejí. System.gc(). Tato statická metoda zavolá GC a provede vyčištění paměti. Doporučuji ji používat pouze když je to zcela odůvodněné. Zbytečně zatíží systém a zpomalí ho ve chvíli, kdy se to většinou nehodí.

Metoda finalize() se trochu podobá destruktorům v jazyce C++. S GC souvisí proto, že je zavolána, když GC likviduje nepoužívaný objekt z paměti. Bohužel neexistuje záruje, že metoda finalize() bude provedena. Proč? Protože například při ukončení aplikace objekty nelikviduje GC, ale celá paměť používaná objekty je předána operačnímu systému jako celek. Použití metody finalize() je tedy silně omezeno a spousta programátorů ani o ni nic neví.

Softwarové patenty v Evropě - jak to vlastně je?

Dnešní přípěvek se nebude týkat pouze Javy, ale všeho software. Dnes, tj. 24. září 2003 se opět bude Evropský parlament pokoušet hlasovat o softwarových patentech.

Co je to patent?
Dle slovníku je patent vynález - návod k technickému jednání, který je nový, průmyslově využitelný a je výsledkem objevitelské činnosti. Jeho majitel má výlučné právo patent využívat, udělovat souhlas k jeho využití jiným osobám nebo na ně patent převést. Patent uděluje původci vynálezu nebo jeho právnímu zástupci patentový úřad. Souhlas k využívání vynálezu chráněného patentem se nazývá licence.

Již z výše uvedeného je jasné, že to jasné není. Největší otázkou a problémem je, co všechno lze patentovat. V některých zemích a především v USA se již mnoho let patentují i takové věci, jako je kliknutí myší, obchodní modely, odkazy (URL) apod. To dozajista (podle mne) nejsou věci, které by se měly patentovat. Samozřejmě znám i argumenty proti, ale nesouhlasím s nimi.

Co software?
Měl by se dát software patentovat? Domnívám se, že ne. Sice v Evropě existuje pár států kde se podařilo různým firmám a jednotlivcům patentovat duševní objevy a vynálezy včetně software, ale většina Evropy byla zatím názoru, že pro ochranu duševního vlastnictví zde máme autorské zákony.

Jediným kdo v důsledku na patentech duševního vlastnictví vydělává nejsou až na vyjímky jejich vlastnící, ale právníci. Právníci v Evropě se smějí americkému patentovému právu, ale ti, kteří stejné právo prosazují v Evropském parlamentu velmi dobře vědí co dělají. Důsledkem právního statusu, že je možné patentovat cokoliv včetně software jsou především dlouhé a nákladné soudní pře. To je nekonečná studnice příjmů pro právníky a jejich firmy. Jiný význam patenty pro software nemají, jsou dostatečně chráněny autorskými zákony a pokud jsou nějaké nedostatky, jde o nedostatky autorských zákonů a ne potřeby patentů. Palmáre a odměny při vyhledávání prior-art (první zmínka související o obsahu patentu) stejně jako v USA budou vyčerpávat vývojové a výrobní firmy a ty bude ještě více pod tlakem firem z východu a západu.

Nejde jenom o software. Pokud bude v Evropě legální patentovat software, bude to znamenat mít možnost i patentovat takové zcela nepatentovatelné věci jako jsou obchodní, vzdělávací a lékařské postupy. Je přece snadné napsat jednoduchý program, který daný postup provádí a tím znemožnit ostatním například prodávat po telefonu. To není žádná fantazie. Firma Amazon.com Inc. má patentovanou metodu prodeje na jedno kliknutí myší, tzv. 1-Click.

Na právníky se okamžitě nalepí firmy a jednotlivci, kteří jsou v USA nazývání patentoví paraziti. Ti budou soudně napadat firmy a chtít od nich licenční poplatky za nesmyslné technické, obchodní, lékařské a další postupy. Stejně jako v USA firmy budou často raději platit než riskovat nákladný dlouhodobý spor s nejistým výsledkem.

Pro Evropu je přijetí širokého patentového práva riskantní i z jiného ohledu. Evropa by se se svým právním systémem stala třesoucím se oslíčkem pro Spojené státy a jediným důsledkem by byly vyšší náklady vývojářů.

Vím, Spojené Státy na tom nejsou špatně. Spolu s Japonskem jsou na tom ve vývoji nejlépe na světě. Za to ale nemohou patenty. Jejich vysoce výkonná ekonomika je výkonná díky liberalizaci celého života a dalším faktorům. Patenty jim nepomáhají, naopak. Evropa se svým silným sociálním cítěním na škody způsobené patentovým právem nemá a zaplatí za to. Nebude to poprvé.

Doplněno 25.9.2003: Zákona byl včera schválen. Není to ovšem tak špatná zpráva, jak to vypadá na první pohled. Došlo k několika významným změnám díky doplňujícím návrhům (díky FFII a EuroLinuxu). Lze sice patentovat vynálezy související s počítači, ale programy ne. Zakázáno je i patentování obchodních postupů. Nyní jde návrh do rady ministrů a potom znovu zpět do Evropského parlamentu. Je to na dobré cestě :-).

Java versus C# v příštích letech

Která programovací platforma bude mít větší úspěch v příštích řekněme 5-ti letech? Bude to Java nebo NET? Zde je několik samostatných otázek, které je nutno probrat.

Java měla zpočátku špatný nástup. Byla a dodnes někým je prezentována jako programovací jazyk pro applety, což jsou programy, které běží v rámci prohlížeče Internetu. Bohužel pro Javu je v tomto případě applet závislý na verzi a kvalitě JRE (Java Runtime Environment), které je jako plugin instalováno v prohlížeči. Po té, co Microsoft zvítězil ve válce prohlížečů a jeho MSIE (Microsoft Internet Explorer) se stal naprosto dominantním prohlížečem i se svou integrovanou verzí Javy, se applety staly pro důležité aplikace nepoužitelné.
Proč? JRE, které je standardně součástí MSIE je nejen zastaralé, ale i velmi nekvalitní.
Proč? Microsoft totiž nemá žádný zájem na úspěchu Javy.
Proč? Java je pro Microsoft nežádoucí a to především z těchto důvodů:

a) Úspěšná aplikace naprogramovaná v Javě běží na všech platformách kde je k dispozici JRE, nejen na operačních systémech Microsoftu. Dnešní výhodou MS Windows je především množství a kvalita aplikací, které jsou pro tyto operační systémy k dispozici. Pokud by tato výhoda zanikla, pozice MS Windows by se otřásla.
b) Microsoft nainvestoval do vývoje platformy NET obrovské částky a hodlá ji výrazně prosazovat. Java je pro NET přímou konkurencí.
c) Osobní antipatie mezi představiteli Microsoftu a Sunu jsou známé a mohou být sice iracionální, ale o to významnějším důvodem.

Většina lidí seznámí s Javou ve svém Microsoft prohlížeči a dojdou k závěru:
> Java je pomalá, program se dlouho natahuje z Internetu a potom pomalu běží.
> Java je ošklivá, MS JRE podporuje pouze AWT, které opravdu není moc hezké.
> Java je nestabilní, kvalita appletů na Internetu je velmi rozdílná a vlastní MS JRE skutečně není moc stabilní.

Dnešní doménou Javy ovšem nejsou applety, ale programování na straně serveru. Technologie J2EE a především servlety a JSP se staly mocným nástrojem. Aplikační servery jako je BEA a JBoss v sobě zapouzdřují tyto špičkové technologie a mnoho dalších služeb a umožňují psát velmi robustní, velké a dospělé aplikace běžící na straně serveru.

Nesmíme zapomenout ani na desktop aplikace v Javě. Sice asi nikdy nebudou tak rychlé jako aplikace psané nativně pro jeden operační systém, ale díky snadnému spouštění pomocí službě Java Web Start, hezkému vzhledu (Swing) a významně zvýšené rychlosti pomocí kompilace HotSpot jsou již dobře použitelné. Jejich 99-100% přenositelnost je to, co více jak vyvažuje pomalejší start a větší paměťovou náročnost než nativní aplikace.

Přenositelnost by nebyla významná bez Linuxu, protože by nebylo kam přenášet. Významný nástup Linuxu na serverech i desktopech Javě velmi pomáhá. Na desktopech se objevil pro Javu další významný operační systém a to Apple OS X, který lze považovat za klon Unixu (je založen na BSD jádru) se špičkovým grafickým X serverem.

Proti tomu stojí Microsoft se svou NET platformou a novým programovacím jazykem C#. Myslím, že C# je to nejlepší, co Microsoft v programování udělal - je velmi dobře promyšlený a má výbornou architekturu. Oproti téměř hrozivým věcem jako je/byl Visual Basic nebo MFC pro C++ je C# pro Microsoft obrovským krokem dopředu. C# se samozřejmě inspiroval Javou a ohlášené novinky v Javě 1.5 se zase inspirovaly C#. Nemohou si navzájem nic vyčítat. Microsoft má proti Javě tyto výhody:
> Stále dominantní postavení na desktopech a tím schopnost uživatelům vnutit potřebnou technologii.
> Stejný vzhled aplikací psaných pomocí NET jako pomocí Win32. Java Swing aplikace jsou sice hezké, ale vypadají trochu jinak a to může některé uživatele odradit.

Java má proti NET tyto výhody:
> Větší konkurence mezi poskytovateli nástrojů a služeb pro Javu (vývojové prostředí, J2EE, servlet engine, apod.).
> Open source nástroje a pomůcky.
> Nezávislost na jedné firmě. Java je sice fakticky spravována firmou Sun, ale v záloze zde je minimálně velmi silná IBM.

Z hlediska programátorů Java prospívá NET a NET prospívá Javě. Je to dnes již vidět na připravované verzi 1.5 Javy. Je také samozřejmě otázkou, zda by bez Javy vůbec NET a C# vznikly. Microsoft si nejdříve pokoušel Javu přihnout podle sebe a když se mu to nepodařilo, tak vytvořil NET. Čím déle bude tento boj mezi těmito technologiemi trvat, tím lépe pro nás. Obě technologie se budou snažit přilákat co nejvíce programátorů a budou se jim snažit přicházet co nejvíce vstříc. To jenom a jenom dobře.

Pokud jste na základě titulku očekávali, že vám zde odpovím která technologie zvítězí, toto očekávání nesplním. Na tuto otázku dnes neexistuje správná odpověď. Pokud se rozhodujete kterou z technologií zvolit, snad jsem trochu pomohl.

Kniha Java 2 - příručka programátora (Hawlitzek)

Kniha se opět pokouší na 316 stranách probrat celou Javu 2. Sice se na titulní straně píše, že je vhodná zejména pro programátory, kteří na Javu přecházejí z jiného programovacího jazyka, ale probírá na 316 stranách vše od popisu a syntaxe Javy, přes vývojová prostředí, základy objektově orientovaného programování, až po referenční příručku nejdůležitějších tříd. V těchto nejdůležitějších třídách je zahrnuto vše včetně AWT, Swingu až po šifrování a vyjímky.

Kniha je taková jízda rychlíkem a z okolní krajiny vidíte většinou pouze šmouhy. Popis tříd je řešen formou obrázkových diagramů, které nejsou moc přehledné a graficky nejsou také moc povedené. Závěr: knihu nedoporučuji, na trhu jsou mnohem zajímavější tituly jak pro začátečníky, tak pro pokročilé.

Hawlitzek Florian: Java 2 - příručka programátora, www.grada.cz, 330 Kč, 316 stran

Kniha 1001 tipů a triků pro programování v jazyce Java (Kiszka B.)

Kniha se tváří velmi velkolepě, ale velkolepá není. Autor asi umí v Javě dobře programovat, ale to není dostatečná kvalifikace na psaní knihy i pro tak rozvržením jednoduché téma. Proč je třeba hned v první kapitole kreslení mřížky v Appletu a naopak třídy jsou popisovány teprve na straně 343? Některé tipy (pouze pár) jsou zcela nesmyslné, mám pocit, že to po autorovi nikdo nečetl, maximálně jazykový korektor. Odborné formulace jsou jsou sice skutečně odborné, ale nevhodné do knihy. Témata jsou přeházená a měla by být lépe seřazena.

Před lety v roce 1997 u nás vyšla v nakladatelství Unis kniha 1001 tipů Java od skupiny autorů Chan, Griffith, Iasi. Popisovala sice dnes již zastaralou verzi Javy, ale pan Kiszka si z ní měl vzít vzor. Kniha byla přehledná a přesto, že se jednalo o nezávislé tipy, dala se svým dobrým návrhem číst jako učebnice. Na druhé straně je rozsah knihy opravdu velký a každý programátor od začátečníka po zkušeného profesionála si v ní najde z nějaké oblasti něco zajímavého.

Závěr: doporučuji spíše začátečníkům, ale mnohem lepší jsou pro ně příklady na The Java Developers Almanac 1.4, stačí jenom velmi mírně vládnout angličtinou. Kdyby nakladatelství přeložilo tuto knihu, udělalo by nesporně mnohem lépe. Naštěstí je celá k dispozici na webu.

Kiszka Bogdan: 1001 tipů a triků pro programování v jazyce Java, www.cpress.cz, 490 Kč, 520 stran

Poznámka pod čarou: ode dneška již nebudu kritizovat více jak jednu knihu denně, je to příliš vyčerpávající okolo sebe plivat tolik jedovatých slin.

České knihy o Javě - nemilosrdně (2)

Dnes pokračuji ve svém miniseriálu ze včerejška o knihách o Javě v češtině. Knihy, jejich autory a nakladatele se snažím nijak nešetřit, což není v českých luzích a hájích zvykem.

Eckel Bruce: Myslíme v jazyku Java - knihovna programátora, www.grada.cz, 427 kč, 432 stran

Bruce Eckel je světově známý spisovatel. proslavil se zejména tím, že většinu svých knih nabízí na svém webu zdarma v elektronické formě. Samozřejmě pouze v angličtině. Je zajímavé, že i v tomto jazyku se jeho knihy prodávají v tištěné formě. Napsal velmi úspěšnou dvojici knih "Myslíme v jazyku C++". O programovacím jazyku Java napsal Bruce Eckel také dvě knihy a Myslíme v jazyku Java - knihovna programátora je první z nich. Kniha se kvalitně věnuje nejen programovacímu jazyku Java, ale i teorii objektově orientovaného programování a podrobně vysvětluje základy OOP. Kniha je bohužel špatně přeložena a je v ní spousta faktických chyb, což jak se domnívám, vzniklo během překladu a odborných korektur. Díky těmto chybám je místy kniha až nesrozumitelná. Závěr: knihu nedoporučuji, pokud ovšem vládnete anglickým jazykem, doporučuji si knihu stáhnout v originálu z bruceeckel.com.

Eckel Bruce: Myslíme v jazyku Java - knihovna zkušeného programátora, www.grada.cz, 467 Kč, 472 stran

Druhý díl knihy Myslíme v jazyku Java od Bruce Eckela, tentokrát s příponou knihovna zkušeného programátora, je skutečně určen pro pokročilejší programátory v Javě. Mimo jiné jsou jeho obsahem vyjímky, dynamická identifikace typů, vlákna a distribuované výpočetní procesy. Kvalita knihy je bohužel stejná jako u předchozího dílu. Vzhledem k obtížnosti témat a kvalitě překladu je někdy až detektivní prací zjistit co měl autor na mysli. Přesto jsem nucen ji doporučit - na českém trhu je málo takto odborných knih a v této se i pokročilý programátor seznámí s věcmi, které nezná. Závěr: přes významné nedostatky doporučuji, vyžadována vysoká míra tolerance k překladateli při studiu.

Dodatek 3.10.2003: pan Herout Pavel mě upozornil, že rozdělení knihy Myslíme v jazyku Java na dvé části není autorovým nápadem, provedlo ho nakladatelství Grada.

Virius Miroslav: Java pro zelenáče, www.neo.cz, 249 Kč, 240 stran

Kniha si na nic nehraje, je určena pro začátečníky v programování v Javě jak napovídá její název. Zkušený český autor probírá od základů všechny důležité aspekty tohoto programovacího jazyku. Kniha je koncipována jako učebnice a může sloužit i jako učebnice ve škole. Závěr: doporučuji pro začátečníky.

České knihy o Javě - nemilosrdně (1)

Českých knih o Javě moc není. Na amazon.com jsem našel 2387 knih podle klíčového slova Java. Na vltava.cz jsem proti tomu našel 273 titulů vyhledaných podle stejného kritéria. Tato čísla ovšem neberte moc vážně. Není jasné, zda se vyhledává pouze v názvu nebo i v anotaci a také není jasné, zda se započítají i knihy, které mají v názvu, resp. v anotaci i slovo Javascript.

Počet knih se zdá velký, ale v naprosté většině se jedná o obecné tituly pro začátečníky a kvalitních knih je velmi málo. Některé z nich (ty kvalitní i nekvalitní) jsem četl a rád vás seznámím se svým názorem na ně. Ke knihám nebudu moc tolerantní. Už mám celkem dost těch recenzí na knihy, které čtu v časopisech a/nebo na webu. Podle nich jsou všechny skvělé až na nějaké maličkosti. Jsem opačného názoru: většina knih o Javě nestojí za nic a jsou špatně napsané, přeložené a zalomené. To se samozřejmě netýká pouze Javy, ale většiny odborných knih se kterými jsem přišel do styku.

Schildt Herbert: Java 2 Příručka programátora, www.softpress.cz, 395 Kč, 552 stran

Autor Herbert Schildt je světově známým autorem knih o programování. Bohužel tato nepatří k těm nejlepším. Nejde snad ani o to, že by byla špatně napsaná, ale tváří se jako kompletní manuál k Javě 2 a to na 552 stranách není možné zvládnout. Kniha velmi přesně zapadá do strategie nakladatelství Softpress: pomocí kvalitního autora zvládnout na poměrně malém rozsahu velké téma. Z toho vyjde buď přílišné zestručnění nebo vynechání podstatných částí tématu. Kniha je na české poměry kvalitně přeložena a autor se umí dobře vyjadřovat. Závěr: knihu nedoporučuji protože nejde ani o knihu pro začátečníky, ani pro pokročilé.

Grand Mark: Java Referenční příručka, www.cpress.cz , 348 Kč, 474 stran

Pokud vím, tak jde o jedinou referenční příručku o Javě v českém jazyce. Bohužel popisuje Javu verze 1.1, což je skutečně velmi zastaralé téma. Zhruba ½ je referenční příručkou jazyka a druhá ½ popisuje balík java.lang. Závěr: knihu nedoporučuji pro její zastaralost.

Herout Pavel: Učebnice jazyka Java, www.kopp.cz , 199 Kč, 349 stran

Autor Pavel Herout se proslavil Svými dvěmi učebnicemi programovacího jazyka C. V této a následující knize o programovacím jazyku Java se pokusil na úspěch těchto knih navázat. Kniha je především popisem vlastního jazyka a nevěnuje se tolik knihovnám. Na 349 stranách je probráno o Javě téměř vše. Od terminálového vstupu a výstupu, přes řídící struktury, metody, pole dědičnost, práci s balíky, rozhraní, polymorfizmus, vnořené třídy, vyjímky soubory, systém, vlákna. Bohužel na tak malém rozsahu nebylo možno všechna tato témata dostatečně kvalitně vysvětlit. Kniha je sice dobře napsána - autor má dobré pero, ale pokud se čtenář témata potřebuje naučit a nic o nich neví, tak bude mít problémy s jejich pochopením. Pokud témata zná, tak knihu nepotřebuje, protože nejde o referenční příručku a témata jsou z prostorových důvodů zestručněna. Cena knihy je příjemná, ale nic není zadarmo a nízká cena je vykoupena "salátovou" vazbou. Závěr: knihu doporučuji s výhradami.

Herout Pavel: Java - grafické uživatelské prostředí a čeština, www.kopp.cz, 199 Kč, 320 stran

Kniha navazuje na předchozí knihu Učebnice jazyka Java. Podrobně se věnuje pouze dvěma tématům:grafickému uživatelskému prostředí AWT a problémům spojených s lokalizací a internacionalizací. AWT je sice u Javy poněkud překonané - neznám žádný kvalitní program napsaný v Javě, který by ho používal - všechny používají JFC/Swing, ale přesto je to téma zajímavé. Dobře je vysvětlen systém posluchačů a událostí. Swing sice nelze považovat za nadmnožinu AWT, ale každá Swing komponenta je založena na jedné AWT komponentě a tak je tato kniha užitečná i pro programátory Swingu. Problematika lokalizace a internacionalizace je vysvětlena nečekaně podrobně. Závěr: knihu doporučuji s výhradou (zastaralost AWT).

Úvod - co je to Java

Našel jsem velmi málo informací o Javě na českém webu. Muslím, že je to škoda, ale bohužel nemám čas a ani energii o tom založit a především zpravovat nějaký vlastní ezine. Tak to zkusím s tímto blogem. Pokud na to budu míta málo času, tak se nezlobte, ale slibuji, že se budu snažit.

Zatím s ničím moc velkým nezačnu, protože se jenom učím s programem EasyBlog, ve kterém zkouším blog psát. Blog je umístěn na webu firmy Neocortex s.r.o., která vydává knížky o výpočetní technice a mám s ní něco společného. Děkuji jí.

Předem se omlouvám ze překlepy a gramatické chyby. Čeština mne moc nebaví a program EasyBlog ve kterém to píši nemá (zatím) žádný alespoň minimální nástroj pro kontrolu pravopisu. Pokud to s těmi překlepy bude katastrofální, zkusím to psát v něčem jiném. Uvidíme.

Rád bych začal tím co je to vlastně programovací jazyk java:

1. Objektově orientovaný jazyk. To znamená, že data jou sice jako v procedurálních jazycích uložena v proměnných a jejich variantách (pole, struktury apod.), ale tyto proměnné jsou navích uloženy v instancích tříd - objektech. To má obrovskou východu, že lze nad programovými úlohami přemýlet mnohem přirozeněji a vlastní programování je mnohem snažší (když se objekty naučíte).

2. Program je spouštěn pomocí Virtuálního stroje Pokud napíšete pomocí libovolného textového editoru program v Javě (s příponou .class), je nutné ho přeložit pomocí programu javac do souboru s příponou .class. Tento již přeložený program je možné spustit na libovolném počítači, kde se vyskytuje JRE (Java Runtime Environment), což je prostředí pro běh programů v Javě, které stručně řečeno zahrnuje interpret Javy a její standardní knihovny. Je velmi důležité dodat, že pro nejrozšířenejší operační systémy (minimálně vím o MS Windows a Linuxu) existuje technologie HotSpot, která před provedením kódu Javy ho přeloží do nativního kódu počítače. Programy v Javě jsou potom srovnatelně rychlé s programy napsanými v C++.

Všechny potřebné nástroje lze pro operační systémy MS Windows, Linux a Solaris zdarma získat na webu Javy firmy Sun, která Javy vytvořila: http://java.sun.com/.