Dadajax’s weblog

blog o technice, počítačích, programování a fotografování
13. 1. 2010 , 21:38

Volná pozice pro Java junior programátora v Praze

Kategorie: Programování, Různé // 7 komentářů » 661 shlédnutí

Zdá se, že je v Praze nedostatek volných Java junior programátorů. Což je docela nepříjemné, protože zrovna hledáme do týmu jednoho šikovného Java developera. Pokud si myslíte, že máte co nabídnout, určitě vám doporučuju to u nás zkusit. O tom jak jsem v Globusu spokojen jsem se rozepsal v tomto článku a od té doby má spokojenost nijak neklesla :) Náplň práce je opravdu zajímavá a získáte skvělou příležitost jak se naučit spoustu nových věcí. A jako příjemný bonus je skvělý kolektiv…práce u nás není rozhodně nudná, o zábavu je postaráno :)

Pokud tedy znáte nějaké volné Java programátory z Prahy, prosím pošlete jim odkaz na tuto nabídku. Rádi bychom našli posilu do našeho týmu co nejdříve.

A na závěr uvedu „oficiální“ text nabídky práce:

Charakteristika pracovní činnosti:

Junior Developer bude členem mladého, dynamického teamu, který se stará o plynulý chod a úpravy rozhraní B2B systému, dle detailních analýz. Realizuje změny stávajících funkcionalit dle uživatelských požadavků. Tvůrčí a kreativní myšlenky jsou vítány. Možnost osobního a profesního rozvoje (odborné školení a publikace).

Kvalifikační a odborné předpoklady:

  • VŠ/SŠ vzdělání technického směru
  • praxi s vývojem v Java/J2EE
  • pasivní znalost AJ
  • týmového ducha, schopnost rychle se učit, myslet v souvislostech
  • praxe 0-3 roky
  • u absolventa potřebná zkušenost při škole

Globus Vám nabízí:

  • motivační odměňování
  • 13. mimořádnou mzdu
  • pravidelné roční hodnocení spojené s aktualizací mzdy
  • zvýhodněné mobilní volání
  • stravenky, nápoje, možnost využití stravovacího zařízení na pracovišti
  • podporu sportovní a relaxační činnosti
  • zvýšený nárok na dovolenou (5 týdnů dovolené)
  • odměnu při životním a pracovním výročí
  • účast v interních vzdělávacích programech
  • jistotu a perspektivu zaměstnání
  • podporu jazykového vzdělávání

Další informace:

Místo výkonu práce: Praha 9 – Čakovice

Nástup:  podle dohody

Kontakt:

V případě, že Vás naše nabídka zaujala, pošlete prosím svůj strukturovaný životopis na adresu GLOBUS ČR, k.s., Kostelecká 822, 196 00 Praha 9 nebo na e-mail.: J.Dadik@globus.cz.

29. 10. 2009 , 12:18

Jak zvětšit heap size pro Ant

Kategorie: Programování // 1 komentář » 622 shlédnutí

Pokud používáte k buildování většího Java projektu Ant, je možné, že jste se setkali s chybou typu „Java heap space“. Nejjednodušší řešení je přidat do enviroment variables ANT_OPTS, do které nastavite minimální a maximální heap size. Ve Windows stačí jen zavolat z příkazové řádky toto:

set ANT_OPTS=-Xms512m -Xmx512m

Velikost paměti si zamozřejmě můžete přizpůsobit podle potřeb.

12. 10. 2009 , 19:50

Jak vypadá práce programátora

Kategorie: Programování // 17 komentářů » 963 shlédnutí

Nedávno jsem od jednoho čtenáře blogu dostal dotaz. Se svolením autora budu citovat: Jak vypadá konkrétní práce programátora? Nemám totiž vůbec ponětí. Dostaneš nějaké zadání a určený čas k vyřešení? Nebo se sejde parta programátorů, rozeberou si úkoly a pracují ve skupinkách? Můžeš mi popsat nějakou konkrétní práci, kterou jsi někde dostal?

Tento dotaz mi přijde opravdu zajímavý, hlavně proto, že jsem si podobné otázky kladl před tím, než jsem nastoupil do své první práce. Mou odpověď bohužel negativně ovlivní několik faktorů. Za prvé jsem nyní teprve v druhém zaměstnání, tudíž nemám moc praktických zkušeností jak to chodí jinde. Díky tomu bude moje odpověď dost ovlivněna tím, co jsem zažil, nebo co jsem se doslechl od známých. Druhý faktor je ten, že o předchozím zaměstnání toho nemůžu moc říct. Budu se ale snažit odpovědět alespoň abstraktně, takže snad nějaké poznatky pomůžou. Tak tedy hurá na to, v následujících řádcích se dočtete co to ti programátoři vlastně dělají.

