Fejlesztések, egyéb gondolatok

Pár szó az adat kezelő megoldásomról, rövid bemutatása, gondolatok a miértekről és a hogyanokról, további gondolatok praktikai fejlesztésekről és szoftver környezettől független kérdésekről.

https://youtu.be/xTNttLgOMjY

( crown v | 2016. 09. 14., sze – 08:55 )

Egy par szo jo lenne, hogy ne legyen URL gyujtemennye lesilanyitva a bloggolas. Plane, roviditett URL, ami halmozati vetseg.

( crown v | 2016. 09. 15., cs – 08:39 )

"adat kezelő" egy szo, ha mar ezt piszkalja az ember allanodan ;)

mirol szol ez a munka? a tablazatrol? a tablazat + db osszekoteserol, a ketto kozotti komunikaciorol? az egesz kornyezet osszerakasarol? ugye, adatbazist sokfelekepp lehet letrehozni, piszkalni, lekerdezni. dinamikus feluletet szintugy. (angularjs most a trendi) es erre az osszesre szerintem vannak mar kesz megoldasok. ehez kepest csianltal valami ujat, vagy ezenken a hasznalatat gyakorolotad?

Hát igen, a videóban nem akartam belemenni a "miért" részébe túlságosan, hogy ne legyen annyira reklám.

Igazából egy extra becsatolt eszköznek szánom és így is használják meglévő infrastruktúrákhoz. Szükség van a meglévő eszközök nagy részére. Nem célom kiváltani ügyviteli, raktárkezelő, számlázó és egyéb célspecifikus rendszereket.

Az adatbázis kezelés nyilván fél évszázados vagy még régebbi. Itt sincs és nem is volt cél semmi új. Sőt.

Viszont általános adatkezelő megoldásoknál hiányoznak azok a feature-ök, amelyeket fontosnak tartok, főleg céges környezetben:

https://service.adatbank.info/main?menu=main_info2&lang=hu#features

Például hogy:
- kikényszeríthessem technológiával, hogy ne lehessen megjegyeztetni a jelszót
- meghatározhassam, hogy csak adott időre visszamenőleges adatokat láthasson egy user (pl. egy új kolléga esetében csak az utolsó 3 hónapot)
- legyen pár klikkes fájl feltöltés
- transzparens OCR
stb.

Az integrált ügyviteli rendszerek ellenére az iparban nagy mértékben használnak olyan dolgokra Excelt, Gdocs-ot és társait, mappákba rendezett fájlokat, email csatornát - amelyekre lehetne sokkal hatékonyabb de még mindig ilyen egyszerű megoldást adni. Erre hoztam létre a megoldásomat.

Legyen alakítható, de tudja a felsorolt feature-öket. Viszont nem engedem meg magamnak, hogy ha beleteszek egy fejlesztést, akkor az rontsa a konzisztenciát vagy az általam meghatározott komplexitási szintet.

Olyan embereknek is szánom, akik alig értenek a számítógéphez. Hogy a menedzsment könnyen kiadhassa nekik gyors döntést hozva egy kérdésben. Csak töltse ki a sort és plusz gomb. Ennyi és ne kelljen többet tudnia. A menedzsment pedig tudja elemezni az adatokat.

Szintén mostani fejlesztésem volt egy eloszlás diagram lehetőségének nyújtása is, de úgy, hogy ne kelljen külön UI változtatás plusz elemekkel - rontva így az egyszerűséget.

Úgy csináltam meg, hogy ha van legalább 2 numerikus oszlop, akkor ezeket kiválasztva és csak ez után klikkelve a "grafikon" gombra mutat egy eloszlást is az egyik szám másik ellenében. Lásd pl. ez:

http://i.imgur.com/zRYODaJ.png

Ezen kívül még fontos a hozzáférés szabályozás. Lehet táblára vagy akár oszlop érték alapján meghatározni hogy ki milyen sorokat láthat csak (például a város oszlopból csak Budapest és Szombathely értékeket tartalmazókat).

Ilyen dolgokkal támogatom a menedzsment munkáját.

( sarkanyolo v | 2016. 09. 15., cs – 08:55 )

Nagyon tetszik, látom benne a fantáziát!
Nem gondolkodtál esetleg bootstrap-en és valami modernebb témán (pl: bootswatch)?

Köszi.

Igazából egy olyan kliens oldali webes felület a célom, amely minimális JS-t tartalmaz, lehetőleg időben visszafelé és előre is sok platformon jól menjen (kompatibilitás), a felület ne egye az akksit a JS miatt, és lehetőleg minden egyes klikk és kérés újra töltse az oldalt hogy biztosak lehessünk benne, az adat rögzült szerver oldalon.

A megbízhatóság fontosságát a design elé helyezem bizonyos mértékben.

nekem pont ezert jottek be a gyari js gyujtemenyek. A sok elore-hatra kompatibilitas, atmeretezes legyen valaki mas problemaja. Es szerintem jopar extjs, angularjs tablazatnal jol megoldottak + eleg jo a fejlesztetoseg.

