Platforma pro vývoj business aplikací rubrika: Programování: Java

2 Rike
položil/-a 22.1.2016

Zdravím! Potřeboval bych vaši radu, názor, zkušenosti. Hledám platformu, která je přímo uzpůsobena vývoji business aplikací (zákazníci, sklady, prodeje...) pro menší a střední podnikání. Asi tu už nikdo nezná Visual FoxPro, ale ten princip se mi zalíbil. Našel jsem něco, co to trochu připomíná - Servoy (http://servoy.com). Je to vlastně o vrstvu výš, než běžné nadstavby pro Javu či C# (co jsem viděl), spousta základních procesů je zautomatizovaná, předpřipravená, stačí naklikat, vy se pak staráte jen o vzhled a aplikační logiku. Není to asi úplně programování v klasickém slova smyslu, když většinu obstarává builder, ale neskutečně to urychluje práci.
Servoy se mi ale moc nelíbí, nepřijde mi dostatečně robustní a není za ním bůhvíjak velká společnost, takže jsem trochu skeptický.

Máte nějakou zkušenost s podobnými nástroji?

Může to být postaveno na Javě, C#, stačí mi vývoj klasických ne-internetových produktů a opravdu nesnáším cokoli definovat skrz XML, JSON, YAML apod.

odkaz
3 geneticy
odpověděl/-a 5.2.2016

Jo, časy Clipperu, dBase, FoxPro a Visual FoxPro... Poslední aplikaci ve VFP9 SP2 a daty na MSSQL2005 jsem napsal těsně předtím, než MS Foxku zařízl (napřed ve prospěch .NET, pak Lightswitch - ani jedno VFP ve skutečnosti nenahradilo a ještě teď jsou stovky živých aplikací v provozu).

Konkrétní rady Vám nedám - to Vám ve skutečnosti nedá nikdo - ale tohle, co chcete dělat, je typická data-driven aplikace. Tady je potřeba hned v počátku uvažovat nad databází - knížecí rady o tom, že to zvládne aplikace jako taková (nebo ORM), jsou dost mimo. Takže se vyhnout proprietárním formátům a souborovým uložištím dat. U těchto aplikací je opravdu veliký důraz na data, jejich konzistenci a bezpečnost.

Dále - klient nebo klienti jsou úplně lhostejní - ať je to tlustý klient nebo tenký (většinou se nakonec dělá obojí a k tomu budou chtít uživatelé ještě připojit Excel nebo jinou takovou věc :)).

Upřímně řečeno, různé buildery formulářů jsou stejně cestou do pekel, ani ve VFP jsem je v produkci nikdy nepoužil - a dal přednost definici ve třídách.

Raději zvolte platformu, jejíž jazyk (- jazyky) a prostředky dobře ovládáte, i když třeba nemá vyložený komfort, nad kterým sníte. I tak se připravte na to, že uživatelé budou každou chvíli chtít něco upravit.

Takže:

  • důkladně promyslet DB platformu, návrh a architekturu. Toto tvoří totiž 50% práce a pokud umíte psát storky, využívat triggery atd. tak i 80%.
  • zvolit jazyk/platformu, ve které se cítíte doma - i kdyby nebyla perfektní. Tyto aplikace vyžadují již docela slušnou znalost platformy a jejich možností - to není místo pro učení nebo splácání prezentačního webu. To musí fungovat - protože...s Vámi třeba vymete účetní, když budete moc experimentovat. Nebo auditor z finančáku.
  • pokud zvolíte one-man show, dost se nadřete a budete muset opravdu hodně komunikovat s uživateli a to i v případě reálného provozu. Ne každý má na to žaludek. Pokud nejste dost odolný, raději se do toho nepouštějte. I třeba proto, že uživatelé budou své Excely a Accessy bránit všemi možnými prostředky včetně social attack.

A jinak - tyto věci se už moc nepíšou...cpou se tam hodně enterprise systémy (kdejaký střední podnik má již dneska miniSAP nebo DynamicAV apod.). Jak bych to řekl - většina středních firem si již tyto věci raději pořídí hotové (+ support) a pak customizuje. O finanční hledisko přitom až tak nejde :). Proto se dost divím, že to ještě někdo dělá na zelené louce...

