Jiří Hradil blog

o software


Definitivně: Oracle kupuje Sun

Aktuální informace přímo od zdroje - Oracle a Sun Microsystems vstupují do konečné fáze dohody, podle které Oracle koupí Sun za cca 7.4 miliardy dolarů. Oracle tak získává Javu, Solaris a ostatní technologie (zdroj: Sun Microsystems: Oracle to buy Sun). Vedle nezajímavých řečí o 20-letém partnersví a obrovském přínosu pro komunitu, uživatele, atd. bude velmi zajímavé sledovat skutečný důsledek této akvizice.

Sun byl sice skvělý technologický inovátor, ale svým technologiím nedokázal přinést vhodný obchodní model. Takže se necháme překvapit, co Oracle konkrétně s Javou provede. Co myslíte?

Publikoval Jiří Hradil • 20.04.2009 v 22:04 • pod kategorií NezařazenéŽádné komentáře

Postřehy z agilní praxe

Proces vývoje software odráží několik posledních let jasný trend - nestálost prostředí a připravenost na změny. Pokud shrneme několik agilních metodik (extrémní programování, Scrum, RUP), tak řeší v podstatě naprosto stejné věci-krátké iterace, testy, otevřenost, zeptej se kódu, atd.  Některé z těchto pravidel rozeberu.

Vyvíjíme po malých částech, čili v iteracích=cyklech=sprintech. Jedním z důvodů je nestálost prostředí, ve kterém má být software používán (např. situace na trhu či legislativa), ale hlavně neschopnost a nemožnost vyprodukovat stabilní analýzu systému, podle které se dá programovat. Analytiky software považuji za dinosaury, jejichž doba dávno skončila a při vývoji software jednoduše nejsou potřeba. Základ software z pohledu uživatele má navrhnout klient a proveditelnost návrhu určují koneční vývojáři. Setkal jsem se s tím, že analytik (který nikdy neprogramoval), vygeneroval stovky stránek krásných diagramů a dokumentů, které si nechal nebohým klientem schválit. Klient samozřejmě netušil, co ty obrázky znamenají (když ony byly tak hezky barevné…). Poté se tento stoh dokumentů předhodil vývojářům, kteří obrázkům taky nerozumněli, ale dostali jasný pokyn - “programujte!” Po několikaměsíčním vývoji při prezentaci systému klient zjistil, že vlastně teď potřebuje už něco úplně jiného a software se do produkce vůbec nedostal.

Doporučení:

  • iterace je dlouhá max. 1 měsíc, v počátcích vývoje kratší, klidně i 1 týden
  • vývojáře musíme protlačit ke klientovi, protože jedině zadavatel a tvůrce systému umí pokládat správné otázky a generovat správné odpovědi
  • po každé iteraci následuje prezentace klientovi, který potvrdí aktuální verzi a na jejím základě generuje požadavky další
  • popis systému je obsažen ve zdrojovém kódu a v uživatelských zadáních
  • podrobná dokumentace je zbytečná - vývojáři ji nepotřebují, tvůrce ji musí aktualizovat a koneční uživatelé jsou tak frustrovaní množstvím software, který musí ovládat, že ji číst nebudou. Složitá sice může být problémová doména, kterou software řeší (třeba statistický software), ale nikdy nesmí být složitý software samotný. Pokud např. posadíme statistika k našemu statistickému softwaru, musí ho být schopen do několika minut bez problémů ovládat, protože ovládá problémovou doménu, do které je náš software zasazen a kopíruje ji.

Testujeme - test simuluje používání systému uživatelem. Ať už to schováno pod pojmy test jednotkový (na úrovni metody), integrační (na úrovni větší části systému), zátěžový, opičí, či jiný, smyslem testu je software nastartovat, aby ukázal, co umí. Testy se mají psát průběžně a to z toho důvodu, že na konci je už nikdo psát nebude. Stejně tak s každým testem vytvoříme nekonečného automatického robota, který nám bude hlásit, jestli pořád software dělá, co dělat má. Psaní testů z krátkodobého pohledu zdržuje, ale dlouhodobě nám právě testy drží software stabilní.

