Gyors adatrögzítés webes felületen

 ( bodnarj | 2018. január 2., kedd - 19:22 )

Sziasztok!

Megkeresett minket egy leendő ügyfél, akinek egy régi karakteres felületű dBase alapú alkalmazását kellene lecserélni egy modernebbre.
Ebben az alkalmazásban nagyon gyorsan tudnak adatokat rögzíteni még összetett képernyőn is. Billentyűzet elég, hozzá sem kell nyúlnia az egérhez, a fájlt közvetlenül látja az alkalmazás, nincs a HTTP kérés/válasz miatti latecy.

Van arra valamilyen módszer, hogy hasonlóan gyors adatrögzítést lehetővé tévő képernyőket tudjunk készíteni?

Tudom ennyiből elég nehéz megfogni mit akarok.
Tételeket kell rögzíteni bizonylatokra.
A bizonylatnak be kell állítani 15-20 paraméterért majd el kell kezdeni rögzíteni a tételeket.
Először is ki kell választani a tételt a neve alapján, majd a tételnek is be kell állítani 8-10 paraméterért. Az egyes paraméterek között függőségi viszonyok vannak, és a bizonylat paraméterei is befolyásolják a kiválasztott tétel paramétereinek értékét, tehát minden egyes felületi elem módosítása esetén kérést kell küldeni az alkalmazás szervernek mely vissza küldi a választható és/vagy számolt értékeket.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Alapvetően nem a képernyők a problémásak, nyilván ha gyorsaságra gyúrsz akkor nem a legújabb csillivilli bloatware js lib-et kell használni, hanem összekell rakni minimálra.
Inkább az ajax rész lehet problémás, illetve az adatbázist rendesen meg kell csinálni mögötte. Illetve ha ezek a "paraméterek" nem nagyon változnak (pl. adott termék adott áfakulcsú, vagy X vevőnek Y százalék kedvezménye van, ilyesmi), akkor azt akár kliens oldalon cache-elheted is.

mellé lőttem

Ha számít a gyors reagálás, akkor AJAX helyett websocket és mint írták, kevésbé bloatware módszerekkel, saját Javascriptet küldeni a böngészőbe. Kompromisszum: websocket csak az utóbbi években megjelent, HTML5-öt támogató böngészőkkel működik, a régebbi, például IE9 böngészőt használóknál nem fog menni.

Lásd még:
http://html5test.com/ (WebSocket szóra keress rá)
https://www.slideshare.net/MarceloJabali/html5-websocket-introduction

Mi csináltunk jó dolgokat WebSocket-tel, de volt pár érdekesség, többek közt a standard 80-as porton egyes IPS-ek alapértelmezett konfiggal (hello Cisco) lehet hogy megfogják a WS-t.

btw.: Az IE nem böngésző.

A legnagyobb idő a renderelés. Konkrétan 4s megjelenítésből az egérkattintás+adat beküldés+adatbázis lekérdezések+adat visszaküldés <0,25s volt, a renderelés a többi.
Erre a megoldás ugyanazzal a motorral egy C++-ban megírt kliens lett.

Ebben a felállásban nem volt még alkalmazásszerver sem. Viszont a brózer miatt kellett szupergyors kliens gépeket beállítani. Mivel a megjelenítéstől független a listák feldolgozása, nem lesz probléma a többszöri szerverhez fordulás, hacsak nem jön vissza mindig sok és hosszú lista.

Erre az okosok még szerveren renderelésben is gondolkodtak, bár ez nem tudom, hogy itt alkalmazható-e.

A fenti mérés elég régi, azóta biztosan romlott a helyzet. ;)
Egy 2400bd sebességű terminálnál nem szokott ilyen kérdés felmerülni.

Ne haragudj, de ha 3.75s -ig renderel valamit a kliens progi, azt valami dilletáns csinálta és nem a C++ -ban újraírás a megoldás (attól függ melyik évben volt ez.. remélem nem az utóbbi 15-ben). :)

Brrr - téves. ;)
A "kliens progi" == IE.
Talán a renderelés kifejezés zavart meg. A jelenség oka az, ha sok elemű listá(ka)t küldesz kombó(k)ba. Igaz, az eredetit dilettáns írta, de később a profik sem találtak jobb megoldást.
A mérés tényleg nagyon régi, de ismervén a rendszert, a konstelláció azóta sem változott. Legfeljebb a brózerek gyorsultak*, meg már nem csak az IE támogatott.
*És itt rögtön betegre is röhögtem magam.
Amit a későbbiekben láttam, az már jóval korszerűbb kialakítású volt, sok-sok ifjú szakember írta. Na, az legalább két nagyságrenddel lassabban működött. Konkrétan 15x gyorsabb vason 13x lassabban működött. És ez még csak az adatbázis! A megjelenítés nem lassú, hanem inkább kétségbeejtő volt. Talán nem a rendszer a rossz, csak elszaporodtak volna a dilettánsok? ;)

Figyeld jól meg: A topic arról szól, hogy egy 25-30 éves, eddig jól működő rendszert hogyan cseréljün le egy - a feladatra teljesen alkalmatlan - modern eszközökkel megvalósított másikra.

Mivel a topicnyitó is kombónként frissítené az oldalt, a többesszám kilőve. Igy mondjuk gyorsabb lesz, de sokkal több interakcióval.

Valóban egy rakás UI framework be tud lassulni, ha a listáknak "túl sok" eleme van :-). A négyzetes skálázódás teljesen tipikus, ami egy mai gépen párezer körül válik problémássá, de aztán nagyon gyorsan használhatatlan lesz. Erre is érdemes rámérni a tipikus elemszámokkal a projekt elején, nehogy meglepi legyen.

Mondjuk a hibásan működőket újra lehet írni igény szerint, de kevesebb szívás van egy eleve jó rendszerrel.

Csináltam mérést, hogy hol tart ma a tudomány, ha választó listákról van szó: https://hup.hu/node/157274

Az a része tuti igaz, hogy elszaporodtak a dilettánsok.
--
Gábriel Ákos

Nem piskóta erők munkálhatnak a Moore-törvény és ezerszeres sávszélesedés ellen, ha a huszonpárévvel ezelőtt Novell Netware háromegykettőn ülő db-t nyitó, 640kB + memóriavarázslattal futó 386-osokon indított clipperes programok rögzítési sebességéért küzdeni kell a modern módszerekkel.
Pedig tényleg.

(Ja, amúgy csak sub, kíváncsi vagyok.)

Már 4MHz-s PC-n is simán lehetett érzetre azonnal választ adó konzolos programot írni. Legyen a mostani cél PC 2GHz-es. Ez 500-szoros gyorsulás.

Egy "mélykonzolos" text alapú program a felhasználónak 80x43x2 bájtot mutat, ennyit kell egy frissítéskor előállítani. Ez 6880 bájt. Lásd: https://en.wikipedia.org/wiki/VGA-compatible_text_mode#Text_buffer