Celý článek..

6. 10. 2009 , 14:19

Spouštění Antu z dávkového souboru ve Windows

Kategorie: Programování // přidat komentář » 512 shlédnutí

Už zase jsem se zasekl na takovém problému při vytváření dávkových souborů ve Windows, že si to musím někam poznačit. Jde o to, že pokud voláte Ant z dávkového souboru, provádění dávkového soboru se ukončí po prvním zavolání Antu. Takže pokud v bat souboru voláte Ant několikrát, po prvním volání se ukončí provádění dávkového souboru. Docela nepříjemná věc :) Řešení je snadné. Stačí volat místo ant toto: call ant.

Příkaz call umožňuje z jednoho dávkového programu zavolat jiný. Vzhledem k tomu, že příkaz ant je pouze dávkový soubor, musíte pro jeho volání použít call.

4. 6. 2009 , 17:46

Jak správně reagovat na výjimky v Javě

Kategorie: Programování // 3 komentářů » 1,251 shlédnutí

Už delší dobu mám v plánu napsat podobný článek. Často totiž narážím na případy, kdy především začátečníci s výjimkami nakládají velmi špatně. O co jde? Uvedu první příklad:

try {
    Thread.sleep(100);
} catch (InterruptedException e) {
 
}

V uvedeném příkladu se v bloku try se zavolá příkaz na uspání vlákna na dobu 100ms. To může vyhodit InterruptedException. Na tuto výjimku máme možnost zareagovat v bloku catch, ale jak vidíte, tento blok je prázdný. V čem je tedy problém? Pokud na výjimku nijak nezareagujeme, koledujeme si o pořádné problémy. Pokud dojde k problému, nebudeme o tom vůbec vědět a aplikace se bude chovat divně. Taková chyba se hledá opravdu špatně a není vůbec lehké ji proto najít. Mnohdy taková chyba spustí řetězovou reakci spoustu dalších chyb.
Další příklad, který nyní uvedu, je oproti tomu předchozímu lepší, nicméně stále nedostačující:

try {
    Thread.sleep(100);
} catch (InterruptedException e) {
    System.out.println(„Nepodařilo se uspat vlákno“);
}

V tomto případě v momentě vyvolání výjimky sice dostaneme informaci o tom, že se něco nepodařilo, ale neřekne nám to téměř nic podstatného. Neznáme totiž žádné detaily této výjimky.

Správné řešení

Pokud nechcete strávit spoustu bezesných nocí nad laděním nefunkční aplikace, silně doporučuju použít tento způsob:

try {
    Thread.sleep(100);
} catch (InterruptedException e) {
    e.printStackTrace();
    // další metody pro ošetření výjimky
}

V tomto případě se v momentě vyvolání výjimky vypíše na standardní výstup stack trace (zásobník volání metod). Tam můžete jednoduše zjistit místo, kde k chybě došlo a často se zde objeví i popis problému. Samozřejmě že to není jediná možnost, dále můžete použít například různé logovací knihovny (například Log4J), které mají své funkce na výpis a logování těchto informací.

Nebuďte tedy líní a vždy v bloku catch nechte vypsat stack trace. I v případech, kdy si myslíte, že k výjimce dojít nikdy nemůže (což je stejně naivní jako třeba spoléhat se na to, že když si namíříte mezi oči nabitou a odjištěnou zbraň a zmáčknete spoušť, zbraň se pokazí a nevystřelí). Ušetříte tak sobě i svému okolí spoustu hodin, které byste jinak promarnili řešením podivného chování aplikace :)

A až budete řešit problém, se kterým si nebudete vědět rady, jednoduše zkopírujete výpis ze stack tracu do nějakého fóra a vaše šance na vyřešení problému se mnohonásobně zvýší. Není totiž nic horšího, než když programátor popíše problém slovy „nejde to“, nebo „píše to nějakou chybu“. Ale to už je na další článek ;)

26. 2. 2009 , 12:55

Java interface tajemství zbavený

Kategorie: Programování // 29 komentářů » 4,192 shlédnutí

Je to asi rok, kdy jsem se začal učit objektově orientovanému programování. Tehdy jsem byl v zaměstnání donucen naučit se OOP principům a to hlavně v Javě. Vzpomínám si, jaké problémy mi dělalo, než jsem pochopil význam a použití rozhraní (interface) v Javě. Tento článek je tedy zamýšlen jako taková pomůcka, která by měla objasnit používání rozhraní a to hlavně začátečníkům. Pro pochopení tohoto článku byste měli zvládat minimálně základy v Javě. Nenechte se zmást, v článku budu používat slova rozhraní i interface, které zde mají stejný význam.

