26. října 2007

Programujeme nebo lepíme

Přiložím si také trochu do mlýna k diskusi, zda jsou vizuální nástroje dobré nebo špatné. Diskuse se nejprve rozvinula v konferenci konference@java.cz, na to se GUI nástrojů zastal Dagi v příspěvku Potřebujeme silné nástroje a následně Pavel Kolesnikov přidal Potřebujeme domyšlené nástroje. Já se chci trochu vrátit k jádru pudla, zda GUI nástroje ano nebo ne.

Na úvod se přiznám, že nejsem velký přívrženec GUI klikátek, asi už jsem z moc starý školy a jsem moc zakořeněnej v unix shellu. Ale napadlo mě, že dneska už vlastně tolik neprogramujem, spíš skládáme (lepíme) dohromady existující kousky. Však se potichu šušká, že vše už bylo alespoň jednou napsáno.

Ale jaký je rozdíl v použití haldy frameworků, které vše řeší za mě, či GUI klikátka, které ten kód vygeneruje? Ja si myslím, že v podstatě rozdíl není. Cíl je stejný, ale cesta je různá. Mám aplikaci a nemusím moc programovat.

Takže proč vzbuzují GUI klikátka negativnější pocity (alepoň v některých lidech, např. jako já) než frameworky. Za sebe mohu říci že, když jsem je používal já, tak mi hezky zpívaly když mě lapaly. A když jsem je začal používat a následně jsem je potřeboval, pak mě hodily přes palubu, protože složitější věci nešlo realizovat, jak jsem chtěl. A já nerad ustupuju.

A jaký je tedy závěr? I nadále programujeme, ale stále více se uchylujeme k lepení. A zda lepíme pomocí GUI klikátek nebo ne, to si musí každý rozhodnout sám, ale já jsem se rozhodl: "Raději ne, děkuji".

PS: Nejlepším lepidlem posledních let jsou anotace. Abychom se do toho lepidla, ale nezalepili sami.

25. října 2007

Architektura naruby

Právě jsem si přečetl Dagiho příspěvek Do pranice: Spring Web Flow a nebo JBoss Seam a nemohl jsem se nepřidat se stížností na dnešní frameworky. Už toho mám dost, jak se neustále pod rouškou jednoduššího vývoje a já nevím čeho všeho porušují základní pravidla vrstvení aplikace: nižší vrstva nemá vědět, ža nad ní je nějaká vrstva vyšší a využívat pouze služeb svých a nebo služeb vrstev pod ní.

JBoss Seam
je úplně klasickým příkladem této šílenosti, protože vrstvy nižší (v tomto případě např. session beany) jsou oanotovány vším možným co se týká jejich komunikace s JSF (přes Seam) jako vrstvou vyšší. Cestou ven je samozřejmě použití XML konfigurace, ale ta se v souvislosti se Seamem skoro neprezentuje.

Z podobného důvodu používám s Hibernate vždy XML konfiguraci. Prostě nechci aby můj model byl zaneřáděn anotacemi, které ke své funkci vůbec nepotřebuje. Mapování uložení do DB je přeci věc DAO vrstvy a model se o něj rozhodně nemá starat.

Ano, je to složitější, pracnější, ale rozhodně je to flexibilnější. Řada čtenářů my možná namítne, že na to není čas, že je jim tato flexibilita na nic atd. Je to každého věc, ale já mám flexibilitu rád a nevzdám se jí. Navíc mám rád pokud je kód přehledný, hezky strukturovaný a provázaný jenom jedním směrem, shora dolů a ne i naopak.

22. října 2007

Jednoduše na CSS Sprite

O CSS Sprite už jsem psal v příspěvku Zaměřte se na fronted, takže jenom z rychlíku. Jedná se o více obrázků rozložených v jednom velkém, které jsou následně pomocí CSS backgroup zobrazovány. Získává se tím větší výkon stránky, protože pro její zobrazení není nutné natahovat 30 malých obrázků (=30 requestů), ale pouze jeden větší.