Ugyanez a program böngészőben a nem túl impozáns 1920x1080x3 felbontásban 6220800 bájt. 904-szer annyi bájton ábrázoljuk tehát ma a képet.

904-szer annyi adatot jelenítünk meg, de csak 500-szor gyorsabb a PC-nk. Majdnem kétszer nehezebb tehát ma megvalósítani, mint huszonpáréve!!!4!4!

:-)

Fetéve, hogy hiszünk nekem és nem akarunk grafikus felüóletre kényszeríteni nem oda való dolgokat - adatrögzítés - hanem egy karakteres felületet adunk a usernek. Akkor az 500-szor gyorsabb gépünkön is csak pár ezer byte-os buffert kell mozgatni. A nyitó posztban ez az igény és az erőlködés azon megy, hogy lehet a varázslást előállítani, hogy az igény kielégüljön egy feleslegesen megnövelt adatmennyiség mozgatásával. :)

A néhány ezer byte mozgatására - úgy 1GB-ban - pedig egy brózer a legalkalmasabb eszköz. :-D
Jó ez az ojjektumorientáltság, csak egy triviális tény felett mindig elsiklanak az emberek. A tízszer annyi adat mozgatásához tízszer annyi erőforrás kell. Bármilyen gépen, bármilyen nyelven.

De tényleg, ha már mindent webes back bevetésével kell megoldani és a felhasználók nincsenek elrontva 3D-ben pörgő desktopon bukfencező mókust animáló egérkurzorral, miért nem jelenik meg a gondolatok között, hogy vegyék elő a lynx/(e)links/w3m közül azt, amelyik virtuális konzolon futva már módosítás nélkül a legkevésbé taszító a rögzítőknek, és annak a kódját szabják át feladatspecifikus ágakkal?

Ez a kalkuláció kicsit sántít. A 4MHz-es PC 16 bites volt 8 bites adatbusszal. Egy utasítás - címaritmetika híján - lehetett 30-40 órajel. A mai processzorok (pici processzor az összes magra számítva) már 10-20 utasítási is végrehajtanak egyetlen órajel alatt 64 biten, esetleg 256 bites adatbuszon, amely utasítások között lehet néhány FPU utasítás is. Ezt alsó hangon véve adjunk hozzá egy 400-as szorzót! Ezzel korrigálva az eredményedet a sebesség >200.000.
A pixelenkénti adatábrázolás némileg túlzásnak tűnik, de van mögötte olyan GPU, ami a CPU-nál - legalábbis erre a feladatra - lényegesen gyorsabb. Na, így már megközelíti a pc korszak elején bios hívások helyett használt directvideo (text buffer(ek)==video memória (lapok)) sebességét. ;)
Egy text alapú programnál csak az abszolút worst case a text buffer alapú számítás. Csak akkor fordul elő, ha teljesen új formot raksz ki. Már a terminálos időkben is egy VT100-nál bonyolultabb terminál kezelt formot. Vagyis első lépésként kimegy a form, és azt rögzíti a terminál. Utána már csak a megjelenített/beviteli mezőkben cserélődik az adat. Így valójában egy 300bd sebességű terminálnál elérhető a látszólag tetszőleges sebességű adatcsere.
A grafikus felület+egér használata további lassító tényező. De a legnagyobb lassítás a gépírás képesség helyetti windows tanfolyam. :)

Szóval durván alulbecsülve maradjunk az 1.000.000 szorzónál. :-D
Már ha adatrögzítésről beszélünk.

Abszolút van rá módszer, több is.
Én lehet h "előbbről" kezdeném a kérdezést, mert lehet h a 30 éves szoftverhez passzoló, gondolom 30 éves üzleti folyamatra is ráfér egy frissítés.

Esetleg nem lehetne bescannelni a bizonylatokat és tömegesen feldolgozni?

Persze ha az ügyfél legokosabb és pontosan tudja h nem akar változtatni akkor "csak" a szoftvert kell jól megírni.
Ha esetleg érdekes lehet a desktop app fejlesztés akkor az electron.js -t érdemes megnézni (attól az websocket a háttérben).

Még egy probléma felmerült bennem, ha a jelenlegi kliens gépek is a 30 évvel ezelőtti színvonalat képviselik akkor eléggé nehézzé válik a helyzet.

--
Gábriel Ákos

Roppant mód érdekelne, hogy miért az ügyfél a hülye mindig, amikor az éppen hypeolt technológia alkalmatlan szar a valós üzleti problémáira.

Legtöbb szoftvercég bem azért szállít mai napig "your companys app"-okat, mert lusták felvenni egy designert (jó, valahol azért is), hanem, mert a legtöbb user úgy van vele, hogy inkább kerüljön még ki az a plusz 3 mező a másik 15 mellé, de tudjon gyorsan dolgozni vele.

Dolgoztam 6 évet egy kereskedő cégcsoportnál, ahol láttam bőven, hogy mi az előnye a "your companys app"-nak és hol van előnye a webes appnak. (Meg az Excelnek). Ez alapján bátran ki merem jelenteni, hogy az ilyen user requirementek sokkal, de sokkal fontosabbak, mint azt te hinnéd. Rengeteg szoftverfejlesztő nem UX szakember, se nem BA, hogy ezekre a kérdésekre objektív választ tudjon adni az usertől elzárva egy iroda mélyéről, mégis meg akarja szakérteni, hogy az user mit akar, csak mert a fancytech egy fos a feladatra.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

+1
Az emberek vizuálisan könnyen megtalálják az információt, ha tudják, hol keressék.

És igen, a "your companys app" hátránya, hogy egy olyan felhasználó számára, aki nem tudja, mit keressen benne, mert épp most látja először, neki bonyolult, átláthatatlan és kusza az egész, míg aki egész nap azzal dolgozik, az plusz 3 kattintás helyett inkább egy képernyőre ki akar tenni minden információt, mert a szeme gyorsabb, mint a keze. A "vigyük rá az egeret a megfelelő vezérlőre" + katt + képernyőváltás + render sokkal több idő, mint vizuálisan egy ismert helyre ránézés.

A "Google app/Apple app" vizuálisan jól néz ki, ha először látod. Nincs rajta sok információ, nincs rajta sok vezérlő, így könnyen fel lehet fogni, hogy mit látsz. Látok egy gombot, csak ezt lehet megnyomni, hát persze, hogy egyszerű használni.

Míg ha nap mint nap dolgozni akarsz egy alkalmazással, akkor csak hátráltat, hogy egy képernyőn minimális információ van, nem pedig annyi, ami az adott kontextusban szükséges.

Sehol sem írtam hogy feltétlenül az ügyfél a hülye. Csak a feladatleírásból indultam ki ami kb. 30 év átugrását jelenti ránézésre.

