Na čem a jak postavit vývoj nového firemního IS ?

16.5.2012 07:55 | Přečteno: 3396× | plky | poslední úprava: 22.5.2012 10:43

Vědělo se, že to jednou přijde a tento čas se pomalu blíží. Je třeba se zbavit starého nepraktického řešení. Otázkou do pranice je, co dál? Chápu, že s takovou věcí se moc na veřejnost neleze, ale říkám si, že bych mohl zkusit trochu otevřenosti :).

Trochu historie

IS si píšeme sami na míru. Začalo to v dávných dobách počáteční slávy FoxPro. Tento jazyk se u nás (ČR) stal velmi oblíbeným, možná proto se o nás říkalo, že jsme FoxLand. Mno nic, začal tedy vývoj na foxpro (klasická dosová verze). Po dlouhé době se přešlo na Visual FoxPro. Z dávných vyprávění starců pamětníků probíhala migrace stylem copy-paste kodů z FP do VFP. Co nefungovalo, to se opravilo/dobastlilo. Migrace trvala několik probdělých dní a nocí, než se za běhu vychytaly ty nejzávažnější mouchy. Tenkrát nebyl MS v moc velké slávě a tak se jako storage použil NetWare(doteď běží) a pro databázový server se použil Oracle. Migrace stylem copy-past platila samozřejmě pro vše, včetně databázové struktury, která se pomalu za běhu napravuje. Tato situace přetrvává do dnes. Jen teda s tím rozdílem, že dnes již není jedno velké sídlo, ale jedno velké sídlo + hafo poboček a centrální oracle databáze neběží na MS Serveru, ale na linuxu.

Současné řešení

Máme tedy IS napsaný ve VFP. Klientská app je umístěna na sdíleném disku a uživatelé si jí spouštějí. Komunikace s oraclem jede přes ODBC drivery. Na centrále jsou všechna data, tedy big databáze. Každá pobočka má svůj server se svojí databází. Databáze na pobočce neobsahuje všechny data, ale jen ta, která jsou nutná pro konkrétní pobočku. Všechny databáze se syncují s hlavní db (potřebné tabulky apod.) Z tohoto popisu je jasné, že klientské app na pobočkách jsou jiné. Dříve se psala klientská app pro každou pobočku zvlášť. Dnes se blížíme k tomu, že budou existovat asi jen 3 klientské app (větší pobočky svoje + jedna universální pro zbytek mini poboček).

Dalo by se tedy říci, že jsou pobočky nezávislé na hlavní databázi a tudíž, když padne spojení s pobočkou, tak lidé na pobočce mohou dále pracovat aniž by něco zaznamenali. Samozřejmě jen po určitou dobu (než budou potřebovat aktuálnější data z centrální db)

Problémy

1) Všichni potřebují všechno z jakéhokoliv místa
Problém je ten, že pomalu chtějí všichni všechno, takže se na ostatních pobočkách objevují klientské app i pro jiné pobočky (vybraní uživatelé mohou přistupovat do jiných poboček). Dále je čím dál tím více potřeba mít aktuální data z více poboček na jednom místě, takže se v klientských app občas najde odkaz na db link směřující do jiné databáze v jiné lokaci. Když tedy v jedné pobočce padne net, tak nemusí něco v nějakém okně klientské app fungovat.

2) Podpora VFP a dokumentace
Dalším problémem je nezdokumentovaný kód IS a podpora VFP je kaput, ač ve Win7 není problém a ve Win8 snad také ještě nebude. Pokud jde o dokumentaci, tak problém se táhl od dob minulých a hektický vývoj a nezažité postupy udělaly svoje. V současné době se to programátoři snaží v jistých oblastech dohánět a počítá se, že s přepisem se vše dohoní.

3) Obezličky ve VFP a 32bit only
Je to starý a nepodporavaný jazyk, není tedy divu, že 64bit podpora není a nebude. Taktéž je na denním pořádku dělat různé obezličky v kódu, nebo občas napsat nějakou utilitu v jiném jazyce a z IS jí volat. Buď kvůli chybě VFP, nebo kvůli tomu, že danou věc nejde jinak udělat.

4) Lokalizace
Hodně poboček v hodně státech vyžaduje nějaký ucelený systém lokalizace, který nyní není a asi by šel už těžko implementovat.

5) Aktualizace klientské app
Mezi další problémy pak patří třeba update klientského programu. Když ho mají uživatelé spuštěný, je třeba je odstřihnout, resp. naplánovat výpadek, páč drží soubory na sdíleném disku. Když nějaký uživatel zapomene ukončit klienta, tak se musí sestřelit atd. Čím více poboček, tím více problémů s aktualizací, obzvláště v případě, kdy je na pobočce více klientů (pro jiné pobočky apod.). Zatím je situace v klidu udržitelná, ale růst naznačuje, že dlouho nebude. Jinak nejhorší update je jádra, tiskové formuláře a další věci, co se často dolaďují, se updatují za běhu, aniž by si toho někdo všiml, jelikož jsou drženi vždy jen chvilkově a né jako hlavní soubory, které jsou drženy nonstop.

6) Oracle client a ODBC
Občas se stane, že něco jde v jedné verzi oracle klienta, něco zase v jiné. Kompatibilita mezi verzemi tedy nic moc, aspoň z pohledu, jak jej využíváme. S Oracle klientem se nesou další data navíc a další věc, co se musí uživateli instalovat a konfigurovat. Toto lze vnímat jako problém, nebo taktéž ne (třeba kvůli tomu, že máme k dispozici image strojů apod., takže netřeba moc řešit).

7) Unit testy
Ano, na nic takového se u nás nehraje, zatím. Osobně jsem kolegovi programátorovi doporučoval, ať aspoň vyzkouší třeba FoxUnit (UnitTesting), ale zatím se netvářil nijak nadšeně. Pro foxku toho moc není. U nového projektu by na aspoň nějaké testování mohl být brán zřetel.

Máte čas na unit testy?
Dotaz: Unit Tests

8) ACL (read/write)
V současnosti na tom nejsme s implementací ACL moc dobře. Nějakým způsobem je u nás ACL implementováno a nějaké věci jsou přímo v kódu.

Nové řešení?

1) Standalone klient na file share + přímý přístup do Oracle databáze
Nad touto možností se uvažuje nejvíce. Jako funkční příklad lze použít Helios IQ, což je modulární IS, který podporuje všechno možné. Je to klasický klient, který se umístí na sdílený disk a uživatelé si jej odtud spouštějí. Klient přistupuje napřímo do MSSQL databáze pomocí SQL Native Client (SQLNCLI), což nevyžaduje žádnou konfiguraci v systému, jen mít tohoto klienta na každé stanici nainstalovaného.
Řešení by to tedy bylo stejné jako máme nyní, jen by se klientská app přepsala do jiného jazyka, byla by universální pro všechny pobočky. Taktéž by existovala hlavní db, do které by všichni přistupovali, aby se zajistilo to, že budou mít všichni "všechno". Komunikace by nemusela běžet přes ODBC a odpadla by tak jedna nepodstatná drobnost, která je ovšem potěšující. V takovém případě by bylo IS bez diskuse napsáno v C#.
Bezpečnost?
Otázkou je, zda by bylo spojení s oraclem šifrované, nebo nikoli. Protože třeba pro šifrovaný databázový link je vyžadována enterprise licence na oracle + koupě Oracle Advanced Security packu. Oproti holé standard verzi oracle je tedy cena diametrálně rozdílná.

2) Oracle + Aplikační server + REST API/nebo SOAP + klientská app
Další cesta je v podobě centrální db, buď Oracle RAC (nyní na jednom místě provozujeme), nebo nějaký cluster + Aplikační server (taktéž v clusteru), se kterým by komunikovali klienti. Tzn. cesta :

client sw -> REST/SOAP -> APP Server -> Oracle Server

V jobu provozujeme dva minoritní aplikační servery, jeden Glassfish (IDM) a jeden Oracle SOA Suite (tam běží naše mini aplikace pro mobilní terminály s mini klientskou app), takže pomalu oťukáváme.

Všechny přímé dotazy/update by prováděla aplikace na aplikačním serveru. Ke klientovi by tekly jen výsledky, takže by se u uživatelů neřešily žádný drivery ani knihovny pro connect do db a bezpečnost by mohla být také na vyšší úrovni (komunikace by běžela s aplikačním serverem, žádný přímý přístup do db, nebo je toto diskutabilní?). Teoreticky by se i trochu ušetřil traffic (méně dat, než kdyby klientská app komunikovala přímo se serverem, nebo ne? Ale stejně by to asi bylo nepostřehnutelné minimum :) ). Dále by byl usnadněn vývoj alternativních klientů (kteří by měli třeba i jen nějaké omezené funkce, viz nějaké mobilní varianty apod.). Dnešní doba je doba mobilních technologií a zatím to vypadá i na budoucnost, takže by se s tím mělo počítat.

Dále stojí uvážit nějaký druh cachování na straně klienta (push proxy apod.), komprimace dat apod.
Šifrování je pak sranda díky komunikaci přes https. Nešifrované spojení mezi aplikáčem a db už tolik nepálí (buď by byly obě části na stejném hw, nebo by mezi nimi mohl být šifrovaný tunel).

Problémy obou řešení

Výpadky internetu
Tato řešení přináší i nemálo problémů, třeba výpadek internetu/vpn spojení s nějakou pobočkou. V takovém případě je pobočka kaput a nemůže makat. Na druhou stranu, všude je backup lajna, která by se musela trochu poladit (v současné době slouží jen pro servery na pobočkách, né pro klienty). Takže je toto možná jen takový vsugerovaný problém, který neexistuje.

Umístění serverů a výpadek proudu
Dalším problémem by bylo umístění hlavních a záložních serverů. Dle šéfa by bylo nejlepší, kdyby zůstaly na centrále pod našimi křídly, jen by se tam posílila lajna a backup lajna by se dotáhla od jiného ISP. Teď máme všechno tzv. u prdele, kdyby byly servery v housingu, tak v případě hw problémů bude větší časová prodleva řešení. Další problém je, že u nás dokážou servery běžet bez proudu cca 5-6 hodin, což v případě housingu problém není. Také těžko říci, co by vyšlo ve finále levněji.

Duální řešení?
Dalo by se říci, že máme ještě jednu big velkou pobočku v jiném státu. Takže řešení spočívající v tom, že budou dva hlavní servery v různých lokacích + samozřejmě backup server, se kterým se počítá vždy a všude. V takovém případě je ovšem problém v tom, jak syncovat data mezi servery v nějakém rozumném čase, aby mohly být oba "live" a jak na tom pak budou struktury db a konzistence dat :-/. Toto řeší asi jedině Oracle cluster.

Jinak zbývá řešení v podobě big serveru v jedné lokaci, na který by se připojovali všichni + jeden backup server v jiné lokaci, který by měl aktuální data + nějaký rollback (5-15min). Tady je ale problém zase v tom, že překlápění z live na backup a zase zpět nebývá moc sranda a časově to také není zrovna "vteřinka" :-/.

Update a umístění klientské app
Pokud jde o update klientské app, tak mysl svádí mít jednoho klienta na file share serveru, ze kterého ho budou ostatní spouštět. Pokud by byly formuláře a další věci v oddělených souborech jako doposud, tak je to rozumná cesta k tomu, provádět update formulářů a jiných věcí bez výpadků (uživatelé je drží jen na chvilku a tak není problém vyhmátnout správný čas na update).

Kdyby ho měl každý klient u sebe na disku a update by probíhal nějakou automatizovanou formou, kdy uživatel bude informován o aktualizaci klienta, kterou bude muset potvrdit, jinak nepůjde pracovat. Verze klienta by mohla být zakomponována přímo v komunikačním REST API/SOAP, nebo v případě první varianty nějak jinak. Tím by odpadl problém s aktualizací klienta na sdíleném disku a taktéž by odpadl problém s případy, kdy je třeba něco udělat s file share serverem. Na druhou stranu, klient nebude mít pár MiB a kdyby měli všichni uživatelé aktualizovat každou chvíli formuláře apod., tak by to nebylo moc optimální :-/.
Toto by šlo vyřešit tak, že by se formuláře řešily nějak jinak, nebyly by jako nyní v podobě souborů na disku, ale mohly by se třeba nějak dynamicky generovat.
Občas se také vyskytne někdo na pomalé síti, u něhož je dobré mít klienta na lokálním PC, protože spoj k file share serveru je tuze slabý. Takový klient je buď někde na slabé wifině, nebo běží dočasně přes 3G/CDMA apod. V případě updatu se pak musí hlídat i aktualizace u těchto lidí.

