Nalezení nedokumentované funkce vždy potěší. A když si někdo dá záležet a najde jaké všechny parametry nejspíše funkce uznává, tak je to krásné. A když je to funkce, která vrátí například home server z aktuálního dokumentu pracoviště, tak je to úplně super. Hurá, hurá, hurá.
Napiš komentář, díky!Nová verze Sametime a Quickplace
O nové verzi Lotus Notes se píše skoro všude. O nové verzi Sametime také, naposledy psal třeba Petr Kunc, že vývoj je ukončen a je možné stahovat a instalovat.
O nové verzi Quickplace, která se právě připravuje, ovšem nepíše skoro nikdo. Čestnou výjimkou je Rob Novak, který se specializuje na práci s Quickplace a Sametime. O verzi 8 natočil dokonce podcast, ve kterém popisuje plány pro tuto verzi. A co by mělo být součástí nové verze? Největší taháky vytahuji:
- více a lepší reportování o serverech, místech a uživatelích
- kompletně nové uživatelské rozhraní na principu AJAXu (ostatně tato verze má vyjít společně s Hannoverem, tak by to bylo fajn)
- kontextové menu
- drag&drop dokumentů mezi složkami
- podpora formátu ODF
- větší integrace s MS Office a e-mailem
Zároveň Rob píše o tom jak je snadné vytvářet Sametime Boty, tedy automatické uživatele, kteří jsou určeni pro speciální akce.
Tak jenom na závěr přemýšlím, jak je možné, že se Sametime a Quickplace moc nenasazuje. Sametime, minimálně v ořezané verzi, je zdarma ke klientovi Lotus Notes, ale přesto není masově rozšířen. Quickplace se mi jeví jako ideální alternativa k Microsoft SharePoint Portal Serveru, nicméně IBM raději vytvoří Workplace Services Express, které nejsou špatné. Ale to co už tu bylo, to je krásné, jenom to začít používat a tlačit. Škoda.
Napiš komentář, díky!Notesy nebo Outlook?
Občas člověk potká odkazy, které stojí za to zopakovat a ukazovat. Jedním z nich je i odkaz na anketu, zda mají lidé raději Outlook nebo Lotus Notes. A, pro mě celkem překvapivě, drtivě vítězí Lotus Notes. Tak teď jenom nevím, zda se odkazy objevily pouze na těch správných stránkách, nebo čím je to způsobeno. Tak nějak se mi zdá, že slyším ve svém okolí spíš více opačných hlasů.
Napiš komentář, díky!R7 končí, ND7 je tady
Zvláštní název příspěvku, který vlastně ani není moc důležitý. Ale proč o něm nevědět 🙂
Od verze 7 IBM nedoporučuje (alespoň jsem nikde nenašel, že by to bylo závazné) používání zkratky R7. Doporučená zkratka, kterou používá i sama IBM je ND7. Tak zkusme změnit zvyky a používat novou zkratku – ostatně změna je život.
Napiš komentář, díky!Jak rychle pracovat s dokumenty?
Čas od času se objeví články, které by stálo za to zarámovat a pověsit si nad stůl. Jedním z nich je článek v posledním čísle časopisu THE VIEW, který rozebírá různé možnosti nalézání dokumentů v pohledech a jejich výkonové srovnání. To nejdůležitější, jsem se pokusil sepsat.
Důležitá informace na úvod – neprocházíme celý pohled, ale pouze nalezené dokumenty. Díky tomu jsou výsledky takřka určitě jiné, než kdyby člověk procházel celý pohled.
Jaká metoda nalezení dokumentu je tedy nejrychlejší? Úplně nejrychlejší je kombinace cyklu For (díky tomu, že jsme potřebné dokumenty nalezli pomoci metody GetAllDocumentsByKey, tak víme jejich počet) v kombinaci s metodou GetNextDocument třídy NotesDocumentCollection.
Na druhém místě se umístila kombinace cyklu While s metodou GetNextDocument třídy NotesDocumentCollection. Následuje použití třídy NotesViewNavigator a cyklů While, který je rychlejší, a Do, ten je o kousek pomalejší.
Předchozí výsledky se týkaly kategorizovaných pohledů – jejich procházení je rychlejší než procházení tříděných pohledů, ty jsou na řadě nyní. Zajímavé je, že rychlost je vyšší u kategorizovaných pohledů přibližně o 10% a to již je cítit.
Po procházení tříděných pohledů přichází na řadu metoda FTSearch kombinovaná s cyklem While. U této metody je ale nutné počítat s tím, že aktualizace indexu nemusí být okamžitá a mívá zpoždění. Někdy i citelné, zvláště pokud dochází k aktualizaci pouze jednou denně.
Překvapením asi není, že procházení dokumentů vyhledaných pomocí metody GetDocumentByKey je ještě pomalejší. Po každém posunu na další dokument je totiž nutné otestovat, zda pořád vyhovuje podmínce. I zde platí, že kategorizované pohledy jsou rychlejší.
Využití třídy NotesViewEntryCollection je ještě pomalejší a zde se pravidlo rychlejšího kategorizovaného pohledu obrací – tříděný je rychlejší. Všechny metody jsou ovšem přibližně o 250% pomalejší než vítězové.
Metoda FTSearch třídy NotesView je o 100% pomalejší než stejná metoda třídy NotesDatabase. Ale to ještě není tak špatné – metoda Search třídy NotesDatabase je o dalších 100% pomalejší – což je přibližně 8x pomalejší než nejrychlejší přístup.
Jednoznačným rekordmanem je procházení kolekce pomocí metody GetNthDocument – trvá přibližně 20x déle než nejrychlejší kombinace.
A další zajímavé výsledky?
Načtení hodnoty z dokumentu je nejrychlejší pomocí NotesDocument.ColumnValues, o něco pomalejší je NotesDocument.GetItemValue a nejpomalejší je ten nejobvyklejší zápis – NotesDocument.ItemName. Rozdíly ovšem nejsou velké, největší rozdíl je mezi posledními dvěmi, přibližně 5%.
Záleží také na správně zapsaném názvu pole – pokud se dodrží správná velikost písmen, tak ušetříte přibližně – celé jedno promile.
Pokud si při procházení dokumentů necháte něco vypisovat do stavové lišty, tak počítejte s velkým zpožděním – v testu vyšlo zpoždění přibližně 500%.
Jednu věc jsem před čtením článku netušil – že pozitivní testy jsou výrazně rychlejší než ty negativní. Rozdíl porovnání i = 1 a i <> 1 činí takřka 50%. Využití kouzelného slůvka Not je ještě o kousek pomalejší.
Naproti tomu nastavování vlastnosti AutoUpdate třídy NotesView nemá takřka žádný vliv – ten se počítá v desetinách promile. Musíte tedy hledat jiné důvody, proč tuto vlastnost použít – a ony existují.
Závěr? Vzhůru ke strojům a přepsat skripty. A všichni, kteří máte stejně jako já rádi cykly Do … vězte, že cyklus While je o kousek rychlejší. Všichni, kteří chcete být ještě lepší, vězte, že pomocí C API můžete být ještě rychlejší. Ale to už je zase jiná kapitola.
Napiš komentář, díky!