Amit írtam electron.js -t egy desktop platform, atom szövegszerkesztő, github desktop kliens ebben van.
Szerintem ezek elég jó referenciák, megnézni legalábbis érdemes.

A platformtól teljesen független h mennyire jó UX-et, UI-t csinálnak hozzá illetve mennyire jó backendet tesznek mögé.

Abban teljesen egyetértünk, hogy a "fancytech" ne legyen meghatározó.
A probléma megoldása a lényeg, hogy milyen technológiával az már másodlagos.

--
Gábriel Ákos

+1

Ne mondjuk ki egyből, hogy a vevő a hülye, de általában ő nem enged semmiből (értsd: követelmények, idő/pénz, környezet), a jelen szituációban maradva: lehetséges, h vki kigurítaná a ncurses.js-t, de mikor kiderül, h ilyenilyen hw igénye van az IE9-cel szemben, akkor vajon ki kezdene el köhögni meg hümmögni vajon? Szóval ha az előbbi követelmény/idő/környezet 3szög elkezd szűkülni, akkor nyilván a technológia is beszorul ezek közé. Ezt lehet megérteni és engedni és lehet nem megérteni és köpködni a szakmát h ezdexar/ennyitsetudtokb+
Szal egy rossz megoldás bevezetésében a vevő a leginkább felelős.

Idézet:
egy rossz megoldás bevezetésében a vevő a leginkább felelős

Miért a vevő felelős, ha a szakmabeli vállalja el a megrendelést?

:)

Amikor ebbe az irányba kezd elmenni egy beszélgetés akkor szoktam jelezni hogy vagy visszatérünk a konstruktív mederbe vagy én mennék is és lehet mást keresni.
--
Gábriel Ákos

Jól értem, hogy egy gépen futó alkalmazást akarsz lecserélni egy hálózati kliens-szerver alkalmazásra?
Egy java alkalmazás vagy applet?

Nem hinném, hogy az lenne
"régi karakteres felületű dBase alapú alkalmazását kellene lecserélni egy modernebbre."
Javahoz nem sok olyan libet tudok, mint a curses/ncurses, ami java.io.Console alapon TUI-t csinálna.

Vagy arra gondosz, hogy cserélje le Javas desktop alkalmazásra?

Amúgy a valóban villámgyors felületű UI-hoz mindenképp natív alkalmazást csinálnék, semmiképpen sem webeset, vagy electronosat.
Az Applet meg már deprecated technológia, semmiképpen se!

Annak idején, mikor még dBase alkalmazásokat készítettem, azok eléggé azon a gépen futottak, ahol használták őket, még ha az adatbázist vagy magát a gépet hálózaton keresztül is érték el.
Java-ban nagyon nem mélyedtem el, de azt gondoltam, elég sok könyvtár lehet hozzá, hogy kompatibilis felületet lehessen létrehozni egy régi rendszerhez.
Az appletet meg leginkább a http miatt írtam, igazából nem derült ki számomra, hogyan került a http a feladatba.

Azért 2018-ban java applet-et javasolni elég merész :D

Az adatrögzítő alkalmazást simán meg lehet írni webapp-ként gyorsra. A formokat össze lehet rakni ugyanolyan elrendezésre mint a CLI alkalmazásban, billentyűzetet tudod kezelni. Ha valóban probléma az aszinkron hívások késleltetése (nehezen tudom elképzelni, hogy akkora adatmennyiséget tolnak fel kézzel egy űrlapba, aminél ez jelentős), akkor kialakíthatsz egy feldolgozó sort, pl. helyi sqlite adatbázisba dolgoznak a kilensek, onnan pedig háttérben tolod fel a szervernek az adatokat.

--
openSUSE - KDE user

Marika néni titkos billentyűkombinációit, amivel oda navigál ahova csak szeretne, nem tudja hozni IMHO egy browseres megoldás sem. Gondoljunk csak arra, hogy le, föl navigáció, enterrel következő mezőre. A rögzítés gyorsasága meg a 30 éves megszokás is nagy úr :). Szóval itt mindkét félnek kompromisszumokat kell kötni, ha ebbe az irányba mentek.

+1, akkor lesz majd igazán szórakoztató a történet, amikor bevezetik az új appot, amivel a _fejlesztő_ gyorsabban tud rögzíteni, csak hát a 30 év muscle memory nagy úr

#define modern

mi az amit az új megoldásnak tudnia kell, de a mostani nem tudja?

Mármint azt állítod, hogy JavaScript kódban nem lehet keyboard eventeket kezelni?

Nyilván lehet, ezt nem állítottam. A megvalósítás más mint c/s környezetben. Clipperben talán nem is kellett ezt külön kezelni, enterrel a következő mezőre ugrott a kurzor.
Míg böngészőben egy formon alapból submit-ot eredményez.

Alapból. De triviálisan egyszerű megoldani, hogy ne így legyen, hanem enterrel a következő mezőre ugorj, és szerintem a többi igény is.

Komolyan néha le vagyok döbbenve a válaszokon.
Mi az, hogy "csillivilli JS lib helyett saját"? Egyáltalán mit értünk ezalatt? Egy axios még lehet, vagy már az se? Pontosan hány nanosecről beszélünk itt az inicializálás megtörténte után, megmértétek? :)
A prerendert hasonlóképp nem értem, hogy jön. Mégis hogy lenne gyorsabb adatrögzítéshez, mint inicializált kóddal egy JSON request/response? (ha nem elég tömör, van még pár protokoll, de tényleg?)

A HTTP amúgy egy lassú protokoll, ezt sose feledd.
Aki csak browserben meg JS-ben tud gondolkodni, néha elfelejti, mennyire sok overhead tud lenni a web.
Elég csak összehasonlítani mondjuk egy electronos szövegszerkesztőt meg egy natívat.

Persze, hogy lassú - legalábbis browserből, mert amúgy elég egyszerű jószág -, nem vitatom! De nem is erről volt szó, hanem hogy túlzásnak, sőt kontárságnak tartok bizonyos dolgokat a hozzászólások közül.

"Mi az, hogy "csillivilli JS lib helyett saját"? Egyáltalán mit értünk ezalatt?"

Szóval "csillivilli bloatware js lib" alatt azt értettem, ami a most éppen felkapott js dzsuva, amitől a fél évvel korábban hype-olt js lib olyan "so 2017"...
Szóval azokról beszélek, amikbe bele van szerelmesedve a js tákolóművészek jó része (tisztelet a kivételnek persze), és amivel 500 karakternyi szöveget és 2 képet tartalmazó oldalt képes már 3 másodperc alatt megjeleníteni egy modern proci összes magját 2 vállra fektetve, 30 mega adatforgalommal és 170 request-tel...

