Helios Green aneb nejsprasenejsi aplikace kterou znam

[pajkus]

zkusim upozornit na tenhle thread, treba se to dostane az k zodpovednym mistum, nechce se mi verit ze by s tim nikdo zamerne nic nedelal...

[Jezevec]

Tak pro zajimavost, spocitat vejplaty pro 70lidi cca 2 minuty na obyc kancl PC.

2pajkus: Ono by se to muselo cely vzit, zahodit a zacit od nuly, nic jinyho stim delat prakticky nejde.

[Petrik]

Tak pro zajimavost, spocitat vejplaty pro 70lidi cca 2 minuty na obyc kancl PC.

2pajkus: Ono by se to muselo cely vzit, zahodit a zacit od nuly, nic jinyho stim delat prakticky nejde.

me je naprosto jasny, jak to vyvijeli. Zacali s hodne spatnym navrhem databaze a pak na to zacali nabalovat nove anove funkce, az z toho vznikl dnesni stav. PRESNE totez se totiz stalo v te firme kde ted pracuji. Nejdriv zacinali jen s pomoci csv souboru (!!), pak nasadili databazi a jelikoz tomu nukdo nerozumel, pouzivali to stejne jako ty csv soubory. Ted je na tom naprosto tragickem navrhu desitek databazi postaven cely system, tedy desitky a stovky tisic radku SQL a java kodu a nejde s tim nic delat nic jineho, nez kupovat silnejsi HW
Alespon tu neprovadime JOIN pres VARCHAR, zato databaze jsou casto sirsi nez vyssi (vic sloupcu (bezne 100 az 200) nez radek)

[Jezevec]

Tak co se tohodle tyce, oni prave relativne nedavno (4 roky) presli na .NET. A misto aby ten prechod vyuzili k predelani databaze a aplikace, tak proste cpy&paste pouzili to co meli => funguje to jeste hur nez predtim.

[Jezevec]

Panove a damy, dobre se posadte, jedeme dale.

Chcete odstavit celou firmu z provozu ? Staci jednuducha vec, 12x pokus o login na kazdeho usera a dotycny se (zatim neznamou) dobu proste neprihlasi. Vypada to na +- 15 minut, ale tech 15 minut samo nesmi nastat zadny neuspesny login. Dokumentaceo teto funcionalite taktne mlci, moznost administratorskeho zasahu podle vseho veskera zadna. Idealni jako nezjistitelna pomsta na kohokoli, staci vedet jeho loginname. Nic se nikam neloguje, takze nezjistite kdo ani odkud. Jedine co zjistite, ze se nekdo pokousel neuspesne o login.

[D_a_v_i_d]

Omg do pitche... už se mi to blíží... Příští týden začneme z HeG dolovat data pro datovej sklad našeho MISu, to jsem zvědavej, jak "veselý" to bude Ale snad když se s tím budem bavit jen SQLkem, tak by to mohlo bejt přístupnější

[Jezevec]

Z SQLka ... Pro priklad, na zbozi se ti rozpocitava doprava. Jenze to funguje nekdy tak a jindy onak. Nekdy se to flakne rovnou na vydejku (radek toho produktu) a nekdy (pokud FP prijde az po vydeji) ti vznikne samostatnej doklad. => pokud tuhle informaci dolujes z DB, nestaci ti jeden select, ale minimalne dva ruzny.

Totez plati napr pro DIC, kde na organizaci mas policko DIC, ve kterym najdes DIC, ale pokud ho pouzijes, tak sis prave nas.ral do bot, protoze je tam jeste tabulka, paac organizace muze mit ruzny DIC v case a to co je v tom policku nemusi byt aktualni. Samo cast aplikace pouziva to policko, cast tu tabulku = je to nekonzistentni.

Jakmile chces nekde operovat s cislem dokladu (reference_subjektu), tak automaticky pocitej stim, ze neni unikatni (ani v ramci dokladu jednoho typu/tridy/poradace). Ty si sice muzes nastavit ze "kontrolovat unikatnost", ale proste to nefunguje => na tohle zapomen rovnou, je treba jit pres cislo_subjektu. Technicky muzes mit v systemu dve (i vic) ruzny poptavky/vydejky/faktury/... se stejnym cislem (to co vidis navystupu). By me zajimalo, jak bys to vysvetlil financaku.