Doporučení:

  • kontrolovat pokrytí software testy (např. v Javě přes Cobertura), stanovit si hranici, pod kterou nesmíme jít, ideálně nad 80%)
  • maximálně urychlit psaní a spouštění testů (mock objekty, databáze v paměti)
  • nepřetržitě integrujeme pomocí integračního serveru (Continuum, Hudson, Bamboo…)

Jsme malí - neudržujme velké týmy. Čím více vývojářů, tím více tření, komunikace, rozhodování, administrativy a neefektivity, kterou nakonec (zbytečně) platí klient.

Doporučení:

  • ideální velikost týmu je 3-5 vývojářů, pokud se jich vývoje účastní více, uděláme více týmů a každý z nich má svou problémovou doménu. Tyto týmy však musí být vzájemně synchronizovány, např. pomocí scrum of scrums-porad, kterých se účastní pouze vyhrazený člověk z každého týmu, nikoli všichni členové  dohromady.

Posaďme tým dohromady, čili  “seat the team together”. Tým musí sedět pohromadě. Tečka. Tohle je nejrychlejší způsob řešení komplikací během vývoje a udržení synchronizovaných znalostí o systému. Pokud má kdokoli v týmu otázku, může ji položit a dostane se mu okamžité odpovědi.

Doporučení:

  • respektovat klid pro práci - pokud máme otázku, nekřičíme na celou místnost, ale zeptáme se, zda můžeme vyrušit, v extrémních případech si zavedeme každou hodinu několik minut na otázky a odpovědi
  • červená čepice - jednoduché pravidlo - v týmu je k dispozici symbol “červené čepice” (ať už cedulka, nebo opravdová kšiltovka), kdo ji má na hlavě, ten nesmí být rušen
  • nepracovat z domova přes Internet, bohužel, zatím se ukazuje, že je stále efektivnější být fyzicky pohromadě v 1 místnosti, než komunikovat přes Skype, Jabber, atd. Budu rád, když mi tuto neefektivitu někdo vyvrátí a přidá praktické zkušenosti.
Publikoval Jiří Hradil • 12.04.2009 v 23:04 • pod kategorií Nezařazené3 komentářů

O marketingu a šeptandě

Bez marketingu nemůže existovat žádný produkt, softwarový nevyjímaje. Jednou z velmi efektivních a dnes používaných forem marketingu je word of mouth, čili “šeptanda”.

Placená reklama je drahá a krátkodobá.  Lepší je mít produkt tak vyčnívající z řady, že si na něj reference předají uživatelé sami. Kromě vlastní zkušenosti neexistuje důvěryhodnější zdroj, než spokojený kamarád, který software doporučil. Třeba Google, v době uvedení služby Gmail, šokoval velikostí schránky 1 GB a také systémem pozvánek, kterých bylo omezené množství. Google si tak otestoval postupné škálování celého systému a zároveň vzbudil u uživatelů, vlastnících účet, dojem exkluzivity. O Gmailu se hodně mluvilo, sám jsem o něm v počátcích psal. Samotné datum uvedení - 1.4.2004, tedy na apríla, je dalším výborným tahem, který zajistil, že byl Gmail chápán jako vtip (tak velká schránka přece neexistuje) a o to víc se o něm mluvilo a psalo. Stejně tak označení Beta (po 5 letech v produkci) je  nejen omluvou za případné potíže, ale i potvrzením, že používáte čerstvý software, který ještě nevychladnul a jste “in”.

Gmail však přežil hlavně díky tomu, že byl a stále je jednoduchý. Dobře se používá a prostě funguje. Rozbořil zažité koncepty (nepotřebujete složky, atd.). Je jiný a proto uspěl.