Jó, de melyik "hype-olt js lib" milyen funkciója okoz olyat, hogy egy adatrögzítési hívás lassabb lesz, mint nem azt használva, és mennyivel?
Értem a jelenséget, amit írsz, és biztosíthatlak, hogy semmi köze a "hype-olt" frontend framework-ökhöz.

Passzolom, mélyebben nem értek hozzá. Csak látom ezeket a bloated szarokat, és azt is, hogy miket képesek ebből kihozni egyesek.
(Valamint arról sem vagyok meggyőződve, hogy erre a web az ideális platform.)

Amik lassító tényezők szoktak lenni:

* Betöltéskor rengeteg fájl betöltése, lehetőleg nem párhuzamosíthatóan (Soros a hibás ugyebár :-) egy részük más domainekről, aminek hatására a betöltés teljes ideje kontrollálhatatlanul elszállhat (analytics, web fonts, reklám, stb) (pl egyszer a google analytics meglassult és hirtelen minden lassú lett a neten)
* Animációk, eventre reagáló eventre reagáló eventre reagáló eventtel kezelt változások
* Többszöri re-Layout, ahogy az objektumok betöltődnek. CPU zabáló, és ugrál tőle a UI.
* Túl bonyolult DOM fák
* Egyetlen akcióra rengeteg Ajax kérés--válasz, lehetőleg szekvenciálisan, amik darabokban frissítik a UI-t
* Hibásan megírt, rosszul skálázódó algoritmusok. (Négyzetes string összefűzés, vagy lista építés)
* Böngésző furcsaságainak hibás kezelése - pl egyszer írtam olyan programot, ami egy hosszú listába kihányt HTML-be párezer div-et. A megjelenítéssel nem is volt baj, de mikor egy ciklusban listenert adtam az elemekhez, az valamiért nagyon lassan futott le. Az adott programban nem volt érdekes, úgyhogy nem néztem utána az okának, de nem is a konkrét eset a lényeg, hanem hogy ezekbe könnyű belefutni, és utána sok idő megtalálni és javítnai őket. Sok hype-olt keretrendszerben is vannak ilyenek.
* Egyetlen user eseményre lefut ugyanaz 2-3x Lásd: https://hup.hu/node/157147#comment-2180886 :-)

És ezek még csak a tipikus problémák, semmi exotikus :-).

Amúgy a Web szerintem sem ideális platform, pláne olyan esetben, ahol nem is lenne szükség kliens-szerver működésre, illetve ha lehetőség van telepíteni a felhasználó gépére.

De jól tervezve és kivitelezve manapság néhány milliszekundum overhead-del meg lehet úszni a webet, ha muszáj. Lásd: https://hup.hu/node/157147#comment-2180168

mondjuk ilyen adatrogzitos esetben kapasbol protobuffal kezdenek :)

Hát van több lehetőség is. Mivel az AJAX asszinkron alapból (lehet szinkron is), nem feltétlenül kell várni a túloldalra, hogy sikerült-e a bevitel vagy nem. Következő lehetőség, hogy mondjuk localStorage-ben el kell tárolni a bevitt értékeket és a háttérben kell küldözgetni AJAX-szal, majd ahol hiba van azt újra próbálni, ahol nincs, azt kiveni a localStorage queue-ból. De én is a websocketet mondanám amúgy elsőre ha sebesség kell, viszont a WS-sel komoly tervezési gondok is vannak a mai napig. Pl. az újracsatlakozós kezelése ami kiválóan tud problémás lenni az egy forrásból max 5 csatlakozással. Ugyanis a reconnect simán képes 10ms alatt 50x is megtörténni. Az AJAX sokkal stabilabb és egyszerűbb megoldás, a backendet is egyszerűbbé teszi, a lassúságot meg kliens oldalon kell elfedni szerintem, nem szerver oldalon. Főleg, ha a szerver nem is helyi hálóban van, hanem valahol a neten. Gubanc esetén is 150ms alatt le kell mennie mindennek. Ha lassabb, akkor ideje elővenni az SQL-es srácot és a rendszergazdát, hogy szedje össze magát.

Értem, tehát behozol egy plusz overheadet a JS-sel, webbel és HTTP-vel, majd az SQL-es arcon akarod leverni az overheaded. ;)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nagyon nem kéne mindent a webes/sql-es adminra tolni. Különösen akkor, amikor várhatóan sok rekord lesz, jó sok és nagy mezővel és még SSD-ről is idő összekókányolni a lekérdezést vagy csak frissíteni az indexeket. A kliens és szerver közötti hálózati távolságot is illik beleszámolni és még arról sincs szó, hogy mennyire sokan használják párhuzamosan.

Jellemzően azzal szokunk találkozni, hogy az előzetes infókhoz képest is bőségesen felültervezett vasakat csodálatos rekordmennyiséggel és mégcsodálatosabb lekérdezésekkel küldik el kapálni. Itt a sokmillió (megtörtént) bennfelejtett vagy archiválható rekordtól a sok JOIN-os lekérdezésig, amiből az utolsó ráadásul duplázott, mindenfélére kell gondolni és még ezeket kombinálni is tudják.

Arra különösen büszke vagyok, hogy az egyik rendszerünk amit 1.5M körüli ajánlat kiszolgálására terveztünk kibírta egészen 80M-ig, utána kellett az architektúrát jelentősen átalakítani. Az aztán szépen felnőtt 280M-ig, jelenleg itt tartunk, köszöni szépen jól van.

--
Gábriel Ákos

Magában a rekordszám nem jelent sokat, csak ugye az események együttállása... :) Azt is tudom, hogy meg lehet jól írni ezeket, meg alá is lehet tenni a vasat, amikor az valóban indokolt. Az sem mindegy, hogy mi az elvárt válaszidő, mert itt tokkalvonóval 150ms-eket emlegettek, mint maximumot és akkor már gond van. Csupán szomorú vagyok, hogy nagyon ritkán találkozunk olyan fejlesztővel aki érti és hajlandó is tennia probléma ellen.

Sosem játszottatok még a Zandagort nevű játékkal..
:)

Webes technológiával is el lehet érni kis válaszidőket, 50ms körüli érték az, amit azonnalinak érez a user, ezt el lehet érni szerveren körbefutó válaszidővel együtt is. Én már optimalizáltam válaszidőre webes és nemwebes GUI-t is, ha meg van csinálva, akkor bucko-val egyetértve azt mondom, hogy a rajzolás szokott a lassú lenni.

