Běžná definice odhadu je nejoptimističtější předpověď, která má nenulovou pravděpodobnost, že se splní“ … Přijetí této definice neodvolatelně vede k metodě odhadování, která by se dala nazvat
„Jaké-je-nejbližší-datum-pro-které-už-nemůžte-tvrdit-že-to-nestihnete“.
— Tom DeMarco, rok 1982
🙂
V minulém díle jsme si ukázali, jak vytvořit jednoduchou stránku v JSP (tzv. špagetový kód).
Nyní si ukážeme, jak vytvořit webovou stránku s použitím návrhového vzoru Model-View-Controller (MVC).
Pokračování textu Začínáme s Webovými stránkami v Javě 2
Mnoho z vás jistě zná modul do apache mod_rewrite, který umožňuje pomocí regulárních výrazů transformovat URL.
Lze tak přepsat URL /index.jsf?typ=clanek&id=1 na krásnější /clanky/1/. Lze jej také použít pro přesměrování uživatele z již nepoužívané adresy (např. při restrukturalizaci stránek).
U webové aplikace by měli být URL dlouhodobě stabilní tak, aby odkazy na ně fungovaly i za 10 let. Proto je dobré o nich přemýšlet. Navrhnete si strukturu aplikace a k tomu odpovídající URL. Tato přepisování umožňují oddělit adresy od použité technologie (lze ji tedy později snáze vyměnit).
Pokračování textu URL Rewriter
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ů.
Do této metody patří:
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
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ů
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.
Narazil jsem na zajímavý článek Charakterizace lidí jako nelineární, proměnlivou ale primární komponentu v softwarovém vývoji.
Autor se snaží identifikovat vlastnosti úspěšných a neúspěšných projektů.
A přišel na to, že nejdůležitější jsou lidé a jejich vzájemná komunikace. Opravdu doporučuji k přečtení.
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)