A závěr tohoto příspěvku pro vývojáře software? Odlišujte se. Přemýšlejte, čím váš software vybočuje z řady. Uniformních řešení jsou dnes stovky. Vy píšete software, který si zaslouží být jiný.  Mějte však na zřeteli, že software píšete pro lidi, ne pro technologii samotnou. Protože jedině v případě, že se váš software používá a koncoví uživatelé jsou s ním spokojeni, jste jako vývojáři uspěli.

Publikoval Jiří Hradil • 30.03.2009 v 18:03 • pod kategorií NezařazenéŽádné komentáře

Používáme Java Server Faces a Hibernate

Z nepřeberného množství nástrojů určených k vývoji aplikací v Javě nyní zkoušíme kombinaci Java Server Faces a Hibernate. Proč právě tyto technologie?

Java Server Faces:
+ technologie vyvíjená a podporovaná Sunem
+ perfektní oddělení view od logiky aplikace
+ jednoduchost
+ možnost tvorby vlastních komponent
- nová technologie, nedostatek tutoriálů a zkušeností při vývoji
- chybí některé základní komponenty (file upload), nicméně byly již napsány třetími stranami (Oracle ADF, MyFaces)

Hibernate:
+ výkonné řešení persistence v Javě
+ relativní jednoduchost používání
+ široká vývojářská základna - mám dojem, že všichni používají Hibernate ;)
- chabá oficiální dokumentace
- trvá dlouho, než pochopíte souvislosti mezi všemi objekty a naučíte se je efektivně používat
- není od Sunu (ano, pro mě je tato maličkost docela důležitá :)