Ami kell a kis válaszidőhöz:
* Egy user interakcióra egyetlen (esetleg 2-3 - key down, key up, key clicked) kérés-válasz legyen a kliens és szerver között, a válasz minden változást tartalmazzon tranzakció-szerűen.
* A GUI is tranzakciószerűen frissüljön: a DOM fát átírjuk JS callback használata nélkül egy löketben, és akkor egyszerre van kirajzolva
* sima HTTP-kérés/válasz technikával is lehet 50ms alatt maradni, WEBSOCKET jó, de lehet élni nélküle
* A következő képernyőn megjelenő képek legyenek előcache-elve a kliensen (ha egyáltalán vannak)
* A megjelenítő DOM fát optimalizálni érdemes, hogy kevés objektumból álljon (keretrendszerek tudnak sokat gyártani)
* A szerveren minden válaszolandó adat legyen memóriában, akkor nagyon gyors válaszokat tud adni. (Állandóan futó szerver legyen, ne kérésenként indított processz.)
* A szerver közeli PING-en legyen, és ne legyen túlterhelve.
* Mérlegelni kell, hogy az időnkénti Garbage Collection belefér-e? Mind a JS, mind a szerver GC-t futtat (kivéve, ha tényleg C++-ban írsz szervert) A GC ideje úgy lehet kicsi, ha a szerver heap-je kicsi (Nem a beállítás a lényeg, hanem a maradó objektumok). Ha az eredeti programot hűen másolod, akkor várhaóan ez elérhető.

A válaszidővel kapcsolatban mielőtt bármit is döntesz, csinálj deszka modellt és mérj vele! Ha technológiából adódó késleltetésed van, akkor azzal semmit nem fogsz tudni később csinálni. Ha pedig a kész program sokkal lassabb, mint a deszka, akkor valami el van rontva.

Amúgy, ha helyi programról van szó, akkor én megfontolnám a böngésző kihagyását a buliból, akár Swing-gel, akár JavaFX-xel lehet gyors válaszidejű GUI-t csinálni. De ha belefér a C/C++ a fejlesztési időbe, akkor pl wxWidgets-szel olyan gyorsat is írhatsz, mint a villám.

De beágyazott Jetty-vel, és deszka JS programmal lehet olyat csinálni, hogy amint kattintasz, azonnal látod a választ. Próbáld ki!

Olyanom volt most, hogy csináltam egy mini tech demót, amin ki lehet próbálni egy Jetty+miniJS program késleltetését:

https://github.com/rizsi/quickjs

A leírásban van link, futtatható jar-ként letölthető a szerver, csak el kell indítani, rámenni egy browserrel és ki lehet próbálni.

Localhoston a firefox network analizátora szerint 1-5ms körüli válaszidők vannak. Ez a körbeforgás ideje ami a technológiából adódik. Nyilván erre rájön az, amit maga a program csinálni fog.

Én kipróbáltam, nálam jellemzően 0-1ms volt. 3 éves i7-es laptop.
Kipróbáltam volna helyi hálón is, de fixen a localhost-ot figyeli, így nem lehet.

Van bug? is benne, minden kérés kétszer megy el, először a régi adatok, majd az új.

Wow, de szemfüles vagy! Az lesz a gond, hogy egymás után jön keypress és change esemény is. Javítani inkább nem fogom.

i.onchange = inputhandler;
i.onkeypress=inputhandler;
i.onpaste=inputhandler;
i.oninput=inputhandler;

Mivel érdekelnek a microservice alkalmazások, ezért csináltam az engem érdeklő Scala-s web "framework"-ökkel egy kis benchmarkot (nem tudományos alapossággal) és ha már itt a deszka, akkor már azt is belevettem.
A tudományosabb tesztet (TechEmpower) itt nézhetitek meg.

Apache Benchmark eszközzel végeztem a mérést.
Eredmény:

- deszka (jetty):   22500 #/s
- colossus:         27000 #/s
- http4s:           20500 #/s
- scalatra (jetty): 20500 #/s
- akka-http:         3200 #/s

Mit csinál az, amit lekérdezel?

Egyszerű plain szöveget ad vissza.

ab mondjuk nem bizonyult számomra a legmegbízhatóbb eszköznek.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Így van, nem a legjobb, de nem is törekedtem tudományos alaposságra.
Ha lesz időm, akkor majd átkergetem ezeket Gatlingon is, azért is, mert elég meglepően nagyok az eltérések a TechEmpower méréseihez képest. Persze ebben benne lehet az is, hogy közben fejlődtek a framework-ök.
Pl. sokkal jobban szerepel a Jetty (deszka model) és a http4s, míg a colossus nem annyival jobb.

Futtattam én is egy ilyet a laptopomon (apache2-utils csomagban van az ab program Ubuntun), JVM melegítés után a quickjs nyitóoldalával:


$ ab -n 500000 http://localhost:8888/
Requests per second: 15244.49 [#/sec] (mean)

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 1
Processing: 0 0 0.1 0 18
Waiting: 0 0 0.1 0 18
Total: 0 0 0.1 0 18

$ ab -c100 -n 500000 http://localhost:8888/
Requests per second: 36889.37 [#/sec] (mean)

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 36.1 0 3044
Processing: 0 1 1.6 1 209
Waiting: 0 1 1.6 1 209
Total: 0 3 36.2 1 3044


Érdekesség, hogy top-pal megnézve a java processz 115%, az ab pedig 45%. A konkurrens változattal ugyenez 190% és 93%.

Tehát a benchmark jelentős CPU terhelést ad, ha agyonoptimalizált a http szerver, akkor szinte a benchmark programot mérjük :-)

Én a query oldallal teszteltem, de most megnéztem a nyitóval is, kb. ugyanaz (~22300):

ab -n 100000 -c 100 "http://localhost:8888/query?id=id&input-0-1=&input-0-2=&input-1-1=&input-1-2=&input-2-1=&input-2-2=&input-3-1=&input-3-2=&input-4-1=&input-4-2=&input-5-1=&input-5-2=&input-6-1=&input-6-2=&input-7-1=&input-7-2=&input-8-1=&input-8-2=&input-9-1=&input-9-2=&input-10-1=&input-10-2="

Tehát a benchmark jelentős CPU terhelést ad, ha agyonoptimalizált a http szerver, akkor szinte a benchmark programot mérjük :-)

Igen, mindenképp jobb lenne külön gépről mérni hálózaton keresztül.

Én csináltam direkt egy "/performance" oldalt is, aminek ez a kódja, tehát lényegében "semmi":

response.setContentType("text/html");
response.setCharacterEncoding("UTF-8");
response.getOutputStream().write((byte[])staticreply);
response.setStatus(HttpServletResponse.SC_OK);
baseRequest.setHandled(true);

Ezzel 37302.83 a 36889.37-tel szemben, tehát az idő legnagyobb részét a Jetty-ben tölti, ami persze várható is volt, mert a http parszolás nem gyerekjáték.

Ha ilyenfajta kiszolgálásra kell optimalizálni, akkor teljes non-blocking stack-ket kellene csinálni, amit a servlet API nem tud. Illetve a választ úgy ahogy van binárisan statikusan lehetne cache-elni, nem kellene minden alkalommal újraépíteni.

