Blog | O výběru technologie pro IS

O výběru technologie pro IS

Dostal jsem se k tomu navrhnout a vyvinout pro zákazníka maličký projektík. Jedná se o vnitrofiremní rezervační systém, kde si obchodníci v terénu rezervují služby pro své zákazníky.

Běhají po venku s tabletem nebo smartphonem a prodávají a rezervují. Změny se musí okamžitě promítnout v UI všech připojených lidí. Je tam ještě centrála a webová rezervace.

A já se dostal k tomu, jak takovou aplikaci postavit a kolik to bude stát.

Mám před sebou několik otázek.

  1. má být aplikace nativní? Zákazník to nepožaduje, ale když si vymyslí, že chce z tabletu i podepisovat objednávky, sledovat místo prodeje, fotit třeba ty lidi, kteří se přihlásili, tak se to vyplatí.
  2. má aplikace fungovat i offline? Zákazník to nepožaduje, čeká, že v Praze bude signál vždy.
  3. jak moc mám čekat, že se bude řešení měnit?

To, že bude aplikace webová, jsem si zodpověděl rychle. Vše, co mě napadlo, že by mohli chtít, už web umí. Zadavatel je nezkušený v oblasti vývoje software, netuší, že může chtít Business Inteligence napojený právě na prodeje, časy, místa. Že si může vypočítávat, kam umístit obchodníky, kdy nabrat další, jaká je sezónnost. Celá firma mu teď běží na papírech a vysílačkách.

Nečekám, že sám bude chodit s mnoha nápady, ale nechá si prodat naše nápady, když budou dobré.

A tak je tu jen otázka toho, jestli musí řešení běžet offline. My jim dodáváme tablety, takže si řídíme kvalitu. My jim dodáváme telekomunikace, takže si řídíme operátora.

Jedná se o jednoduchou business aplikaci, nezáleží moc na vzhledu, ale na použitelnosti a rychlosti UI záleží dost.

Zvažuji několik variant:

Nette+jQuery+AJAX

Taková klasika. Aplikace, jak by se napsala i před 10 lety. Všechny technologie jsou známy. Můžu použít hotový hosting a nemusím se o nic starat. Můžu si udělat malou přípravu pro fungování v offline, ale celá podpora tam bude jen napasovaná.

Na druhou stranu je to bez magie, bez runtime, jen čistá práce s JS, HTML, CSS.

Můj odhad: 2 dny vývojového času

Vaadin a AJAX

Všechno napíšu ve Vaadinu. Tam se píše v Javě a ta je pomocí GWT kompilovaná do JS. Člověk píše kód, který vypadá skoro jako psaní nativní aplikace.

S Vaadinem jsem už udělal zkušenost. Je fakt, že pokud vám moc nezáleží, jak to vypadá (ono to vypadá celkem dobře), ale aby to bylo rychle hotovo, tak Vaadin funguje dobře.

Je to ale těžká magie. Člověk vůbec nic neví o HTML. Vůbec nic neví o JS. Píše jen Javu a upravuje CSS (ani to nemusí). Dlouho nerefreshnutá ani nepoužíváaná stránka přeruší session. Aplikace má vlastní runtime a já nevím, co od něj čekat.

Můj odhad: 3 dny vývojového času

Vaadin Elements, Polymer, Clojure Backend a AJAX

Vaadin má hotové komponenty v Javě. Má ještě další projekt, Vaadin Elements, kde tytéž komponenty vydává jako elementy pro Polymer.

Výhodou je, že funguje Vaadin Designer.

Výhodou je, že je to opět skoro čisté HTML, JS, minimum magie. Ladit to půjde. Je to připravené perfektně na offline běh.

Musí se oddělit frontend a backend a nějak to propojit. Tady uvažuju jednodušší variantu, kdy se budu dotazovat AJAXem každých pár vteřin. Backend je jednoduchý, jen nadstavba nad SQL. Clojure je můj default, ale stejně dobře by se dal použít i Python, PHP, Ruby.

Můj odhad: 6 dní vývojového času

React, Redux

Úplně nejvíc fancy by bylo použití Reactu, Redux, sdílení změn pomocí něčeho jako redux-scuttlebutt.

Nevýhoda je, že tam nejsou hotové komponenty, člověk píše od začátku všechno. Což je perfektní, pokud děláte něco unikátního, ne miliontou první business aplikaci. Na druhou stranu máte v rukách vše. Ale to u víc low level řešení platí vždy.

Můj odhad: 6 dní vývojového času

Co jsem vybral

Zkouším vytvořit prototyp v kombinaci Vaadin Elements a Polymeru. Líbí se mi to, že budu mít hotové komponenty, že budu mít podporu offline módu, že nemusím jít low level cestou. Nelíbí se mi, že musím psát backend, který bude velmi jednoduchý a redux-scuttlebutt by mi leccos zjednodušil.

Je velkou otázkou, jak moc bude chtít zákazník vývoj rozvíjet. Protože když by zůstal spokojený s tím nejmenším, mohl by ho systém stát půlku. Jakmile by ale přišly požadavky na rozvoj, rychle by se z tohoto rozhodnutí mohla stát koule na noze. Naštěstí je ochotný akceptovat vyšší cenu za první verzi.

Dobrá věc je i to, že když se dívám na další aplikace, které mám před sebou (informační systémy s responzivním designem bez poptávky po extra speciálních elementech UI), je na ně toto řešení vhodné. Na tomto malém projektu se to naučím, na dalších dvou použiju už se zkušeností.

Předejte zkušenosti i dalším a sdílejte tento článek!

Předchozí článek
Následující článek


Jiří Knesl
Business & IT konzultant

Jiří Knesl poprvé začal programovat v roce 1993. Od té doby, díky skvělým učitelům a později zákazníkům, měl možnost neustále růst v oboru vývoje webových aplikací a informačních systémů. v roce 2002 se přidal zájem o ekonomii a v roce 2006 o organizaci práce. Vším tím se konstantně profesně zabývá jak ve svém podnikání, tak i u zákazníků. Za posledních 5 let vydal na tato témata přes 400 článků.

Prohlédněte si moje reference

Mám zkušenosti z rozsáhlých projektů pro korporace, velké podniky, střední i malé firmy, ale i pro startupy v cloudu. Zvyšoval jsem jejich know-how, pomáhal nastavovat jejich organizační strukturu, byl lektorem a mentorem v náročných situacích. Podívejte se, jak vidí můj přínos samotní klienti.

Sledujte mé postřehy na sociálních sítích