Instalace JSF:
1. Stáhneme JSF 1.1 ze stránek Sunu.
2. Soubory {JSF}/lib/*.jar zkopírujeme do adresáře knihoven aplikačního serveru (viz. konfigurace Tomcatu).

Instalace JSTL:
1. Stáhneme Jakarta Taglibs Standard Library 1.1.2
2. Zkopírujeme {JSTL}/lib/*.jar do adresáře knihoven aplikačního serveru (viz. konfigurace Tomcatu).

Konfigurace Tomcatu:
$CATALINA_HOME/shared/lib - zde se nachazi sdilene knihovny, ktere budou pouzivat vsechny nase web aplikace.
$CATALINA_HOME/common/lib - knihovny umístěné sem jsou viditelné jak našim aplikacím, tak internímu kódu Tomcatu.
Pro JSF a JSTL jsem zvolil $CATALINA_HOME/shared/lib

Instalace JDBC:
1. JAR soubor s ovladači k rozhraní JDBC ( např. u PostgreSQL soubor pg74.215.jdbc2ee.jar) zkopírujeme do $CATALINA_HOME/common/lib

Instalace Hibernate:
1. Stáhneme Hibernate 2.1.6 a Hibernate-extensions 2.1.2 ze Sourceforge.
2. Hibernate vyžaduje, aby všechny jeho knihovny byly součástí WEB-INB/lib u každého projektu. Prý by pak nastaly problémy s nástroji jako Log4j, commons-logging a dalšími (ještě jsem nezkoušel) .
Znamená to, že pokud vyvíjíme Hibernate aplikaci, kterou potřebujeme opakovaně zkoušet-deployovat na vzdálený Tomcat server, tak vytvořený war archiv bude neúměrně velký právě díky těmto knihovnám :). Pokud nemáme rychlé inet připojení, je vhodné instalovat Tomcat lokálně.
Není však třeba kopírovat všechny knihovny z {HIBERNATE}/lib/, stačí jen ty, které potřebujeme. Seznam vyžadovaných a volitelných najdeme v {HIBERNATE}/lib/README.txt}
Jak řešíte instalaci Hibernate knihoven vy?

Hibernate-extensions:
Tady najdeme pomocné nástroje k Hibernate, např. hbm2java (CodeGenerator) a class2hbm (MapGenerator). Tyto knihovny většinou nepoužíváme přímo v našich aplikacích, spíše k počáteční inicializaci - vytvoření základních java souborů z hibernate mappings, nebo skeletonu hibernate mappings ze zkompilovaných tříd (pomocí reflexe)-jedná se však jen o zakladní generaci, která vyžaduje ruční doladění.

Odkazy:
Java Server Faces Technology
Hibernate
Jakarta Tomcat
JSP(tm) Standard Tag Library
Oracle ADF
MyFaces

UPDATE 24.11.2004: Doplněna instalace JSTL a zbývajících knihoven JSF.

Publikoval Jiří Hradil • 21.11.2004 v 22:11 • pod kategorií NezařazenéŽádné komentáře

Pro uživatele Blogger.com: Převod Atom do RSS

My všichni, kdo používáme blogovací systém Blogger.com a potřebujeme konvertovat Atom XML do RSS, můžeme využít služeb 2RSS.com, kde je k dispozici konverzní odkaz či formulář.

Ukázkový odkaz:

http://www.2rss.com/atom2rss.php?atom=http://hradil.cz/atom.xml

Základní služba je k dispozici zdarma, do RSS jen přidává reklamu na produkty 2RSS (jeden řádek), což se dá přežít.
Placená verze stojí $14.95/rok a reklamu neobsahuje.

Dříve jsem používal formulář na Loosely Coupled, teď mi však nefunguje. Blogger.com doporučuje službu FeedBurner, ještě jsem to však nezkoušel.

Publikoval Jiří Hradil • 01.06.2004 v 23:06 • pod kategorií NezařazenéŽádné komentáře

Jakarta POI: Práce s Excel a Word dokumenty v Javě

Práci s MS Office soubory v Javě nám jistě usnadní framework Jakarta POI.

POI obsahuje tyto komponenty:

POIFS - port OLE 2 Compound Document format, na tomto portu jsou založeny všechny následující komponenty.
HSSF - port MS Excel 97-2002 do Javy. Podporuje čtení souborů a jejich zápis.
HWPF - port MS Word 97-2002. Podporuje čtení a zápis. Tato komponenta je v ranné fázi vývoje a je zpřístupěna jen přes CVS.
HPSF - port pro nastavení vlastností souborů (jméno dokumentu, autor, datum poslední modifikace). Zatím podporuje pouze čtení těchto vlastností.

Pro ukázku možností si jednoduše vygenerujeme MS Excel soubor:


import java.io.FileOutputStream;
import org.apache.poi.hssf.usermodel.*;
import org.apache.poi.hssf.util.*;

/**
 * Vytvoreni testovaciho MS Excel souboru pomoci Jakarta POI
 * (http://jakarta.apache.org/poi/)
 * @author  Jirka Hradil
 */
public class TestExcelSouboru {

    /**
     * @param args ignorovano
     */
    public static void main(String[] args) throws Exception {
        HSSFWorkbook sesit = new HSSFWorkbook(); //novy MS Excel sesit
        HSSFCellStyle styl = sesit.createCellStyle(); //novy styl
        HSSFSheet list = sesit.createSheet(); //novy list v sesitu
        HSSFRow prvniRadek = list.createRow(0); //vytvorime radek
        HSSFCell prvniBunka = prvniRadek.createCell((short) 0); //a v radku bunku

        //nastavime kodovani bunky na UTF
        prvniBunka.setEncoding(HSSFCell.ENCODING_UTF_16);
        //pojmenujeme prvni list
        sesit.setSheetName(0, "žluťoučký kůň", HSSFWorkbook.ENCODING_UTF_16);

        //pridame text do bunky
        prvniBunka.setCellValue("Příliš žluťoučký kůň úpěl ďábelské ódy!");

        //stylu nastavime pattern-jednolita barva
        styl.setFillPattern(HSSFCellStyle.SOLID_FOREGROUND);
        //nastavime barvu stylu, zluta barva
        styl.setFillForegroundColor(HSSFColor.YELLOW.index);

        prvniBunka.setCellStyle(styl); //a priradime styl bunce

        //stream pro vystup
        FileOutputStream vystup = new FileOutputStream("c:/vystup.xls");

        sesit.write(vystup); //zapiseme vystup do souboru
    }
}

