21. ledna 2008

Jak vnést trochu pořádku do CSS

Jsem puntičkář, mám rád, když věci mají jasný řád. Ale todle nějak nejde dohromady s našimi CSS soubory. Snažil jsem se malinko upravit layout stránky a vztekal jsem se s tím skoro půl dne. A pak mi srazil vaz Explorer a začal iterativní proces sbližování vzhledu Firefox vs. Explorer.

Nakonec jsem se poohlídl na webu po nějakých radách a typech, jak zanést řád do změti selectorů, atributů a jejich hodnot. Našel jsem pár šikovných rad, které jsou zřejmě lidem pracujícím s CSS delší dobu již známy, protože si je velmi pravděpodobně již vymysleli nebo přečetli. Ale pro Javisty, kteří považují CSS spíš za nutné zlo, snad budou tyto rady prospěšné (i když všechny popisované principy jsou nám již dávno známé).

Modulárnost

První věcí je modulárnost a její striktní dodržování. Přivede nás k opakovanému použití celých CSS souborů. Takže náš styl jsme rozdělili do následujících souborů:
  • Typografie - definuje základní vlastnosti HTML elementů včetně fontů, velikostí atd. Tento soubor je nezávislý na projektu.
  • Formuláře - asi nejsložitější část stylů, spousta hacků, aby formuláře vypadaly stejně ve většině prohlížečů apod.
  • Navigace - velmi často se menu aplikace dá použít napříč více projekty, takže proto jej umístěme do zvláštního souboru.
  • Layout - základní layout stránky je velmi jednoduše oddělitelný od zbytku a navíc je silně projektově závislý.
  • Barvy - definice barev je samostatná, což umožňuje jednoduché přebarvení stránek, vše máte na jednom místě.
Abychom neměli 5 CSS souborů (v souladu se závěry z Yahoo!) pak je vhodné mít ještě šestý soubor, který složí 5 zmíněných v jeden pomocí @import url("file_name.css");.

Sjednocení marginu a paddingu mezi Explorerem a Firefoxem

Následuje zjednošení počtu hacků, které používají jiné definice pro Explorer a Firefox. Celá věc je velmi jednoduchá a ušetří spoustu kódu:

* {
padding:0;
margin:0;
}

h1, h2, h3, h4, h5, h6, p, pre, blockquote, label, ul, ol, dl, fieldset, address {
margin:1em 5%;
}

li, dd {
margin-left:5%;
}

fieldset {
padding: .5em;
}

Speciální CSS soubor pro Explorer

Protože jsme stále potřebovali řadu hacků, speciálně pro Explorer (primární platformou pro vývoj je u nás Firefox), pomocí podmíněného komentáře dotahujeme styl pro Explorer (nakonec jsme použili stejnou hierarchii jako v kapitole o modulárnosi):

<!--[if IE] >
< link rel="stylesheet" href="IE.css" media="screen" />
<![endif]-- >

Závěr

Celé nám to chvíli trvalo, protože ve stylech skutečně panovala anarchie, ale nyní je velmi jednoduché představit nějaké změny, odstartovat nový projekt a podobně. Ukázalo se, že je možné zanést pořádek i tam, kde mi bylo tvrzeno, že to nejde ...

Odkazy

14. ledna 2008

Používám Linux a nelituju ...

Nějak se rozhořelo téma Linuxu na desktopu (dagi či Aleš Dostál), i když na specifickém desktopu a to jest desktopu vývojáře. Ja používám Linux na svém desktopu už skoro 5 let (od února roku 2003) a jsem s ním nad míru spokojen. Od jakživa používám SUSE, nyní openSUSE (altuálně 10.2) ve spojení s KDE (GNOME bylo zkraje hodně velký žrout paměti a už jsem zvyklý na KDE, takže měnit nebudu). Nově jsem si openSUSE nainstaloval i na své nové VAIO a světe div se, vše funguje (jenom původní token iKey 1000 není pod linuxem podporován, takže potřebuju iKey 3000 - to vše pro přístup do firemní sítě).

A proč nechci už Windows ani vidět? Důvody jsou 3: KWrite, terminal a ssh.

KWrite je ten nej editor na cokoliv, který jsem kdy viděl, přepínání kódování, blokové kopírování, podpora XML. Command line v podobě terminálu je naprosto k nezaplacení, nedokážu si představit, že bych pracoval bez ní (už v ní i kopíruju soubory, rozbaluju archivy apod.) a ve Windows jsem zatím nenašel solidní náhradu (ani jsem moc nehledal ...). A ssh je prostě víc než PuTTY, fungují všechny klávesy jak mají (např. ctrl + end).

Největším problémem je asi přenos dokumentů mezi MS Office a OpenOffice, ale zvykl jsem si. Podpora se za těch pět let hodně zlepšila, opravdu hodně moc ... není to na to, abych něco napsaného v MS Office vytiskl a vypadalo to, jako vytištěné z MS Office, ale čitelné je vše (včetně poznámek, tj. není pravda co psal ronnie).