Celý článek..

6. 2. 2009 , 21:06

Jak vytvořit jar soubor

Kategorie: Programování // přidat komentář » 2,998 shlédnutí

Než začnu popisovat postup na vytvoření jar souboru, rád bych trošku objasnil detaily tohoto typu souboru. Jar soubor je jen obyčejný ZIP archív (jar znamená Java Archive), který slouží ke snadnější distribuci Java class souborů. Dále může obsahovat soubor s metadaty, které určujou některé parametry balíku. No a vzhledem k tomu, že se jedná o klasický archív, může obsahovat i cokoliv jiného – např. grafiku, audio a podobně.

Pokud je v manifestu uveden Main-Class parametr, je jar soubor spustitelný. Buď klasickým poklepáním na soubor (pokud je dobře nastavena asociace v systému), nebo pomocí příkazu java -jar soubor.jar, kde soubor.jar je název souboru.

Metadata jsou v archívu uloženy v souboru META-INF/MANIFEST.MF. Jedná se o klasický textový soubor, který můžete editovat i ručně. Kompletní výčet informací, které můžete do manifestu uložit najdete přímo ve specifikaci. Pro začátek bude stačit, když budete znát význam těchto atributů:

  • Main-Class : Pokud chcete, aby byl jar soubor spustitelný, musíte do souboru MANIFEST.MF zapsat tento atribut, za kterým následuje cesta ke class souboru uvnitř balíku.
  • Class-Path : Tento atribut je velmi důležitý. Pokud totiž vaše aplikace používá nějaké další knihovny, musíte uvést do Class-Path atributu cestu k těmto knihovnám. Cesty jsou oddělené mezerami.

Myslím si, že další atributy nejsou pro začátek tolik důležité a jejich význam už si můžete snadno dohledat ve specifikaci. Když už víte, jak jar soubory přibližně fungují, určitě vás napadne způsob jak jar soubor vytvořit. Můžete jednoduše zabalit adresář s class soubory a do archívu vložit manifest soubor. Jenže kdo by se s tím měl takhle trápit. Existují mnohem jednodušší způsoby.

Díky Antu to jde snadno

ant_logo_largeAnt je pro Java vývojáře velmi užitečný nástroj. Díky němu můžete urychlit a zautomatizovat některé jinak zdlouhavé operace. Pro jednoduchost uvedu tento případ: máme Java projekt, který obsahuje několik souborů. Hlavní třída, kterou chceme aplikaci spouštět se bude jmenovat Hlavni. Musím připomenout, že aby tato třída byla spustitelná, musí mít metodu public static void main(final String[] args).Vytvoříme si tedy soubor build.xml, do kterého budeme přidávat úlohy pro ant.

Začneme s definováním některých atributů, ve kterých definujeme cesty k adresářům a název výsledného jar souboru.

<property name="srcdir" location="./src" />
<property name="bindir" location="./bin" />
<property name="deploydir" location="./deploy" />
<property name="jarname" value="Aplikace.jar" />
<property name="mainclass" value="Hlavni" />

Vytvoříme první target, který nám zkompiluje všechny .java soubory z adresáře ./src a výsledné .class soubory uloží do adresáře ./bin. Samozřejmě, že adresářová struktura se zachová.

<target name="compile">
    <javac srcdir="${srcdir}" destdir="${bindir}" />
</target>

Nyní máme zkompilované class soubory a můžeme se vrhnout na vytvoření jar souboru. Pro tento účel vytvoříme další target.

<target name="createJar" depends="compile">
    <jar destfile="${deploydir}/${jarname}">
        <fileset dir="${bindir}"/>
        <manifest>
            <attribute name="Main-Class" value="${mainclass}"/>
        </manifest>
    </jar>
</target>

Target createJar závisí na compile, takže se nejdříve zkompilují java soubory a teprve poté se z class souborů vytvoří jar soubor. Do tohoto souboru se vloží obsah složky ./bin a vytvoří se META-INF/MANIFEST.MF se správně nastaveným atributem Main-Class. Díky tomu bude tento jar soubor spustitelný. Pro pořádek ještě uvedu obsah celého build.xml souboru:

< ?xml version="1.0" encoding="UTF-8"?>
<project name="Test" default="createJar" basedir="../">
    <property name="srcdir" location="./src" />
    <property name="bindir" location="./bin" />
    <property name="deploydir" location="./deploy" />
    <property name="jarname" value="Aplikace.jar" />
    <property name="mainclass" value="Hlavni" />
 
    <target name="compile">
        <javac srcdir="${srcdir}" destdir="${bindir}" />
    </target>
 
    <target name="createJar" depends="compile">
        <jar destfile="${deploydir}/${jarname}">
            <fileset dir="${bindir}"/>
            <manifest>
                <attribute name="Main-Class" value="${mainclass}"/>
            </manifest>
        </jar>
    </target>
</project>

Spouštíme Ant

Buildovací skript máme napsaný, takže teď už jen stačí spustit ant z adresáře, kde máte build.xml soubor uložený. Pro zjednodušení si můžete vytvořit soubor antbuild.cmd, který editujte v textovém editoru a vložte do něj tyto řádky:

call ant
call pause

Poté stačí antbuild.cmd spustit, a vaše aplikace se zkompiluje a vytvoří se jar soubor. Pokud vám příkazový řádek bude hlásit, že nezná příkaz ant, tak si budete muset Ant stáhnout (z této adresy) a nastavit k němu cestu v Enviroment variables (česky Proměnné prostředí). Vzhledem k tomu, že na každém systému se toto nastavuje jinak, doporučuju do Googlu zadat výraz „how to set environment variable on X“, kde za X dosadíte název vašeho systému.

S Eclipsem ještě jednodušeji

Pokud používáte Eclipse, můžete ant scripty spouštět ještě snadněji přímo z IDE. Stačí na soubor build.xml kliknout pravým tlačítkem a vybrat Run as -> Ant build. Vzhledem k tomu, že Eclipse už v základu obsahuje Ant, nebudete muset nic stahovat, ani nastavovat.

Proč Ant?

Většina IDE umožňuje export do jar souboru. Problém je, že takový postup nelze plně automatizovat a člověk přitom může udělat chyby. Když budete jar soubory generovat pomocí Antu, budete mít jistotu, že všechno probíhá tak, jak si přejete. Navíc při změně IDE nemusíte zdlouhavě řešit, jak se jar vytváří jinde. Stačí spustit Ant a máte po problémech.

Malé doplnění

Na začátku jsem se zmínil o atributu Class-Path, který může být vložen do manifest souboru. O tom, jak tento atribut vygenerovat pomocí Antu jsem již jednou psal v tomto článku. Považuji tedy za zbytečné se o tom znovu zmiňovat.

1. 2. 2009 , 8:00

Produktivita práce v Eclipse

Kategorie: Programování // přidat komentář » 1,183 shlédnutí

Konečně jsem se dostal ke shlédnutí prezentace o produktivitě práce v nástroji Eclipse. Vzhledem k tomu, že v tomto IDE trávím spoustu času bych rád poznal všechny vychytávky, které toto IDE nabízí. Samozřejmě si je můžu všechny prostudovat a vyzkoušet, ale kdo na to má čas a náladu, že? :) Proto mi tato prezentace přišla docela vhod, protože jsem si během chvilky udělal představu o tom, co Eclipse nabízí a co ještě neznám, nebo nepoužívám.

Pokud tedy používáte Eclipse, určitě doporučuji se na přednášku podívat. Stojí to za to.

Odkaz: http://blog.novoj.net/…

31. 1. 2009 , 8:00

Angličtina – jediný správný jazyk pro programátory

Kategorie: Programování // 5 komentářů » 1,116 shlédnutí

O nutnosti zvládat anglický jazyk jsem už psal v jednom starším článku. Tentokrát se zaměřím na oblast programování a důležitosti anglického jazyka. Pro některé programátory to může být udivující, ale pojďme tedy na to.

Pište zdrojové kódy jen a pouze anglicky! Píšete-li kód v jakémkoliv jiném jazyce a chcete se programováním živit, jste na nejlepší cestě k problémům. Asi vás napadne, proč je ta angličtina tak důležitá. Důvodů je hned několik:

  • Veškerá dokumentace je anglicky. Nespoléhejte nikdy na to, že dokumentaci někdo přeloží do vašeho rodného jazyka, nebo alespoň vyjdou nějaké přeložené tutoriály. Čtení dokumentace je základ, který musí nutně každý dobrý programátor zvládnout.
  • Pokud napíšete kód anglicky, bude mu rozumět každý dobrý programátor na celém světě. Můžete tak snadno spolupracovat s někým z druhého konce světa na stejném kusu kódu, protože oba budete vědět, o co v kódu jde. Otevírá se vám tedy spoustu příležitostí, jak se dostat třeba k vývoji nějakých velmi známých open-source projektů.
  • Pokud budete pracovat v nějaké solidní firmě, budou po vás vyžadovat anglicky psaný kód.
  • Až budete potřebovat pomoc s nějakým specifickým problémem, můžete se obrátit na celý svět. To je mnohem lepší, než se spoléhat na pomoc z té naší malé podmnožiny z planety Země.
  • Kódem se budete moct prezentovat třeba na přijímacím pohovoru, nebo kdekoliv jinde.