ODKAZY:
Jakarta POI
Jakarta POI HSSF: Excell-ové tabulky v kostce
Jakarta POI 2.0 FINAL

Publikoval Jiří Hradil • 22.05.2004 v 18:05 • pod kategorií NezařazenéŽádné komentáře

Opera a Java Web Start

Jen taková drobnost-jak nastavíme Operu, aby spustila Java Web Start aplikaci po nakliknutí na odkaz *.jnlp?

Tools/Preferences/File types/New/předvyplníme údaje

Pak zbývá jen Operu restartovat a vše funguje, jak má.

Publikoval Jiří Hradil • 15.05.2004 v 00:05 • pod kategorií NezařazenéŽádné komentáře

Blogger: změny k lepšímu?

Již několik dní si uživatelé služby Blogger mohou vyzkoušet novou verzi systému, která přináší změny a vylepšení pro všechny, kdo chtějí blogovat-rychle a s minimálním úsilím.
Nová verze je opět o krok blíž dokonalosti, avšak nevyhnula se ani několika nedostatkům, které, (alespoň doufám) budou brzy opraveny.

Nejdříve zmíním největší pozitiva (nového/starého) Bloggeru:

Nenáročnost na cílové platformě
Jediný požadavek pro plnohodnotnou práci se systémem je místo na WWW serveru (Blogger nabízí virtuální server pro ty, kteří nemají vlastní, něco jako sweb.cz, centrum.cz, aj.). Žádný scriptovací jazyk, či databáze není třeba. Zadávání příspěvků probíhá přes browser, který poté vygeneruje dokonale provázané HTML stránky a uploaduje je přes (S)FTP na server.

Komentování příspěvků
I přes “absenci” dynamických stránek lze jednotlivé příspěvky komentovat-Blogger po zadání příspěvku na serveru automaticky statické stránky přegeneruje.

UPDATE 23.5.2004: Přešel jsem zpátky k HaloScan. Komentování přes Blogger vyžaduje navíc přihlášení a není možné komentáře zpřístupnit přes RSS.

Blogování přes mail
Zřídíme si adresu uzivatel.tajnyretezec@blogger.com a cokoli na tuto adresu pošleme, může být vystaveno (nebo odloženo pro pozdější publikování) na blog. I čeština funguje perfektně.

Blogovat může více uživatelů najednou
Tuto možnost využívá třeba Roman Pichlík.

Nové šablony
Pro nás kdysidávnowebdesignéry je jistě příjemné zvolit si existující šablonu a nestarat se tak o návrh blogu. Současná tvář tohoto blogu jednu z těchto nových šablon využívá.
UPDATE 23.5.2004: Nyní používám vlastní šablonu, mám více místa na text a vylepšené CSS (např. zobrazení zdrojového kódu Javy exportuji přímo z NetBeans IDE).

Profil uživatele
Ano, ten rámeček s fotkou vpravo, to jsem já :). Po nakliknutí jsou k dispozici předvyplněné údaje a pokud má uživatel více blogů, může se rozhodnout, u kterého z nich profil nechá zobrazit.
UPDATE 23.5.2004: Zobrazení profilu jsem zrušil. Zabírá místo a není až tak důležitý.

Nyní se podíváme na nedostatky:

Samovolné přegenerování uložené šablony
Zřejmě na Bloggeru fungují nějaké pozdní replikace uložených dat. Jednou se mi stalo, že systém se po přegenerování příspěvků vrátil k několik hodin staré šabloně a vesele mi tak změnil uloženou šablonu novou. Podruhé to samé zopakoval při komentování mého příspěvku. Protože jsou stránky na serveru statické HTML, tak po každém nově vystaveném příspěvku se provede nový upload stránky na web server. A právě pro šablonu aktualizované stránky sáhnul Blogger jinam než měl a web měl rázem starou tvář.