Komentáře

  • tvavrda : Mých $0.05, jelikož se tímto tedy živíme. Naprostý souhlas s tím, že je vhodné vybrat technologii, které dobře rozumím. DB aplikace se dá napsat na 1000 způsobů, a je lepší, když máte nad technologií nějakou kontrolu. Samozřejmě toto může vyvážit support, pokud si jej ovšem někdo platí. A také, pokud je vůbec nabízen (nebo je cenově dostupný). A co se týče použití SAPů, Dynamicsů, apod., resp. otázky, proč dneska vlastně něco ještě dělá na zelené louce? 1. Lidé od SAPů a spol. jsou prostě příliš drazí na vývoj menších aplikací. Ty firmy vznikly, když se platily 1000 USD za hodinu za člověka, co tomu opravdu rozumí, a tihle lidé neradi slevují... Jsou na tom ty firmy celé postavené. Drahé licence, drazí konzultanti. A dnešní SaaS na tom není o moc lépe. Drahé víceleté kontrakty a ne-již-tak-drazí konzultanti. 2. Někdy ty aplikace jsou prostě tak daleko od ERP, že "ohýbání" je vlastně mnohem náročnější než to napsat znovu. Některé firmy jsou prostě unikátní i s jejich procesy a může to být dáno odvětvím a/nebo geografickým umístěním. Třeba např. cukrovarů není ve světě zase tolik, aby pro ně SAP udělal speciální řešení. Jelikož ještě méně je těch nadnárodních. A např. i ten nadnárodní cukrovar dělá byznys v ČR úplně jinak než ve Francii nebo v Rusku nebo, považte, třeba na Slovensku. Jsou tu jiné podmínky, zvyky, zákony, technologie... A ohýbat desítky/stovky let fungující podnik je prostě složitější než naprogramovat software na zelené louce. A samozřejmě souhlasím s tím, že opravdové programování na zelené louce je v případě data-driven aplikací opravdu trochu moc. Těch dokola se opakujících funkcí, které ve všech těch aplikacích jsou, je opravdu mnoho, tak proč je programovat znovu? Proto jsme vytvořili platformu (viz moje odpověď v této diskuzi), která stojí přesně mezi: Nabízí vše dobré z ERP systémů, ale bez vnucování určité funkcionality (účetnictví, sklady...). Na druhou stranu nestavíte na zelené louce – vše, co je "dobré" pro DB aplikace, je již vytvořeno a sdíleno a ověřeno na mnoha projektech. A nakonec k tomu vždy poskytujeme podporu, protože s takovou platformou to - přiznání - NENÍ vždy jednoduché, ale my chceme, aby projekty měly úspěch a fungovaly mnoho let či desítek let. A musím říci, že běžně aplikace postavené na naší platformě ko-existují vesele vedle SAPu, Heliosu, Dynamics, a všichni jsou spokojeni. 7.2.2016
  • Rike : Ono to ve skutečnosti stojí trochu jinak. Databáze (návrh), UX, to všechno existuje, jen ve VFP. Chtělo by to tomu dát perspektivu + je zde zásadní problém, že se nedají použít žádné standardizované produkty, resp. dají, ale člověk by dal za customizaci strašné peníze. Narazil jsem na jednu v podstatě zásadní otázku. Já si zakládám na tlustém klientu, protože doteď dělám záležitosti převážně webové a vím, jak špatně se tam řeší třeba takové věci, jako je opravdu kvalitní a efektivní ovládání klávesnicí. Jenže když jsem teď týdny prohlížel produkty pro "RAD", vesměs jsou primárně webové. Je to budoucnost? Mám se koukat spíš po nějakém JS, AngularJS, Node.JS řešení? Nevěřím mu tolik, jako starým dobrým Swing, ale zase v tom svedu o trochu víc, než v čisté Javě. Také jsem narazil na SceneBuilder pro JavaFX a to mě fakt zaujalo. Ta lehkost tvorby a přitom srozumitelnost (i když je to to "pitomé" XML). Jenže nemám kapacitu do všechno kvalitě spojit s databázovým strojem, vyřešit procesy v nižší vrstvě (data broadcasting) a nestrávit tím dlouhé měsíce. Proto hledám tedy ten "RAD", abych se mohl soustředit opravdu jen na aplikační logiku; nejlépe takový, který funguje spíš jako builder, tedy že na pozadí vzniká přístupný reálný kód, který se bude moci v budoucnu kdykoli optimalizovat. Je to tak trochu "agilní" způsob pohledu na věc, ale jinak to dneska nepůjde. Ne v dané konfiguraci. 7.2.2016
  • tvavrda : @Rike nechci to tu opravdu "zasvinit" reklamou na to, co děláme, ale v podstatě jste se úplně trefil. Zajímavé s tím desktopem. Trochu příběhu - my jsme začínali právě s desktop frontendem. Klasická 2-vrstvá aplikace, ale psali jsme ji na 100 let dopředu, tj. modelování místo programování, interpretace modelu místo generování kódu, apod. No a pak jsme vytvořili webovou verzi. Desktopovým uživatelům stačilo "přepnout" a jejich aplikace fungovala beze změny na webu. Snažili jsme se (a stále snažíme), aby i ta webová disponovala přesně těmi vlastnostmi, jako ta desktopová, a měli jsme za to, že tomu tak je – klávesnice, uživatelský komfort... Ale někteří zákazníci prostě z desktopové nepřešli, protože prostě rozdíl mezi 0,01s odezvou desktopové aplikace a (třeba) 0,2s odezvou webové aplikace je prostě s**la. Nám to přišlo malicherné, jim ne. A nakonec stále udržujeme obě verze – je možné je provozovat i souběžně. Pro přístup zvenku nebo pro určité "speciální efekty" je aplikace webová, pro přístup uvnitř firmy se může používat desktopová. 7.2.2016
  • tvavrda : @Rike a ještě k té agilnosti. Opět příklad ze života. Jedna pojišťovna ve Švýcarsku měla potřebu převést jednu svoji agendu z Access zbastlených aplikací do něčeho "lepšího". Konkurence: již hotové řešení na SAPu a cosi ze zelené louky. Během 1 pracovního dne vznikl funkční prototyp (tj. opravdová aplikace, resp. 1 její základní obrazovka, samozřejmě bez většiny obchodní logiky, ale přesto něco, na co se uživatel může dobře podívat a zhodnotit, jestli to jde směrem, který si on představuje. První prezentace – místo klasické prezentace portfolia firmy (tohle dovedeme pro někoho jiného, tak něco podobného uděláme i pro vás) se předvedl tento prototyp. Zákazník viděl přesně to, co chtěl vidět (jeho obrazovka, jeho názvosloví, jeho proces). A zvítězili. Další vývoj probíhal zábavně – uživatelům se předvedl daný prototyp a na základě něj se v průběhu asi měsíce rychle "přestavoval" do finální podoby – vlastně se interaktivně vylepšoval datový model a vzhled frontendu přímo s koncovým uživatelem (každé dva-tři dny nová verze pro uživatele – ultra agilní!). Pak už to bylo příliš detailní, a začaly se požadavky sepisovat do Wordu – vznikla klasická analýza. Ovšem ne jako první, ale jako druhý krok po vytvoření prototypu, a to v té analýze byly screenshoty z budoucí aplikace s popisy, co jak upravit! Mezi-prototyp se pak akorát "oživil" (procesní logika, validace, apod.) a – představte si – systém se nasadil a používá se dodnes (s každoročními aktualizacemi dle požadavků). Akceptace koncovými uživateli byla 100%, jelikož aplikaci již od začátku sami pomáhali vytvářet, a vlastně její základní podobu viděli ještě před rozhodnutím o vítězi tendru. 7.2.2016
  • rmaslo : Takto agilní vývoj také používám. Dokonce rád dělám aplikaci v páru se zákazníkem (v podstatě ve smyslu extrémního programování). Zajímavý je ten pojem "modelování místo programování". Poslední dobou totiž uvažuji o nějaké nové lepší verzi a vše mě vede k tomu opustit programování v PHP a přepsat do do nějakého "vlastního" jazyka (opravdu nevím zda jej nazvat modelovací či programovací), který by se dal compilovat do PHP, JS (pro single page app) a případně do jiných serverových platforem. 7.2.2016
  • tvavrda : @rmaslo ano - k tomu nakonec dospěje mnoho lidí. Říká se tomu DSL – doménově specifický jazyk – https://cs.wikipedia.org/wiki/Doménově_specifický_jazyk – vytvoříte si vlastní jazyk, popisující ideálně vaši doménu působení (tj. pro popis fotbalové aplikace např. příkazy PRIHRAJ a DEJGOL), se kterými pak velice efektivně popíšete jakoukoli aplikaci v dané doméně. No a pak nezbývá, než napsat mezičlánek, který převede tento jazyk do strojového kódu, kterému pro změnu zase rozumí počítač. Anebo do nějakého jiného kódu (tak třeba Java, C#, PHP...). Anebo interpreter. Jenže tohle opravdu dobře udělat není legrace. Vlastně nejen, že vytváříte kladivo, ale za chvíli začnete vytvářet továrnu na kladiva, továrnu na továrny na kladiva... Jestli ono není lepší občas si prostě to kladivo koupit a jít ťukat :-) 7.2.2016
  • Kit : U toho DSL by si však programátor měl dát pozor, aby se neutopil v těch továrnách na továrny na kladiva. Je to poměrně zábavná činnost, ale v tom tkví její riziko. DSL by měl zůstat tím jednoúčelovým jazykem. Jakmile po něm chceme něco navíc, tak místo jeho modifikace je často lepší ho zkombinovat s jiným DSL. Takových nástrojů používám velké množství a většinu z nich mám dostupných přímo z editoru. 7.2.2016
  • tvavrda : @Kit Přesně tak, lepší bude najít již existující DSL, než si vytvářet svůj. Existují tedy i nástroje na vytváření DSL, ale to už jsme na tenkém ledě. Teď doufám, že nikoho neurazím, když srovnám programování s vařením. Můžete vařit instantní polévku, můžete si ji dělat "ručně" z nakoupených surovin, můžete si ty suroviny sami pěstovat. A můžete používat hotové recepty nebo recepty sami vymýšlet. No a v dnešní době nemůžu opomenout báječnou disciplínu 3D tisku potravin :-). No a vytvoření vlastního DSL + jeho interpretace... To jsme spíš někde na úrovni molekulární biologie jídla, tj. vymýšlení samotných surovin. 7.2.2016
  • rmaslo : Já souhlasím s tím, že se jedná v podstatatě o nějakou datovou strukturu popisující stránku v jejíchž některých klíčích jsou funkce a šlo by to napsat třeba v XML s podporou pojmenovaných šablon (tj. defacto XML funkcí). Pak bych vlastní DSL dělat nemusel a také bych měl platformní nezávislost. Ale já to nevidím jako "nutný úkol" naopak se mi do toho docela chce a těšim se na to. Nicméně to je nějaká budoucnost myslím, v současnosti je popis Stránky vlastně PHP pole v jehož některých klíčích jsou funkce. 7.2.2016
  • Kit : @rmaslo: XML sice má processing instructions, ale tak hluboko se obvykle zacházet nemusí. XML se dá využít pro zápis samotné struktury projektu, ale pro konverzi do požadovaného formátu (klidně i do zdrojáku v PHP nebo SQL) se používají jiné DSL, které se jen parametrizují. Z jednoho XML pak generuji jedním nástrojem zdroják v PHP, druhým nástrojem zdroják v SQL, třetím nástrojem Javascript a čtvrtým CSS. Úpravou jednoho XML se mohou změnit všechny závislé soubory pouhým průchodem těmito filtry. 8.2.2016

Pro zobrazení všech 9 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.