Kipróbáltam egy-kettőt a TechEmpower saját tesztjével, ami alatt wrk dolgozik.

Elég mellbevágó lett az eredmény:

jetty (kvázi a deszka modell): 64.000 #/s
colossus:                     256.000 #/s

Wildfly 11: 21700 #/s

De hát a Java EE az bloat!

Ebben a tesztben nincs EE, sima web server.
Egyébként igazad van! ;-)

Szerintem ami fontos, hogy
1. Gyors legyen a renderelés, ne legyen nagy overhead. Használj modern JS libet, ahol erre figyeltek (én pl Vue-val állnék neki).
2. Egy művelet = 1 AJAX, és arra válaszul jöhet az eredmény / változott dolgok tranzakciószerűen. JS renderelheti azonnal a dolgokat.
3. Ha az AJAX is lassú (de nem hinném), websocket is mehet, de az sokkal macerásabb (fejlesztésben), és sokat itt nem ad cserébe.
4. Billentyűzet. Amit eddig azzal csinált (mindent), azt most is azzal akarja. JS is tudja ezeket kezelni, szóval mérd fel, milyen billentyűk / kombinációk vannak most, és gyakorlatilag ugyanazokat beállíthatod te is.

html5 storge + commit ajax-szal, de nem tételenként?

Ilyeneknél nem a committal van gond, hanem azzal, hogy pl. ha kiválasztasz egy kategóriát, akkor (vizuálisan) azonnal legyen ott a kontextusfüggő további opicók mindenféle csicsapicsa nélkül egy tab/enter/akármi lenyomása után.

Egyébként kiváló példa erre mondjuk egy bolti számlázóprogram: amint becsippantja valaki a vonalkódot, egyből akarja látni az eredményt a listában, esetleg egy +/--al mennyiséget módosítani, következő csippanásra azonnal lőni akarja a következő terméket. És lehet, hogy 5 másodperc alatt végig fog lőni neked 10-15 cikket. Nem fog várni neked ajax hívásokra, mert a vevő sem azért fizet, hogy vár az eredményre. És innen max egy gombnyomás után zárni akarja a nyugtát, ahol max választani akar, hogy bankkártya vagy készpénz. Na ilyen use-caseket képzelj el nagyon sok esetben ezeknél a programoknál. És ahogy persicsb is írta fentebb: kevésbé problémás ezeknél a szoftvereknél, hogy nem teljesen intuitívak, mivel úgy is van betanítási időszak és rutinból fogják használni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A bolti példád megragadott. Nézd meg a Praktiker, ikea, stb. áruházláncok gépeit. Ott DB2 van a háttérben egy iseries gépen és karakteres képernyőt használnak, mert az adatkezelésen van a hangsúly és nem FB-on. :) Win kliensekre feltolják a tn5250 terminálemulátort és kész. Röppen az adat úgy, ahogy írod. Persze a kérdezőnél PC-s vonalat tolnak. Ott pedig egy Linux/unix szerverrel, my/pgsql motorral, de akár oracle/DB2 motorral is megvalósítható, hogy a rögzítő továbbra is karakteres gyors munkahelyet kapjon, míg a többieknek ott a browseres csicsamicsás, le- fel, jobbra- balra gördülő izékkel díszített felület egy webszerverrel.

Nem a karakteres felülettől lesz gyors. De, hogy nem a webtől és a HTTP-től, az is tuti.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A karakteres felületen az ügyintéző/rögzítő felhasználó boldogul gyorsabban. Általában. Mint írtam, készítettem delphi alkalmazást kb. 10 évvel ezelőtt, ami teljesen úgy működött, mint az általa leváltott clipper app és így nem okozott traumát a platformváltás sem. De ha nem indokolja semmi, az alkalmazás szempontjából releváns indok, akkor én meghagynám a karakteres felületet, azt szokták meg, miért kéne mást erőltetni, amikor simán produkálható a megszokott felület egy korszerűbb működéssel, technológiával.

Egyébként a prakti, ikea, stb. tcp/ip kommunikációra épülő adatátvitellel dolgozik, esetleg régebben token ring alapon, ma már Ethernet alapon nyilván, de használtak más érdekes, az itteniek előtt ismeretlen adatátvitelt is.

Írtunk 3270 protokoll+terminál emulátort full java-ban (servletben).
Salesforce integrációhoz, és persze normál terminál funkciókhoz.
A felhasználó szemszögéből semmivel se lassabb mint a windowsos "natív" cucc.
Viszont halálba integrálható kb. bármivel, itt éppen workflow + sf webservice-k volt a feladat.

--
Gábriel Ákos

lanterna néven van egy Java alapú terminál API és emulátor is. A poén az benne, hogy működik GUI ablakban Swing alapon, és valódi terminálablakban is!

https://github.com/mabe02/lanterna

Poénból írtam egy karakteres teljes képernyős BASIC interpretert is vele (valamikor újra fogom publikálni, ha lesz időm), egész jól működik.

(Amiért nem írom, hogy tökéletesen az az, hogy néhány billentyűkombináció nem működött tökéletesen, debuggoltam is, és ha jól emlékszem, ezek a terminál megvalósítás problémáiból adódtak.)

Úgyhogy akár így is lehet csinálni Java alapon karakteres GUI-t.

Az frankó. De itt nem egy kész rendszerhez kell terminál, hanem egy specifikusabb valami az elvárás. Ha a megrendelő el merné határozni, hogy egy iseries-t beállít kiszolgálónak, akkor a terminállal meg is lenne oldva a kliens oldal és csak kiszolgáló oldali fejlesztés kellene. :)

Milyen DB lesz mögötte? Gondolom azt is lecserélitek valami modernebbre. Én írnék nekik karakteres felületet natív kliensoldali alkalmazás formájában és hálózaton érném el a DB-t. Ennél gyorsabbat nem tudsz csinálni. Ha a böngészők valamelyikét is belerángatod, akkor meg tuti hogy elégedetlenek lesznek, mert akármilyen ügyes vagy, nagyságrenddel lassabb lesz a rögzítés. Nem kell mindenhová grafikus felület, mert feleslegesen sok munkát ad a gépnek. Ha pl. mysql-t, pgsql-t vagy oracle motort tesztek mögé központi adatbázisnak, akkor standard library-k vannak a DB hálózatos kezeléséhez az authentikációtól egészen az adatmanipulációk tárházáig a DB managementen keresztül, jogosultságtól függően, amíg egy telephelyen belül vagy, ha ki kell menni internetre, akkor meg az egész kommunikációt becsomagolod ssh tunnlbe és első körben talán ennyi elég. Ha bitmap vagy egyéb grafikus adat nincs - scannelés, stb. - akkor a grafikus felület erőltetése tuti bukás lesz user szinten. Ők dolgozni akarnak, nem ablakot méretezni és színezni, meg fontot állítgatni. Azt nem az adatrögzítők csinálják, hanem más, felesleges irodai dolgozók. :)