A já vám nyní předkládám odkaz na stránku, kde si takový CSS Sprite můžete vytvořit. Zazipujte své malé obrázky, uploadněte je a získáte zpět jeden velký. Proč se s tím pachtit v GIMPu.

19. října 2007

Jak na vlastní design File Input položek formulářů

Každý již jistě někdy psal stránku, která umžňovala upload nějakého souboru. To je problém celkem jednoduše řešitelný, ovšem problém nastává, pokud máte nějaký design tlačítek na stránce a chcete, aby i tlačítko pro výběr souboru mělo jednotný design. A zde se už naráží.

Ovšem i toto je věc řešitelná (ve světě počítačů snad neexistují neřešitelné problémy). Celý postup názorně popisuje Shaun Inman ve svém blogu. V principu jde o kombinaci CSS, DOM a JavaScriptu.


Funguje to tak, že se input obalí wrapper-tagem (např. label), jemuž se nastaví pozadí na námi požadovaný vzhled. Následně se nastaví neprůhlednost (opacity) tagu input na 0, čímž se zneviditelní, ovšem stále je klikatelný. No a zavěrečný krůček nám pomůže udělat JavaScript, kterým zařídíme, že tlačítko pro výběr souboru bude vždy umístěno pod ukazatelem myši, pokud je uvnitř našeho wrapper-tagu.

A teď v jakých prohlížečích to funguje? Překvapivě IE 5.5+, Firefox 1.5+, Safari 2+. Uspokojivě je použitelné v IE 5.01 a Opeře.

18. října 2007

Jak ovládat Eclipse pomocí prohlížeče

O Eclipse RAP se už blogovalo (např. dagi), ale o integraci Eclipse s prohlížečem zatím ne. Celé se to jmenoje Web Broser-Based Integration with Eclipse IDE, a jde o skutečné ovládání Eclipse pomocí prohlíče. Nainstalujete speciální plugin včetně Jetty serveru a to je celé. V nastavení eclipse spustíte server, do prohlížeče (pozor celé to funguje pouze ve Firefoxu) zadáte adresu http://localhost:9008/ a zobrazí se vám váš Eclipse.

A takhle vypadá originál:

Celé to funguje velmi jednoduše, skoro se mi chce napsat trapně jednoduše, UI Eclipsu se překládá do XUL Firefoxu, který jej pak zobrazuje.


Zatím je to jenom preview, ale možnosti jsou opravdu velmi široké, od přístupu ke své Eclipse instalci pomocí prohížeče (či k centrální instalaci s definovanými pluginy a projekty), při podpoře více uživatelů (zatím chybí) dokonce může více uživatelů sdílet jednu instalaci Eclipse až po vývoj webových aplikací pomocí Eclipse RCP.

12. října 2007

Vývoj aplikace za běhu

Dostala se mi pod nos opravdu zajímavá věcička, která si říká JavaRebel. O co se jedná? Jedná se o udělátko, které za běhu aplikace dokáže reloadovat třídy. A pozor, nepoužívá k tomu class loader (tak problém řeší Howard Lewis Ship pro Tapestry 5) ani hot swap (jenž je v javě od verze 1.4).

Ale jak to tedy dělají? Jak sami říkají, pomocí změny bytecodu a trochu kouzel. Každopádně JavaRebel podporuje všechny změny tříd až na změnu v dědičnosti (tj. extends a implements). Dá se použít jak při vývoji webových tak klientských aplikací.

Po Terracotte je to další technologie, která používá manipulace s bytecodem k docílení až zázračných věcí.

Jediné mínus je, že se jedná o komerční produkt, a stojí 100$ na vývojáře. Ovšem to je investice, která se vrátí snad už za týden.

Odkazy


8. října 2007

Kam se ztrácí zkušení programátoři

Přečetl jsem si velmi zajímavý článek API: Design Matters od Michi Henninga. Je velmi poučný a vhodně doplňuje prezentaci Jaroslava Tulacha Jak psát API, které přežije nástrahy času (slidy, video). Takže rozhodně si ho přečtěte, protože API navrhuje každý z nás.