A proč se mi líbí právě SUSE a né třeba Fedora nebo Ubuntu? Je to kvůli YASTu, protože funguje jak v terminálu tak v Xkách a nastavím s ním většinu věcí, které běžně potřebuju ...

Tj. nebojte se linuxu, je to jiný než myšoidní přístup Windows, asi nevypadá tak líbivě jako Windows, ale funguje spolehlivě a bezproblémově.

8. ledna 2008

Nová Java: Chceme ji? - tvrdá realita

Dneska jsem si pročítal nějaké články o Closures v Javě a narazil jsem na článek Closures and Preserving the Feel of Java, který nepřináší nic nového, ale v jeho komentářích jsem našel perličku od Kurta Christensena:

I remember a great presentation by Bjarne Stroustrup back around 1997 at the Computer Literacy bookstore. Someone said that Java looked like a much better, cleaner C++, to which Stroustrup replied that we should ask him about it again in 10 years after everyone was finished adding the features they want. Well, it's 10 years later, and new Java code is starting to look an awful lot like C++.
Tak trochu střílím do vlastních řad, protože jsem pro rozšiřování jazyka, ale nechci jej rozšiřovat za každou cenu, pokud se nějaké, byť prospěšné, rozšíření ukáže jako problématické, či zesložiťující syntaxi, pak jej nechme být ...

6. ledna 2008

Nová Java: Chceme ji? - počtvrté

Myslím, že jsem se dostal do finále, alepoň pro tento okamžik, protože poslední věc, která by jistě zasloužila vylepšení je vytváření naplněných collections. Dneska je nutné vytvořit instanci (Collection nebo Map) a postupně do ní přidávat prvky.

Jistě existují různé "zkratky" přes pole, která můžeme vytvářet pomocí inicialiazátoru. Další pokrok přináší Google Collections Library, ale stále to není ono. A přitom jednoduchou syntaxi již máme vymyšlenou, např. pro Groovy.

Takže proč collection nevytvořit:

Collection<Object> col = [ 1, 2, "33", new Long(10) ];
Je to jistě jednodušší než:
Collection<Object> col = new ArrayList<Object>();
col.add(1);
col.add(2);
col.add("33");
col.add(new Long(10));
Jen pro dolnění, prázdná mapa je: [].
Pokud přejdeme na na mapy, je věc identická. Nejprve klasicky v Javě:
Map<Integer, String> map = new HashMap<Integer, String>();
map.put(1, "1");
map.put(2, "dva");
map.put(3, "3");
A jak by tyto 4 řádky vypadaly, kdyby se vylepšila syntaxe vytváření map:
Map<Integer, String> map = [ 1:"1", 2:"dva", 3:"3" ];
Jenom pro doplnění prázdná mapa se vytvoří [:].

Závěr

Nedokážu odpovědět na otázku, zda takovou Javu chceme? Za sebe mohu říci, že změny, které jsem navrhoval podporuju. Ale nesmí dojít k nejasnostem jako v případě implementace generik. Vše musí zapadnout do již existujícího jazyka a fungovat. Pokud se ukáže nějaký problém, jsem pro, aby se z implementace vycouvalo.
Otázkou samozřejmě je, zda je nutné zachovat zpětnou kompatibilitu. Myslím si, že není problém udělat nekompatibilní JavuX a vní implementovat vše co potřebujeme, ale je to co chceme? Ja myslím, že ne, protože to už by nebyla Java ...

5. ledna 2008

Nová Java: Chceme ji? - potřetí

Původně jsem si myslel, že na tenký led typu closures se pouštět nebudu, protože to je hodně pálivé téma, ale když už se do toho pustil Dagi, chci přidat svůj pohled.

Předně co si pod pojmem closures představuji já: v podstatě zavolatelný kód, takový pointer na funkci. Nespojoval bych to se správou zdrojů (Automatic Resource Management).

Nejprve jsem si prošel všechny návrhy, které se okolo closures v Javě 7 přetřásají (JSR, BGGA, CICE, FCM, C3S). Musím se přiznat, že přestože jsem relativně dost nakloněn novinkám v Javě, tak BGGA návrh mi přijde hodně špatný. Kód je složitý, closures není možné použít všude, kde to dává smysl, a tzv. closures se nechovají jako kus Java kódu (nejde použít break, continue ani dokonce return). Takže pokud otázka stojí: Chceme BGGA návrh jako closures do Javy? říkám jasně a nahlas Ne.

Je jasné, že přidat do Javy closures tak jak je známe např. z Groovy se asi nepovede. Takže potřebujeme nějakou zjednodušenou variantu. A ty vidím dvě. První, která se mi líbí kvůli velmi jednoduché syntaxi a široké nabídce možností, je FCM (First Class Methods). Jsem přesvědčen, že mi pomůže skutečně zjednodušit všechny typy algoritmů, kde si na closures vzpomenu, když je píšu v Javě.

Kdyby existoval argument proč FCM nepoužít, pak se kloním k CICE, které není tak jednoduché jako FCM a není tak moc komplexní, ale přesto nabízí hodně. Bohužel neodstraňuje nutnost existence rozhraní, které bude "closure" implementovat...

Věřím, že se BGGA v Javě 7 nedočkáme ...