Asi si budete říkat, že u vašeho malého projektu, na kterém zrovna pracujete angličtinu prostě nebudete potřebovat. To může být sice pravda, ale díky tomu si nikdy nezvyknete na programování v angličtině. Když pak přijdete např. do firmy, kde to po vás budou vyžadovat, budete složitě vymýšlet názvy metod a proměnných.

Naopak pokud programujete jen a pouze anglicky za všech okolností, nebude vám to nikdy dělat potíže. Budete psát plynule a jen ve výjimečných případech sáhnete ke slovníku.

Nikdy nemíchat!

Co je ještě horší než česky psaný kód? Je to kód psaný v několika jazycích. To už zavání totální prasečinou a pokud jste něco takového zplodili, je nejvyšší čas na pořádnou refaktorizaci. Takový míšený kód je silně nepřehledný a i zkušený vývojář se v takovém kódu snadno ztratí. Mnohdy to vede i k duplicitě, což je jedna z mnoha cest do programátorského pekla. Vemte si třeba takové:

Time getTime() {
    ...
}

Time ziskejCas() {
    ...
}

Tahle situace může nastat celkem snadno, protože prostě zapomenete, že takovou metodu už máte napsanou. Potom když budete chtít získat v programu čas, tak občas použijete getTime a někdy zase ziskejCas. Taky je vám už jenom z té představy špatně? Mělo by. Samozřejmě podobná situace může nastat i v případě anglického kódu (např getTime() a returnTime()), ale dodržováním konvencí při psaní kódu byste se měli podobným problémům vyhnout.

Angličtina je prostě přirozenější

Ostatní jazyky (nemyslím teď programovací) ve většině případů musíte osekávat kvůli diakritice a dalším odlišnostem. Naproti tomu s angličtinou nejste omezeni nijak. Nemusíte řešit nějaké časování (ziskejCas, nebo ziskatCas?) a tím si ušetříte spoustu času nad zbytečným přemýšlením. Pokud budete psát kód anglicky, budete snadněji studovat kód psaný v nějakém tutoriálu a nebudete k tomu ani potřebovat umět přeložit celý článek. Naučit se anglicky na úrovni potřebné pro programování je docela snadné. Těch technických slov moc není a spousta z nich se běžně používá i v češtině.

Psaní kódu anglicky má prostě své nesporné výhody. Naproti tomu psaní kódu v jiných jazycích je špatné a vytváří to velmi špatné návyky, ze kterých se potom budete dlouho dostávat.

Jaký máte na používání jiných jazyků při programování názor vy? Setkali jste se s tím už někdy?

24. 1. 2009 , 19:23

Urychlete si práci na projektech

Kategorie: Programování, Software // 5 komentářů » 951 shlédnutí

Pokud máte rozjetý nějaký svůj vlastní projekt, určitě ho chcete dokončit co nejdříve. Času je málo a proto je třeba s ním dobře zacházet. Začal jsem tedy analyzovat svůj čas strávený na projektu a objevil jsem asi největší trhlinu. Pokud právě dělám na nějaké konkrétní činnosti (ať už se jedná o implementaci nové featury, refaktoring, nebo opravování nějaké chyby) tak problémy nejsou. Vím co mám dělat a vím k čemu směřuju. Problém ale nastává v momentě, kdy tuto činnost dokončím. Většinou nastává dlouhá chvíle přemýšlení nad tím, co je třeba udělat a vybíráním nějaké činnosti, na kterou mám zrovna náladu. Odhadem mi tato činnost zabere až 40% času a mnohdy končí tím, že si dám „pauzu“ a přestanu se práci na projektu věnovat.

V momentě kdy jsem si uvědomil kolik času tímhle zabiju jsem s tím začal něco dělat. Potřeboval jsem nějaký systém vedení úloh. Automaticky jsem vyřadil seznam úkolů v Outlooku (a tím pádem i ve WM), protože tyhle úkoly tam u mně nemají co dělat. Zkoušel jsem několik aplikací pro vedení seznamu úkolů, ale většina z nich mě odradila svým user-unfriendly rozhraním. Dokonce jsem začal hledat řešení i mezi různými issue a bug trackery, jenže to bylo ještě horší. Tyhle systémy jsou hodně komplexní a pro jednoduchou zprávu úloh se prostě nehodí. Nehodlám strávit většinu času reportováním a udržováním takového systému.

