Symbol LABoratory

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.

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.

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

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!

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

A jövő hét folyamán jelenik meg programunk új verziója. Ezzel nem is mondunk újdonságot. Partnereink megszokhatták, hogy minden két hétben előrukkolunk valamivel. Ha kérik, ha nem. Mert van még a tarsolyunkban.

Amivel a jövő héten megjelenünk, azt nem kérték. Mert ezidáig még senki nem csinált ilyet. Talán nem is gondolták volna az ügyfelek, hogy lehet ilyet is. Mottó: “Egyedi fejlesztés, ingyen.”

Mi a helyzet az egyedi igényekkel?

Általában a felhasználók kérik, cégük működéséhez akarván igazítani a dobozos ügyvitel megoldást. Ez így helyén is van, ők a megrendelők.

Mi a baj az egyedi igényekkel?

Ez már fogósabb kérdés. A problémát az okozhatja, ha szót fogadunk és a fejlesztőcsapat beleépíti a kívánt funkciót a programba. Az ügyfél boldog, majd megkapja a számlát. Akkor már csak félig örül. (Valljuk be, minden egyedi fejlesztés pénzbe kerül. A nyomott árú piacon sajnos a termék árának többszöröse is lehet egy-egy új lista vagy export fájl.) De a funkciót megkapta, cége működése rendben van. A fejlesztőcsapat viszont évek múltán is kell, hogy emlékezzen valamilyen egyedi igényre, amely a programban valahol drótozottan jelen van. Nem kell messze mennünk (és sok karaktert sem beütni a böngésző címsorába), hogy példát hozzunk erre.

Képzeletbeli nagy cég, sok egyedi fejlesztés. Évek múltán is ott virít a “IF dubaj_mukodes” feltétel a programban, mert valamikor az őskorban eladtak egy programpéldányt a sejkeknek. A tizedik egyedi fejlesztésnél már egy külön ember kell arra, hogy fejben tartsa, mit kinek és miért építettünk bele. Szomorú tesztelők.

Mi még a baj a felhasználói kérésekkel?

Az, ha nem tudjuk megvalósítani. Technológiailag képzettek lehetnének a szakemberek, de Zsiguli típusú személygépjárművel már csak a Bamakó rally-n indulhatunk. Ne legyenek Forma-1-es terveink és ígéreteink.

Amit mi ígérünk…

Mi nem ígérünk semmit, lehetőséget biztosítunk. Hogy mire? Ez ki fog derülni a jövő héten…

Türelmüket megköszönve, a Symbol Tech Kft. csapata.

A szoftverfejlesztő cégek kell, hogy erősebb számítógépekkel fejlesszenek, mint a felhasználói számítógépek, de nem csak a GHz-ek számítanak. Egy kis betekintés, hogy min dolgoznak kollégáink.

Dell notebook-ok: A fejlesztők számítógépei mind notebook-ok, ebből is természetesen minőségi gépet kell választanunk, a leállás sokkal nagyobb hátrány, mint pár tízezer Ft. Ezért is választottuk a DELL számítógépeket. 2.4GHz, Core2Duo. Windows Vista.

17”-es display, 1440×900-as felbontás: sokmindennek ki kell férnie az asztalra. De nem lehet sokkal nagyobb, mint a felhasználók (kijelzőjének) felbontása, mert a kollégák hirtelen túl nagy ablakokat hoznának létre.

2-3GB memória: A hordozható számítógépek hátránya, hogy hordozzák őket. Emiatt nem mindenki az irodában tölti a munkaidejét. Ezért a teljes infrastruktúra kis méretű változata rendelkezésre kell, hogy álljon a számítógépeken. Adatbázis szerver, fejlesztőeszköz, Symbol Ügyvitel alkalmazás. Ez mind egy gépen is kell, hogy fusson. Ezért kell minimum 2GB.

Központi fejlesztői szerver: Master adatbázisunk, amely a fejlesztés magja ezen a számítógépen helyezkedik el. Ehhez csatlakoznak a kollégák, a forráskódok is ezen kerülnek tárolásra.

Adatmentés: Folyamatos adatmentés, amelynek részei: adatbázisok, forráskódok, grafikai fejlesztések (portál, wordpress, stb.) munkafájljai.

Céges adatok: Természetesen mi is a Symbol Ügyvitelt használjuk. Ehhez egy külön szervert állítottunk be, amely LINUX és fájlszerverként is szolgál. Ez egy jó tesztkörnyezet is.

VMware: Tesztelést végző kollégáink külön erre a célra lecsupaszított virtuális számítógépeken tesztelik programjainkat. Két fontos szempont van, amit mindig ellenőrízni kell:

1. Üres operációs rendszer. Frissen telepített operációs rendszereken is futnia kell a programnak, nem elég ha fel tudunk mutatni egy számítógépet, amin elindul. Hiszen az ügyfélnek általában nem fejlesztői számítógépe van.
2. Változatos operációs rendszerek.WindowsXP, Windows Vista, Windows7. Ez utóbbi kettőből x86 és x64-es változat, magyar, angol és német nyelvi beállítás. Ez is egy komoly és fontos feladat.

Néha még így is elfogy a memória… A Microsoft-os fejlesztőkörnyezetünk átlag heti egy alkalommal memória “elfogyásra” panaszkodik. Ilyenkor újra kell indítani. No, ez belefér. Jó munkát!