Obecne de kazda vec udelat min 3ma naprosto datove rozdilnejma postupama (nekdy ale klido deseti). Napr rekneme ze zakaznik si rozmysli nakup => bud se smaze doklad uhrady => zustane nezaplacena faktura (a nejsou vydejky, takze z ucetniho hlediska je to OK). Nebo se udela storno toho dokladu = vznikne zapornej, opet OK. Nebo se da vystavit dobropis .... z pohledu zakose dycky stejnej vysledek, z pohledu spracovani dat nocni mura. Zalezi samo jak moc kreativni jsou zamestnanci.

[Petrik]

Sorry ze ted budu trochu OT, ale zajimalo by me, co se vam libi vic: co nejvice logiky v db, tedy foreing_keys, triggery,procedury, eventy a pod, nebo naopak co nejvice logiky v aplikaci?

[NeMeM9aA]

Ja osobne davam prednost tomu, kdyz je logika jak v DB tak i aplikaci.

Ale proti gustu ....... tak jak to tady ctu tak si nekdo poridi Helios green, kde logika chyby jak v databazi tak aplikaci ....

[Marty]

IMHO tohle jsou stejně jen takový zoufalý výkřiky. Každej systém má mušky, mouchy i masařky. Všude se něco najde... A nebo je to za cenu kompromisů a pekelný ceny.
Stejně tu nic nevyřešíme

[Jezevec]

Sorry ze ted budu trochu OT, ale zajimalo by me, co se vam libi vic: co nejvice logiky v db, tedy foreing_keys, triggery,procedury, eventy a pod, nebo naopak co nejvice logiky v aplikaci?

IMO by to melo byt vyrovnany, rekneme ze struktura DB by mela jasne vyjadrovat vztahy mezi tabulkama a mela by zajistit v maximalni mire konzistenci dat = nedovolit aplikaci to rozjebat a aplikace by mela resit aplikacni logiku = co se kde bude scitat ... protoze to zase nema co delat v databazi. Mozna jinak receno, zmena legislativy by nemela vest ke zmene databazovych struktur. Ty by mely byt maximalne stable a menit se jen naprosto minimalne.

2Marty: Sak ja se nesnazim nic vyresit, ony jsou totiz chyby a chyby. Ja kdyz budu mit nekde neco blbe, tak z pripadnyho zakaznika aspon nebudu delat debila a budu se to snazit napravit.

[xvojta]

IMHO tohle jsou stejně jen takový zoufalý výkřiky. Každej systém má mušky, mouchy i masařky. Všude se něco najde... A nebo je to za cenu kompromisů a pekelný ceny.
Stejně tu nic nevyřešíme

SOuhlasím s Martym. Vždycky je to otázka kompromisu. Dokonalá aplikace neexistuje.
Každý vývoj něco stojí a to se pak odráží na ceně softwaru a maintenance. Pokud chci levné ERP, měl bych počítat s tím, že to bude mít mouchy. Problém nastává ve chvíli, mohu-li za stejnou cenu sehnat o řád kvalitnější ERP. Zde je pak jasné manažerské selhání (kapříci) při výběrovém řízení daného ERP.

P.S. A osobní zkušenost? Jezevec má pravdu. Jednou jsem tenhle bazmek (HeG) taky potkal na projektu a nerad bych to opakoval...

[D_a_v_i_d]

Dokonalá aplikace samozřejmě neexistuje, problém je v tom, že občas se prostě "povede" tak špatný návrh, že to zezačátku jakž takž funguje, tak se na to balí další a další funkcionalita, něco jako když děláte kouli na sněhuláka... Jenže pak se aplikace dřív nebo později dostane do stádia, že to prostě "takhle dál nejde" a teď babo raď. Předělat to stojí spoustu času, čas = peníze, peníze, který autorům aplikace nikdo nedá (zákazník by ideálně "neměl nic poznat", minimálně ne v podobě výpadků při přechodu na "nové" struktury)... Jenže to je často dost obtížné prosadit či v případě skutečně "zmaštěných" návrhů prakticky nemožné udělat... Tak se holt ta kára tlačí dál a v tichosti se doufá, že to ještě chvíli vydrží, než z toho bude komplet průser...

Ad náš současný projekt - tak o SQL dotazy a "dodávky dat" se tam díkybohu bude starat firma, která se "heliosem živí", takže my se v tom snad rejpat nebudem muset, teda pevně doufám, po tom, co tady tak čtu...

