Helios Green aneb nejsprasenejsi aplikace kterou znam

[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

[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

[Jezevec]

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....

Jiste, databaze je tak uzasne optimalizovana, ze nad ni nemuze pracovat 30 lidi zaroven (by default samo) bez toho, aniz by se navzajem vsichni zablokovali. A dodavatel ma tak uzasne vyvojare a databazisty, ze to ani za penize nejsou schopni vyresit. A to podotykam, ze se nebavime o desitkach ani stovkach tisic.

Jiste, moje optimalizace byla jiste naprosto zbytecna, zajimave ze bez ni novy uzasny .NET nejede vubec.

Ad nazvy poli, taky uzasna funkcionalita, kdyz se pole jmenuje jinak na formulari a jinak ve filtru, ze ? Aha, ja zapomel ze je to featura (a podotykam, ze nemluvim o uzivatelskych formularich). Dalsi uzasna featura je, ze by default vsichni muzou vsechno, a jakmile se objevi nejaka nova vec, tak ji admin musi vycuchat a zakazat (protoze jinak se useri dostanou klido k vejplatam ...). Jo, abych nezapomel, na dynamicky vztahy pro jistotu prava nastavovat nejde vubec, taky dobry, ne?

Apropos, napada vas nejaky duvod proc se 10 000 zaznamu v logu maze hodinu? To bude jiste tim dokonalym navrhem databaze.

Ad grid, by default se nacita 30 zaznamu, a pak se, kdyz je monitor dost velky, nenaplni ani okno a neukazou se ani rolovaci listy (ja vim, uzasna featura) takze kazdy normalni uzivatel zije v domeni, ze uz toho tam vic neni ( jo, ja vim uzasna vec ze tam je pocet v zahlavi, tam to urcite kazdej hleda ). Mimochodem PB verze byla 10x rychlejsi ve vsech ohledech. A nechapu proc si nemuzu odrolovat 100 000 zaznamu, kdyz v blbym excelu si jich odroluji klidne mega za par vterin. Jen pro zajimavost, udelal sem si grid, prasknul do nej query nacitajici hlavicky dokladu, a ono to naprosto vpohode rolovalo stejne jako kazda normalni aplikace => statisice zaznamu behem par vterin. Prgani (teda spis kliknani) na 10 minut prace.

Ad chyby, buton odeslat adminovi je naprosto k hovnu, protoze se z nej (z toho hlaseni) jakozto admin ani nedovim co ten uzivatel delal. Takze stejne potrebuju aby mi to napsal nebo tipnul screen. Jiste dalsi uzasna featura.

Ad dialogy, vazne mam najit ta min 3+ let stara hlaseni, ze se zobrazuji okna dotazu za formulari ? Stale nevyreseno. Neumi to ani takovou trivialni vec, aby okno prihlaseni melo focus. Ano, mluvim o tom co se pusti po stlatecni ikony, kazdej blbej soft ma fokus, jen na tohle se musi jeste kliknout.

patche (sem zvedav kde mate tech 20MB):
42.30 - 105MB
42.30.40 - 91MB
42.33 - 113MB
42.33.10 - 96MB

(pro ty co netusi, tak bez tretiho cisla je to patch, s nim "hotpatch", to posledni je prvni uprave te 33 => nebali to na sebe predchozi => ten 20MB maximalne velky hotpach v realu ani vzniknout nemuze, to muze byt tak maximalne quickbuild => zakaznikem vyrvana oprava vuci jeho patchsetu, ale to je proste neco, co se standardne nevydava)

2Marty: Jo, ono to funguje - uz, oni nejak pani v LCS zapomeli v dokumentaci zminit, ze neumeji tisknout na sitovou tiskarnu, ale ze musi by nainstalovana jako lokalni. Takova drobnost co se resila tusim 3 nebo 4 mesice.

BTW: Pro vasi informaci, nekde se mi tu povaluje ten vami zminovany certifikat, to skoleni je taky uzasna vec, na ktery se clovek nic nedozvi. Ze vsech, ktery jsem absolvoval stalo za rec jediny, ktery skolil nejakej ranenej vyvojar, to ostatni bylo predcitani pripravenych plku. Jo, vubec nejlepsi bylo kdyz skolitelka zjistila, ze "ono to nefunguje tak jak rika (na moje upozorneni)" a mlela vesele dal.

----
Mimochodem, celkem nedavno sem prisel na novou featuru, kdysi slo nad prilohama zmenit zpusob ukladani do databaze a poradac vesele dal fungoval, jen nove soubory ladoval do novehoho uloziste a ty stare normalne oteviral z disku. Nevim se kterym patchem, ale prestalo to fungovat a na dotaz se mi dostalo uzasne dlouhe odpovedi uplne o hovne (a o necem jako hromadnym presunu tech souboru, si muzu nechat leda zdat, pricemz i tohle prasteny forum to umi).

Edit: Pro zajimavost, rad bych jedineho zakaznika (opravdu mi staci jeden jediny), ktery mi rekne do oci, ze je se system spokojen. Nikoho takoveho nam LCS nebyla schopna dodat. Kdykoli sme nekam jeli se podivat na nejake reseni (predevsim ohledne migrace) tak se zjistilo, ze to byl jeden velkej pruser.

[mugsat]

tak popořadě... jezevčáku vidíš to moc černě.

30lidí nad tou databází může pracovat naprosto s přehledem, aniž by se navzájem blokovali, SAMOZREJME... pokud spustíš nápočty skladových uzávěrek, je logický, že kvůli konzistenci dat se musí záznamy které se načítají zamknout... nikdo ti nezakazuje dtb replikovat a takovéhle operace provádět mimo... Pokud se ti to zamyká více, bylo by vhodné zjistit příčinu ( např z logu blokování ... )


Co se týče tvoji optimalizace, tak pokud sis přidal své indexy, může to být pokud se v tom vyznáš dozajista výkonově lépe natom, než indexy, které generuje systém při zakládání uziv. trid...

Default muzou vsichni vsechno... co k tomu dodat,... nastav si defaultni skupinu tak aby nemohla nic ale to neni vada systemu, kdyz nastavis ve windows práva na disk pro everyone na všechno, tak každý nový uživatel taky bude mít práva... tak se nad tim zamysli proboha.

Ad jména na formuláři a filtru... - co na to proboha říct? POle se jmenuje pokaždý jinak, jen tam máš jiný label pravděpodobně. Nevím jestli to je zakázkový formulář, nebo to je v defaultnim modulu, ale vzdy mas moznost ctrl + shift + d si zjistit přesný název pole, pokud ti to neni jasny od pohledu... A uzivatelsky formulare myslim nema cenu rozebirat, kdyz si je muze upravit kazdej jouda ze?

Ad datamining co tu byl zminovanej, vyzkoušel jsem využít toho výrazu, jak jsi říkal, a nepodařilo se mi nasimulovat. Udej prosim příklad.

Proč se 10 000záznamů maže hodinu? Protože se hlídá konzistence dat ... jestli ti to něco říká kontroluje se, zdali neni zaznam navazany ve vztazích, případně nepovolí záznam smazat, pokud na něj něco ukazuje. Pokud si navrhl systém, kde se tohle nehlídá, gratuluji, můžeš ho smazat

ad grid -> proboha, nastav si počet načítanejch záznamů sám a optimálně podle sebe. Jinak tady je nejaky fail, tohle scrolování se mi taky nelíbí.

Ad dialogy -> hlásil si ty chyby?

Ad focus : zadej to jako iou požadavek, určitě ti za nějaký obnos asseco vyhoví

ad tiskárna - https://forum.helios.eu/green/doc/cs...u_PrintRequest - oddíl 2. -> tiskárna musí být na aplikačním serveru. -> méně stěžování na fóru -> více hledání na dokument. portálu / zavolat na hotline a bude ti veseleji


ad externí soubory -> ve verzi 43 došlo ke změně práce s externími soubory taktéž bych doporučil manuál

https://forum.helios.eu/green/doc/cs..._-_manu%C3%A1l

Bohužel z mojí pozice nemohu mluvit o klientele, ale obecně mohu říci že například. vodárenské společnosti s heliosem jsou v celku spokojeny.

[Jezevec]

a) ad pocet uzivatelu a blokovani, mno LCS to resila 2 roky? (Marty?) a nevyresili NIC. Za optimalizovanou rozhodne nepovazuju databazi, kde jsem schopen jako administrator dosahnout vic nez desetinasobnyho zrychleni, tomu se totiz nerika optimalizace, ale sprasena aplikace. Vubec nemluve o HW pozadavcich, pro prislusny pocet uzivatelu, mame (dle pozadavku LCS) min 100x predimezovany HW(to sem zaridil tak trochu i osobne) a stejne to jede jak kdyz se.e a maluje (na HW dle specifikace by se to nedalo provozovat, coz nam potvrdilo nekolik zakazniku, kteri naivne uverili).

b) ad prava, rad bych, ale to by to muselo fungovat (nekolikanasobna zkusenost).

