Author Archives: admin

Zjednodušte si práci s Mavenem

Někteří z vás si možná všimli, že jsem dlouho nic nenapsal. Neměl jsem moc času, programoval jsem si prográmek pro usnadnění práce s Mavenem. Kdo s Mavenem pracujete, asi víte, že jeden z největších problému při práci s ním je hledání artefaktů (knihoven) ve vzdáleném repository. Pro Eclipse existuje plugin (http://m2eclipse.codehaus.org/), který by to měl usnadňovat. Ale nemám s ním moc dobré zkušenosti. Není příliš stabilní. Dále existuje stránka http://www.mvnrepository.com/, která umožňuje artefakty hledat. Ta mi také moc nevyhovovala.

Když jsem se snažil portovat aplikaci sestavovanou Antem do Mavenu, tak mi po hledání veze a umístění desátého jaru došla trpělivost. Napsal jsem si prográmek s poetickým jménem m2-repoindex (http://m2-repoindex.krecan.net/), který moje potřeby řeší.

Takže ve zkratce, je to Java Web Start aplikace, která umožňuje hledat artefakty podle jména nebo regulárního výrazu viz. obrázek

Hledání podle jména
Věc která mi ve všech programech dosud chyběla, je identifikace jarů. Asi to znáte, máte na disku jar a potřebovali byste znát verzi a kde ho v Maven repositáři najdete. m2-repoindex vám s tím pomůže. Načte jar, spočítá jeho MD5 a podle něj se pokusí najít odpovídající artefakt.

Hledání JARu
Docela užitečná věc, zvláště když těch jarů máte několik desítek.

Co jsem se z toho naučil?

  1. Java Web Start je docela zajímavá technologie. Umožňuje snadnou instalaci Java aplikací a to včetně ikony na ploše a ve start menu. Stačí jen kliknout na odkaz. Měly by fungovat i automatické updaty, ale to se mi zatím nepodařilo zprovoznit.
  2. Potvrdil jsem si, že dělat aplikaci ve Swingu jde už docela dobře dělat i v Eclipse.
  3. Zjistil jsem, že psát i takto malou aplikaci po večerech zabere dost času. Prvotní napsání jde snadno, ale dostat ji do stavu, kdy se dá zveřejnit je dost náročná činnost. Připadá mi, že přítelkyně začíná žárlit na můj počítač, chodí kolem nás se sekyrou v ruce a nějak divně se usmí

Proč mám rád get a set metody

Ano přiznávám se jsem staromilec. Možná dokonce i zpátečník. Mám rád get a set metody a nerad vidím snahu se jich zbavit. Občas se na internetových diskuzích setkám s návrhy jak „lépe“ řešit přístup k vlastnostem objektu. Dokonce se jeden takový návrh dostal do návrhu změn v Javě 7. Návrhy jsou podobné následujícímu:

Místo

private String foo;
public String getFoo() {..}
public void setFoo(String foo){..}

budeme psát

public property String foo;

nebo ještě lépe

@property
private String foo;

Tím si ušetříme spoustu práce s nudným psaním get a set metod. Kompilátor všechno krásně vygeneruje za nás.

Nejvíc mi vadí to, že nikde nevidím problém, který se těmito návrhy má řešit. Nikdo přece už dávno get a set metody nepíše, všechno to za nás dělá vývojové prostředí. Napadá mě jediný argument, a to že tím pomůžeme Javě v nesmyslné válce o implementaci čehokoli na co nejméně řádek. Dosáhneme tím o trochu lepší výsledky při porovnávání počtu řádek s implementací v Ruby nebo C#. To si opravdu všichni myslí, že počet potřebných řádek kódu je to co určuje kvalitu jazyka?

Zpět ale k uvedeným návrhům. Odhlédněme od toho, že ve skutečnosti neřeší žádný reálný problém. Podívejme se co by jejich přijetí znamenalo. Za předpokladu, že by za nás get a set metody generoval kompilátor bychom nezískali vůbec nic. To už rovnou můžeme psát

public String foo;

a přistupovat k poli přímo. Jediné v čem by nám „zjednodušený zápis“ mohl pomoci by mohlo být nějaké automagické sledování změn hodnot a generování příslušných událostí. To bych ale raději řešil aspekty.

Co mi na druhou stranu get a set metody přinášejí? To samé co objektově orientované programování! Možnost skrytí implementace, možnost defenzivního programování a obecně možnost volby. Je totiž mnoho případů, kdy get a set metoda nejsou v té triviální podobě tak jak nám je generuje GUI. Často potřebuji zařídit, aby bylo pole jenom pro čtení. Například když píši neměnitelnou (immutable) třídu. V tom případě udělám set metodu private. Nebo ji udělám protected, když chci, aby ji mohly měnit jen spřátelené třídy. Už vidím návrh, že by se to dalo řešit takto:

public property readonly change protected String foo;

Krása. Neřeší to ale defenzivní programování. Případy, kdy místo

public void setDate(Date date)
{
this.date = date;
}

píši

public void setDate(Date date) {
this.date = new Date(date.getTime());
}

To za mě jazyk nemá šanci vyřešit. To si musím napsat sám. Počítač neví, že chci zabránit tomu, aby mi kdokoliv kdykoliv změnil datum, které mám uložené a proto si chci vytvořit defenzivní kopii. Podobně u vracení kolekcí neví, že nechci aby mi ji někdo měnil a chci ji vracet neměnitelnou.

public List getList() {
return Collections.unmodifiableList(list);
}

A to už vůbec nemluvím o kontrole vstupních parametrů přicházejících do set metody.

Teď se můžeme začít hádat o procenta. Kolik je metod, u kterých mi stačí jednoduchý standardní tvar a kolik je těch, které potřebuji nějak modifikovat? Nemohli bychom náhodou tu většinu řešit magickou anotací a těch pár co potřebujeme změnit napsat postaru? Ne nemohli! Dostali bychom dva různé zápisy pro tu samou věc, museli bychom nějak řešit co dělat, když použijeme anotaci i get metodu a ze všeho by vznikl hrozný zmatek. Ano mohlo by to být stejné jako u implicitních konstruktorů, ale nemyslím si, že nám to všechno stojí za to, jenom kvůli pár ušetřeným řádkům kódu.

Knihovnička softwarového inženýra: Facts and Fallacies of Software Engineering

Chtěl bych se s vámi podělit o zážitky z četby knihy Facts and Fallacies of Software Engineering od Reborta L. Glasse. Na první pohled je to tenoučká kniha, do které se toho moc vejít nemůže. Nicméně uvnitř najdete 55 faktů a 5 klamů o softwarovém inženýrství. Nečekejte žádné novinky, spoustu faktů najdete i jinde, spoustu jich je samozřejmých a většinu věcí lidé prostě vědí.

Co je tedy na té knize tak zásadní, že vám tu o ní píši? Je to právě nashromáždění věcí, které by měl každý software inženýr vědět. Uveďme příklad:

Fakt 8: Jeden ze dvou hlavních důvodů splašení projektů jsou špatné odhady.

Ano, všichni to vědí. Projekt je často ve zpoždění protože někdo někdy udělal odhady pracnosti a z těch se po celou dobu projektu vychází. Odhady se málokdy upřesňují. A téměř nikdy jejich autoři nedostávají zpětnou vazbu. Proč tomu tak je? No přeci z obchodních důvodů. Aplikace musí být hotova do konce roku a musí stát méně než X miliónů. Je tedy naprosto jasné, jaké si můžeme dovolit odhady. Nebo ne?

Možná přemýšlíte, co je ten druhý důvod splašení projektů. Než budete číst dál, zkuste na to přijít sami. Tak co, máte to?

Fakt 23: Jeden ze dvou hlavních důvodů splašení projektů jsou nestálé požadavky.

Zase žádná novinka. V některých společnostech jsou sběr požadavků a zpracování změn docela zvládnuté. Pamatuji ale projekt, kdy týden před plánovaným ukončením vývoje ještě nebyly jasné všechny požadavky. A ty co už byly stanoveny, se často měnily. Asi si dovedete představit kvalitu výsledného produktu.

Ale zpět ke knize, pokud vás z psaní aplikací zajímá i něco víc než jen bušení kódu, tuto knihu vřele doporučuji. Nečekejte však od ni žádné rady jak řešit problémy. Dostane se vám jen popis faktů a hodně odkazů na literaturu pro podrobnější informace. Na rozloučení ještě asi nejvtipnější fakt:

Fakt 14: Odpověď na studii proveditelnosti je skoro vždy „ano“.