Do desíti - s Danem Vránou
Jak jsi se dostal k Lotusu? Jaký byl ten začátek a jaký si myslíš, že by byl v dnešní době?
Dan Vrána ze společnosti CubeTeam je dalším z těch, kteří začali vývojem, zkusili si projektové řízení a vedení lidí a nakonec se rozhoupal, osamostatnil a se společníkem založil firmu, která roste přímo raketovým tempem (dá se říci, že každý rok zdvojnásobí svou velikost, což znamená, že od dvou zakladatelů dorostli na aktuálních 10 osob).
Studoval jsem na vysoké škole a někteří spolužáci už pracovali, tak jsem si řekl proč ne a přes kamaráda kamaráda jsem v roce 1996 potkal na Invexu Františka Baštu z CS Developmentu - no a zůstal jsem u nich až do roku 2003. A v dnešní době? Obávám se, že kdybych to podobně "nestřelil", tak bych nad notesama ohrnul nos a připojil se k armádě javistů. A byla by to chyba, protože ta technologie stále žije a rozvíjí se. Jaké problémy chtějí zákazníci řešit nejčastěji, co trápí skoro každého?
Vždy se to točí kolem emailu a kalendáře - nejjednodušší forma je kategorizace emailů a schůzek, složitější je linkování emailů do CRM (k firmám, projektům/obchodním případům, kontaktním osobám) a nakonec tvorba vlastních mailových/kalendářových aplikací a jejich propojení s mailovou schránkou. Ukaž mi nějakého programátora, který nikdy neupravoval mailovou šablonu nebo to po něm alespoň někdo nechtěl. A faktem také zůstává, že když vývojář upraví scriptové knihovny mailové šablony a ona stále funguje, je to hezký test, že ví co dělá.
Takže odpověď na otázku - rozšíření mailu o groupwareové nástroje, třeba nám v budoucnu pomohou Activities z Lotus Connections, uvidíme ... A co by je naopak trápit mělo a takřka nikdo to sám o sobě nechce?
Jednoznačně zodpovědnosti na straně klienta - novému zákazníkovi musíme víceméně vždy vysvětlit, že je spolutvůrcem systému a nemůže čekat, že se po podepsání smlouvy na pár měsíců zavřeme a pak mu pošleme instalační CD poštou. Je třeba u klienta určit zodpovědnou osobu, která bude mít čas a potřebné znalosti atp. O to více si vážím zákazníků, kteří tento vztah akceptovali - to je pak radost s nimi pracovat :) Řešení na které jste nejvíce hrdí, co to je? A je to spíš nějaká drobnost nebo masivní systém?
Jedná se o drobnost, která nám obrovsky šetří práci a je to objektový model připravený k Personální bázi. Kdykoliv potřebujeme v nějaké aplikaci použít adresování na funkční místo, řešit nadřízenosti atp. je to neocenitelné - zápis výběru osoby se smrsknul na 3 řádky v LotusScriptu. To samozřejmě platí pro případ, kdy nepoužíváme Lotus Workflow.
Obecně rozhodnutí, kdy už se pro něco vyplatí vytvořit (a hlavně vymyslet) objektový model, je obtížné - naši programátoři to mají jako "vedlejšák" a postupně firemní knihovny rozšiřují a dokumentují. Kdybys měl v Lotus Notes poukázat na jednu vlastnost pro kterou stojí za to je koupit, co by to bylo?
Ono je to těžké, když se člověk kolem jedné technologie pohybuje moc dlouho, tak její výhody už ani nevnímá a považuje je za automatické. Ale hodnocení jednoho mého kamaráda, že nic nereplikuje tak dobře jako notesy, musím potvrdit - je to Replikace. Věc, kterou bys v LN zrušil?
Před několika lety bych řekl bookmarky, ale dnes už tak moc nezlobí. Tak se zaměřím z uživatelských problémů na programování - proč proboha už konečně neumožní používat @DbLookup v pohledech?!? Čtenář možná nechápe co mu to může přinést, ale argumenty 1) zjednodušení aplikací, 2) okamžité změny dat v pohledech a 3) snížení administrace případných plánovaných agentů. Hovoří to za vše, ne? Osmičky - na trhu jsou už relativně dlouho, česká verze 8.0.1 už je tu taky. Přecházejí už zákazníci nebo s tím nespěchají? A má vůbec smysl migrovat, když je verze 8.5 za dveřmi?
Doby, kdy takzvaná "nulová" verze (tedy LN x.x.0) byla nepoužitelná, jsou již díkybohu pryč. Pokud tedy zákazníkovi dodáváme Domino server jako aplikační server bez klientů, pak tam jdou osmičky automaticky - viz jejich funkce pro webové služby atp. Co se týká instalací klientů, obvykle upgradeují ob-jednu verzi, tedy klienti s LN6 upgradeují právě teď, ti sedmičkoví většinou vyčkávají. Přechod na osmičky určitě doporučujeme, verze 8.5 na klientské straně nepřináší moc věcí navíc, tak není proč otálet. Kromě Lotus Notes, co dalšího zákazníci poptávají a používají? Jaký je ten další super produkt od Lotusu?
O produktech jako je Quickr nebo Traveler bych tu mohl napsat tak za rok, že ho klienti poptávají a používají, zatím je to pouze ve fázi vysvětlování smyslu klientům s drobnými krůčky implementace. Další produkt, který je na trhu už víceméně 2 roky a rozšiřuje skvěle vlastnosti Lotus Notes je ukládání dat do DB2 a jejich datamining. Firem, které mají spoustu dat v nsf databázích a nemohou s nimi pracovat v agregované formě je mnoho a ty data mají přitom obrovskou hodnotu. Jak se řídí takové projekty nad Lotus Notes - je to díky rapidnímu vývoji spíše jednodušší nebo složitější tím, jak se to může rychle změnit?
Hodně otázek, které mi dáváš jsou diskutabilní, ale tady už se neudržím a odpovím: Jednodušší nebo složitější? Jak kdy.
Legrace na Lotus Notes je ta, že jako groupware, tedy uživatelské prostředí pro týmovou spolupráci jsou skvělé a jako prostředí pro týmovou spolupráci programátorů je to horor. Iterativní vývoj, tedy prezentace "prázdné" aplikace nebo jinými slovy beta verzí, používáme už poslední 4 roky striktně a výsledky jsou skvělé. Prostě a jednoduše, zákazník i dodavatel si ověří, že zadání obě strany pochopili stejně a zároveň do projektu byla investována maximálně 1/2 rozpočtu. A co si představujeme pod pojmem "prázdná" aplikace? Ukázkové funkce (formuláře, tlačítka, dialogy), klíčová slova jsou "natvrdo", grafika jen někde. Web, plný klient nebo mobilní zařízení - co nyní letí?
V roce 2004 jsme pro jednoho klienta programovali aplikaci v J2ME pro mobilní zařízení a vzhledem k požadavkům na změnu funkce a designu a problémech se vzdálenou synchronizací jsme ji ještě rádi převedli na web a optimalizovali pro mobilní zařízení. Ten odklon od tlustého klienta se poslední dobou díky AJAXům, jQuery a podobným, začíná týkat i Lotus Notes. Když vidím co naši programátoři dokážou ve webovém prohlížeči, začínám věřit tomu, že i LN klientovi pomalu zvoní hrana. Trochu mě to mrzí, protože s webovými technologiemi nejsem úplně sžitý a lepší už to nebude, ale webový klient se stává standardem i u intranetových aplikací - příkladem může být i SAP. Můžeme se zkusit vsadit, který klient bude poslední a IBM pak už jen bude vyvíjet Domino server - budou to devítky? Co se lidem na Lotus produktech líbí nejvíc?
Přes všechny marketingové průšvihy IBM se jim daří držet spoustu klientů na vlně entusiasmu a lásce k Lotus produktům, podobně jako příznivce Applů. Slýcháme hodně často "hlavně ne nic od Microsoftu" a není to jen nějaká ideologie, ale opravdu jednodušší správa a multiplatformnost. Vždyť řešení na Linuxu pro řekněme 10 express klientů a nějakou jednodušší aplikaci na míru je rozumně drahá softwarová firma schopná dodat pod 100 tis. a v ceně mají i robustní groupware nástroj s mailem, kalendářem a úkolovníkem. Takže odpověď je jednoduchá správa, podpora Linuxu a express licencování.
Jaké otázky byste položili vy? A koho byste se chtěli zeptat?
Upozornění pro personální agentury a personalisty: cílem rozhovorů není zviditelnit lidi pro jejich přetažení do jiné firmy, prosím respektujte tento fakt.
Technorati: Do desíti IBM Lotus Lotus Connections Lotus Notes Lotus Quickr Lotus Traveller Lotus Workflow Dan Vrána
Do desíti - s Danem Vránou
@DbLookup v pohledech by byl možná z hlediska vývojáře hezká věc, ale co by to asi provádělo s výkonem klienta nebo serveru?
Kdyby to mělo ve sloupci pohledu ke každému dokumentu dohledávat hodnoty z dalších pohledů a dokumentů, to snad šlo aktualizovat jednou za nějaký čas. Ale pokud by se to vše muselo refreshovat při každé změně, to by byl z hlediska výkonu asi trochu problém. Navíc při současném přístupu více uživatelů do stejného pohledu by asi bylo poněkud problematické udržovat různé verze pohledu podle dohledaných informací, pokud by někteří uživatelé neměli právo číst některé dohledané dokumenty. Pokud by jeden pohled dohledával pomocí @DBlookup hodnoty v jiném pohledu, který ovšem zase dohledával hodnoty pomocí @DBLookup v původním pohledu, asi by se to mohlo pěkně zacyklit.
To jsou takové úvahy, proč to asi dosud neumožnili - může to být takový programátorský oříšek pro tvůrce LN.
Proto je asi jednodušší spustit jednou za čas agenta s odpovídajícími právy, který by do dokumentů v pohledu zapsal aktuální hodnoty místo toho, aby byly dohledávány hodnoty v pohledu @Dblookupem při každé změně v DB.
Re: Do desíti - s Danem Vránou
Možná ano, ale zas na druhou stranu, když na to člověk koukne jako na černou skříňku a porovná se SQL databázemi - proč ty to umí?
Jak jsem tak chodil po pohovorech před nějakou dobou, tak jsem došel i do firmy, která dělá datové sklady. A ti mi říkali, že teď začíná frčet jejich zpracování v reálném čase a je to bomba. Člověk si to tak vyposlechne a řekne - vždyť je to jasné, proč to ještě nefunguje?
Takže z hlediska technologie to možná problém je, ale když na to kouknu z dálky - proč to ještě nefunguje? Proč "přesně" tahle finta je možná, pokud uložím data do DB2 a použiji SQL view?
Do desíti - s Danem Vránou
Problém bude ve vnitřní struktuře DB. Jak pravil jeden bývalý kolega, LN má bezva uživatelský interface, ale uložení dat naprosto nahov... Relační databáze mají zase bezva uložení dat, ale ty komplikované uživatelské interface ve srovnání s LN ...
Jeden bývalý kolega kdysi pracující v relační DB Progress 4GL byl hodně nadšený, když někdy mezi Progress R6 a R9 přidali nějaké rozšíření určené pro publikování na webu. Prostě se najednou nemuselo používat zamykání záznamů obvyklé na relačních DB (Progress měl tehdy jen 3 druhy zamykání, např. IBM DB/2 má 6 druhů zámků). Případné konflikty vyplývající z nezamykání záznamů musel programátor najednou ošetřovat sám na úrovni kódu, ale zase byla možná jednoduchá replikace, nestrukturovaná data s proměnlivou délkou a další výhody, které mají LN odjakživa. Z hlediska filozofie programování takový přechod od relačního způsobu programování tehdy přirovnával k takové změně myšlení, jako když má programátor přejít ze strukturovaného na objektově orientované programování.
Trochu mi to také připomíná snahu o propojení určitých protichůdných požadavků, když jsem četl někde na internetu popis postrelační databáze Caché. Také se v ní snažili propojit výhody relační DB a objektového přístupu k datům, vysvětlovali rozdíly mezi relačním a OO přístupem k ukládání dat, atp. Některé protichůdné požadavky z těchto různých postupů se v té DB snažili co nejvíce sblížit, ale stejně je nešlo kvůli odlišnosti původních principů úplně eliminovat.
A tam někde bude zakopaný pes - existují nějaké modely uložení dat, každý má nějaké výhody pro určité použití, které jsou současně nevýhodami pro použití jiné.
Do desíti - s Danem Vránou
Hm, je to čistě akademická debata, protože IBMku my asi nepřesvědčíme, ale když už navrhují designové prvky jako XPages apod. tak proč nemůžou tohle? Asi programátoři málo křičí a tak to nemají důvod řešit.
Vidím tu určitě řadu problémů - když by indexer takový pohled indexoval, tak jak zajistit, že pohled ve kterém hledá pomocí @DbLookup už naindexovaný byl (něco jako zacyklení), dál aby z hlediska výkonu třeba další pohledy nemohli k @DbLookup sloupcům přistupovat atp.
Ale jak píše Martin, relační databáze to mají a když v ní člověk tvoří pohled jako select do jiných pohledů, tak v tom nevidím rozdíl - ten pohledový @DbLookup by mohl být omezen na ColumnNumber (a neuměl by vracet data fieldů) a pak je to analogické.
Prostě pánové z IBM nebo Irisu - šup na to a ať je v LN8.5 výsledkem změna v helpu :)
...
Usage
This function does not work /in column or/ selection formulas, or in mail agents.
Re: Do desíti - s Danem Vránou
My vlastně žádnou zásadní změnu v logice nechceme, nám stačí, když z helpu bude moci zmizet jedna větička :)
Do desíti - s Danem Vránou
Proč asi byla ta DB/2 v LN cca 218x pomalejší oproti klasické LN databázi, jak to před cca 3-4 lety prezentovali na jednom semináři o R7 tuším v Digi-trade? Relační DB je tabulka, která je navržena na optimální ukládání strukturovaných dat. Notesová DB je struktura, která je zjevně optimální na hierarchické uložení nestrukturovaných dat. Určitě lze upravit relační DB tak, aby se mohla tvářit jako hierachické úložiště (např. výše zmiňovaný Progress nebo Caché) - nejspíš proto také do LN dali DB/2. Možná to bylo jednodušší než dodělávat nějaké relační vztahy do úložiště, které se je výhodné pro odlišný druh práce s daty ... Takže LN s DB/2 budou možná oproti klasické verzi 200x pomalejší, ale třeba to jednou umožní dělat něco jako relace pomocí @DBLookup v pohledech.
Nicméně loni tvrdil tuším Vojta T. na jednom semináři, že se připravuje pro LN nějaké nové úložiště na bázi Java Content Repository. Mělo by to umožnit prohledávání DB na mnohem nižší úrovni (např. data mining pro datové sklady) a kdoví co ještě. Ale pojmy jako Java a Rychlost jsou také zatím spíše protiklady než synonyma .-)
Možná by stačilo opravit jen ten help, ať s tím musí každý pěknou chvíli laborovat, než zjistí, že to stejně v pohledu nefunguje a sám si pak musí doprogramovat jakoby relační chování na bázi synchronizace dat mezi dokumenty pomocí agentů či OOP. ;-)
Re: Do desíti - s Danem Vránou
Ajajaj, poslední dobou slýchám podobné názory na nejrůznější věci, všechny mají jedno společné - v historii mi to nefungovalo/nelíbilo se/.... a už se nikdo nedívá, že se od té doby několikrát měnily verze a vývoj (zvláště v počítačích) jde raketově kupředu.
Takže DIGI TRADE opravdu kdysi dělal prezentaci na spojení LN a DB2 a prezentoval nějaká čísla (převzatá z THE VIEW). ALE - bylo to na beta verzi 7 a bylo tam spousta různých měření, některá pomalejší, některá stejně rychlá, některá třeba i rychlejší. Od beta verze se to ovšem přirozeně měnilo a ve verzi 8 (kde je to snad už volně dostupné všem) to může být zase jinak, takže bych se tím nenechal moc ovlivňovat, navíc vždycky závisí na konkrétním použití.
No a co se týká Javy - Java a rychlost nikdy nešla dohromady, ale zase je to otázka kde, kdy a proč. Java a server dohromady celkem jde, možná první spuštění je pomalejší, ale pak to fičí a je třeba doporučeno používat servlety místo agentů, protože agent se pokaždé natahuje, kdežto u servletu se to stane jednou. Stejně tak na klientovi to sice chvilku (dnes už ani né tak dlouhou) trvá, než se applet spustí, ale pak už to jede. Takže je otázkou jak uživatel pracuje, je možné, že to první spuštění vůbec nezaznamená a pak bude happy a je tedy nesmysl, se tomu appletu vyhnout jenom proto, že se na začátku trochu déle spouští.
Reálná čísla (trochu historická)
To je zvláštní. Přednášející (nějaký Martin H.?) tehdy na tom semináři tvrdil, že všechna měření prováděli sami na svém testovacím prostředí. Přestože to zpomalení na DB/2 v některých případech dosahovalo až 218 násobku v porovnání s klasickou DB v LN, v reálu to byl rozdíl jen pár sekund. Pokud si to správně pamatuji, jednalo se o stejné DB (repliky?), kde byly tuším desetitisíce dokumentů. Jedna měla jako úložiště DB/2, druhá nativní LN databázi. Určitě se nejednalo jen o převzatá čísla z THE VIEW, protože to na tom semináři také názorně předváděli přímo na tom testovacím serveru, aby bylo jasně vidět, že se na jednalo jen o minimální reálné rozdíly (v LN to sběhlo v okamžiku, v DB/2 to pár sekund trvalo). Že by to tehdy byla jen nějaká kamufláž?
Re: Reálná čísla
A že to bylo před takovými 3 možná i více lety se shodneme? Že to dost možná bylo na beta verzi? A že to dneska může být úplně jinak ;) Vždyť je to vlastně jedno, vždycky to chce vyzkoušet a pak se uvidí, zda je to pomalejší nebo rychlejší.
Archiv - nejlepší přítel paměti
Lotus Notes/Domino 7 - skok vpřed?!
Zveme Vás na odborný seminář zaměřený na představení nové verze Lotus Notes/Domino 7, pořádaný společností DIGI TRADE. Seminář je určen všem uživatelům, vývojářům a administrátorům, kteří se chtějí dozvědět o novinkách v nové verzi. Uskuteční se v pátek 25. března 2005 od 8:30 hodin v prostorách nového sídla společnosti DIGI TRADE, s.r.o. (Olšanská 1a, Praha 3, budova SUDOP Praha).
Program semináře
08:30 - 09:00 Registrace, káva
09:00 - 09:10 Slovo úvodem (Martin Humpolec)
09:10 - 09:40 R7 a kam dál (René Zahradník - IBM)
09:40 - 10:10 Novinky pro uživatele (Martin Humpolec)
10:10 - 10:55 Novinky pro administrátory (Miloš Šafařík, Lukáš Konečný)
10:55 - 11:15 Přestávka, káva
11:15 - 12:00 Integrace dvou světů - LD a DB2
(Miloš Šafařík, Lukáš Konečný)
12:00 - 12:45 Novinky pro vývojáře (Pavel Hrbáček, Petr Škácha)
12:45 - 13:15 Oběd
13:15 - 14:15 Praxe - koření života (Michal Štěpánek, Pavel Hrbáček)
14:15 - 14:30 Diskuse, losování cen, závěr
Takže to bylo před 3 a 1/4 rokem.
Beta verze to možná byla, možná ne. Na jednu stranu DB/2 je koneckonců oficiálně podporována až od R8 a navíc R7 byly uvedeny oficiálně v ČR až v září 2005. Na druhou stranu R7 byly asi uvedeny ve světě o něco dřív a je možné, že je partneři měli k dispozici už na jaře - tedy v březnu 2005?
Dneska to může být úplně jinak, ale na druhou stranu: přestože se svět počítačů tak rychle rozvíjí, tak základní matematické principy, ze kterých vychází konkrétní modely uložení dat se jednoduše změnit nedají, podobně jako u fyzikálních zákonů. Automobilový průmysl také postupuje docela rychle, ale i ta nejmodernější auta bourají dál, protože asi někdo při jízdě předpokládá, že nejnovější bezpečnostní systémy v jeho vozidle dokáží fyzikální omezení za každé situace eliminovat.
Re: Archiv - nejlepší přítel paměti
A mě se zase povedlo vypátrat prezentace z té doby, ať to máme kompletní :)
Takže jsou tam dva slidy, jeden cituje čísla týkající se beta 2, je převzat z The View a píše se na něm:
- přidávání záznamů do db o 10% rychlejší (při použití db2)
- obnova pohledu o 280% pomalejší
- procházení pohledu o 1800% pomalejší (wow)
Pak byla praktická ukázka v našem podání pomocí beta 3 verze a vyšlo:
- procházení pohledu je znatelně pomalejší (ale nestálo to za číslo, takže to zas asi nebude tolik)
- vyhledávání dokumentů agentem pomalejší o 200%
Takže mezi beta 2 a beta 3 zjevně solidní změna, takže dneska už to opravdu může být rychlejší - třeba to někdo vyzkouší nebo se mi to podaří někde zjistit.
A to přirovnání s těmi auty - dřív jezdila 30km/h, dneska i 300km/h, pořád to má 4 kola, 1 volant a 1 motor. Takže vlastně žádný rozdíl, akorát rychlost je vyšší :)