c) Sorry, ale kazda normalni aplikace si bere viditelny nazev z nejaky prekladovy tabulky, a zobrazuje ho vsude a vazne chci videt, jak budu chudakum uzivatelum vysvetlovat, ze to co videj na formulari nenajdou v seznamu poli ve filtru a ze si maj nejdriv zjistovat jak ze se to ve skutecnosti jmenuje. O tom, ze to je tak jako tak bordel (uzasna vec, kdyz to neni razeny abecedne, ale podle typu, kterej je omarkovanej nejakym pidiznakem a navic v tom nejde hledat) ani nemluve.

d) ad mazani, znaji v LCS neco jako cizi klice? Podle vseho neznaji, uzasne sledovat jakym zpusobem (napr) mazou data. Konzistenci dat ma zajistovat databaze, a ne aplikace. Nemluve o tom ze mluvim o LOGu!, tedy nic, co by stalo z pohledu dat za rec + tu sou od toho transakce. A ad konzistence dat, uz se LCS naucila zaridit UNIKATNI cisla dokladu? Pokud vim, stav je jiz nekolik let takovy, ze doklady (celkem bezne) maji obcas stejna cisla. Pri nasem mnoztvi jich sem schopen najit tak 10 do mesice - opet opakovane reportovana (a zdaleka nejen nami) chyba, kterou jaksi neumi vyresit. Vubec nemluve o uzasnem systemu generovani noveho cisla dokladu pohledem do databaze na posledni existujici => pokud udelam fakturu, a nasledne ji smazu, tak dalsi faktura bude mit stejny cislo (plati obecne o vsech dokladech), fakt uzasny.