K otázce Petrika - ono je to jedno s druhým, ideální je skloubit oboje, u menších aplikací, které jsou "méně náročné" bych si dovolil tvrdit, že nějaká "prasárna v mezích funkčnosti", která je takříkajíc "vyretušovaná" silnějším HW, se prostě nějak "přežije", tam jde o to, aby byla hlavně dobrá ta "aplikace", tj. to, co uživatel "vidí"... Průser nastává v případě, že si firma řekne "hurá, prodává se to, tak to trošku rozšíříme, ještě víc, ještě".... A viz začátek mého postu

Obojí by mělo jít ruku v ruce, nicméně jak říkali i naši předkové, dokonalá jsou jen díla boží, takže je potřeba opravdu hledat kompromisy, protože "dokonalou" aplikaci by možná někdo dokázal napsat, ale umřel by hlady, protože za cenu adekvátní nákladům na vývoj by to asi nikdo nekoupil

[mugsat]

Tak pánové....
pro Vás rádoby chytrálky.

1) pole máte za barákem, to co nazýváte polem je atribut. ANO, uživatelský (UDA) atribut, který zakládáte Vy nemůže mít ve slově postfix "_nazev" ani "_refer", a to protoze se dynamicky zpracovavaji formuláře a tyto postfixy automaticky určují, že se jedná o vztah.
2) ad servicegate.asmx -> to webové rozhraní, jak vy píšete o tom že někdy něco zůstane někdy ne - je to jednoduché... zpracovává se to transakčně. Předpokládám že mluvíte o funkcionalite INSERT/UPDATE volání, kde se zpracovávají jednotlivé záznamy jakožto samostatné tranasakce.
3) k návrhu databáze - je dovolím si říct ve standardu slušně optimalizována. Je implementováno x desítek společností, kde pracuje naráz více jak sto uživatelů a není zaznamenáno problémů. Možná je problém v implementaci od partnerske firmy.


Howgh....

[Marty]

Je hezké, že se k tomu vyjádřil někdo znalý! Jsi vývojářem v Assecu?

[MEluZíNa]

ale tak ten atribut by asi mel mit atribut "uzivatelsky viditelny nazev"? Aspon jak to psal fox, z toho vyplynulo ze uzivateli se zobrazi databazovy nazev atributu...

[D_a_v_i_d]

No vida, pak že se sem nehlásí nováčci... Co takhle trošku nakydat hnůj i na SAP, Cognos a další známější systémy a hned se sem pár vývojářů přihrne, aby si hájili svoje? A hned se nám uživatelská základna rozroste

BTW musím v práci zalobbovat, ještě nemáme funkci "advokáta chudých", tj. maníka, co by prolézal net, jestli se náhodou nepíše o našem produktu někde něco ošklivýho, aby na to případně reagoval

[Doktor-Prase]

No vida, pak že se sem nehlásí nováčci... Co takhle trošku nakydat hnůj i na SAP, Cognos a další známější systémy a hned se sem pár vývojářů přihrne, aby si hájili svoje? A hned se nám uživatelská základna rozroste

BTW musím v práci zalobbovat, ještě nemáme funkci "advokáta chudých", tj. maníka, co by prolézal net, jestli se náhodou nepíše o našem produktu někde něco ošklivýho, aby na to případně reagoval

CATIA Suxx

[mugsat]

Ano, jsem vývojářem HeG v partnerské firmě Asseco(drive LCS) Jen me nastvalo ze clovek co o tom evidentně moc neví, nadává na "funkcionalitu"... Doporučil bych školení / certifikaci, kterou asseco pro klientské správce / partnerské konzultanty nabízí dle smlouvy bezplatně / za drobný poplatek, nebo si pročíst dokumentační portál, kde jsou tyto informace veřejně přístupné.

ad MeLuZiNa>>>
Vždyť takový atribut tam je - lcs.nis_columns.nazev_col třída atributy, atribut Název atributu. Potom máš dole db_name... A jak říkam, v názvu může být slovo "nazev", jen musíš v atributu "DB Name" vyplnit jiny nazev, treba "auto_jmeno" ... Tak složity to zase neni. Jinak ad pravnik chudych ... nic takoveho nastesti nejsem, jen nahodou kamarad narazil na tenle topic.

[D_a_v_i_d]

Jenže ono to opravdu může být tak, že z pohledu vývojáře "geniální" aplikace je pro uživatele nepoužitelný zmetek... Někdy je potřeba se nad tím pokusit zamyslet i z uživatelského hlediska... Minimálně u prvního postu co psal Jezevec nevím, že by pomohlo nějaké školení...