Pracné přidávání komentářů ke starým příspěvkům
Pokud chceme využívat komentovací systém, je nutno editovat postupně každý příspěvek, povolit možnost komentování samostatně a pak každou stránku zvlášť přegenerovat na cílovém serveru. Proč nejde u příspěvků změny pouze uložit a pak vše publikovat najednou?

Nedostatečné možnosti parametrizace
Přes veškerou snahu nelze některé texty přenastavit. Jedna z nich je profil (tak rád bych přepsal “About Me” na něco líbivějšího :), pak třeba v komentářích volba “Post a Comment”.

Přes všechny trable však zůstávám Bloggeru věrný a pevně věřím, že všechny zmíněné nedostatky budou postupně odstraněny.

Některá další pozitiva/negativa můžeme najít v následujích odkazech.

ODKAZY:
The Great Blogger Relaunch
Nový Blogger.com - ošklivé káčátko?
Blogger.com v novém - a lepším!
Blogger.com - výborný systém od Google!

Publikoval Jiří Hradil • 12.05.2004 v 23:05 • pod kategorií NezařazenéŽádné komentáře

Téma: ukládání dokumentů na serveru

Představme si následující situaci. Máme vlastní informační systém, který běží na straně serveru (na Javě, PHP…) a klientům zasílá vygenerované HTML či XHTML stránky.
Hlavní komunikaci klienta se serverem zprostředkovávají formuláře.
Systém by měl fungovat jako datový sklad pro dokumenty, uploadované na server společně s připojením popisných údajů-vlastní název souboru, poznámky, propojení s nabídnutým číselníkem, atd.
Popisná data dokumentu budeme ukládat do databáze, ale co se samotnými dokumenty, které můžou být také binární data-obrázky, mp3, všemožné doc, xls?

Nabízí se několik možností:

Popisná data uložíme do databáze (DB) a dokument přímo do filesystému (FS) na serveru. Součástí popisných dat v DB bude odkaz na tento dokument ve FS.

  • + Dokumenty ve FS je možné sdílet a přistupovat k nim i jinak, než jen přes rozhraní systému. Třeba jen pro čtení. V Linuxu lze nastavit sdílení složky s dokumenty např. přes Sambu a klienti mají možnost otevírat soubory přímo ze serveru, což může být někdy rychlejší, než přistupovat přes browser.
  • + Dokážeme tak ukládat i velké objemy dat (mnoho velkých dokumentů). Protože databáze uchovává pouze popisná data, mohla by být menší a rychlejší.
  • +/- Data na dvou místech - pokud spadne DB, dokumenty máme jinde (řeší kvalitní záloha). Avšak musíme se starat o zálohu dvojí.
  • - Obtížná implementace fulltextového prohledávání dokumentů. Pokud umíme pracovat s určitým typem dokumentu, pak výsledky vyhledávání zřejmě budeme muset taky ukládat do databáze. Pak by v DB byla popisná data a výsledky fulltextu. Odkaz na dokument ve FS.
  • - Neustále je třeba kontrolovat konzistenci dat, pokud se smaže dokument v DB, musí se smazat i ve FS a naopak. Tohle je asi největší problém.

Vše uložíme do DB. Binární data dokumentu budou jako datový typ blob, bytea, large object, apod.

  • + Vše na jednom místě. Vyřešíme tím dokonale provázání popisných dat a dat dokumentu.
  • + Fulltextové prohledávání (pokud umíme s daty dokumentu nějak pracovat) bude řešit DB.
  • ? Rychlost a náročnost DB. Tady opravdu netuším, jaké bude mít DB odezvy, pokud v ní budeme mít několik GB dokumentů.

Téma: Co si myslíte o jednotlivých řešeních? Napadá vás nějaký jiný, rozumný a pokud možno co nejjednodušší návrh?

Publikoval Jiří Hradil • 28.04.2004 v 23:04 • pod kategorií Nezařazené6 komentářů

Gmail Beta - první dojmy