e) hlasil sem tolik chyb ktery nikdo nevyresil, ze to uz ani neresim, stejne jako vsichni ostatni admini a ne, opravdu nehodlam ani premyslet o placeni za opravy CHYB.

f) ad tiskarna, kde tam je, ze ma byt lokalni? Kdyz primontuju sitovou tak v ramci aplikacniho serveru existuje, kazda jina aplikace na ni bude tisknout. Ostatne tisk je vubec kategorie sama pro sebe, kolik ze tam je tech tlackatek, 7? A ani lidi z LCS nedokazou vysvetlit, jakej je mezi nima rozdil.

BTW: Vodarny, ty asi nemaj 20 000 polozek ve skladu co? Ta jedna co tam maj ta to opravdu nevytrhne.

Nejvic me pobavily ty plky pri prechodu z PB na NET, ze je to jen patch na odpoledne, a ze to vykonostne bude pry dokonce lepsi nez PB ... ... pripadne predstava LCS o tom, co to je tenky klient (ma to 200MB, to je fakt klientik do mobilu jak kdyz fikne) ... pripadne 3stupnova architektura (min 1/2 logiky neresi aplikacni server, ale klient + SQL scripty) a taky me bavi, jak chudak nas partner pres podporu musi bastlit do DB vsemozne triggery a updatovat natvrdo do databaze, aby zajistil pozadovanou funcionalitu.

Vysledek prechodu na NET byl ten, ze vykon spadnul zhruba 10x a bez toho co jsem v DB udelal by se to nedalo pouzivat vubec (napr takove pridani polozky na poptavku trvalo cca 2 minuty - optimalizovana databaze od LCS).

---
Jen tak jeste hodne pod carou:
Pozadavek: Potvrzeni funkcionality na SQL 2k5 (provoz na 2k)
Vyjadreni: No mi to na tom mame a funguje nam to ...
Vysledek (po testovacim prevodu): No ono je treba x, y,z, .... a to vsechno bude trvat min celej den ... a jeste to nemusi dopadnout ...
Nekolik tydnu po prevodu ostre DB: No mi sme zjistili, ze stimhle nastavenim(vyse doporucenym jako jedinym moznym) nam nefunguje KLM, bylo by lepsi, kdyby ste to prevedli zpet (naprosto nerealne).

Predpokladam ze prechod na vyssi verze bude vypadat podobne - "si to nejak prevedte, ale taky vam to nemusi fungovat"
Ocekaval bych, ze u SW za par mega dostanu jednoznacny vyjadreni ve smyslu "ano, SQL 2k5 podporujeme, funkcionalitu garantujeme a je treba nasledujicich kroku:"
Stejne jako bych ocekaval, ze dodavatel je schopen rict, zda neco bude nebo nebude fungovat v nejake konfiguraci (ze to otestuje) a ne ze rekne "no mi to tak nemame, tak nevime".