Ovšem co mě skutečně praštilo do očí je jedna z posledních kapitol, která se designem API zaobírá spíše okrajově. Hovoří o tom, že zkušení programátoři (a v podstatě i designéři či architekti) přestávají existovat. Jak je to možné?

Upřímně kolik znáte programátorů, kterým je přes 40? Já jsem zatím poznal tři (a zkušenost je jednoznačně pozitivní), takže mladší jednoznačně převládají. Proč? Protože je sociální tlak, aby programátor skončil s programováním včas a přeorientoval se na designéra nebo architekta, v nejhorším případě na project managera, protože přeci nemůže na ty mladé kluky, co se nové technologie učí na škole, stačit.

Ovšem co umí mladý kluk, když opouští univerzitu. Umí minimálně 5 programovacích jazyků (což by jistě s knihou a chvilkou času zvládl i bez učitele), umí řadu děsně zajímavých algoritmů, které většinou nikdy nepoužije a když tak velmi vyjímečně. Ale to co by měl používat denně: objektový design, psaní přehledného kódu, test driven development, code coverage, continuous integration, nedej bože jiné metodiky vývoje než vodopád (nejlépe scrum). To nezná.

A kde je problém designérů a architektů? Jsou drazí a je jich málo. Proto nemohou na projektu zůstávat po celý jeho životní cyklus a tím se odtrhávájí od reality, protože netuší jaké dopady mají jejich rozhodnutí. Chybí jim zpětná vazba.

Takže kdeže jsou ti zkušení? Neexistují ...

4. října 2007

Velmi jednoduchá validace HTML formulářů JavaScriptem

Dneska mi padla do oka velmi jednoduchá knihovnička na validování HTMl formulářů pomocí JavaScriptu - JSValidate. V podstatě bych řekl, že se mi víc líbí nápad, jak jsou položky formuláře označovány na co mají být validovány, než samotná knihovna, protože obsahuje validaci pouze JavaScriptem, tj. na klientu, a to je pro mě málo.
A co je to tedy za nápad? Prostě a jednoduše položky formuláře, tj. input tagy označíte CSS třídou podle toho, jak jej chcete validovat a přidáte následující 3 řádky na začátek stránky:

<script type="text/javascript" language="javascript" src="scriptaculous/lib/prototype.js"></script>
<script type="text/javascript" language="javascript" src="scriptaculous/src/scriptaculous.js"></script>
<script type="text/javascript" language="javascript" src="jsvalidate.js"></script>
A jste hotovy.

Příklady

Jednoduchá položka, jejíž hodnota je povinná:
<input type="text" name="name" class="jsrequired" />

Nebo položka pro číslo:
<input type="text" name="number" class="jsvalidate_number" />
A nebo položka na email, který je nutné zadat:
<input type="text" name="email" class="jsrequired jsvalidate_email" />

Jaké jsou dostupné třídy

  • jsrequired - musí být vyplněna
  • jsvalidate_number - číslo
  • jsvalidate_digits - pouze číslice
  • jsvalidate_alpha - pouze písmena
  • jsvalidate_alphanum - písmena, číslice a podtržítko
  • jsvalidate_email - email
  • jsvalidate_uscanzip - ZIP code USA nebo Kanady
  • jsvalidate_usstate - 2 znakový kód státu v USA
  • jsvalidate_usphone - telefonní číslo v USA
  • jsvalidate_creditcard - číslo kreditní karty
  • jsvalidate_ssn - Social Security Number - číslo sociálního pojištění (USA)
  • select-notfirst - používá se u selectů, kde zajistí, že první položka ze seznamu nemůže být vybrána

Závěr

Myslím, že existuje problém, kde se tato knihovná dá nasadit. Asi to nebude do žádné větší aplikace, kde bude na validační framework kladen podstatně větší nárok, především mám na mysli prováznost s validací na serveru.
Co se mi jeví jako hodně zajímavé je využití CSS tříd pro identifikaci, to je velmi jednoduché a elegantní.

Odkazy