- Budou pak chybové hlášky více user-friendly?
- Bude rolování gridu méně vytěžovat PC?
- Bude se pak rozhraní pro komunikaci s jinými systémy chovat lépe?
- Bude dialog ptající se na potvrzení uživatele vyskakovat před, nikoli ZA oknem (tohle mě fakt pobavilo ), ve kterém uživatel dělá?
- Bude aplikace stahovat menší balíky pro update?

...atd... Chápu, že někdy je to "masakr", dělám v podobném businessu, na druhou stranu ne vždy je řešením prohlásit, že uživatel "o tom ví prdlajs" a "ať nám zaplatí a my ho vyškolíme"...

[mugsat]

co se tyce otazek bude -> to se neptate na spravnem miste. co se tyce hlasek, tak sou dvojiho typu (s dalsim delenim) - pro uzivatele(osetrene rekneme zjednodusene messageboxy) a pro vyvojare (kterym user ani nema rozumet, jen stiskknout button odeslat adminovi... )
Ad rolování gridu, tam bych viděl problém jinde, bud ma jezevec nějakou powerbuilderovou verzi, nebo mají blbě nastaveny počet načítaných záznamů. Defaultně se do gridu načte prvních cca 100 (tušim že 71 je default ale proste rekneme cca) záznamů dle aktuálního sortu, a až při rolování směrem k posledním se donačítají po dalších takovýchle skupinkách, navíc při dosažení určitého limitu to uživatele i varuje, že by mohlo načítání trvat dlouho, proto jsou v každém gridu filtry, kterými dozajista uživatel nalezne záznam který hleda rychleji než scrolováním

Ad rozhraní pro komunikaci - nevím co myslíš chovat lépe. Pokud myslíš "totálně blbuvzdorné" tak to nebude nikdy. Každopádně s verzí 43.x.x přišlo i rozšíření tohoto rozhraní a řekl bych ke kladu, i když jsem si na to déle zvykal. Jinak ze své zkušenosti mohu říci, že toto rozhraní používám zhruba k deseti interfacum ke zcela rozličným systémům, a jediný problém který jsem nalezl zatím, byla data na vstupu. Ale to bych řekl že je obecně problém importů.

Ad dialog za / před... vím, že v některých hotpatchích verze 42.x.x se to stávalo.. ale naštěstí asseco relativně reaguje na takovéto chyby. většinou se takováta chyba opravuje v následujícím hotpatchi po NAHLASENI chyby

Co myslíš "menším" balíkem? patche jsou velikostně někde okolo 100mb, hotpatche okolo 5-20mb. při dnešních rychostech internetu to není nikterak závratná velikost, zvlášťě, když se to instaluje pouze na server, na klienta pak putuje autoupdaterem zlomek velikosti.

jinak ještě k hláškám, je pravda ze nektere asseco hlasky dohani k silenosti i nas vyvojare napr. hlaska "Nastala obecna chyba, nelze pokračovat"

[meteor]

Ano, jsem vývojářem HeG v partnerské firmě Asseco(drive LCS) Jen me nastvalo ze clovek co o tom evidentně moc neví, nadává na "funkcionalitu"... Doporučil bych školení / certifikaci, kterou asseco pro klientské správce / partnerské konzultanty nabízí dle smlouvy bezplatně / za drobný poplatek, nebo si pročíst dokumentační portál, kde jsou tyto informace veřejně přístupné.

Jen počkej, až se objeví Jezevec to bude prima diskuse...

[mugsat]

uz se tesim.

[Marty]

Pokud vím, jezevec teď řešil něco stran problémů s tiskem vyvolaným přes XML rozhraní, nějak to kucí z Asseca nepořešili.. Myslím, že to řešíme my nějakým workaroundem

Takže diskuze bude rozhodně plodná.

[D_a_v_i_d]

jinak ještě k hláškám, je pravda ze nektere asseco hlasky dohani k silenosti i nas vyvojare napr. hlaska "Nastala obecna chyba, nelze pokračovat"

To je koukám všude stejný Nás zase v našem systému drtila v počátečních verzích univerzální hláška "Odkaz na objekt není nastaven na instanci objektu" - což mohlo znamenat víceméně cokoliv, někdy jsem měl pocit, že to hlásí i když je špatný počasí a počítači se nechce pracovat