Az meg, hogy mekkora js van mogotte, talan mindegy, mert elso alkalommal megy minden script a browser cache-be :)

Gyorsra, es hatasosra is meg lehet csianlni (sot, egyszerre :)
Angular egyik bazinagy elonye, a modularitas, es tesztelhetoseg. Sebessegben, eroforras felhasznalasban is eleg jol teljesit.
Amugy JS-ben van valasztas:

https://www.airpair.com/angularjs/posts/jquery-angularjs-comparison-mig…

https://www.codementor.io/reactjs/tutorial/reactjs-vs-angular-js-perfor…

Szal' van valasztek, sze szerintem verseny.

Angular 2 most jott ki, ami a TypeScript-el eleg eros versenyzo.

Ez azért nagyban függ a kliens erejétől. Én P3-on teszteltem, és gyors a cuccom. Tudom hogy nem életszerű, de ezzel csak szemléltetem. Ahol 10 éves gépek vannak, nem kell kidobni őket.

A 125 - 500 ms nem elég nekem (ez az 1000 sor létrehozása volt). Én 100 ms alatt generálom le az egész oldalt 4-500 SQL művelettel és egy rakás másik komplexabb művelettel. Mindenzt kliens gép teljesítményétől függetlenül. Olcsó, 8-10 ezer forintos táblagépen is.

Tudom en hogy a vanillajs a legjobb ! :)

De egyreszt ez viszonyitasi alap. Masreszt a google gmail.com es hasonlok is ugy mennek, hogy van rich client es pure html. Poriasra csianlod, mindenki jol jar, es a sebessegcsokkenes nem lesz eszreveheto.

Ha kivancsi vagy, hogy teljesit a cuccod regi gepen, egy virtualbox probat meger ;) [en is kivancsi lennek az eredmenyre]

Azért itt sok minden más is játszik, amit figyelembe lehet/kell venni.

  • Felhasználók száma. Ami egy kliensen fut az max. azt az egy klienst lassítja, ami a szerveren, az valamelyest mindet.
  • Hálózati sebesség. Egy gyenge kliensen leellenőrizni valamit általában gyorsabb, mint felküldeni a szerverre, majd vissza az eredmény.
  • Oldal megjelenítés. A teljes oldal lerenderelése általában lassabb és rosszabb felhasználói élményt ad, mint a dinamikus oldal módosítás.
  • A mai táblagépeknek, telefonoknak (még a P3-aknak sem) meg se kottyan egy kis js végrehajtás.

@crown @enpassant

Ezt elfogadom, de az esetemben jelenleg nem lenne jó kivitelezni, mert nem tudok csak kliens oldalon módosítani a szerverrel való beszélgetés nélkül. A tervezés legelső lépésekor döntöttem a szinte kizárólag szerver oldali kód mellett, mert annyi számolni és tárolni való van, hogy így jobb a rendelkezésre álló pénz, idő, energia szempontjából.

Meg ugye ez nem egy általános weboldal egy szimpla db-vel :)

Ezt pluszegyezem

Ill. - igaz, csak végigpörgettem a videót -, de ajánlom figyelmedbe a PatternFly-t (http://www.patternfly.org/) - egy RedHat-os projekt annak a dokumentálására, hogy milyen egy jó webes alkalmazás UI, letölthető működőképes sablonokkal (ne csak ezeket használd, az ajánlásokat is olvasd végig, mert bár van benne jó pár, ami megkérdőjelezhető [pl. hogy a gombok felirata felszólító ige legyen (Log In), ami az angolban tényleg működik, de magyarul a "Jelentkezz be" szvsz. nagyon ostobán hat], hasznos dolgok vannak benne.

Pl. az, hogy a kijelölt rendezésnek megfelelően csoportosítsa szerintem intuitívabb lenne úgy, hogy egy Table View-ban egy tábla-szintű Action-ként definiálod, amit akkor engedélyezel, amikor van aktív rendezés (pl. Csoportosítás gomb).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Aztán amikor más irányba mennek, akkor meg nehéz összehozni az addigi általam lefektetett működési logikával :)

Illetve a rendezést semmiképp nem akarom JS-ből csinálni, mert egy csomó szerver oldali feladatot is elvégzek (az aktuális nézet eredményét sql szinten le-cache-elem, tárolom permanens-en a nézetet, hogy másik gépről belépve is azt kapja és ne cookie-ban legyen csak tárolva - ha meg JS-ből kell vissza beszélni, az security szempontból nem tetszik stb stb - nem jó JS-ből).

Ez a patternfly oldal remek gyors, ilyennek kellene lenni minden oldalnak - habár nincs is rajt sok infó :) A JS-el dinamikusan épített cuccoknál nagyon nagyon rossz tapasztalatom van - mikor scrollozol az egér gombbal, és vemhez vamzer csigabakter módjára kezd el lassan futni az oldal az egér görgő után..