Egyébkén hajdanán én delphi-ben készítettem ilyen speckó mellett egy hitelminősítő és nyilvántartó rendszert, multiuseresre, hálózatosra. Ott is clipper alapról költöztek át mysql-re ha jól emlékszem rá...vagy pgsql-re? mindegy. A delphi azért volt jó, mert a clipper billentyűzetkezelését simán oda tudtam tenni. Alig egereztek. Nem tudom, hogy hol tart ma a delhi, van-e egyáltalán....

Egy, már kész alkalmazásunkra állnának át, csak kellene neki pár kiegészítő modul. Ezen új modulokból lenne egyik, amiben irdatlan mennyiségű adatot kellene felrögzíteni eléggé sok függőséggel a rögzítendő mezők között. És igen az Enterrel végigszaladok az adatlapon dolgot nagyon nem lehet kiverni a fejükből.
Szóval van egy alkalmazásszerver amelyben van az üzleti logika. Maga az üzleti logika gyors, ki van mérve, nem az lesz a szűk keresztmetszet: Inkább a mezők közötti függőségek miatti HTTP kérés/válasz üzenetek nagy száma és az ebből adódó renderelés miatt aggódom, hogy ez lesz sok idő. Szerintem a JSF keretrendszer túl sokat fog dolgozni a háttérben.
Szóval erre lettem volna kíváncsi hogy ezt a "gyorsaságot" el lehet érni valahogy a böngészőben. Akár úgy hogy itt a JSF helyett valami más megoldást alkalmazunk.

"Szóval erre lettem volna kíváncsi hogy ezt a "gyorsaságot" el lehet érni valahogy a böngészőben. Akár úgy hogy itt a JSF helyett valami más megoldást alkalmazunk."

Pont erre csináltam deszka alkalmazást, reagálj arra is, ha már dolgoztam vele: https://hup.hu/node/157147#comment-2180168

Gyors mai processzoron 1 frame (16 ms) körüli válaszidőt produkál böngészővel is, szerintem lassú gépen is 50 ms alatt maradsz, de olyanom nincs, nem tudok mérni :-).

Néztem én is a kis deszka programot, nálam a szerver-kliens közötti kérés-válasz küldés:
0-1ms volt Firefoxon
0-5ms volt Chrome-on

Teljes oldal frissítés:
80-150ms Firefoxon
15ms Chrome-on

A kliens és a szerver is ugyanazon a három éves i7-es laptopomon futott.

A deszka alkalmazás 4-25 ms között voltak Chrome böngészővel és Intel i-s processzorgeneráció előtti processzoron.

Az 99.9% hogy valami más megoldást kell keresnetek, JSF-nél lassabb technológiát még nem láttam.

--
Gábriel Ákos

+1

A JSF-fel nekem sincsenek túl jó tapasztalataim.

JSF helyett de jó lett volna, ha bekerül a Java EE 8-ba a Jave EE MVC (JSR-371).
De sajnos eléggé halott specifikáció, egy éve nem foglalkoztak vele.

https://www.ag-grid.com/example.php ez a demo oldal. JS data table, teljesen testre szabható akár cellánként mi történjen.
Billentyűzettel is működik alapban. Kimondottan rámentek a gyorsaságra is. Használhatod plain JS-el és bármelyik JS frameworkel is. Háttérben természetesen asyncron küldöd a cuccot amikor akarod.

(felirat)

+1

Hát ennyiből nehéz megmondani, de jópár ügyviteli alkalmazást terveztünk már, váltottunk le Z80 technológiát is, ha gondolod, keress meg (az adatlapodon nem lehet üzenetet írni)

Általaban keyboard flow-t kell tervezni, de nyilván 2017-ben már van egy csomó technológia, hogy ne annyi adatot kelljen felvinni, meg az új munkatársak akkor is egerezni fognak ha billentyűzettel gyorsabb, szóval a kérdés nem trivi.

Ráadásul Magyarországon a clipper-shortcutokat a szoftverek második-harmadik generációja másolja már (pl. az első ixdoki clipperes volt, természtesen minden gombnyomás működik az ixdoki 2000-ben és többségük az ixnetben is, de ugyanez igaz a MAEF-VMAEF-CRMAEF generációkra is)

Szerk.: Tárgytalan, azt nem láttam, hogy a ti alkalmazásotokhoz kell modul, akkor a FlagShip, xHarbour és hasonló kész megoldások nem játszanak.

Kicsit konkrétabban is lehetne tudni, hogy mi ez a feladat?
Kicsit nehéz elképzelni ezt a sok paramétert és a hozzájuk tartozó, függőségeken alapuló további paramétert.
Ez egy komplett gyártást támogató valami akar lenni, vagy inkább egy raktárkezelő rendszer?
Kvázi egy embernek kell felrögzítenie egy komplett, összetett termék előállításának minden elemét?

Fantasztikus hogy a fejlesztők rögtön nanosecundumokkal dobálóznak, de még a feladat sem világos szerintem.
Biztosan van már a régi programra egy megfelelő, modern, új megoldás, aminek megfelelő kifejlesztése többe kerül webes felületen, mint megvenni a kész programot.
Valamint bodnarj megírja a webes felületet, amire senki más nem tud támogatást adni, és máris mehet a lecsóba az egész,ha őt elüti a villamos?! Esetleg csillagászati összegért lesz, aki átvállalja majd a supportot?
Egy vállalat működését nem bíznám ilyen saját fejlesztésű valamire.


Nem csak az M$ számol furán... A Zinternet lenne ilyen gyors?
65% [62 Sources 1528 kB/6239 kB 24%] 3062 PB/s 0s

" Egy vállalat működését nem bíznám ilyen saját fejlesztésű valamire."

azok az idok szerencsere mar elmultak amikor csak a voros oktober ruhagyar konfekcio oltonyeit lehetett hordani itthon. :DDD

"Egy vállalat működését nem bíznám ilyen saját fejlesztésű valamire."

Nagy kő esett le az SAP nevű borotválkozógépből élők szívéről.

:D Ezen hangosan felröhögtem!

Az SAP-re pont nem gondoltam, az is csak felesleges, rengeteg pénzkidobás, szóval marad a kő...

De azért gondoljatok bele, hogy egy olyan helyen, ahol ilyen összefüggésekkel nagy mennyiségű adatot kell felrögzíteni, azt akár az itteni, korábbi fórumbejegyzések alapján nem sokaknak sikerült összehoznia. Mindenki bajlódik valamivel (alulméretezett db, túlbonyolított program, összeszedetlen adatkezelés, nem tuti query-k, stb...).
Mindenképpen olyan adatbázis és alkalmazás is kell hozzá, ami arra van kitalálva.
(És igen, a kő marad az M*sql -eseken is)
:)