Vývoj probíhá stylem : "Potřebujeme tady přidat tohle info a tamhle toto tlačítko. Bylo by to dobré do konce týdne." + K tomu opravy chyb a aktualizuje se tedy docela dost často. Všichni chtějí všechno hned, jak jinak :). Tudíž systém aktualizací nesmí být pro uživatele příliš otravující a pro adminy příliš náočný :).

Dá se říci, že dost věcí by pořešil klientský program formou webového aplikace, ale co svižnost? Možnosti klávesových zkratek a další věc? Lze vůbec udělat dostatečně použitelného klienta?

Rád si poslechnu nějaké návrhy :). Třeba existuje něco, o čem nemám páru.

Java vs. net? :D

A jsme u toho :). Jen se tento dotaz vztahuje k řešení č.2, protože u řešení č.1 jsme si řekli, že C# je jasná volba.
V čem tedy napsat klientskou a serverovou část (tou, co by běžela na aplikačním serveru). Jsou jen dvě zmíněné možnosti, tedy java, nebo C#. Pro nic jiného není důvod, protože toto jsou jazyky celkem jednoduché, obsahují hodně frameworků, které ulehčí práci a přechod z VFP by nemusel být tak bolestný, jako kdyby se přecházelo třeba na C++. V týmu máme jednoho javistu, zbytek je VFP, nebo všehochuť. Javista teď ale v javě moc nepíše, spíše píše v C#. Taktéž máme licence na Visual Studio.

Rozebírat, který jazyk je lepší, asi nemá moc smysl. Oba jsou na tom hodně dobře. Otázkou spíše je, co by bylo lepší pro nás? :D. Šéf by rád použil C#, jedním z důvodů je i to, že je to jednoduchý jazyk, nějaké zkušenosti s ním také jsou, licence na Visual Studio také máme (to je ale podle mně irelevantní, páč v tak velkém projektu se cena licencí za VS ztratí jako nic). Pár lidí už v něm u nás i něco napsalo.

Vendor lock-in
Mně se osobně nelíbí, že by u nás vznikl vendor lock-in. Nic jiného, než MS servery a aplikáče nelze použít. Existují nějaký open source aplikáče pro .NET, ale těm bych ani za mák nevěřil, nehledě na potřebu clusterování apod., což v podání MS není moc levné. Naproti tomu, aplikáčů pro javu existuje dost a s některými mám i zkušenosti, je tedy z čeho vybírat a o verze se supportem taktéž není nouze (buď by tedy sw řešení vyšlo na 0,-Kč, nebo něco, u čeho je support). Navíc oracle = java.
Lehkou nevýhodou javy zase může být na straně klientů problém s runtime, kdy .NET se tahá z windows update a od Visty je součástí OS, takže u .NETu odpadají problémy s frameworkem. Ovšem toto je celkem diskutabilní, jelikož reinstalace javy/pročištění systému apod. je otázkou chvilky, zato zažraný .NET, tam když se něco pose**, tak to není příjemné řešit.

Také je na snadě řešení, že serverová část by byla napsaná v javě a klientská v C#, ale to je podle mně hloupost, držet se dvou jazyků. Na druhou stranu jsem mluvil s kolegou javistou a ten říkal, že je to jedno, že jsou ty jazyky stejný.

Již existuje "hotové" řešení?
Narazil jsem i na řešení, kde je serverová část již pořešena (REST api, SOAP služby apod.) a vše je připraveno čistě jen na implementaci, viz třeba : tnaps (je to jen příklad, zmíněný produkt bych spíš viděl pro nějaké menší řešení). Mohl by někdo doporučit, nebo informovat o nějakém podobném řešení? Komerční/nekomerční, java/c#...Vůbec nemám představu, zda třeba něco podobného neposkytuje oracle apod.

Frameworky
S jazykem se táhnou i frameworky, jaký byste doporučili u zmíněnýh jazyků pro zmíněné řešení? Pro javu jsem narazil třeba na Spring, který je tak populární, že byl přepsán pro .NET.

Lokalizace
Jak řešíte u svých app lokalizaci? Nebo jak byste jí řešili a v jaký formě by byla lokalizace uložena?

Jak zní dotazy v souhrnu událostí

Počet uživatelů by mohl být řekněme kolem 800.
Velikost centrální db kolem 250GiB.
Formát dat bych přirovnal k objednávkovému systému, kde se pracuje jak s jednotlivými objednávkami, tak se skupinou objednávek a se skupinou skupin objednávek :) + je integrován fakturační systém nad těmito objednávkami, který je propojen se SAPem. Současná práce probíhá stylem : uživatel vybere položku, vyskočí okno, položku zedituje, okno zavře, jiný položku přiřadí do nějaké skupiny, sloučí s jinou položkou apod. V prostředí fungují klávesové zkratky (zkušení uživatelé myš moc nepoužívají) Z tohoto popisu by mohly být trošku patrné případné požadavky na latence.

• Standalone klient app?
• Co použít ke komunikaci s oraclem?
• Lze zajistit nativní šifrované spojení mezi klientskou app a oracle standard edicí?
• Je možný nějaký druh cache (push proxy apod.)?
• Není toto řešení návrhem méně bezpečné jak řešení č.2?
• Použití REST/SOAP a aplikáč?
• Java nebo C#?
• REST nebo SOAP?
• Jaký aplikáč?
• Je nějaké hotovější existující řešení, na kterém by se dalo stavět?
• Cachovaní na straně klienta (push proxy apod.)?
• Umístění serverů?
• Jak řešit failover?
• Kde by měla být klientská app, na file share, nebo u klienta?
• Jak by měla fungovat aktualizace klientské app?
• Nebo použít web klienta a vykašlat se na klasické app? (nemyslím si)
• Doporučované frameworky?
• Nejlepší cesta k tiskovým formulářům? (dynamické generování?)
• Nejlepší způsob lokalizace? (parsování souboru asi nebude patřit mezi to nejrychlejší)

Závěr

Předně bych chtěl upozornit diskutující, že nejsem programátor. Sice si občas zahraju na slepovače kódu, ale to je asi tak vše, nemám to rád :).
Taktéž bych nerad, aby to vypadalo, že se u nás za měsíc rozjíždí nový projekt s novým IS, to opravdu ne :D. Tento můj zápisek je spíše takový malý předprůzkum. Co vím, tak možná za rok se začne něco dít, ale je třeba se na to dostatečně připravit a volit vhodné nástroje a řešení. V současné době se volí jazyk a trochu se oťukává. Jelikož šéfovo představa je o C# (a asi i o řešení č.1), tak se nyní oťukává C#. Teamová diskuse na toto téma bude za pár dní.

Takže, jak to vidíte? Má někdo nějaké jiné nápady, se kterými by byl ochoten podělit se? Řešil někdo z vás už podobnou otázku? :).

Děkuji
Zdar Max        

Komentáře

[daks]

Podle tohoto postu jde platforma .NET tak trochu do kopru, já bych se na ní dnes už asi do většího vývoje nepouštěl.

[Karel]

Zadny .NET do kopru nejde, zkuste vic studovat a mene mluvit. To uz jde vic do kopru ta java pod Oraclem...

[=^..^= AmigaPower®]

LOL! Widlák-radikál

[Karel]

Usmevna reakce :)

[=^..^= AmigaPower®]

Mám penis!

[daks]

Může být, že i Java jde do kopru, možná teď není vhodná doba na rozhodování se jen mezi .NET a Javou.

[Sten]

+1 Otázka by měla být: Python, Ruby nebo C++/Boost?

[kouzer]

Osobně bych šel do javy a Oracle DB (případně Postgresql), bez použití JBoss nebo GlassFish. Případně pro ušetření práce by se dal nějaký "IS" sfouknout v Oracle Application Express...

[Max]

APEX používáme na jednu věc a fakt ne :D. Na malý projekt to je moloch a na velký projekt to má zase jisté limity. Když člověk provozuje db a má volný server, tak v tom jde rychle něco bez obav splácnout bez větší práce, ale na nic náročnějšího bych to nepoužil :)
Zdar Max

[Arnošt Málek]

Pokud to není bezpodmínečně nutné, tak bych šel cestou "webové aplikace", bez standalone klienta - odpadá tím spousta starostí. V tom případě se dá udělat primární a sekundární server a mezi nima master - slave replikace. Využít HA linux (když jsme na linuxovém serveru) a mělo by to fungovat dobře a spolehlivě.

No a pak stačí "jenom" zvolit vhodný programovací jazyk a databázi - a tady si myslím že to je defacto jedno od Javy přes Perl, Python až po PHP - zvolil bych to, co nejlíp umíš - respektive ten člověk (lidé) co to bude psát. Jako databáze opět jedno Od Mysql přes PostgreSQL až po Oracle.

Takové řešení má jednu obrovskou výhodu - pokud se to dobře napíše, tak funguje na různých zařízeních (od mobilu po PC) a operačních systémech a nemusí se instalovat.

[anon]

Jo kvalitni webova app mi taky prijde jAko spravny reseni - akorat server -> klient komunikace muze byt problem ale tam by meli pomoct websockets (ikdyz zase ie nema furt podporu Asi)

[Arnošt Málek]

To může být problém. Je ale otázka, jak moc je taková komunikace potřeba - to si musí zvážit autor. Jsou IS, kde komunikace ze strany serveru defacto není vůbec potřeba a stejně tak je možné si představit i extrém opačný. Myslím si, že většina podnikvých IS si vystačí se současným HTML, Javascriptem a Ajaxem. Pokud se na začátku problém rozumně zanalyzuje, neměl by s tím být problém.

[Max]

Tak nad tím jsem také uvažoval, ale pro takovou věc u nás chybí zkušenosti a abych pravdu řekl, mám z toho celkem obavy, hlavně třeba latence, ošetření drobného šumu na síti apod.
Jinak databáze je jasná, u Oracle zůstaneme a jelikož je Oracle na windows OUT, tak taktéž zůstaneme u linuxu.
Zdar Max

[depka]

nevidim zadny rozdil mezi 1. a 2. resenim, v obou pripadech musi klient pristupovat k nejakemu serveru, tzn ze bez pripojeni si neskrtne, nebo v prvnim pripade je aplikace nasdilena pouze v ramci jedne pobocky?

[Max]

Rozdíl je samozřejmě v návrhu, kdy možnost 2 usnadňuje nemálo věcí v dalším vývoji a je to celkově robusnější řešení. Jinak je jasné, že kdyby byl klient na sdíleném disku, tak na každé pobočce, jelikož by nebylo příliš rozumné, aby si třeba 200 uživatelů spouštělo program ze sdíleného disku přes nějakou 16Mbit lajnu, nehledě na latence.
Zdar Max

[depka]

2. reseni se me zda spise jako komplikace - prevadet data od klienta do soap a zase do sql, komunikoval bych primo z sql, nehlede na pozdejsi upravy struktur dat - zase se budou muset upravovat na vice mistech po celem retezci

data to neusetri vubec zadne - tahas prece jenom ty data ktere zobrazujes

bezpecnost? jestli to ma vubec smysl na technicke urovni tak sifrovane sql spojeni + prava na sql

takze podle me: bud ciste webove reseni, nebo klient ktery komunikuje primo z sql, sql bud centralni nebo centralni + pobocky(sync s centralou)

[rADOn]

2. řešení používáme v práci v podobě xmlrpc a oproti předešlému zaměstnavateli kde se lozilo přimo po DB je to jednoznačně zlepšení. Backend server může nad daty z rpc dělat kontroly příčetnosti a formátovací operace bez zatěžování db, nebo i složitou logiku pokud jde paralelizovat. Klienti jsou proto z hlediska logiky dost tencí, což usnadňuje upgrade a overhead serializace se v tom snadno ztratí. Jiná věc je že všechno u čeho se nehledí na hrubý výkon píšeme v pythonu – kdybych se musel matlat s Javou tak by mě to asi taky donutilo narvat co nejvíc logiky do DB