Když už jsem to chtěl vzdát, dostal jsem od kolegy v práci super tip na skvělý ToDoList. Ještě ten den jsem tu aplikaci vyzkoušel a musím říct, že je to přesně to co jsem hledal. Aplikace je docela rozsáhlá a nabízí spoustu možností a nastavení. Na druhou stranu jde ale docela snadno vše nastavit podle potřeb jednotlivce.

Osobně jsem si pohled na úkoly osekal co nejvíce. U jednotlivých úloh mě tedy zajímají tyto údaje:

  • Priorita – tady je to jasné. Úkoly s vyšší prioritou by měly být splněny co nejdříve. Většinou se jim snažím dávat přednost.
  • Odhad (estimate) – odhadování času do ukončení úkolu je noční můra snad pro každého developera. Odhadnout přesně dobu, kterou úloha zabere je hodně složité a málokdy se ji podaří odhadnout dobře. Jedná se ale jen o odhad (který by se měl co nejvíce blížit skutečnosti), takže se počítá s tím, že to nebude úplně přesná hodnota. Proč ji ale používám i u soukromého projektu? Je to pro mě důležité v momentě, kdy vím že mám na programování třeba jen hodinu. Můžu tedy vybírat úlohy, které bych měl být schopen bez přerušení stihnout v daném čase.
  • Procentuální stav - u této položky jsem docela váhal. K jejímu použití jsem se ale rozhodl hlavně z důvodu, že když měním procentuální stav úlohy, tak se dynamický mění i časový odhad. Díky tomu nemusím pořád přepisovat odhady a mám alespoň orientační přehled nad tím, co je v jakém stavu.

Toť vše. Více položek by mě zbytečně zdržovaly a nevidím v nich nějaký větší přínos pro mé potřeby. Samozřejmě ke každé úloze ještě patří název úlohy a nějaký komentář. Právě ty komentáře jsou hodně užitečné. Zobrazují se v závorce za názvem úlohy (toto chování jde vypnout) a pokud úlohu označíte, komentář se zobrazí ve zvláštním panelu. Komentáře potom upřesňují obsah dané úlohy a případně nějaké další potřebné informace.

Každá úloha může obsahovat několik dalších pod-úloh, díky čemuž si můžete větší úlohy rozdělit na několik menších a splnitelnějších.

A smysl toho všeho? Když dokončím nějakou činnost na projektu, nebo ten den s vývojem začínám, stačí otevřít seznam úloh. V přehledu úloh si vyberu tu, která mi vyhovuje po časové stránce a v případě několika časově shodných úloh volím podle priority. Odpadá mi tedy doba přemýšlení nad dalšími kroky (nebo se tato doba zkrátí na přijatelné minimum) a nemusím se pak vymlouvat nad tím, že nevím co dál dělat. Tento systém používám teprve krátce, nicméně se mi už osvědčil a můžu ho doporučit všem, kteří měli stejný problém s rozhodováním jako já :)

Zde přikládám screenshot takového ToDo listu:

ToDoList

Odkaz na domovskou stránku projektu: http://www.codeproject.com/KB/applications/todolist2.aspx

A co vy? Vedete si u svých projektů nějaký ToDo list?

26. 12. 2008 , 12:24

Co mi přinesl rok 2008

Kategorie: Programování, Ze života // 11 komentářů » 1,078 shlédnutí

Tímto článkem bych rád zahájil novou tradici – psaní článků na konci roku, které shrnují události v daném roce. Nepředpokládám, že by to mohlo někoho zajímat, proto tyhle články vznikají spíše pro mou potřebu. V budoucnu si určitě rád připomenu některé střípky z minulosti a právě tyto roční resumé jsou pro to ideální. Nebudu to dále okecávat a raději začnu.

Celý článek..

3. 12. 2008 , 18:16

Získejte knihu Moderní programování úplně zdarma

Kategorie: Programování // 6 komentářů » 1,604 shlédnutí

Microsoft přišel s nabídkou zaslání knihy Moderní programování- učebnice pro začátečníky zcela zdarma. Knih je jen omezené množství.

Další informace o knize, včetně obsahu najdete na http://www.moderniprogramovani.cz/. Vypadá to, že kniha je vhodná pro úplné začátečníky v oblasti programování a může sloužit jako dobrý úvod do této problematiky. Je jasné, že kniha se bude zabývat Microsoft technologiemi a naučí vás programovat v C#.

Původní cena knihy je 250Kč, takže nabídka je to určitě zajímavá. Kvalitu knihy ovšem posoudit nemůžu.