Nem csak az M$ számol furán... A Zinternet lenne ilyen gyors?
65% [62 Sources 1528 kB/6239 kB 24%] 3062 PB/s 0s

A feladat nem a lehetetlen, hanem sokkal inkább annak a kategóriája, hogy milyen nehéz a fő csapásból kilépni.

A fő csapás szerint mindent grafikusan jelenítünk meg, fenn a padláson, az adatokat meg lenn a pincében, VALAMILYEN adatforrásban manipuláljuk, a kettő között pedig általános célú lépcsősorok húzódnak több szintben. ITT viszont nem általános célokra van szükség, hanem EGYFÉLE adatforrásra, minél közelebb a megjelenítéshez, ami NEM grafikus.

Nem lehetetlen ezt a kettőt közelre összecsinálni, "csak" a világ nem ennyire jó fej, mint itt a kérdező, hogy a billentyűzetet gyorsan kezelő és a jól működő app felépítését is fejből tudó adatrögzítő igényeit tiszteli, hanem lenyomja a torkán azt, ami "modern", járulékos veszteségek nem számítanak -- ezért nem fejlődtünk (vagy én nem tudok róla) olyan irányba, hogy legyen egy "modern clipperünk"* (pl. adott motor összekötése szintközeli curses prezentációval).

Persze erthető, hogy a fríszoftokat fejlesztők az általánosabb trendivel próbálják megmutatni magukat (tegyenek alá CPU-t!), nem olyannal, aminek országonként 2 cég örülne, de nagyon.

A konkrét feladatban kiderülhet, hogy 1. a rögzítőket olcsóbb-e meghajlítani, vagy 2. ilyesmit háznál összehozni, esetleg 3 .egyszerű webet lynxezni/linksezni.
Az elmúlt órákban 4. nem jutott eszembe.

* A modern clipperről jut eszembe, hogy hajdan a gyártó is a modernedést úgy képzelte el, hogy kiadta win alá a 4GL-es CA-VOt, ami erőforrásigényben meghaladta azt, amit a kor alá tudott tenni.

Nézzük meg az idővonalat is!

Közel 30 éve - az általánosan elterjedt számítástechnika hajnalán, vagy reggelén - láttam egy csapat lányt. Abszolút nem kockafejűek, viszont vasvillával hányták befelé a jól működő kódot.

Feljebb, mikor kifejtettem, hogy a lista renderelés sok időbe telik a következő választ kaptam: Biztosan 10-15 éve volt.

Jelen pillanatban guruk és okostojások dagonyáznak a libekben és apikban. Tehát napjainkban bizonyára létezik vállahatóbb megoldás, de szakember kell az alkalmatlan technológia alkalmassá tételéhez, vagyis költségesebb.

A a rögzítőket olcsóbb-e meghajlítani egészen addig poénnak tűnik, amíg ugyanarra a feledatra nem kell 2-3 Mancika helyett 15 Micikét alkalmazni.

Ebből az egyszerű sorból egyértelműen látszik a visszafejlődés, amit tényleg csak a CPU gyártók ellensúlyoznak. Ez ugyan szomorú dolog, de legalább nem kell attól rettegnünk, hogy a gépek elveszik a munkánkat! ;) Egyébként is egy Core i7 olcsóbb, mint Micike fizetése. Bár ezen lehetne köröket futni.

Fantasztikus hogy a fejlesztők rögtön nanosecundumokkal dobálóznak, de még a feladat sem világos szerintem.

Amire a nanosecundumokat dobáltuk az a része elég világos:
Inkább a mezők közötti függőségek miatti HTTP kérés/válasz üzenetek nagy száma és az ebből adódó renderelés miatt aggódom, hogy ez lesz sok idő

A HTTP kérés/válasz üzenetek számára, idejére és a renderelés idejére kapott választ a nanosec dobálásokból.

Biztosan van már a régi programra egy megfelelő, modern, új megoldás, aminek megfelelő kifejlesztése többe kerül webes felületen, mint megvenni a kész programot.

Én bodnarj leírásából úgy értem, hogy a régi programot is ők írták, tehát vélhetően egy egyedi alkalmazásról van szó. Ráadásul a program nagy része lefedi a vevő elvárásait, csak kisebb plusz fejlesztések kellenek, amik miatt aggódik. A tévedés jogát fenntartom! ;-)

Megkeresett minket egy leendő ügyfél, akinek egy régi karakteres felületű dBase alapú alkalmazását kellene lecserélni egy modernebbre.

Egy, már kész alkalmazásunkra állnának át, csak kellene neki pár kiegészítő modul. Ezen új modulokból lenne egyik, amiben irdatlan mennyiségű adatot kellene felrögzíteni eléggé sok függőséggel a rögzítendő mezők között. És igen az Enterrel végigszaladok az adatlapon dolgot nagyon nem lehet kiverni a fejükből.

Szerintem részben tévedtél. :)
Úgy nézem, hogy az üzleti logika tökéletes, csak gyorsan el kellene látni adatokkal, amire van egy olyan ráérzés, hogy nem fog menni. Tán nem csak a sok enter miatt. ;)

Ha már láttál ósdi Novell rendszerről SAP-re átállást, akkor mindent láttál.

Ha már láttál ósdi Novell rendszerről SAP-re átállást, akkor mindent láttál.

Én már olyat is láttam, hogy 1 év átállás után adták fel az SAP-re átállást. ;-)

Pedig akkor már nem szokták. Miután belecsusszant 50-100 milla már nem nagyon van visszaút vagy igen komoly seggberúgások jönnek. És azon a szinten ezt már nem szokták vállalni...

--
Gábriel Ákos

https://harbour.github.io/

Talán megér egy kísérletet.

OpenBSD 6.2 theo for the prezident:D

+1, nalunk bevalt.

Nem én kértem, de köszönöm, hogy hallok ilyenről.
Ezexerint nem az egész világ szeret atombombával verebészni, csak majdnem.

Ha lenne valakinél ilyen fejlesztéshez kapacitás, kérem jelezze priviben.

- PostgreSQL (9.6+)
* PL/pgSQL szerveroldali postgresql nyelv
* linuxon
- Laravel 5.5 (php framework)
- Vuejs (cél: Single Page App)
* esetleg angularjs a vuejs helyett
- socket.io vagy ajax (pl. laravel, jquery,typeahead, a cél egyrészt:
autocomplete search from database, másrészt postgresql notify -> frontend értesítés)
- git (gitlab) ismerete az SCM-hez

A feladat nagyon hasonló ahhoz, mint ami a topicindítóban szerepel és lenne rá itt valamennyi pénz elköltenivaló.