bezpecnost? jestli to ma vubec smysl na technicke urovni tak sifrovane sql spojeni + prava na sql

Práva na sql nejsou pro spoustu věcí dostatečně jemný nástroj.

[depka]

nesly by ty manipulace nad rpc daty dat do sql procedur? klient by tak v podstate komunikoval pouze volanim primo sql procedur - tam si muzes uz delat s daty co chces a zaroven je pouze na procedurach co mu zpristupni - z hlediska bezpecnosti

[radix]

Mne prijdou ulozene procedury jako zlo. Velmi spatne se s tim pracuje (napr. verzovani), je to primitivni, pevne svazani dat s business logikou, zbytecne to zatezuje databazovy server - ktery typicky byva bottleneckem.

[rADOn]

Přesně tak. Storky a triggery jsou spíše způsob jak hlídat integritu dat, než místo na řešení programové logiky. Naopak čím více logiky vytlačím ven do backendového serveru, tím více práce se dá vyždímat jejich prostým přidáváním. Přidávání serverů na databázovou práci už zahrnuje replikaci, sharding nebo podobné vyfikundace.

BTW teď zrovna dělám na projektu který sloučil dva původně oddělené dabázové shardy. Backend server v C++ řeší jen výkonově a integritně kritické věci, logika v pythonu. Databázový server má na starosti pouze to v čem je dobrý – držet data a poskytovat k nim konzistentní paralelní přístup. Na Javu bych už nesáhl ani klackem

[alblaho]

Tlustý klient startující ze sdíleného disku mi přijde jako řešení z minulého století, tedy pokud pro to není nějaký technický důvod.

Měl bych tendenci jít do webové aplikace. Dobře napsaná JS aplikace je schopná fungovat i offline (appcache, local storage). Ale je fakt, že s tímhle stylem programování nemáte moc zkušeností.

Nevím jak moc by bylo rozumné mít ty webové servery i na pobočkách... Třeba by to bylo super robustní, ale nepříjemné na údržbu.

Vendor lock-in bych se bál taky, ale jsem postižený linuxák. Každopádně uzamčení u MS je určitě řádově dražší než pár licencí k VS . Šel bych do Javy.

A co nějaké méně mastodontní řešení? Ruby+RoR, Python+Django?

[Honza]

Ze se tak resi vendor lock-in u M$, pritom ten Oracla se jevi v posledni dobe jako vetsi parchant...

[radix]

Oracle je vetsi parchant, ale vetsina Javy je open source a na rozdil od MS nemaji pod kontrolou cely ekosystem.

[kyytaM]

Oracle DB odmigrues na DB2, ked velmi treba alebo na EnterpriseDB. Ale co .NET? Jedine komplet prepises...

[Max]

Přesně tak, Oracle není takový problém odmigrovat jinam. Vím, že třeba jedna big společnost právě migruje, nebo bude migrovat oracle na db2. Důvodem je prostě cena (těch oracle serverů mají docela dost).
Samozřejmě záleží na tom, jak db používají a jakou použivají app, ale třeba v případě SAPu je to šumák.
Zdar Max

[kyytaM]

JJ, vo viacerych bankach uz prechadzaju alebo zvazuju postupny prechod od Oracle k IBM. Pokial to bol Sun a Solaris bola spokojnost, ale Oracle je uplne iny pribeh...novy HW sa kupi od IBM (power) zo Solarisu sa ide na AIX, pripadne RHEL. S tym, ze zadna vratka do buducna sa nacrtnu aj na migraciu Oracle DB na DB2 v nasledujucom kroku.

[znalec]

A co nějaké méně mastodontní řešení? Ruby+RoR, Python+Django?

Výhoda těchto jazyků je spíš v rychlém vývoji a podnikový SW se obvykle moc nemění. takže bych řekl, že to nemá moc smysl.

[Pedro]

...Tlustý klient startující ze sdíleného disku mi přijde jako řešení z minulého století, ...

proc?

[rADOn]

Protože celý ten nápad je jen ohýbání programů napsaných pro jednoúlohový DOS aby se dalo napsat do letáku že je to "klient-server architektura". V devadesátých létech byla taková móda to tam psát, asi jako teď je móda být "v cloudu"

[Pedro]

ok, to co jste napsal chapu. Asi je problem v tom, co si kdo predstavuje pod pojmem tlusty client. U nas se neco takoveho dela, tlusty klient je windowsovske .exe, ktere je umisteno ve sdilenem adresari, aby to nemal kazdy pocitat lokalne a lepe se delal update.

[User682]

zdravim,

pridam par nametu k rozhodnuti.

ozkousel jsem jak #C, tak Javu. A delam Javu. Pokud chcete rychle produkovat, tak #C. Pokud chcete rychle udrzovat, tak Java. Java ma vyhodu, ze Vas vede a nejde v ni tolik "prasit kod".

Zalezi na tom, co je pro Vas priorita.

Pro me je hodne dulezite rychle udrzovat a rozsirovat aplikaci. Mit nejake otestovane moduly. Je to dulezitejsi nez rychle neco nacmarat v navrhari nebo usetrit par radku kodu.

Co se tyce webu, tak je sice krasne mit vse online, ale budete mit i ty detske nemoci webu. Hodne veci v javascriptu budete spatne testovat. Spatne se to bude ladit. Zadne logy. A to, co delate jednoduse s desktopovymi komponentami, tak budete delat slozite v javascriptu. Problem se spise jmenuje, jak jednoduse distribuovat aplikace na stanice.

Podle me dojdete k .NET a #C. Sam to vidim v mistech, kde jsem byl. Hodne malo firem preslo s tymem, co delal Microsofti technologie na Javu. Vetsinou je to na vymenu celeho tymu. Lepsi nez mit team, ktery "sni" o navrhovych vzorech a designu v MS, tak mit team, ktery to bezne pouziva.

gf

[knagy]

My jsme tohle řešili před dvěma roky a zvolili jsme Javu + NetBeans platform,která pěkně řeší (kromě jiného) lokalizaci a autoupdate aplikace. Upravíte nějaký modul, uděláte build a nahrajete ho na web/ftp/disk - aplikace si pak testuje, zda neexistuje novější verze a pokud ano, tak si nové moduly stáhne. Jediný problém v Javě byla neexistence databázových komponent typu Delphi (datasety, tabulka napojená na dataset, ...) - ty jsme si museli napsat. Tisky řešíme přes JasperReport - iReport

[Člověk z Horní Dolní]

Jako nejlepší a nejjednodušší mi přijde řešit to jako webovou aplikaci. Možnost výpadku internetu bych vůbec neřešil, to se stane jednou za rok...

Osobně bych použil Play framework a Javu na serveru. Zkoušel jsem pouze Play 1.x, je radost to používat, o řád jednodušší než Spring / Java EE, přitom funkcionalita je +- srovnatelná.

Na klientovi Bootstrap, LESS, JS knihovny jako jQuery, Backbone.js atd. Komunikace přes JSON.

Při použití cache by neměl být problém s rychlostí.

BTW, budoucnost jsou frameworky jako tenhle http://www.meteor.com/, některé věci ukázané na videu vypadají hodně ostře :)

[Max]

Z hlediska návrhu je to určitě nejlepší řešení, ale z hlediska vývoje je to docela problematická záležitost, jak už tu někdo vzpomenul, problémy s debugováním, navíc je vývoj docela hektický a dochází k hodně změnám. Osobně v tom nevidím přínos pro projekt na 20 let.
Taktéž těžko říci, jak velký skok by to byl pro současné vývojáře :-/.
Zdar Max

[Petr Susak]

Psal si ze ten puvodni system je napojen na SAP, proc teda nepouzijete SAP? Nebudes muset resit technologii na aplikacnim serveru ani technologii klienta, jen proste dopisete aplikacni logiku kterou potrebujete. A se SAPem muzes pouzit tlusteho i tenkeho klienta jen si vyberes. SAP si muzes taky namigrovat na 10 druhu OS a 5 druhu DB, nejsi s nicim svazany teda krome toho SAPu :)

[Bedňa]

Tiež som to nepochopil, celý systém postavený na komerčných riešeniach a pritom tam už majú SAP. Tak buď chcem šetriť, použijem Linux, PostgreSQL, Java, alebo platím výplané SAPákom, tak to všetko dám do jedného systému a budem to mať krásne previazané bez nejakých obezličiek.

[Max]

Ano, SAP jsme z donucení nasadili, ale jen pro asi 18 lidí. Slouží čistě jen jako účto.
Celý SAP je outsourcovaný. Jinak nato, aby člověk mohl začít něco tvořit v SAPu, tak v něm musí umět. Aby v něm musel umět, tak musí projít nemálo školeníma a dalšíma věcma. Takže stovky tisíc.
Dále, nyní dáváme za licenci pro jednoho klienta asi 40-50kkč. Museli bychom tedy do něj nalejt jen za školení a licence desítky milionů a pak bychom mohli začít programovat vlastní logiku.
Sám jsem o tom taktéž přemýšlel, ale myslím si, že touto cestou nepůjdeme, hlavně kvůli té ceně.
Zdar Max

[Bedňa]

SAP kvôli účto? Tomu chýba logika, SAP predsa dokáže riadiť firmu z jej všetkými previazanosťami, od skladu cez výrobu, montáž, plánovanie materiálové zabezpečenie, real time lowe, kontroling, proste všetko. Dávať za účto toľko lowe je blbosť a vôbec nevyužíva jeho prednosti.

[Max]

Jde o to, že náš "majitel" má všude SAP, takže chtěl mít všude stejné/jednotné prostředí. Tudíž rozkaz bez diskusí shora(z ciziny). Navíc původní účetní program nebyl moc optimální, přechodem na SAP se celý proces zefektivnil a investované many do SAPu by se měly díky propouštění lidí z účtárny (už jich nebylo tolik potřeba) do několika let vrátit. Tudíž to ve finále zas takový false nebyl.
Zdar Max

[Max]

Jinak je v něm účto a sklad, nic víc. Aspoň myslím :).
Zdar Max

[Bedňa]

Keď sklad, tak aspoň s nastavením minimálnych nákupných dáviek a plánovaním nákupu, je pravda že pokiaľ si zvykol na finančný kontroling účta v SAPe dá sa to pochopiť, páč to majú vymakané a dá sa to prepojiť s ostatnými firmami, teda pokiaľ toho má viac. Osobne by som ale tie prachy za to nedal, páč Ferš s FlexiBee by určite ponúkol niečo naviac.

SAP je super kompexný nástroj na plánovanie biznisu, pokiaľ tam dáš správne dáta, tak sa dozvieš dopredu ako to bude vo firme vyzerať (teoreticky), niečo ako komunistické päťročnice :)

Ja som už dva krát zažil zmenu systému, poprvé by som si spravil procesný diagram a podľa toho sa rozhoval čo vlastne potrebujem. Potom by som tento návrh na pripomienkovanie dal zamestnancom a potom sa rozhodoval ako to spraviť. Páč ľudia čo s tým budú denno denne robiť určite výborne poznajú slabiny terajšieho systému a majú nápady ako by to idálne malo vyzerať z ich pohľadu.

Momentálne sa rieši u nás nový výrobný modul a práve vďaka pripomienkovaniu sa odhalili slabiny ktoré má, bez toho by sa len vyprodukovala vec ktorá by ľuďom život komplikovala na rozdiel od toho na čo nám má technika slúžiť.

[xvasek]

SAP kvôli účto? Tomu chýba logika...

Ani ne. Když máš konsolidovat nadnárodní skupinu, tak nakonec stejně přijdeš na to, že nejlevnější a nejrychlejší je nasadit stejný ERP a v něm pak použít ve všech pobočkách stejné nástroje.