Knihu můžete objednat na adrese http://www.microsoft.cz/akce/moderniprogramovani/.

29. 11. 2008 , 20:38

Jak vytvořit Java aplikaci s podporou více překladů

Kategorie: Programování // 1 komentář » 2,032 shlédnutí

Při vytváření aplikace musíte myslet na spoustu věcí. Dneska se budu zabývat tvorbou multi jazykových aplikací. K čemu je to vůbec dobré?  Pokud vytvoříte aplikaci v češtině, budou ji používat pouze lidé, kteří rozumí česky. Pokud aplikaci uděláte anglicky, bude rozsah uživatelů, kteří budou schopni s aplikací pracovat mnohem větší. Pořád bude ale rozsah uživatelů omezen použitým jazykem.

Je tedy dobré se tohoto omezení zbavit. Samozřejmě zapomeňte na něco podobného:

if (jazyk == "český")
    zobraz("Ahoj!");
else if (jazyk == "anglicky")
    zobraz("Hello!");
else ...

Tohle je totiž snad ten nejhorší způsob, jak problém s jazyky vyřešit. Co když bude třeba přidat nový jazyk? Bude se muset upravit všechny zdrojáky, které pracují s texty. Každý zásah do zdrojového kódu sebou nese riziko zanesení chyby a v tomto případě, kdy se bude upravovat dost kódu, je velmi pravděpodobné, že dřív nebo později k chybě dojde. Navíc nemáte texty nijak pohromadě a jejich hledání a úprava je složitá.

Mnohem lepší je mít uložené texty někde mimo. Když pak budete chtít editovat texty, stačí jen upravit soubor obsahující texty a nemusíte znovu překládat aplikaci. Pokud bude soubor snadno editovatelný a jeho struktura bude jednoduchá, budou moct na překladu pracovat i uživatelé – neprográmatoři. Ještě lepší řešení je dodávat lokalizační program, který umožní uživatelům editovat jazyky ještě snadněji. Jak toho docílit ve vaší Java aplikaci si ukážeme na názorném příkladu.

Celý článek..

Java poradna – sběr nápadů

Kategorie: Programování // 4 komentářů » 922 shlédnutí

Tenhle článek je pro všechny Java programátory, kteří se náhodou zatoulají na tento blog. V Javě dělám teprve krátce, ale myslím si, že už nějaké zkušenosti s ní mám. V poslední době jsem zde sepsal nějaké články o Javě a rád bych napsal i další. Nějaké nápady v zásobě mám, ale hodila by se mi další inspirace.

Pokud tedy začínáte v Javě a není vám něco jasné, dejte mi vědět zde v komentářích. Pokud mě dotaz zaujme (a bude v rámci mých schopností), zpracuju na to téma nějaký článek.

A proč to vlastně dělám? Když píšu takový článek, tak se při tom i učím. Protože nechci v odborném článku uvádět nesmysly, často si informace ještě ověřuju. Díky tomu se přinutím k tomu, abych si zopakoval základy, nebo popřípadě se doučil některé maličkosti, které jsem odkládal. Navíc pokud dokážu dát svým znalostem nějakou tu písemnou formu, je to pro mně dobrý způsob jak zjistit, zda dané problematice opravdu rozumím, nebo si to jen myslím :) No a nakonec se to hodí také proto, že mám děravou hlavu, a co si nezapíšu, to nevím. Takhle se můžu kdykoliv vrátit ke svým předchozím poznámkám a můžu z nich dále vycházet.

Z toho vyplývá, že je to prospěšné pro všechny zůčastněné :) Tak hurá do toho, už se těším na ty komentáře…

23. 11. 2008 , 18:57

Jak spouštět JUnit testy pomocí Antu

Kategorie: Programování // přidat komentář » 1,792 shlédnutí

JUnit je framework, který slouží v Javě k jednotkovému testování. V tomto článku se nebudu zabývat filozofií testování, zmíním zde jen způsob, jak jednoduše integrovat testy do vašeho build procesu takovým způsobem, abyste v případě vzniku chyby věděli, že k chybě došlo.

Co k tomu budeme potřebovat? Především Ant a JUnit knihovnu.

Kód, který budeme testovat

Uvedeme si jen takovou jednoduchou třídu:

public class SimpleClass {
	public int getSum(int a, int b) {
		return a + b;
	}
}

Jednoduchý JUnit test

Nejdříve si napíšeme jednoduchý test – uvedu zde pouze ilustrační příklad, který otestuje naší třídu. Tady máme náš test:

import static org.junit.Assert.*;
import org.junit.*;
 