Jakožto uživatel systému Blogger jsem využil nabídku být jedním z prvních uživatelů, kteří můžou vyzkoušet službu Gmail (nyní v betaverzi). Jedná se o webmail, rozšířený o řadu netradičních funkcí:

  • + Jednoduchost. Skutečně, klientské rozhraní působí velmi střídmě a přehledně.
  • + Zprávy se netřídí, ale prohledávají (velmi rychle a jednoduše). Tato funkce je pro mě jednoznačně nejužitečnější.
  • + 1 GB volného místa (bezesporu nejlákavější marketingová nabídka :)
  • + Seskupování zpráv (pokud přijde email a odpovím na něj, v detailu emailu je vidět předchozí konverzace).
  • +/- Reklama - absence vyskakovacích oken s reklamou. Systém velmi rychle pozná, odkud jsem přišel a nabízí mi statické reklamy na české stránky. Gmail by měl primárně těžit z cílené reklamy, která odpovídá charakteru textu v emailu. Toto “vylepšení” však bude zřejmě ještě upraveno. Test: poslal jsem si mail s předmětem “notebook LCD monitor” s textem “musím koupit nový hardware, software, najíst se v restauraci a vyspat v hotelu!” a Gmail mi nabídl jen reklamu na koupi luxusních bytů v Praze, o HW a SW ani zmínka :). Současný způsob reklamy však nepůsobí agresivně a dá se vydržet (možná jsem již tak otupělý reklamou ze všech možných médií, že mi tato připadá taková… neškodná :).
  • + Řazení zpráv do skupin (labels). U každé zprávy lze rozhodnout, kam obsahem zapadá a pak ji dle vytvořené a přiřazené skupiny jednodušeji filtrovat. Je to v podstatě taková obdoba složek. Klasické složky (adresáře) nelze v Gmail vytvářet. Existující složky jsou pevně dané. Docela revoluční nápad, uvidíme, jestli mi jednotlivé složky budou chybět. Myslím však, že vše dokáže nahradit účinné prohledávání (a to již dal Google Gmailu do vínku).
  • + Spolehlivost (aneb neříkej hop…). Ale je to přece jen Google, takže se dá očekávat vysoká rychlost a spolehlivost v ostrém provozu. Prostě jim věřím :)
  • + Spam filtr. Nevyžádanou zprávu lze označit ručně jako spam a systém se podle těchto informací učí.
  • + K dispozici je i nastavení filtrů po příchozí zprávy a nastavení prohledávání.
  • + Příprava pro tisk.
  • + Klávesové zkratky (jen část, seznam je dlouhý. Fungují i comba, např. g+i).
  • +/- Kontrola pravopisu, chybí však čeština. Snad jen dočasně.
  • - Adresář je jednoduchý, ale v tomto případě možná až příliš. Chci víc položek!
  • - České rozhraní chybí. Avšak čtení a odesílaní českých emailů funguje bezchybně. Google používá UTF-8. Kdo pomůže s překladem?
  • ? Externí klienti (POP3?) V budoucnu měl být systém dostupný také přes externí klienty (zdarma či za minimální částku).

Závěrem: Jsem mile překvapen, jak přehledný a jednoduchý může webmail být. Pokud se nebude zvyšovat procento agresivní reklamy a bude zachována jednoduchost, tento webmail bude u mě s přehledem nejoblíbenější.

UPDATE 28.04.2004: V komentářích reaguji na některé části příspěvku “Gmail: Nejhorší webová aplikace” z About weblogu.

UPDATE 07.05.2004: Po přihlášení mám možnost pozvat 2 kamarády, kteří si pak můžou zřídit vlastní testovací přístup. Takže prvním 2 zájemcům, kteří se mi ozvou na můj mail tuto pozvánku rád zašlu (potřebuju jen platný mail).

UPDATE 08.05.2004: Pozvánky rozeslány.

Publikoval Jiří Hradil • 26.04.2004 v 23:04 • pod kategorií Nezařazené4 komentářů