Druhá cesta je konsolidovat přes excely nebo nějaké formuláře, které ti pošlou z jednotlivých poboček, ale pak přijdeš na to, že oni tam mají nepravdivé údaje - ať už proto, že nerozumí tomu, co po nich chceš, nebo tam dají nesmysly záměrně. Navíc si to nemáš jak ověřit, protože jejich informačnímu systému nerozumíš a podrobnější data nemáš. Když na ně začneš tlačit, tak CFO odejde ke konkurenci a začínáš znovu od nuly s tím, že tam není nikdo, kdo by uměl aspoň vyplnit ten původní formulář. Za tři roky se stejně naštveš, koupíš globálně nějaký rozumný ERP a konsolidaci ti udělá tvé vlastní IT a nakonec řekneš, "kdybysme to udělali o tři roky dřív, tak jsme mohli být dávno jinde".

Navíc při prodeji firmy dokáže nevěrohodný účetní systém hodně srazit cenu a naopak věrohodný ji hodně posílí - toto konkrétně jsem viděl loni, kdy se implementoval ERP čistě proto, aby se dosáhlo vyšší prodejní ceny společnosti. Další věc je, že akcionáři chtějí často nahlížet dovnitř do firmy a když nerozumí systému, tak jsou nespokojeni.

[pasmen]

Celé jsem to nečetl, ale pochopil jsem, že máte SAP?

[depka]

jako vtip dobre :D

[dad]

skutecnost , ze se zde preferuje vetsinou webowske reseni by mohlo svadet k dojmu, ze je to idealni reseni.

Pravdou vsak je, ze vetsina programatoru jsou dnes webari a nic jineho neumi.

[Arnošt Málek]

Může to tak vypadat, ale opravdu se to při současných technologických možnostech zdá nejlepší. A to jsem se učil programovat v BASICu a Asembleru Z80 v době, kdy se o Y2K nemluvilo ani v akademické rovině

[JS]

při současných technologických možnostech

Tak tohle spojeni me pobavilo. To jako ze s casem ty moznosti klesly? Nebo v cem konkretne prinasi tenky webovy klient vyhodu nad tlustym klientem?

Neberte to zle. Ja nemam nic proti webovym resenim. Urcite to sve vyhody ma. Jenom nevim, co ma tolik lidi proti tlustym klientum. Prijde mi, ze u tenkeho klienta musite resit veci, ktere u tlusteho neexistuji.

[Arnošt Málek]

Ale kdepak, díky tomu že technologické možnosti vzrostly, tak to tak lze dělat. Díky relativně levným a výkoným počítačům je možné provozovat aplikace, které před 10-15 lety provozovat nešlo. Dnes není problém vzít obyčejný počítač za 10 tisíc a provozovat na něm třeba IS na LAMP. Nebo si pronajmout virtuál, to už je jedno. Díky tomu, že jsou počítače výkoné se nemusí řešit třeba to, že (například) PHP je interpretovaný jazyk.

A naopak, u tlustého klienta se řeší věci, které se neřeší u tenkého. Jednu výhodu jsem už zmiňoval (běh na různém HW či OS). Další výhoda je například neexistence instalace na stanici uživatele. Také odpadají starosti s nefunkčností při stažení nějaké aktualizace OS, případně instalací úplně nového OS.

Samozřejmě vždycky je potřeba zvážit co je lepší a výhodnější. Ale konkrétně u firemního IS je koncepce tenkého klienta (WWW prohlížeče) podle mého většinou výhodná.

[JS]

Hm. Takze kdyz to shrnu. Jedinou vyhodou tenkych klientu je potencialni multiplatformnost. Coz vetsinou u IS, je to priorita? Asi tezko. IS jsou temer vzdy postavene na neci platforme, malokdo ma uplne cely vlastni. Takze pokud si ho postavite na Jave, tak tu platformu tam mate tak jako tak, bez ohledu na to, jestli to bezi na Windows nebo na Linuxu nebo na mainframu. Nehlede k tomu, ze vetsi firmy jsou typicky zavisle na vsech platformach. I kdyz budete mit IS v Jave, ktera teoreticky muze bezet leckde, porad potrebujete, aby ten, kdo zrovna dela Javu, ji podporoval!

Jinak slova o tom, ze pocitace jsou vykonnejsi a tedy muzeme byt rozmarilejsi beru jako vtip. To neni prece duvod, proc neco postavit na nejake technologii. A s tim cloudem, no, rekl bych, ze v pripade IS je to jeste ve hvezdach. (Ono pokud se bavime o vyuziti vykonu kancelarskych PC, tak je dost mozna tlusty klient mnohem efektivnejsi reseni. Moderni PC maji takovy prebytek vykonu, takze cim vic toho udelate na klientovi, tim mene musi udelat server.)

[Miloslav Ponkrác]

Já bych podotknul, že pokud si nedáváte bacha, tak snadno napíšete v Javě kód, který není platformově neutrální. Takže „máte to tak jako tak“ je třeba postavit od první chvíle jako pravidlo vývoje, nebo to nemáte tak jako tak.

Výhodou tenkých klientů je mnoho věcí. Snadnější údržba, menší náklady, a asi tak miliarda dalších věcí.

[JS]

V cem mensi naklady na tenkeho klienta? Vyvoj tlustych klientu (tedy, GUI aplikaci) je tu prece daleko dele a je technologicky daleko snazsi. To co dnes zacina jakz takz umet HTML + JS uz je v grafickych aplikacich leta.

[rADOn]

To je jednoduché: na webovou věc jde najmout nějaká cvičená PHP opice která maká za banán. Na řízení projektu stačí managor s kvalifikací "Facebook kompatibilní" tj. umí otevřít prohlížeč a klikat na modře podtržený text. Takový projekt přece nemůže být drahý ne?

[Vskutečnosti Saýc]

Kolega vyse odpovedel popularne naucnym zpusobem, ja bych to zkusil opravdu: myslim ze to dochazi k nepochopeni toho, co se mysli slovy "tenky klient". Pro to, jestli jde o tenkeho nebo tlusteho klienta neni dulezite jestli jde o aplikaci v prohlizeci nebo o GUI z jaru, ale to, jestli klient obsahuje nejakou logiku nebo nechava vsechno na serveru.

System kde je business logika na jednom miste (idealne spolecne s AAA) je skutecne pricetnejsi na vyvoj nez system kde hromada tlustych klientu zapisuje rovnou do nejakeho uloziste, nebo kde je cast logiky v klientech a cast na serveru. A je jedno, jestli ten "tenky klient" je sablonovaci engine ktery dostava rovnou POJO (nebo POWO, W = whatever) od aplikacniho serveru, nebo treba GUI napsane ve Swingu komunikujici se serverem pomoci RESTu. Tam uz zalezi v zasade na podruznostech (jar se musi deployovat, ale zas je narozdil od HTML a Javascriptu zpetne i dopredne kompatibilni, ale webgui se zas dobre testuje pomoci selenia, ale jar zas byva responzivnejsi, bla bla bla ...)

Pokud udelam neco co ma propojenou business a zobrazovaci logiku, tak je to skutecne smutne. A to se da i s webovymi technologiemi (treba kdyz nekdo pise MVC v sablonovacim jazyce jako je PHP )

...

Kdybych to mel delat ja (a nenajal externi firmu abych se z toho nezblaznil, ale to je jina pohadka), tak napisu aplikacni server v Clojure a klienta weboveho v Rails a necham je komunikovat, ... ale ja jsem magor.

[Vskutečnosti Saýc]

Takovy kod bych rad videl. zvlast pokud je to tak snadne.

[Arnošt Málek]

Těch výhod jsem psal víc, multiplatfomnost je pouze jedna z nich. A u firemního IS ji naopak považuju za velkou výhodu. Nepíšu ani o Javě, zmiňoval jsem koncept "jednoduchého HTML a Javascriptu" a to mi poběží všude kde je WWW prohlížeč - a třeba v tomto vidím ten (technologiký) pokrok, dneska má spousta zařízení tolik výkonu a takový prohlížeč, že právě takový koncept je funkční.

O "rozmařilosti" jsem nepsal, pouze jsem zmínil to, že zvolit -například- interpretovaný jazyk není nutně problém. To přece neznamená, že se ma prostředky plýtvat! O cloudu nepíšu taky, zmiňoval jsem se o virtuálním serveru, což rozhodně není cloud ... zmínkou o levných PC jsem myslel například to, že koupit si dnes server je investice, kterou si může dovolit i malá firma.

S přebytkem výkonu PC máš pravdu, ovšem, mohl bych použít tvůj argument o rozmařilosti a vtipu na tlustého klienta, ne?

Ale, jak už jsem psal, je potřeba vždycky zvážit konkrétní situaci a podle zvolit řešení.

[JS]

No, mne to s tim HTML a JS prijde trochu teoreticke. Stejne je totiz potreba na napriklad mobilni zarizeni s dotykovym displejem potreba udelat specialni UI. A nechtejte nejaky slozitejsi widget (treba bindovany na data) - pak mate problem.

Muj argument byl, proc by mel vsechnu praci delat dedikovany server, kdyz PC ten vykon ma a nepouziva ho? To neni nutne o rozmarilosti, to je o praci, ktera se musi udelat tak jako tak. Napriklad ruzne predzpracovani/preview a podobne. V distribuovane aplikaci je potreba kazdou ptakovinu resit pres protokol, komunikace se nemusi podarit a je treba se z toho umet zotavit, dalsi vec je zabezpeceni atd. V tlustem klientovi je vsechno jen datova struktura v pameti, a tam tyhle problemy nehrozi. V tom vidim ohromnou vyhodu tlustych klientu z hlediska vyvoje - muzete si urcit, na jake urovni a co chcete komunikovat. V tenkem musite komunikovat vsechno od UI dolu. A to se jeste nebavime o dalsim overheadu - komunikace znamena serializaci/deserializaci a to neco stoji atd.

[xvasek]

nj., ale jak dělat rozumně změny v tlustém klientovi? Dovedu si představit, že Max má na ten jejich systém cca 5-10 požadavků za den, které mění logiku chování toho systému, co s tím?

[JS]

No, tak to se pak musi vykomunikovat, tam vam asi nic jineho opravdu nezbyde. Ale to jeste neznamena, ze ten klient musi byt nutne tenky.

Ja pracuji na podobne aplikaci. Ma tlusteho klienta, ktery si ovsem chodi na server pro urcita data (jak neco zpracovavat). Tady se ovsem ta data tolik nemeni (tak max. 1x do tydne) a bylo by daleko rychlejsi, kdyby si klient ta data docasne ukladal k sobe.

Navic, ja opravdu nevidim moc velky problem v tom dnes treba v Jave, aby si ten program stahl svuj vlastni update. Stahnout 5x za den par megabajtu vyjde jiste usporneji nez posilat nekolikrat vsechna data tam a zpet.

[JS]

Ja se ve firemnich IS nevyznam (jsem jen proste skepticky vuci tenkym webovym klientum - prijde mi to slozitejsi v mnoha ohledech nez nativni aplikace, a to ze dnes jsou na vsechno knihovny na tom moc nemeni), ale opravdu je potreba menit program (a nikoli jen nejaka data!) co ridi firmu 5-10x za den? Je to zdrava firma, ktera tohle dela? Jak s takovym pokrokem mohou lide drzet krok?

[xvasek]

Pokud má klient aplikační logiku na serveru, tak už to není tlustý klient, i když je to třeba nativní aplikace - nebo tak to aspoň vidím já. K možnostem čistě webových klientů bych byl taky zatím spíš skeptický, na druhou stranu jsou věci, jako třeba teď už nebožtík Picnik, které ukazují, že když se chce, tak ty hranice jsou dost dál, než si spousta lidí myslí.

Jinak k těm změnám - pokud se ve firmě zavádí nový proces, tak si myslím, že 10 změn za den je ještě velmi málo - teď jsem kupříkladu propojoval automatizovaný regálový zakladač a systém pro vychystávání zboží k ERP, dělal jsem to přes den za provozu a těch zanášených změn byly desítky až stovky. Jasně, šlo by to udělat bokem a pak to až večer přenést do ostrého systému, ale takto mi to lidi prakticky po částech testovali za chodu a mohl jsem jet večer domů s tím, že to funguje. Kdybych si to nachystal vedle a nahrál to tam najednou, tak bych vsadil svoje spoďáry, že by tam druhý den něco nefungovalo.