public class SimpleTest {
 
	static int number1;
	static int number2;
	static int number3;
 
	@BeforeClass
	public static void init() {
		// Tato metoda se zavolá jednou - na začátku testování
		number1 = 5;
		number2 = 3;
		number3 = 8;
	}
 
	@Before
	public void setUp() {
		// Tato metoda se zavolá před každým testem
	}
 
	@AfterClass
	public static void delete() {
		// Tato metoda se zavolá po skončení posledního testu
	}
 
	@After
	public void clear() {
		// Tato metoda se zavolá po skončení každého testu
	}
 
	@Test
	public void firstTest() {
		SimpleClass simpleClass = new SimpleClass();
 
		assertTrue( number3 == simpleClass.getSum(number1, number2) );
	}
}

Všimněte si, že název testovací třídy obsahuje řetězec Test. Proč tomu tak je vysvětlím později.

Ant

Nyní máme napsaný jednoduchý test. Aby nám testy k něčemu byly, měly by se spouštět co nejčastěji. Myslím si, že nejvhodnější chvíle na spuštění JUnit testu je doba těsně před vytvořením výsledného spustitelného balíku. To zaručí, že pokud vytvoříme nějaký spustitelný balík (jar soubor), bude vše potřebné řádně otestováno. Ideální je nastavit to tak, aby při selhání jakéhokoliv testu nebyl tento balík ani vytvořen.

Vytvoříme si proto build.xml soubor:

< ?xml version="1.0" encoding="UTF-8"?>
<project name="SimpleProject" default="createJar" basedir="../">
	<property name="mainclass" value="SimpleClass"/>
	<property name="srcdir" value="./src"/>
	<property name="bindir" value="./bin"/>
	<property name="junit" value="./lib/junit-4.5.jar"/>
	<property name="junit-report-dir" value="./report"/>
 
	<target name="compile">
		<javac srcdir="${srcdir}" destdir="${bindir}" >
		</javac>
	</target>
 
	<target name="createJar" depends="compile,JUnitTests">
		<jar destfile="Simple.jar">
			<fileset dir="${bindir}"/>
			<manifest>
				<attribute name="Main-Class" value="${mainclass}"/>
			</manifest>
		</jar>
	</target>
 
	<target name="JUnitTests" depends="compile">
		<mkdir dir="${junit-report-dir}"/>
		<junit haltonfailure="yes">
			<formatter type="plain"/>
	   		<classpath>
	   			<pathelement location="${junit}" />
	   			<pathelement location="${bindir}" />
	   	  	</classpath>
			<batchtest fork="yes" todir="${junit-report-dir}">
		    	<fileset dir="${srcdir}">
		      		<include name="**/*Test*.java"/>
		    	</fileset>
		  	</batchtest>
		</junit>
	</target>
</project>

Jak to funguje?

Default target pro Ant je createJar, který je závislý na targetu compile a JUnitTests. To znamená, že se nejdříve zkompilují zdrojové kódy, potom se spustí testy a nakonec se vytvoří jar soubor.

Elementu junit můžete nastavit attribut halfonfailture, který pokud je nastaven na yes přeruší buildování v případě, že některý test neproběhne v pořádku. To se nám hodí – pokud testování selže, nevytvoří se jar soubor.

Do elementu classpath uvedeme cestu k JUnit knihovně (tu musíte stáhnout z této stránky) a také ke zkopilovaným třídám.

Samotné testování zařídí element batchtest, který je určen k hromadnému testování. V mém případě jsem si jej nastavil tak, aby otestoval všechny soubory, které mají v názvu řetězec Test. Díky tomu se otestuje i náš SimpleTest.

Pokud vše proběhne v pořádku, můžeme se na výsledky testu podívat do souborů uložených v adresáři report. V případě vzniku chyby můžete v těchto souborech najít podrobnější informace o chybě.

Krátké shrnutí na závěr

Pokud budete psát JUnit testy důsledně, máte díky tomuto postupu velkou šanci na odhalení chyby hned, jak se objeví. Díky integraci do build procesu si nemusíte spouštění testů nijak hlídat. Samozřejmě vím, že JUnit testy nikdy nepokryjí 100% kódu, takže i přes tuto snahu může nějaká chyba proklouznout. Nicméně tyto testy neslouží k odstranění rizika vzniku chyby – JUnit testy pouze zmenší šanci, že se taková chyba objeví.

Všechen přiložený kód jsem otestoval, nicméně je možné, že jsem někde mohl udělat chybu. Pokud tedy najdete nějakou chybu, nebo nesrovnalost, prosím dejte mi vědět v komentáři pod článkem.