Autor: Petr Ferschmann

Effective Exception

Občas je možné slyšet, že kontrolované výjímky v Javě (checked exceptions) jsou experiment, který se nepovedl. Bruce Eckel je ve svém článku (Does Java need Checked Exceptions?) odsuzuje a říká, že by Java byla lepší bez nich.

Autor říká, že kontrolované vyjímky obvykle nedokážeme ošetřit namístě a proto je pošleme „výš“ – buď je zabalíme do jiné (obecnější) vyjímky nebo naší metodu označíme, že vyvolává tuto vyjímku (to ovšem znamená porušení abstrakce – proč by volající měl vědět něco o tom, že čtu ze souboru nebo z databáze?).

Důkazem tvrzení, že s kontrolovanými vyjímkami není něco v pořádku, je i změna HibernateException z kontrolované na nekontrolovanou (mezi verzemi hibernate 2.x a 3.x).

Článek
Effective exception ovšem říká, že kontrolované vyjímky nejsou tak úplně špatné. Jen jsou špatně použité v základních Java API.

Myslím, že autor v tomto článku to vystihl správně. Doporučuji k přečtení. Toto je také důvod, proč se kontrolované vyjímky nejeví jako problém už u malých ukázkových programů – prostě u nich chápeme jinak chybu programu (contingency) a selhání systému (fault), než u velkých projektů.

Testování programů metodou černé skříňky

Metoda černé skříňky spočívá v testování softwaru tak říkajíc s klapkami na očích.
Do této metody patří:

  • Testy splněním
  • Testy selháním
  • Testování stavů

    • Můžeme testy provádět náhodným klikáním, zkoušet zadávat čísla a různé vstupy a snažit se vyvolat chybový stav programu. Ze začátku se vám bude dařit nalézat hodně chyb, zvláště pokud ještě probíhá vývoj, ale časem se dostanete do stavu, kdy budete muset začít při testování používat pokročilejší techniky.
    Pokračování textu Testování programů metodou černé skříňky

    Automatická správa zdrojů

    V C++ existuje jedna velmi používaná technika pro získávání/uvolňování zdroje (zamykání, alokaci paměti, vrácení databázového spojení do connection poolu, apod.) – používají ji např. autopointery (auto_ptr<> a Smart Pointers z boost.org).

    Základní myšlenkou je, že vytvoříte jednoduchý objekt na zásobníku. V jeho konstruktoru získáte zdroj a v destruktoru opět uvolníte. Celé je to velmi efektivní, protože dojde k alokaci paměti jen na zásobníku. Pokračování textu Automatická správa zdrojů

    FCKFaces

    Součástí JSF implementace MyFaces je i balík rozšiřujících komponent Tomahawk. Ten obsahuje i komponentu pro wysiwyg editaci (<h:inputTextarea/>). Ta je celkem otřesná, pokud ji porovnáte třeba s FCKEditorem. Narazil jsem ovšem na FCKFaces – JSF plugin, který používá FCKEditor.

    Instalace je jednoduchá. Stáhnete jar, přidáte do classpath (např. do pom.xml, nainstalujete do repository) a v JSP stránce můžete použít:

    <ui:composition xmlns:fck="http://www.fck-faces.org/fck-faces">

<fck:editor value="#{akce.obsah}" width="100%" toolbarSet="Basic"/>

    Aby ovšem modul fungoval správně (totiž všechny JavaScript soubory a obrázky jsou součástí jaru), musíte ještě použít FCKServlet a přidat jej do web.xml:

    <servlet>
        <servlet-name>FCKServlet</servlet-name>
        <servlet-class>org.fckfaces.util.Servlet</servlet-class>
</servlet>

<servlet-mapping>
        <servlet-name>FCKServlet</servlet-name>
        <url-pattern>/fckfaces/*</url-pattern>
</servlet-mapping>

    Začínám si myslet, že by bylo dobré, aby součástí JSF specifikace byl způsob exportu souborů potřebných pro JSF komponenty (MyFacesExtensions, FCKServlet, …). A přitom se jedná jen o poskytnutí souboru při požadavku.

    Tester, urážka či vážená profese 1. (Testy specifikace)

    Spousta začínajících programátorů byla postavena nejprve do pozice testera. Dosti často jsem slyšel od nich, už abych začal programovat. Ani já jsem se netvářil zrovna nejradostněji, když mě v práci nechali psát test plány a testovat software.

    Co je obsahem práce testera, testerů nebo oddělení QA (Quality assurance)?
    Proč programátoři nemají rádi testery a někteří testeři chtějí být programátoři?
    Je tester perspektivní zaměstnání?
    Pokračování textu Tester, urážka či vážená profese 1. (Testy specifikace)

    How to use Java6 in Ubuntu edgy/dapper

    I was looking on internet for simple way how to use Java6 (aka Mustang) in edgy/dapper. I wanted to use it same way I do with Java5. So I looked for Java6 debian package. Finally I found solution:

    1. Visit http://packages.ubuntu.com/feisty/source/sun-java6 and download all three source files (bottom of the page. They ends with .dsc, .tar.gz and .diff.gz).
    2. Put them in same directory (like /tmp/java6).
    3. Run dpkg-source -x *.dsc
    4. Enter the newly created directory (in my case sun-java6-6-00)
    5. Run fakeroot debian/rules binary
    6. Debian packages will be created in upper directory. Install them.
    7. To use Java6 by default run: update-alternatives --config java

    I hope that soon we will have Java6 in edgy backports or at least binary packages.

    Maven Archetype: JBoss Seam

    Pokud si chcete zjednodušit integraci Mavenu 2 a Seam zkuste si přečíst článek Maven Archetype for JBoss Seam. Generuje kostru pro použití Seamu s MyFaces, Facelets a EJB 3.0.

    Archetype je název pro generátor kostry aplikace pro Mavenu.

    Měl jsem problémy aplikaci rozběhnout. Pomohlo až ruční stažení a umístění do lokální cache.

    Aktualizace: Můžete také vyzkoušet Seam Archetype, který jsme vytvořili pro naše potřeby.

    Začínáme s Webovými stránkami v Javě

    K napsání tohoto záznamu mně inspirovala diskuse, že vývoj jednoduchých webových stránek v Javě je příliš složitý. Chtěl bych tedy ukázat, že i v Javě je to jednoduché

    Nechci se pustit do srovnávání jazyků. Chtěl bych jen ukázat, že i Javu lze snadno používat v prostředí, kde tak kraluje PHP – a to je tvorba jednoduchých webových stránek.
    Pokračování textu Začínáme s Webovými stránkami v Javě