Jinak lidi s tím problémy nemají - změny jsou povětšinou maličké a týkají se zpravidla jenom uživatelů, kteří si o ně explicitně zažádali - jeden reprezentant za všechny - teď jeden zákazník chtěl, aby mu při tisku upomínek vyjely najednou i relevantní dodací listy a faktury, tak jsem mu to dal do jedné tiskové sestavy na jedno tlačítko - finanční o tom ví a nikoho dalšího to nezajímá.

Co se týká přístupu, kdy by si klient stáhl sám sebe - asi by to nějak šlo vymyslet, ale zatím jsem to nikde takto neviděl. Ono aplikační logika na serveru je u lepších ERP systémů takový bonton, ostatní přístupy totiž zpravidla vyžadují nějaké kompromisy. Tím bych ale nechtěl říct, že tlustý klient je špatný vždycky - určitě jsou případy, kdy takovéto jednoduché a přímočaré řešení perfektně sedí.

[Max]

Ano, firma je zdravá víc než dost. Jinak přesně, jak píše xvasek. Jsou lidi s jistými požadavky, když jim to schválí jejich šéf, tak se to implementuje a nemusí o tom vědět všichni (navíc všichni stejně neví všechno, protože každý potřebuje jen tu část, která je určena pro jeho oddělení/práci). Navíc firma neustále roste, rozjíždí se nové a nové věci a vznikají nové a nové požadavky. To je také ten důvod, proč to nezadávat jiné firmě, protože ten vývoj je neustálý a v žádném případě není jen udržovací.
Zdar Max

[xvasek]

To je také ten důvod, proč to nezadávat jiné firmě, protože ten vývoj je neustálý a v žádném případě není jen udržovací.

No, zase pokud potkáte schopné konzultanty, kteří znají best-practice v oboru, tak vám můžou vyházet nesmysly z procesů, nemusíte vynalézat kolo a můžete to firmu zase někam potáhnout. Ale na druhou stranu můžete jenom vy vědět, jak se to má dělat, protože best-practice zatím neexistuje - to je těžko říct, když ani nevíme, co je vlastně za systém...

[dad]

no, ja do tech IS uz 30 let delam. Behem te doby prichazely a odchazely technologie, kazda nova byla revolucni a mela zmenit svet a zejmena programy mely byt bezchybne a levne. Kazdy starsi programator potvrdi, ze se tak nestalo a nebude tomu ani nadale.

Jak psal pan Ponkrac tady dole, casto zalezi na tom, kdo se s kym vyspi u tech velkych firme, jak ktere firemni divize proti sobe broji a zejmena kdy zase marketingu napadne, ze je potreba zase nejaka nova technologie, aby se mohlo prodavat, vydavat nove knihy, prodavat nova skoleni a nutit lidi k updatum.

Nyni k tem klientum. V Cesku je zajimava situace z hlediska historie IT tim, ze vsechny takove vychodni zeme 'preskocily' to obdobi 80. let na zapade, kdy tam v oblaszi IS proi stredni firmy panovala stredni unixovska technologie. U nas v Cechach zacina IT vlsatne az s windows a vetsina obyvatel si mysli, ze 'pocitacova technika' je neco jako excelovska tabulka. Proto si take vetsina lidi predstavuje pod tlustym klientem program, ktery ma v sobe celou logiku a bezi na clientskem pocitaci - a saha si pro data na nejakou databazi na servru.

IS , ktere vznikaly na zapade na unixech samozrejme takhle vubec nefungovaly a mely skoro vzdy nejaky aplikacni server a klient byl tedy nejaky 'tenky', asi jak tady popisuje xvasek v jednom komentari k tomu IS abas. Takze co je tenky a tlusty klient?

Web-client ma podle me nasledujici nevyhody:

- vejde se na nej o 50 - 100% mene informaci

- integrace podpurnych sluzeb skoro nemozna (telefonie, komunikace s hardwarem jako vahy v expodici, pokladny a pod.)

- komfort jako zadavani udaju (kde mam zadat cislo a muzu zadat 'halabala' a kdyz odskocim mi system rekne ze to neni cislo je zoufalost)

- zavislost na prohlizeci

[Vskutečnosti Saýc]

Ja mam spatnou zkusenost s vyvojem neceho takoveho inhouse, je tam casto problem s odpovednostmi, s tim co to ma vlastne umet, a s tim ze IT oddeleni vlastne dohlizi samo na sebe a podobne. Radeji bych si nechal udelat nabidky od par firem a vyzadal si aby odevzdali zdrojaky a dokumentaci abyste si to mohli sami spravovat nebo neco takoveho. Kdyz uz to maji delat vasi lide, stoji casto za to najmout aspon externiho projektaka.

Jinak technicke reseni ktere jsi nezminil je aby kazda pobocka mela vlastni databazi a mezi nimi probihala synchronizace davkove pomoci nejake ETL sluzby. Ale ono to asi nestoji za tu rpaci, pokud to tak clovek mit nemusi z historickych duvodu. Vyhodou ale je omezena funkcnost i v pripade vypadku, a pokud by v pobockach byly vsechny data, je mozne interagovat i napric pobockami, a hotove ETL si umi poradit s vypadky, duplikaci dat, chybami na urovni jednotlivych radku a podobne mnohem lepe, nez nejake ad-hoc systemy.

Webova aplikace je asi nejjednodussi reseni, pokud je zpusob prace s aplikaci takovy, aby se webova aplikace dala pouzit. Mam zkusenost, ze udelat takove webove GUI dobre da docela praci, a casto to neni nejpohodlnejsi, ale na druhou stranu je to "mene vyvoje" nez udelat zvlast aplikacni server ktery se bude startat o business logiku a nejakeho klienta (treba ve Swingu) ktery s tim bude komunikovat pomoci XML, nebo neceho takoveho.

[Max]

Vyvíjet si to musíme sami, jelikož není žádná dokumentace stávajícího projektu, nebo je minimální. Mají to všichni v hlavě a seznámení se vším někoho jiného by vzalo čas i kolegům (hafo času).
Zdar Max

[rADOn]

Špatná odpověď I když si to budete vyvíjet sami, stejně si tytéž věci budete muset ujasnit (projektová dokumentace?specifikace? analýza?), jináč to skočí průserem přesně jak psal Šum. Co není na papíře, to se během vývoje třikrát změní. Kromě částí které se změnit mají ale "nemůžou".

[rADOn]

1) Standalone klient na file share + přímý přístup do Oracle databáze. Jako funkční příklad lze použít Helios IQ…

Jestli má být Helios typický představitel kategorie, tak je to viditelný argument proč takový přístup nepoužívat.

Update a umístění klientské app…

Celý tenhle "problém" je objevování kola. Civilizované operační systémy mají k tomuto účelu balíčkovací systémy. Dokonce i ty méně civilizované mají nějakou centralizovanou správu software na počítačích v doméně.

Java vs. net

To je jako zeptat se jestli chceš být zastřelen nebo oběšen… chci žít v klidu a v pokoji, prezentaci a co největší část business logiky nacpu do nějakého skriptovacího jazyka. Například halasně proponované webové aplikace mají přednost v tom že prezentační vrstvu celkem v klidu vykostíš do nějakých šablon. V C++ bych sáhnul po QML. Určitě se najde něco i pro Javu (přinejhorším jython nebo jruby a k tomu nějaká MVC knihovna). Kromě toho…

Vendor lock-in

Před pár lety bych ještě řekl že Java je jasná věc. Dnes už bych si nebyl tak jistý. Redmond tě sice bude držet na krátkém vodítku (windows, windows, …), ale platící zákazníky se aspoň snaží nesrat přes míru . Na druhou stranu Oracle IMO předvedl že je zcela ochotný hodit uživatele přes palubu pro pár velmi krátkodobých drobných.

[Max]

Mohl by jsi nějak zdůvodnit bod 1, na který reaguješ? Zajímají mně důvody. Osobně Helios nevnímám nijak tragicky.

Balíčkovací systém ti ale moc nepomůže, když potřebuješ updatovat klientskou app "za běhu", tak to potřebuješ pořešit nějak "za běhu" (u windows nejde moc dobře měnit soubory pod nohama)
Zdar Max

[rADOn]

ad bod 1) … v jedné předešlé práci jsme měli přímého předchůdce Heliosu jménem Noris a bylo to opravdu tragické. Tedy funkčně to bylo docela vychytané, ale uživatel který se z aplikace "nekorektně" odhlásil (resp. neodhlásil protoze mu upadly wydle) dokázal dostat aplikaci za miliony do kolen. hmm… V současné práci máme Helios a o moc lepší to není – pravidelné aplikace oprav způsobují několikahodinové výpadky, do RPC rozhraní mi padají podivné chyby z MSSQL nebo IIS (?!) a draze placená podpora řeší chyby předchozích "oprav"… Ne že by to byl špatný soft po funkční stránce, AFAIK uživatelé jsou celkem spokojení a oproti cirkusu se SAPem je v podstatě zlatý ale za vzor technické dokonalosti bych to tedy nedával…

ad updatování "za běhu" – Právě proto že to pitomé zamykání je inherentní vlastnost wydlí by si s tím měl zabudovaný systém poradit líp než něco co zbastlíš sám. Nebo možná ne, ale rozhodně by to bylo první co bych zkusil. U náš to nějak funguje, admini občas posílají spam maily aby se wydláci relognuli že se jim nainstaluje nějaká závažnější aktualizace. (Na vlastní oči jsem to neviděl, přebývám v linuxáckém koutku… :-P )

[xvasek]

Ano, můžu potvrdit, dělal jsem správce Norisu několik let. Problém byl veskrze v tom, že ten klient byl tlustý - byl jenom klient a ten přímo přistupoval do databáze na úrovni SELECT FROM a INSERT INTO. Když chtěl člověk udělat nějakou změnu, musel ve své podstatě nahradit nějaký soubor klienta jiným, který si někde bokem připravil nebo dostal od partnera. Pro tuto výměnu bylo potřeba "vyhodit" všechny lidi ze systému - mimo jiné proto, že klient si soubory na sdíleném share zamykal - vyměnit ho a pak je tam zase pustit.

Teď dělám s jiným systémem (abas) a deploy se tam doslova "nebe a dudy". V abasu je klient sice taky Windows aplikace, ale je relativně tenký - když se má otevřít nějaké okno, stáhne si ze serveru popis obrazovky, což je v podstatě "kde na formuláři umístit které pole a jakého je datového typu" a pak při každé změně v takovém okně u klienta se posílá každá tato změna jednotlivě k vyhodnocení na server. Server pak může poslat zpět klientovi například okno se zprávou, aktualizovat jiná pole ve formuláři, otevřít u klienta nové okno apod. Klient o vnitřní logice formuláře neví zhola nic, oproti Norisu, kde naopak klient musel vědět všechno.

Když dělám změny, modifikuju jenom data na serveru - ať už jde o formuláře samotné, nebo o vnitřní logiku. Dělám to za provozu a na klienta se to aplikuje okamžitě, jakmile daný program uložím, nebo jakmile se na klientovi otevře okno (podle typu změny).

Jít zpět na úroveň Norisu, kde si člověk půl dne něco připravoval, pak musel všechny otravovat vyhozením a pak to tam teprve slavnostně nahrát, by pro mě byl velký krok zpět. Nehledě na situace, kdy se po půl hodně nějaký Franta ozve, že mu tam něco blbě funguje, ať to opravím...

Na druhou stranu nutno přiznat, že tlustého klienta není úplně nutné dělat vždycky takto blbě, pokud se to udělí chytře, může se i u tlustého klienta měnit za chodu - např. pokud se logika rozdrobí do hodně XML souborů, nebo se třeba definuje v databázi - pak je ale otázkou, jestli je možno takového klienta pořád nazývat tlustým.

Každopádně pro aplikaci typu abas je ještě jedno další pozitivum - myslím, že udělat webového klienta místo té Windows aplikace by schopnému programátorovi zabralo cca týden.

[Miloslav Ponkrác]

