Symboogle – a keresési mindenes

Lassan végső fázisba érkezik az univerzális ügyviteli keresőnk tervezése és fejlesztése.

A Google megváltoztatta a világot a mindenre kiterjedő, szavak – a gyakorlatban szinte gondolatok – alapján történő kereséssel. Azt is kitalálja, mire is akartunk keresni. Ha nincs sok találat, ajánlást tesz arra is, hogy mire kellene keresnünk. Egyszóval okos.

A Google az Interneten keresgél, a Symboogle-val ugyanezt tervezzük megvalósítani ügyviteli adataink között. Mindenre, mindenhol. Symboogle.

Parancssori kapcsolók – Csak rendszergazdáknak (18+)

Manapság a parancssori kapcsolók az átlag felhasználók számára már nem fontosan. A modern felhasználói felületű operációs rendszerkben nem kell a programokat a nevük begépelésével indítani és működést befolyásoló opciókat megadni. Azonban némely esetben a kapcsolókkal érdemes a működést befolyásolni.

Csak rendszergazdáknak!

A Symbol Ügyvitel az alábbi parancssori paraméterekkel rendelkezik:

/syxmode SyX fejlesztői üzemmód

/server=<hostname>:<databasefolder> Kiszolgáló felülbírálása hálózatos üzemmódban

/skipotherconnections Adatbázis frissítés kikényszerítése aktív kapcsolat esetén is

/firstonly Több céges adatbázis esetén kapcsolódás mindig az első adatbázishoz

/? Súgó megjelenítése

A parancssori paraméterek beállításai frissítéskor és újratelepítéskor elvesznek, mert az asztali parancsikon is frissítésre kerül! Célszerű a parancsikon egy másolatát ellátni a parancssori paraméterekkel.

A 64bit mára már természetes

Brandom LeBlanc összefoglaló értekezése világosan szemlélteti, hogyan terjednek a 64bites Windows operációs rendszerek. Ennek oka lehet a tudatosság. De ismerve a honi és külhoni társadalom hozzáállását, inkább az OEM-nek köszönhető a terjedés.

Ezek szerint az új számítógépet vásárlók már nem biztos, hogy tisztában vannak vele, mit is vásárolnak. A népszerű programok futnak a számítógépükön, de mi lesz az ügyvitellel?

A Symbol Ügyvitel minden változata alkalmas 64bites operiációs rendszeren való futattásra:

  • Windows XP 64
  • Windows Vista 64
  • Windows 7 64
  • Windows 2008 x64

És természetesen Linux kiszolgálót választva minden 64bites Linux disztribúciót támogatunk, ami fut a Firebird adatbázis-kiszolgáló.

A LAB folyamatosan hegyezi a terméket

LAB csapatunk 12 emberhónapig készítette a keretrendszert, de időről-időre újra előveszik azt. Az összegyűjtött tapasztalatok alapján minden alkalommal találnak a rendszerben valamilyen gyorsítási lehetőséget.

A. Rendszerünk jelenleg több, mint 130 adatbázis táblában tárolja az adatokat (1347 mezőt számoltunk össze, persze nem kézzel kockás papíron). Adatbázis műveleteink központosítottak, bármilyen adatkezelési/adatelérési változás a módosítás után a programunk minden pontján megjelenik.

Számos alkalommal finomítottunk:

  • a nagy mennyiségű adatok lekérésének módján
  • a megszakítható lekérdezéseken (pl: véletlenül rosszul beállított szűrőfeltétel)
  • Large Object (BLOB = maximum 2GB-os adat, például video vagy tárol PDF) mezők lekérdezésein

B. Javítottuk a felesleges adathozzáféréseket. Többször előfordult, hogy egy-egy rendelkezésre álló adatot újból elértünk, újból áthoztuk a hálózaton. Ezen hibák kiküszöbölésére a LAB a fejlesztők rendelkezésére bocsátott egy SQL napló felületet, ahol a fejlesztő kolléga már munka közben látja, hogy az általa megvalósított funkció (pl: számla stornózás) hány alkalommal fordul a kiszolgálóhoz és milyen válaszidőkkel kell számolnia. Így a tesztelésre kerülő alkalmazás nem vagy csak ritkán küzd sebesség problémákkal. A tesztelőknek pedig nem ezzel kell foglalkozniuk.

C. Az SQL napló mintájára a fejlesztők figyelemmel kísérhetik, hogy a program adott állapotban milyen memóriafoglalási mérőszámokkal fut. Konkrétan hozzáférnek a betöltött (és betöltve maradt) például 43 vevőhöz, amelyek mindegyikéről minden adat lekérdehező és látható az is, hogy mikor és hol került betöltésre. És főleg miért maradt bent, mi használja?

D. Az architektúrából adódóan eddig is volt egy ún. “felpörgési ideje” a rendszernek. Az ablakok első megnyitása – “hála” a Microsoft-nak – az inicializálás (runtime compiler) miatt kicsivel lassabb volt. Mostantól azonban a ritkán változó adatok állandóan memóriában tartása miatt a felpörgési időt sikerült csökkenteni. A törzsadatok és egyéb statikus információk a változási valószínűségük alapján egyre ritkábban töltődnek újra. Kb. 30 percnyi programhasználat után már csak a ténylegesen változó adatok elérésekor van szükség hálózati forgalomra.

Konklúzió.

A sikeres, gyakran két embernek is több napos, hetes munkát jelentő mögöttes fejlesztések során eljutottunk odáig, hogy az alkalmazott technológia képes kiszolgálni a következő felépítésű céget. Gyakorlatból állítjuk, hogy:

  • 50 helyi felhasználó, call-center (gyakori, rövid műveletekkel)
  • 5-15 távoli felhasználó 2Mbit up/down bérelt vonalon
  • 5 nagyon távoli (külföldi) felhasználó a fent említett bérelt vonalon
  • átlagos, szerver célokra tervezett, de nem több milliós számítógép, 64bites Fedora Linux operációs rendszert futtatva.

Büszkék vagyunk a teljes egészében általunk tervezett és épített keretrendszerre, amely az elmúlt egy évben sok-sok felhasználónál, különböző platformokon is jól teljesített. Hajrá LAB!

Microsoft .NET vs. Java – Családi viszály

Fejlesztői körökben sem mindenkinek. Csak és kizárólag erős idegzetűeknek!