Noris je napsán v produktu PowerBuilder. Kdybyste v tomto Sybasím vývojovém nástroji pokoušeli něco naprogramovat, po 14 dnech budete obdivovat kohokoli, kdo v něm kdy něco udělal. Větší srajda než jsou Sybasí produkty neexistují. A to prosím pěkně si vůbec nedokážete představit, co a v jakém stavu dokáže Sybase prodávat.

[xvasek]

Vím. Někdy okolo roku 1992 prodali ze Sybase jeden produkt do Microsoftu, kde už se s tím pachtí dvacet let, aby to trochu jelo.

[rADOn]

ROFL… máš velké tlusté +1

[Vskutečnosti Saýc]

Větší srajda než jsou Sybasí produkty neexistují.

Takova Informatica si s tim nezada.

[Miloslav Ponkrác]

Jak se nepoučit z chyby.

1) Microsoft Vás vyšplouchl s VFP a Vy mu lezete do chřtánu podruhé s .NET

Jako člověk, který tu nas..á spoustu lidí chválou na Microsoft, jedno vím jistě. Microsoft nemá touhy chránit investice do sw naprogramovaného v jejich technologiích, méněno jejich programovacích a scriptovacích bazmecích.

Pokud chcete něco naprogramovat „bez diskuse v C#“, lezete do stejné pasti a ocitnete se poměrně rychle na startovací čáře číslo 3. A to jak to přepsat z .NETu do něčeho jiného.

2) Přijde mi jako nesmysl řešit, zda bude připojení k dbms nativní či přes odbc nebo přes jiné API. To je celkem podružné.

3) Dále vidím „pro nic jiného není důvod“.

Proboha, mě tento článek přijde jako zmanipulované výběrové řízení od Kalouska. Dají se podmínky takové aby vyhrálo přesně řešení, které chci a jen si potřebuji krýt záda, že mi na abclinuxu poradili totéž.

---

Dál jsem už nečetl ani článek ani diskusi. Protože to nemá smysl.

[Max]

Taky názor :).
Zdar Max
PS:Toto "Takže, jak to vidíte? Má někdo nějaké jiné nápady, se kterými by byl ochoten podělit se? Řešil někdo z vás už podobnou otázku? :)." rozhodně nelze přeložit jako „pro nic jiného není důvod“

[Miloslav Ponkrác]

Ach jo, aby autor článku zapřel doslovnou citaci věty, kterou sám napsal. Doporučuji použít vyhledávání textu v browseru a najít věci, ve které píšete, že pro nic jiného není důvod.

[Max]

Aj, už to vidím, špatně jsem pochopil. V textu je to myšleno pro zmíněný bod/řešení č.2.
Přiznávám, že to lze chápat různě, ale určitě né tak, že když definuji dva jazyky, tak nemohu použít nějaké jiné "řešení".
To, že napíšu, že programátoři by zvládli ten a ten jazyk a je tedy vhodné to napsat v nich, aby byl pro ně přechod co nejjednodušší, ještě přeci nelze vykládat jako:

"Dají se podmínky takové aby vyhrálo přesně řešení, které chci a jen si potřebuji krýt záda, že mi na abclinuxu poradili totéž."

Pochopil bych to u nějakého atypického(úzce zaměřeného/málo používaného) jazyka, ale né u těchto dvou, se kterými lze postavit hodně různých řešení a existuje pro ně hafo nástrojů, frameworků apod..
Zdar Max

[alblaho]

Jak se to vezme. Win32 api je zase záležitost umožňující spouštět stejné aplikace od roku 95.

.Net jen nebyl designován na mobilní aplikace, proto se zdá, že od něj teď MS dává ruce pryč ve prospěch jakési modifikace C++. I když to stejně mohli vyřešit jinak, každý "ví", že Java a .Net jsou paměťově nenažrané, ale na Androidu to nikomu nevadí. (A výkon Dalviku oproti ObjC na iOS taky zjevně není problém). Ale to už jsou nějaké politické čachry uvnitř MS.

[Radek Miček]

MS nedává ruce pryč od .NETu, to je nesmysl. Naopak vyjde další verze – .NET 4.5.

[alblaho]

Hele, když se pekly Windows Vista, tak velká část jejich kódu měla být v .Netu. Dopadlo to přepisem do C++ a tříletým zpoždědím.

Pak se .Net slušně etablobal na desktopové programy u kterých výkon není kritický.

No a teď přichází Windows 8 a tam je preferovaným jazykem pro vývoj aplikaci C++. Ale asi hlavně pro tu mobilní metro část.

Nové verze .netu budou vycházet dál, ale jistý ústup ze slávy vidím. Navíc je to i o té politice uvnitř MS, bojují mezi sebou divize "windows" a "development".

[Radek Miček]

No a teď přichází Windows 8 a tam je preferovaným jazykem pro vývoj aplikaci C++. Ale asi hlavně pro tu mobilní metro část.

Proč by mělo být C++ preferované víc než C#? Je sice pravda, že oproti C++ jsou v C# nějaká omezení navíc, ale to přeci platí i pro vývoj na normální Windows. Například díky GC a podpoře pro asynchronní programování mi přijde C# 5 jako vhodný jazyk pro Metro aplikace.

[alblaho]

No prostě metro je napsané v C++ a API je v C++. No a tohle API je zpřístupněné i pro jiná prostředí (.net, JS) přes takzvané "projekce" (nebo jak tomu ti šaškové říkají). Takže nejefektivněji napsaná metro aplikace bude v C++.

Kdyby svět fungoval "dle očekávání", tak bych čekal metro celé v .netu, ne?

Ale je fakt, že podpora pro asynchronní programování je v C#, tam to prostě šlo udělat.

[Radek Miček]

Kdyby svět fungoval "dle očekávání", tak bych čekal metro celé v .netu, ne?

Hlavním důvodem bude asi výkon. Navíc současné řešení (alespoň potenciálně) umožňuje vytvořit projekce i pro jazyky, jenž nevyužívají .NET.

[Max]

Budoucnost .NET
Téma: Budoucnost .NET
Podle mně je hloupost (a podle druhého linku taktéž), že .NET by měl nějak ustupovat. Preference C++ jsou jen pro metro, tedy minimum věcí.
Zdar Max

[rADOn]

Ono to není ani tak o tom že něco ustupuje. Spíš že realita dohnala naivky kteří uvěřili marketingovým kecům o kouzelné hůlce která vyřeší úplně všechno, nejlíp, nejrychleji a se šlehačkou navrch

[Miloslav Ponkrác]

Hlavně se také ztratila motivace v Microsoftu ohledně .NETu.

1) .NET je trucpodnik proti Javě. Už není moc proti čemu trucovat, Java teď řeší své vlastní problémy ohledně vlastnictví a Oracle. A když není společený nepřítel a ten hajzl, kterému to musíme natřít, tak není motivace.

2) .NET ukázal to samé co Java. Na desktop a jako univerzální platfroma jsou tyhle virtuální věci propadákem. Tedy v koncepci Java/.NET, která má vlastnosti statického typování už v runtime a jako základní kámen – protože kompilované statické jazyky dají Javě/.Netu v praxi na prdel. A dynamické jazyky zase dají pro změnu Javě/.NEtu na prdel taky v možnostech dané dynamikou jako první vlastností.

Tedy rychlost = C++.

High level = Python, Ruby, LISP, … (asi milión dalších jazyků).

Java/.NET nese sebou nevýhody koncepce statických jazyků a zároveň nevýhody koncepce virtuálních mašin a výhody obou jsou efektivně potlačeny.

Vzniká tak hodně rozčarování z celého konceptu odstartovaného masově Javou a .NETem v podstatě zkopírovaného.

Obojí tak ustupuje z mnoha nik.

A o to méně motivace je ho prosazovat jako lídra platformu.

---

A o článcích na babel.blog.root.cz si myslím své. Autor píše jednu kravinu za druhou. Diskusní příspěvky moderuje a to stylem, že třeba rozhodne o příspěvku třeba za tři dny po napsání. Takže se opájí svou vlasntí genialitou a kritici to dávno vzdali.

Ale pokud se chcete něco dozvědět o C++, rozhodně berte babel.blog.root.cz jako inspiraci a počítejte s tím, že tak polovina je pravdu a druhá polovina je kravina na entou. Často je obojí v jednom.

[Radek Miček]

Hlavní výhodou C# oproti tzv. dynamicky typovaným jazykům je typový systém a oproti C++ větší robustnost.

[Miloslav Ponkrác]

Ovšem namixované v poměru, že se spíše sčítají nevýhody než výhody.

Ostatně proto je rozpačitost z .NETu na mnoha stránkách a na mnoha místech.

Java, pokud vyřeší svou licenci, což je její Achillova pata už minimálně 10–15 let, a teď to Oraclem vrcholí, má alespoň záruky ohledně nějakého standardu (plus mínus, slabé, ale nějaké náznaky jsou), neuvázanosti na jednu konkrétní platformu a dlouholetou snahu co nejlépe vyhovět enterprise řešením.

Zatímco .NET je totální bastl bez záruk, který rozumně funguje pouze na Microsoft platfromě.

[Radek Miček]

Zatímco .NET je totální bastl bez záruk, který rozumně funguje pouze na Microsoft platfromě.

Mono má komerční podporu i na Linuxu.

Ovšem namixované v poměru, že se spíše sčítají nevýhody než výhody.

To si nemyslím. Určitá robustnost aplikací je pro mě vyšší prioritou než rychlost (netvrdím, že se to týká každého). A s novými typovými systémy postupně klesá potřeba dynamicky typovaných jazyků.

[rADOn]

To si nemyslím Spíš stoupá zmatenost "kompilátoristů" nad rozdílem mezi "slabě" a "dynamicky" typovanými jazyky, protože v modernějších skriptovacích jazycích už tyhle dvě vlastnosti nejsou tak pevně spojené jako ve starém dobrém basicu.

BTW co jsou to ty "nové typové systémy"?

[Radek Miček]

BTW co jsou to ty "nové typové systémy"?

Mám na mysli typové systémy, jenž kombinují různé druhy polymorfismu a je pro ně znám algoritmus typové inference, který s "malou" dopomocí od programátora odvodí typy a vždy skončí.

[rADOn]

Jo tohle… to je "nová" myšlenka asi jako všechno ostatní v počítačovém průmyslu, čili vůbec Je to určitě bezvadné vylepšení staticky typovaných jazyků, ale tvoje vysněná klesající potřeba dynamických jazyků z toho nebude. Síla dynamicky typovaných jazyků leží úplně jinde.

[Vskutečnosti Saýc]

Tak zas Haskell je v tomhle docela dobrej.

Pointa ovsem neni ani tak v dynamicky typovanych jazycich, ale v dynamickych jazycich. Muze existovat i dynamicky typovany jazyk ktery neni dynamicky.

[rADOn]

Přesně to jsem měl na mysli výše s dynamickým vs. slabým typováním. Bohužel většina proponentů silného typování zná nejvýše tak PHP. Někomu prostě nevysvětlíš že rozdíl mezi PHP a Pythonem je asi jako mezi Javascriptem a J2EE

[Radek Miček]

A kde jsou ty různé druhy polymorfismu?

Síla dynamicky typovaných jazyků leží úplně jinde.

Řekněte, kde leží?

[Miloslav Ponkrác]

„Jak se to vezme. Win32 api je zase záležitost umožňující spouštět stejné aplikace od roku 95.“

Ano, a principy Win API vyvinula IBM a částečně v systému VMS. Takže stále platí co jsem napsal.

Microsoft je geniální v implementaci věcí, které nevymyslel. Jeho kompilátor programovacího jazyka C/C++ například je vynikající. Jeden z nejlepších kompilátorů co existuje vůbec.

Ale pokud jde o jazyk, který vymyslel Microsoft, skončí to ignorací zpětné kompatibility, a zmítání se v různých marketinkových cílech MS. Za pár let je z toho vždy eintopf.

Zmínil bych také, že Microsoft nemá problémy věci utnout. Například kdysi utnul Microsoft Visual J++, a bezradné banky co v tom implementovaly své IS nechal ve štychu. Stejně tak Microsoft bez problémů utnul Microsoft Visual Basic. Jméno Basic pak recykloval pro nekompatibilní a zcela jinou věc VB.NET.

Já osobně bych .NET nepoužil, protože není záruka, kdy rupne Microsoftu v kouli a nesmete nějakou část/knihovnu/atd. v .NETu z povrchu zemského.

Dál je to autorův byznys.

---

„.Net jen nebyl designován na mobilní aplikace, proto se zdá, že od něj teď MS dává ruce pryč ve prospěch jakési modifikace C++. I když to stejně mohli vyřešit jinak, každý "ví", že Java a .Net jsou paměťově nenažrané,…“

Ach jo. .NET byl v první řadě trucpodnik proti Javě.

Uvnitř Microsoft vývojového týmu teď bojují dvě frakce stylem Sparta × Slavie. Jedna frakce je frakce pro vývoj .NETu, druhá frakce prosazuje C++ a .NET nechce ani vidět. A druhá skupina je silnější, takže se daleko intenzívněji vyvíjí C++ jak v jeho Microsoft Visual Studiu, tak v jeho nasazování do různých částí Windows, tak to prosakuje do marketinku.

Prostě tým uvnitř Microsoftu .NETu je slabší a tak dostává .NET na prdel. Proč je slabší nevím. Možná tým .NETu méně prosazuje rektální alpinismus u Steva Ballmera. Možná že hlavní manažer souloží v pracovní době členku C++ týmu. Nebo možná se některý člen týmu .NEtu snažil sestřelit svého nadřízeného z jeho pozice a ten ho teď oplácí. A nebo půlka členů týmu .NEtu obehrála někoho s rozhodujícími pravomocemi v MS ve skleněných kuličkách a ten pak byl týden v depresi a rozšlapal jim kyblíček.

Hledáte logiku tam, kde rozhodují emoce, sympatie různých týmů uvnitř MS, a kdo se s kým vyspal, kdo s kým hrál golf.

[Radek Miček]

Ach jo. .NET byl v první řadě trucpodnik proti Javě.

Není to reakce MS na žaloby Sunu ohledně modifikací Javy?

[rADOn]

Ne, mezi tím je několik let díra. Reakcí na tenhle spor se Sunem bylo že prakticky přes noc ukončili microsfti svojí Javu, dotnet vznikl až dlouho potom.

[Radek Miček]

dotnet vznikl až dlouho potom

Spor začal 1997 a vyvrcholil 2001. .NET 1.0 byl vydán 2002.

Reakcí na tenhle spor se Sunem bylo že prakticky přes noc ukončili microsfti svojí Javu

Ano, ukončili vývoj J++, ale s .NETem 1.0 přišel J#, který byl v podstatě následovníkem.

[Miloslav Ponkrác]

„Ano, ukončili vývoj J++, ale s .NETem 1.0 přišel J#, který byl v podstatě následovníkem.“

Ďábel se skrývá ve slove „v podstatě“.

Ono třeba Ruby je také v podstatě následovníkem Céčka (když to vezmete podle správných kritérií). Ale Céčkový projekt pod Ruby nespustíte.

Pohled lidí, kteří zainvestovali velké prachy šité na míru ve Visual J++ na „v podstatě následovníkem“ – tedy napsat to celé znovu a investovat ještě jednou – je odlišný.

[Radek Miček]

Pohled lidí, kteří zainvestovali velké prachy šité na míru ve Visual J++ na „v podstatě následovníkem“ – tedy napsat to celé znovu a investovat ještě jednou – je odlišný.

Právě, že celé znovu to psát typicky nemuseli (podrobnosti jsou v příručce pro upgrade).

[Miloslav Ponkrác]

Ach jo, ta naivita.

Migrace není stoprocentní a to ani zdaleka.

Jinak řečeno, stejně musíte všehcno projet, zkontrolovat. Část přepsat nebo opravit. Po této migraci musíte projekt považovat za neotestovanou alfa verzi, kterou musíte znovu otestovat od nuly a projet všemi testy, testovacím nasazením a kontrolou, musíte zajistit nějaké náhradní řešení pro firmu mezitím.

A teprve po vynaložení balíku prachů, kterým byste umlátili velrybu za přechod, můžete pokračovat na J#.

[gtz]

Umístění serverů : nevím přesně co myslíš, ale asi bych použil nějaké blade řešení na kterém by běželo všechno včetně duplikace/redundance/virtualizace.

failover bych osobně řešil přímo na nějakém SAN storage řešení, vše připojené přes FC, jistě by se to dalo řešit pomocí nějakého blade řešení. Ano šlo by to řešit nějakým FC polem připojeným přes Qlogicy do kříže ke aplikačním serverům přes FC, ale řešení na blade je přímější.

[Max]

Umístění jsem myslel, jak je v článku popsáno, zda servery hodit do housingu, nebo je hostovat ve firemní serverovně, která samozřejmě nemá generátor a baterky zvládnou udržet servery 5 hodin.
Zdar Max

[gtz]

Pokud máte výpadky až 5 hod. pak bych asi volil housing, ale otázka je zda když bude šlus, zda vůbec vy ty servery uvidíte? Pak je možná lepší investice do serverovny někde u Vás a není zase tak velký problém nacpat někam pořádně velkou UPSku, aby stačilo na vše. Sice 5 hod je hodně a hodně dlouho, ale většina velkých potvor cca 150K a více stačí na to, aby servery běžely k cca 2 hod. a pak v klidu uložily práci. Otázka jsou pouze finance nic jiného.

[Max]

Nemáme výpadky 5h :). Máme rackové skříně plné baterií, které celou reckovnu napájejí a vydrží v případě nějakého výpadku jen 5-6h.
Takové výpadky nastávají buď kvůli údržbě transformátorové stanice(minule byla údržba na 4h a tak jsme přežili ok), nebo kvůli kopáčům, když něco přešmiknou :).
Když je šlus, tak je šlus na celé pobočce, ale všechny síťové prvky jedou na ty velké baterie, takže ostatní pobočky nás samozřejmě uvidí a nepoznají nic.
No a je právě otázka, zda je toto dostačující řešení, nebo nikoli. Kdyby nastal delší výpadek, nebo se trochu více začaly vysávat baterie, tak by mohl být problém (hafo lidí i z jiných poboček bude čumět a nebude mít co na práci).
Zdar Max

[gtz]

Pak bych to nechal asi tak jak je, možná bych maximálně posílil baterie pro kritická místa. Pokud budete řešit nové servery pro posílení infrastruktury (failover, cluster, geocluster) apod. tak bych asi šel spíše do toho mít servery na jednom místě v budově kde jsem. Kdyby se to někam přesouvalo pak stejně potřebný HW na tyto věci by se tam musel dodat nebo se spolehnout na něco co již někdo má. No já na failover bych použil nějaké Blade řešení popř. jak jsem psal bych vzal dva QLOGIC FC switche k nim bych připojil FC-SAN řídící jednotku a k ní přes dual FC 8Gbit bych připojil dvě FC pole na SAS discích. Server bych připojil přes FC křížem (do jednoho i do druhého switche) a mělo by to být v pohodě (ideální by aby tam byly 2 FC SAN řídící jednotky).

[kyytaM]

A motorgenerator? Vo vedlajsej firme (mensi Inet provider/hosting/outsorcing) maju dokonca 2 - jeden velky seriozny na dvore v bude, ktory utiahne vsetko a jeden maly prenosny, na ktory sa da operativne zapojit par kritickych veci. :)

[Max]

Tak baterie člověk potřebuje vždy, minimálně na tu dobu, než natočí generátor. Problém s generátorem je cena a náročná údržba. Před rokem jsme za pár stovek tisíc koupili 2x 10kVA rack plný baterií. Napájí to všechno, je to spolehlivé (né jako generátor, který člověk nemusí natočit) a je to bez údržby.
Zdar Max

[SPM]

Mno, baterie taky nedrží věčně a může to velice nemile překvapit :) to jen k tomu, že to až tak bez údržby není; je vhodné je párkrát do roka nechat změřit/otestovat...

[Max]

Není tak třeba. Všechno se to "samo" postará. O testování se postará výpadek proudu, který tak 1x do roka vždy asi je.
Přecijen, není to jedna baterie, ale racková skříň s managementem a dalšíma věcma kolem. Stářím jistě bude kapacita ustupovat, ale rozhodně bych se nebál nějakých velkých překvápek :). A když odejde několik baterií, tak se nic neděje, stále mají kritické servery duální napájení a napojení na druhou sadu baterií.
Zdar Max

[SPM]

No jo, jenže když ten výpadek to otestuje a batrky jsou špatné, tak seš dole :) A už jsem jednou i viděl regál plný baterií, které se nějakou dobu nezkoušeli a odešli - plánovaný výpadek elektriky měl potom nehezké následky...

[Radek Miček]

Pro .NET:

Doporučované frameworky?

Vybíral bych z galerie NuGetů. Osobně bych se vyhýbal frameworkům, jenž se musí komplikovaně konfigurovat v XML a dal bych přednost konfiguraci v kódu – např. různá mapování lze pěkně nastavovat s pomocí Expression Trees – důvodem je samozřejmě fakt, že typový systém může ochránit před chybami v konfiguraci (ví se, že metoda/vlastnost existuje a má správný typ).

Nejlepší způsob lokalizace? (parsování souboru asi nebude patřit mezi to nejrychlejší)

Třeba pomocí .resx souborů?

Jak by měla fungovat aktualizace klientské app?

Pokud se aplikace nemá zavřít, tak funkčnost, kterou bude třeba aktualizovat, umístit do zvláštní assembly a tu loadovat do zvláštní AppDomain. Při aktualizaci celou AppDomain zrušit a vytvořit znovu s aktualizovanou verzí assembly. Mezi různými AppDomain se komunikuje pomocí remotingu. S tímhle může pomoci Managed Add-in framework (MAF).

Vím, že bohaté zkušenosti s FP měl DAQUAS, zkusil bych se jich zeptat.

[Max]

Díky za tipy.
Zdar Max

[Martin]

No, nevím, čím bych mohl ještě přispět, ale zkusím to z opačného konce. Zkuste OpenERP. Je to hotové řešení a jen se udělá customizing. Vymýšlet něco od píky je znovuobjevení kola. Já osobně, když jsem to viděl, tak jsem hořce zaplakal. Jak moc se snažím a pachtím s ASP.NET, MS-SQL, jQuery a jinými.

OpenERP nabízí vše, co bych pro případný vývoj potřeboval, je to OpenSource a má velmi VELMI silnou komunitu. Navíc 3.000 doplňkových modulů mi dává, když nic jiného, obrovský studijní materiál.

Pamatuji stále na první větu v manuálu k TurboVision. Nevymýšlejte kolo, sdílejte jej

Martin

[Max]

Zajímavý projekt, děkuji. Koukám, ale asi podporuje čistě jen Postgres databázi, nic jiného (oracle se nevzdáme).
Zdar Max

[Miloslav Ponkrác]

„Pamatuji stále na první větu v manuálu k TurboVision. Nevymýšlejte kolo, sdílejte jej“

Je zajímavé, že tyto věty o nevynalézání kola píší Ti, kteří ho znovu vynalezli.

Zlí jazykové by řekli, že je pokrytectví.

[Miloslav Ponkrác]

Mimochodem, Borland chcípnul přesně na znovuvynalézání kola. On se rozhodl, že si vše napíše znovu a sám. Nepoužije nic, všechno napíše znovu. Ve výsledku to neuřídili ani finančně, ani neměli dostatek vývojářů.

[JS]

Zrejme nepotrebovali cist manual k vlastnimu SW.

[Agent]

Dočetl jsem se, že "Chybějící podpora českého prostředí - není dokončen překlad a moduly nejsou uzpůsobeny pro specifika českého prostřední, Chybějící podpora pro českou legislativu a specifika českého účetnictví.

Je to stále pravda, nebo už s tím něco uďáli?

[Grunt]

Dočetl jsem se, že "Chybějící podpora českého prostředí - není dokončen překlad

Zas na druhou stranu česká lokalizace je jediná, která je vůbec rozpracovaná (IMHO v tom bude mít prsty pověstná česká vyčůranost (ještě znásobená a zkoncentrovaná v průmyslovém odvětví)). Co jsem to tak v rychlosti proletěl, je to práce na některý víkend (maximálně dva).

a moduly nejsou uzpůsobeny pro specifika českého prostřední, Chybějící podpora pro českou legislativu a specifika českého účetnictví.

Je to stále pravda, nebo už s tím něco uďáli?

Přesně o tom mluvím. Vyčůraný jak pětikoruna. A aby se to samo stáhlo a implementovalo náhodou nechceš, když už je to všechno i tak zadarmo? IMHO maličkost.

[xvasek]

IMHO maličkost.

No, z pohledu toho, kdo legislativní lokalizaci německého ERP dělal, bych teda neřekl. Ono ani tak nejde o to, že by to bylo nějaké těžké informatické kouzlo. Na lokalizaci je asi nejtěžší vědět, v čem konkrétně daný ERP nepodporuje českou legislativu a upravit to. Představ si, že máš nainstalovaný třeba tady ten OpenERP, umíš ho z programátorského hlediska upravovat, tak se do něj přihlásíš a jdeš jako dělat legislativní lokalizaci. Kam teda půjdeš a co upravíš? Nevěděl bych ani já, i když jsem to dělal na jiném systému, protože zrovna tady tento systém může mít problémy v jiných oblastech, než měl ten jiný, který už jsem dělal.

Musíš sestavit tým lidí, kteří mají kvalifikaci v jednotlivých agendách (daně, mzdy, majetek, obecné účto, intrastat, účtování výroby, účtování skladů, inventury, clo atd.) a oni se musí s tím ERP naučit dělat, pak snesou požadavky pro kompatibilitu ERP s legislativou, které se nakódují. Dobré je pak ještě nechat udělat audity systému od třetí strany.

Je fakt, že čistě z pohledu IT, který ví, co má dělat, to až tak složité není.

[Grunt]

Jo, přesně takhle jsem to myslel. Co se týče implementace Ajťákem, tak je to maličkost. Znalost legislativy (ta ještě jde, ale všechny ty ekonomické žblebty…) už je něco jiného. Samozřejmě předpokládám že to není běžná výbava žádného z Ajťáků (max. nějaký kříženec v Pythonu kutaný, ale ti se většinou drží jiných projektů). Sám vím jak těžké je nakřížit Ajťáka s nějakým kalkulačkomačuklátorem (termitus technicus z pohledu libovolného technika:Zmrd). Zas tak jako se Ajťáci udržují ve formě a v přehledu o nejnovějších technologiích si oni drží (a ve svých kruzích debatují o) přehled v novinkách legislativy (jeden by až řekl, že je to baví). Ale stejně tak vím, že na libovolný kód by nešáhli ani násadou od zmetáku i kdyby byl reprezentovaný v Bertíkovi. Takže tohle fakt nevím. Predikovat jak by něco takového dopadlo si netroufnu. To je ještě horší než z kávových sedlin věštit budoucnost .NETu.

[Grunt]

Zas na druhou stranu česká lokalizace je jediná

Omlouvám se. Chyba.

[alfonz mucha]

Máte nějaké větší znalosti o OpenERP? Napsal byste nějaký článek o provozování, případně úpravě atd? OpenERP vypadá jako dostatečně použitelný projekt.

[Max]

Taktéž je to věc, která by mně zajímala :).
Zdar Max

[Grunt]

Si kontaktuj Zaina Idreese, ten ti k tomu všechno poví

[multi]

Me se jako nejvhodnejsi reseni zdar c. 2, tedy aplikacni server. Pro tak velke ukoly se me to zda nejlepsi. Vzhledem k narocnosti uzivatelu a kteri jsou porad stejni, bych jako klienta volil desktopovou aplikaci.

[Bluemoon]

OpenERP je suprovy ERP system. Je napsany v jazyce python, potrebuje postgre databazi a uz vubec nepotrebuje bezet na aplikacnim serveru, coz ho samozrejme stavi do pozice ERP systemu s nenarocnymi pozadavky na hardware a se svymi moduly zase pro narocne pouziti v praxi.

K cestine: cestina je prelozena oficialne ze dvou tretin. Doprelozeni by trvalo tak dva tydny intenzivni prace, sam jsem se o tom presvedcil.

K ceske legislativni norme: Je tim myslena predevsim fakturace, kde musi byt oznaceno datum uskutecnitelneho danoveho plneni a DIC spol., pokud je platcem DPH, dale take aktualni danova sazba. Vazeni panove, tohle cesky modul sam o sobe resi, jen je potreba v nem prepsat aktualni sazbu DPH, protoze je z drivejsich let. Navic k tomu dostanete i ceskou ucetni osnovu.

ERP bezi jako server, webove rozhrani je klient bezici na jinem portu nez server samotny, coz bych zduraznil jako bezpecnostni plus. Muze se pouzit GTK klient na linuxu nebo windows. Pripravuje se mobilni klient. V nove verzi je uz dokonce vylepsene vydejni misto graficky podobne pokladnim systemum.

Mate moznost si to vyzkouset na mojeit.eu, kde je cestina u cca 150modulu(bez tech lokalizacnich) na urovni 95%. Jmeno pro vstup nami podporovanych systemu na vyzkouseni je tester a heslo testertester. Pro ERP je potreba mit povolen port 9100 u vaseho ISP.

[alfonz mucha]

Podporujete zavádění OpenERP do českých společností? Daří se vám to? někdy mi totiž přijde, že to OpenERP, je takové částečně zmatené.. Jinak jsou tam možnosti např. pro bližší specifikaci skladu? Tedy že nebudu mít pouze základní parametry pro výrobek, ale třeba dalších 10 specifických, pro danou skupinu výrobků, tedy např. vína rozdělím, dle červená, bílá, růžová, nebo tak nějak?

[bluemoon]

Ano zavádíme OpenERP do výroby a poskytujeme k němu podporu.

Lze zde rozdělit výrobky nejen umístěné ve skladu do kategorií, to by mělo být standardem každého ERP. Zmatené to celé vypadat může, ale opravdu záleží na nastavení dle potřeby, není to jednoduchá věc na jedno odpoledne. Pro větší společnosti zde lze dokonce vytvářet dceřiné společnosti, které vyrábí určité součásti výroby, např. pro zmíněné víno bude dceřiná spol. dodávat skleněné 0,7l lahve, další jiná plastové 1,5l a další nedceřiná bude dodávat dárkové stojánky též dle kategorií a lze zde vytvářet objednávky na základě odlišných parametrů od svých dceřiných společností a mít je tak ve skladu dle různých parametrů od všech spol.

Pro složitost celého systému je zde si potřeba uvědomit, že OpenERP podporuje všechny tři typy výroby(A, V a T neboli někdy Y) a k tomu ještě tlačný MRP II.(požadavky v čase a priority) a tažný systém JIT(právě v čas) výroby a ve spojení s HR a analýzami, analytickými účty také i DBR(úzká místa výroby). Tomuto se musí pak následně podřizovat sklad a nikoliv, aby tomu bylo naopak, aby se výroba nebo dokonce odbyt odvíjel od skladových zásob. To by pak firma samozřejmě prodělávala, mít něco skladem navíc stojí peníze a když výroba vázne opět to stojí peníze. Jedním z předpokladů ERP systému je právě zpružnit výrobu s příjmem a odbytem nebo ušetřit náklady. Pokud to berete opačně je to jen další skladový software a to s nadhledem zvládne i exelová tabulka a moc peněz Vám to neušetří. V exelovské tabulce si také můžete tabulku filtrovat podle dalších parametrů, ale už to zase nereaguje na výrobu, která stojí jenom proto, že máte dostatek 0,7l skleněných lahví ve svém skladu, který stojí peníze a ne 1,5litrových plastových, které zrovna potřebujete pro výrobu obyčejného vína a stojí tak výroba. Příjem a odbyt, procesní časy v plánu celého výrobního procesu tomu dávají další rozměr, který dnes už nelze vést pouze v papírové dokumentaci nebo v jednoduchých tabulkách. Nelze se zkrátka spoléhat na schopnosti jednotlivých manažérů v různých výrobních oddělení a komplexně už vůbec.

Příklad s vínem je ještě celkem jednoduchý na nastavení. Ptal bych se raději na příklady, kde se ty nůžky daleko více rozevírají např. u V výroby bych zmínil textilní průmysl a léčiva a u A výroby strojírenský a automobilový průmysl u T výroby potravinářský průmysl.

reference jsou také velmi dobré dle postupu: Singer šicí stroje, Danone nebo La poste francouzská pošta.

[Max]

Teď mně napadla jedna otázka neznalého. Mám aplikaci, která si šahá přímo do db. Co zabrání uživateli/útočníkovi(někomu, kdo získa user+pass nějakého uživatele), přihlásit se do db pomocí nějakého sql manageru a prozkoumat příslušné tabulky + si v nich popř. udělat nějaký guláš s daty?
Oproti tomu, když by byla logika napsaná na aplikáči, tak útočník tolik škody nadělat nemůže, naopak je pro něj dosti těžké vyzjistit a napsat si kdyžtak vlastní komunikaci s aplikáčem, ne?
K tomu se vztahuje i ACL, které jde lépe udělat v rámci aplikáče, než v rámci databáze(když si šahá aplikace přímo do db, tak by měly být práva zkrouhnuté na db, ne? Protože možný útok, který popisuji výše.).
A nebo se mýlím a je to jinak?
Díky
Zdar Max

[rADOn]

Vybrání přístupu z aplikace která sahá přímo do databáze můžou teoreticky zabránit správně nastavený práva v DB. V praxi afaik existujou dvě kategorie aplikací – ty které mají práva v DB nastavené blbě a ty které práva v DB nepoužívají vůbec Všechny větší aplikace co znám mají práva ve vlastních tabulích a vynucují je na aplikační úrovni. Obvykle to znamená že všichni uživatelé mají na mašině nastavený BDE / ODBC / JDBC / whatever zdroj s maximálními potřebnými právy. A ano, každý kdo ví kam má koukat si může zařádit podle libosti. :-P

Aplikační server si můžeš navrhnout lépe – tedy i lépe zabezpečený, ale taky je s tím podstatně více práce. Rozhodně to není tak jednoduché jako doufat že "…vyzjistit a napsat si vlastní komunikaci s aplikáčem je dosti těžké…", to je security through obscurity. IMO většina menších uživatelů když zjistí co by to obnášelo (tj. menších než nadnárodní koncerny a megalomanské státní úřady) se spokojí s tím že zase tak moc bezpečné to vlastně nepotřebuje…

[xvasek]

Všechny větší aplikace co znám mají práva ve vlastních tabulích a vynucují je na aplikační úrovni. Obvykle to znamená že všichni uživatelé mají na mašině nastavený BDE / ODBC / JDBC / whatever zdroj s maximálními potřebnými právy. A ano, každý kdo ví kam má koukat si může zařádit podle libosti. :-P

Je to smutné, ale je to tak. Je to víceméně kvůli tomu, že aplikace potřebuje často práva na čtení nebo zápis ne podle tabulek DB, ale podle jednotlivých vět nebo polí (sloupců), což AFAIK SQL neřeší. Ono vůbec SQL není pro ERP zrovna ideální jazyk. Řešení s aplikačním serverem je lepší. I kdybych dělal nějakou blbost, dělal bych to přes aplikační server a co nejjednodušší rozšiřitelný protokol - toto rozhodnutí se v delším čase na 100% vyplatí.

[Filip Jirsák]

Nezabrání mu nic. Můžete ho omezit právy nad databází – ale aplikace bude typicky používat jeden účet pro přístup všech uživatelů, jednak práva v DB nastavíte na tabulky a sloupce, ale ne na jednotlivé řádky.

Pro útočníka nemusí být problém zjistit komunikaci s aplikačním serverem – bude to nejspíš HTTPS a uvnitř buď XML, nebo serializované objekty daného jazyka. Ale aplikační server by měl sám kontrolovat přístupová práva, takže i když na něj útočník pošle požadavek, který nemá v GUI dostupný, aplikační server by měl zkontrolovat práva a operaci odmítnout.

Je ale potřeba myslet i na detaily a třeba neposílat z klienta na aplikační server části SQL příkazů, protože pak může útočník podstrčit svůj kód a opět získat plný přístup k databázi.