A hiba az esetek 90%-ban elfedésre kerül, azaz a válasz üzenetben nem érkezik semmi, a böngésző egy üres ablakot jelenít meg. Helyette a 413-as hibát kellene visszaadnia. Így sajnos azok az eszközök, amelyek webrendszeren küldenek adatot, nem értesülnek arról, hogy hiba történt.

WebSyX-ünkben is megvalósítottunk egy hibakezelő réteget, amely az elfedett 413-as hibát megkerüli és precízen kezeli. Amennyiben a hibakezelést bekapcsoljuk, úgy a POST adatfelküldésnél választ kell adni a feltöltésre. A WebSyX esetében ez egy OK szó kell, hogy legyen. Amennyiben nem kapunk választ (a csomag a nagy méret miatt elveszett) úgy hibának érzékeljük. Amennyiben az OK-tól eltérő választ ad vissza a szerver, úgy azt a szöveget is hibaüzenetként kezeljük. Ezzel egyéb, szerver oldalon bekövetkező hibákat is jelezni tudunk (MySQL error, PHP error, out of disk space, stb.)

WebSyX-ünk új változata letölthető a

http://syx.symboltech.hu/tanusitott-syx-beepulok/websyx-webaruhaz-kapcsolat/ linkről.

Text és Binary külön. A nagy mennyiségű adatok betöltését a rendszer automatikusan késlelteti, de ezen belül is ketté kellett választani a bináris és szöveges jellegű adatok betöltését. Egy olyan adathalmazban, ahol képek és szövegek is vannak, egy-egy szöveg mező tömeges módosítása az összes termék képének betöltését hozta magával. Ez így nem (volt) jó. A módosítás tesztelése folyamatban van.

Adatmódosulás feliratkozások. Az adatok módosulása esetén a feliratkozott más adatok feleslegesen kaptak nagyon sok értesítést (delegates and events), amely általában csak a kód minőségét rontotta, némely esetben – komoly – erőforrás problémákat is okozhatott.

Adatok trimmelése. Akár ügyviteli, akár egyéb adattárolási oldalról nézzük, logikus lépés az adatok trimmelésének (kezdő szóközök és szöveg közbeni többes szóközök kezelése) beállítása. Felhívjuk partnereink figyelmét, hogy ez az adatátadásban körültekintést igényel, emiatt konzultációt biztosítunk.

Hazánkban már több, mint 10 cég használja keretrendszerünket szoftvereinek egyszerűbb és gyorsabb fejlesztésére.

Pályafutásom kezdetén, a CCS Hungary Kft-nél szoftverrendszert fejlesztettünk, amely a légitársaságokat és a Malév-ot szolgálta ki. Egyik funkciója volt a csomagok gépre rakása. Ha a gép indulása előtt negyed órával volt még függőben lévő csomag, akkor különleges figyelmeztetést kellett megjeleníteni.

Jött a korszakalkotó ötlet, hogy ne csak vizuális, hanem “audiális” is legyen a figyelmeztetés. A villogó piros mellett 5mp-enként hangot is adott. Kis sípolós kattanás. A szoftver rendben volt, vittük telepíteni.

A telepítésnél ott voltam, ezért én kaptam az első “pofont”. Az automatikus frissítő rendszer kb. 30 gépre lerántotta az alkalmazást és a felhasználó tényleges feladatától függetlenül minden gépen jelzett a csipogó. 5mp-enként szólalt meg ugyan, de 30 számítógép esetén ez 6csipogás/mp-es ütemezést jelentett. Egy nagy terem, ami csipog. A csipogás mellett már sikítottak is a kollégák. Nagy zűrzavart okoztunk

Szóval ezért nem szeretjük a hangokat. De az üzleti felhasználás most megkövetelte. A felugró emlékeztető (Partnerkapcsolat modul) és az átküldött jegyzet (Sticky-note) hangot ad, amikor megjelenik. Reméljük, nem lesz belőle hangorkán.

Mi is az API?

Az API egy függvénytár, amely egy rendszer kívülről elérhető funkcióit engedi megszólítani. Kis vagy közepes funkcionalitás esetén az API annyi megszólítható “dolgot” tartalmaz, amennyit két kezünkön meg tudunk számolni. Példaképpen említhetjük a POP3 vagy IMAP parancsokat, amelyek a levelek letöltését, üzenettörzs letöltését, üzenetek törlését valósítja meg. Nem is kell többet.

Ugyanilyen a Google Docs API, amely dokumentumok tárolását szolgálja. A műveleteknél nem is vágyunk többre, mint dokumentum feltöltése, letöltése, törlése, áthelyezése és egy gyors keresőszolgáltatás a dokumentumok tartalmában (ez utóbbi nem is biztos, hogy része a rendszernek, de ha már Google, akkor talán igen)

SaaS

Egy összetett (nem bonyolult, hanem komplex) rendszer esetében egy teljes API legalább annyi műveletet tartalmaz, mint ahány főmenüpontja van, a paraméterek száma is több tízre tehető. Ez nyilvánvalóan nem valósítható meg, pontosabban olyan mértékű ráfordítást igényel, amely nem térül meg.

Ehelyett a dolog méregfogát úgy húztuk ki, hogy egy önálló programozási platformmal lehetővé tettük bármilyen API megírását. És mindezt ingyenes eszközökkel. Egy SaaS kompatibilis SyX megírása ahhoz hasonlítható, mintha a Google Docs adatbázisához hozzáférünk (saját adataimat nem rejtsék el előlem) és saját lekérdezéseket írhatunk. A lekérdezéseket egy szabványos hozzáférési rétegen (HTTP) kivezetjük, hogy az azt felhasználó kollégáknak ne kelljen valami újat megtanulniuk.

Nézzünk erre egy példát!

Szükségünk lenne egy termékhez tartozó készletinformációra. Ezt egy külső program (amely a weboldalt frissíti) fogja felhasználni. Programozási nyelve lehet PHP, Delphi, C++ vagy C# is. Triviális megoldás, ha az adatbázisból közvetlenül lekérdezzük ezeket az információkat. (Ügyfélszolgálatunk támogatást nyújt a szükséges adatok helyének megismerésében). Ez a megoldás azonban közvetlen adatbázis kapcsolat igényel, amely közepes méretű cégeknél nem megoldható. Emellett külön kell azzal foglalkozni, hogy a fent jelölt programozási nyelvek miként kapcsolódnak az adatbázishoz. Helyette valósítsuk meg a dolgot két lépésben!

1. lépés: SaaS funkció létrehozása.

Hozzunk létre ingyenes fejlesztőeszközzel egy SyX-et, amely SaaS működésre alkalmas. A fenti művelet kiszolgálására készítsünk egy metódust, amely egy termékkódot vár és egy opcionális dátum paraméterrel hívható meg. A metódus “magja” kb. 8-12 programsor segítségével a beérkezett kérést ki tudja szolgálni a megfelelő táblákból történő lekérdezéssel. Végeredményként visszaadja az összes raktárt és benne a készletet, ahol a termék eddig megfordult. Fontos megjegyezni, hogy a bemenő URL feldolgozását nem nekünk kell elvégezni, sőt az eredmény formátumát sem nekünk kell meghatározni, azokat a SaaS definiálja (XML lesz).

2. lépés: SaaS funkció hívása.

Következő lépésben a Symbol Ügyvitel által használt webszervertől le tudjuk kérni a http://localhost/GetWarehouseBalance meghívásával a raktárkészlet információkat. Az URL meghívása szinte programozási nyelv függetlenül megtehető, minden nyelv tartalmaz weboldalról való letöltést megvalósító funkciókat. A visszaadott érték lehet XML formátumú, esetleg JSON, sőt teljes HTML weboldal is, ha az URL-t böngészőn keresztül kívánjuk elérni.

A fenti példán keresztül jól látható, hogy miért nem egy teljes API-t valósítottunk meg, mennyire szerteágazó lenne az ügyfelek minden igényét egy API-ban kielégíteni. Helyette azt a megoldást választottuk, hogy szabványos platformot hoztunk létre, amelyben mindenki a saját API-ját elkészítheti a saját adatai feletti rétegben.

A biztosítékot az csapta ki, hogy az ESZIG nyomtatvány mezőnevei az IMP/XML fájlban ugyanolyan véletlenszerűen vannak, mintha egy jó véletlenszám generátort készítenének az adóhatóságnál. (Bocs, helyesen NAV). Néha láttunk benne szabályszerűséget, de a végén nem sikerült semmilyen elvet ráhúzni. Maradt a kódtáblázat, azaz sor+oszlop-hoz hozzárendeltünk egy számot, ami az azonosítója lett a mezőnek.

Kérdésem az, hogy milyen szabályok alapján határozták meg a mezők azonosítóját. Esetleg több lépcsős módosítás során álltak elő a számok? A lényeg, hogy egyelőre sikerül megvalósítanunk a dolgot, de egy publikus API ennél okosabb/logikusabb is lehetne…

Felhasználható-e a Firebird web célokra?

Mivel a Firebird szervernek létezik Linux-os változata (ez is kompatibilis a termékünkkel), telepíthető olyan számítógépre, ahol egy web kiszolgáló (Apache 2.2) is telepítésre került. A két komponens PHP-n keresztük jól megérti egymást. A web-es adatokat lehet Firebird adatbázisban tárolni és onnan kiszolgálni, de nem célszerű.

Alkalmas-e a Symbol Ügyvitel adatbázisa web célokra?

Amennyiben WEB célok alatt olyan működési módot értünk, ami néhány felhasználó számára az összes adat irányába elérhetőséget biztosít, akkor a válasz IGEN. Példa lehet erre egy Ticketing rendszer, ahol cégének ügyfelei belépnek a web-es felületre, ahol azonosítják magukat, majd megnézhetik, hol tart a rendelésük vagy a kért javításuk. Ennek kiszolgálására rendszerünk alkalmas.

Természetesen UTF8/Unicode üzemmódban tároljuk a szöveges adatokat,
így web-es környezetben sem merülhetnek fel ékezet problémák.

Alkalmas-e a Symbol Ügyvitel adatbázis portál célokra?

Ha portál célokra használnák a Symbol Ügyvitel terméktörzsét, NEM javasoljuk a használatot. Egy portál egyetlen oldalának felépítése során sok (>10) lekérdezés fut le. Köztük termékképek, termékcsoportok, készletinformációk, stb. Ezek kiszolgálására nem elég a Firebird adatbázis kezelő. Nem erre találták ki. Pláne, ha 10-20 konkurens felhasználót feltételezünk az oldalon, akik eszeveszetten kattintgatnak egy termék után kutatva.

Az adatbázis állandó?

Külön ki kell térni arra, hogy a Symbol Ügyvitel adatbázisa NEM állandó. Fenntartjuk magunknak a jogot, hogy adatbázisunk formátumát átalakítsuk. Általában bővíteni szoktuk a tárolandó adatok körét, ritkán használunk új mezőként valami olyat, amit kötelező kitölteni (NOT NULL), illetve kivételes esetben szüntetünk csak meg mezőket. A fentiek figyelembe vételével kicsi az esély, hogy egy jól megírt lekérdezés egy új verzióban ne fusson le, de elképzelhető.

Az adatbázis formátumáért külső felhasználási célból felelősséget nem tudunk vállalni,
még akkor sem ha adatbázisunk nyitott, a felhasználók adatait nem rejtjük el.

Akkor mi a megoldás?

Sok helyen (>50) jó megoldást jelent egy saját webáruház működtetése saját adatbázis motorral és ehhez egy illesztőfelület megvalósítása. Mikből lehet választani?

• osCommerce
• Joomla + VirtuaMart webáruház motor
• Saját fejlesztés (PHP, Java, stb.)

Az illesztőfelületre nemsokára elkészül az általános megvalósításunk, aminek segítségével minden webfejlesztő saját webes megoldását (vagy valamilyen ingyenes megoldást) hozzáilleszthet a Symbol Ügyvitelhez. Ehhez cégünk közreműködésére nincs szükség. Szabadon letölthető WebSyX beépülőnk (nemsokára elérhető) szabadon tesztelhető, az általa küldött XML fájlok nyílt formában elérhetőek.

További információk: syx.symboltech.hu

Elmúltak azok az idők, amikor 64kB RAM állt rendelkezésre és nagyon hatékony, gyakorlatilag kihegyezett algoritmust kellett írni mondjuk 200 dolgozó bérszámfejtési adatainak kezelésére. És nem mindenki tudta ezt megcsinálni.
Jelenleg az igazán sok adatot adatbázisokban kezeljük, nem számít a memória, a szerverben legyen sok.

A fejlesztők pedig 4-6 éve (Java-sok régebben) már túlléptek azon, hogy a numerikus analízisben megismert elveket kelljen ismerniük, hogy használható programot készítsenek. Mert beköszöntött a keretrendszerek kora. Ebben minden általánosan használt funkció már megírásra került, sőt eszközök is vannak arra, hogy a hiányzó részeket se tudjuk rosszul megírni (Generics, Interface, etc.)

Jó lenne ha emlékeznék, de nem fog menni. Valamikor a keretrendszer által támogatott rendező algoritmusok (Generic List Sort()) helyett sajátot készítettünk. (Ennek oka, hogy a BindingList-ben nincs sort, de ez mellékes). A saját pedig – minden bizonnyal – “pár napig jó lesz kipróbálni” szemlélet alapján egy gyors buborék rendezés lett. 4 sor, lehetetlen tévedni. Működött is. Majd a pár napból egy év lett.

Nem is lett volna baj, minden szépen működött, az SQL szerver rendesen kezelte a 80.000 terméket ügyfelünknél. Egészen addig, míg a 80.000 termék több, mint 5000 (!!!) gyártó alá került besorolásra. Ekkor a termékkiválasztó ablak megnyitása 30-50mp-et vett igénybe. A konzulens kollégák jelezték, hogy ez nem fatális hiba, emiatt nem kell azonnali verziót közzétenni, de minket mégis izgatott a dolog…

És kb. egy órába telt, mire kiderült, hogy nem az adatbázis műveletek lassúak, nem is az 5000 gyártó combobox-ba feltöltése (valóságban más felületi elem, de példaképpen legyen combobox), hanem valahol belül egy adatátadás. És ekkor jött a homlokhoz csapás. A bubble-sort 5000 elem esetén statisztikailag 5000 x 2500 = 12.5M összehasonlítást végez és ennyi cserét is, ha kell. Ennek pedig ideje van. Egész számok helyett objektumok esetén még inkább.

A dolog sikerrel zárult, mert 3 órányi munka után a keretrendszerünk egy operáción esett át és a gyomor (körülbelül ez felel meg a rendező algoritmusoknak) újra egészségesen viselkedik. Persze újra felidézve tanulmányainkat rájöttünk, hogy a már rendezett adatokat a QSort nem is rendezi be újra, azaz még hatékonyabb lesz a működés.

Kis adatmennyiségek esetén nincs szerepe a fentieknek, de ott sem árt egy kis performancia-tuning.

És, hogy mit látunk?

• Van olyan cég, amely 2009. év közepe óta nem jelentetett meg hírt magáról. A saját weboldalán! Leszálló ág, vélelmezhető, hogy csökkenő Incoming Cash-sel rendelkeznek…
• Van, aki szépen csendben fejleszt, 2 havonta kiad egy új verziót, benne apróbb gombok, kis kényelmi funkciók. Lelkes csapat, Csendes folyó, 1-et fizet x-et kap (x>=3) akcióval…
• Van régi motoros, régi V12-es. Sokat fogyaszt (termékkövetés), már nem annyira hatékony és a kasztni is itt-ott kopott. Slusszkulcsának pörgetésével, kapuzárás előtti sofőrjével még bejön néhány hölgynek…
• Van, aki újként indult, rögtön v3.0-ként jelzi rendszerét. Szépen felépített koncepció, egyszerű kezelhetőség, 4 számjegyű árak. (És valahol máshol már látott működési modell, ismerős MsSQL instance név, ablakok) Naturalisztikus bulvártermék, csak bírja ügyfélszolgálattal… szurkolunk.
• És még sokan mások…

Ki mutat újat?

Örömmel tölt el minket az a fellelhető irányvonal, hogy tudunk még nekik is újat mutatni. Több megvalósult fejlesztésünk köszön vissza a versenytársak termékeiben. A maguk módján. Biztos, hogy nem napi szinten foglalkoznak velünk. Ez nem is lenne jó. De néha észreveszik, hogy mit csináltunk és ötletet merítenek belőle/belőlünk.

Több forrásból értesültünk, hogy fejlesztéseinket elemzik is. Tudjuk, hogy az egyik cég a Symboogle és a Symbol Suggest megoldásainkat nem tartja jó ötletnek. Mások a jelenlegi CRM+ rendszerünkre ráharaptak, jelenleg 12 hónapos fejlesztési feladatként még kicsit halogatják. (Nemsokára CRM+ rendszerünk még nagyobb tudású lesz)

Fontos megjegyezni, hogy ez nem tilos, sőt jó. Mert előre viszi a világot. És két dolgot bizonyít számunkra:

1. Jó úton haladunk, ötleteink nem csak számunkra bírnak értékkel.
2. Többedik alkalommal elemezve azt, ahogy minket követnek, azaz INNOVATÍV PIACVEZETŐK vagyunk.

Mitől versenytárs?

Itt álljon egy kis magyarázat arra vonatkozóan, hogy mitől versenytársak. A konkurens ugyanazt adja más köntösben, talán apróbb paramétereiben eltérően (nagyobb internet sávszélesség, nagyobb GB, +25% a samponos flakonban, ugyanaz a mobiltelefon olcsóbban WiFi nélkül), de végeredményben ugyanarra jó. Itt azonban versenytársakról beszélünk, akik egy pályán haladnak, versenyeznek. De nem ugyanazzal a járművel mennek, sőt valaki tankkal tör előre, van aki versenybiciklivel hagyja le a tankot a kanyarban.

De nincs célszalag, nincs győztes, nincs a legjobb. Ez egy folyamatos verseny…

Van, aki 100m után hagyja abba, van, aki fut még 3 kört és valaki lefutja a fél-maratont. Mert mást akar elérni a pályán, a piacon.

Emiatt nem a megtett körök (=megszerzett ügyfelek) száma a fontos, sokkal inkább a futás stílusa és főleg az, hogy ki fut legelöl, kit követnek a többiek. Mi ezek szeretnénk lenni, sőt mi ezek vagyunk. Jelenleg. Lehet, hogy jön egy új versenyző, tele erővel és ötletekkel. De addig maradunk elöl. Köszönjük a megtisztelő figyelmet!

Kérem kövessenek!

ps: régi feladvány a ’80-as évekből

“Hányadik leszel, ha futóversenyen megelőzöd a második helyezettet?”
Általános válasz, hogy első, de a helyes válasz a második

Aztán, amikor a Java 1.1 beköszöntött és hozta a java.lang.reflect névteret, akkor néztünk nagyokat, hogy mi értelme van egy osztályt felderíteni futásidőben? Pláne, amikor programozás közben ott vannak a property-k és metódusok. Aztán csak-csak hasznát vettük, de a címben említett megoldásra még rémálmunkban sem gondoltunk volna. De a Symbol LAB összefogott és megoldotta ezt is…

1. Keretrendszer

Adott a keretrendszerünk, amiben sok helyen használjuk a reflection-t. Például listáink szűrőablakai nem léteznek önállóan, hanem szűrőosztályokat definiálunk (közös ősből interfésszel). Az osztályok feltérképezésével pedig létre tudjuk hozni a szűrőablakokat. Ha találunk egy property-t, aminek DateInterval a típusa, akkor kikerül két dátumválasztó, amelyek a property-be írnak, onnan olvasnak (DataBinding). A property-k attributumokkal rendelkeznek, amik magyar nevet adnak a mezőknek.
Szép, kidolgozott technológia, meg is számolom… (2 perc eltelik itt) … a Symbol Ügyvitelben jelenleg 103 szűrőobjektum van.

2. Probléma

A feni technológiát kényelmes használni, nem is akarunk letérni az útról, de egyedi fejlesztéseink (SyX) esetén külső fájlból jönnek az osztályok, amelyek nem az 1-es pontban említett ősosztályból származnak. Mi tévők legyünk? Az ügyfél várja a megoldást, ki kell valamit találni…

3. (Egyelőre még nem elégséges) Megoldás

Fejlesztési vezetőnk pénteken már említett valamit, de csak hétfőn állt elő az ötlettel. Ha fel lehet térképezni egy osztályt, akkor miért ne CSINÁLNÁNK egyet, csak úgy futásidőben. Még jó, hogy van Google, mert volt honnan információt meríteni, de hideg zuhanyként ért minket a találatok listája.
Létre lehet hozni típust futásidőben, de a következő lépéseket kell végiggondolni:

1. Minden property-nek van egy lokális változója
2. Kell, hogy legyen egy GET és egy SET metódus, amely a property értékét olvassa és írja a lokális változóba/változóból.
3. A GET és SET metódusok törzse, lényegi része nem C#-ban írandó, hanem a köztes MSIL/IL nyelven, ami a .NET-ben megvalósított Assembly nyelv, azaz szinte gépi kód.

Itt egy kis szomorúság jött, mert ilyet nem oktatnak az egyetemen, nem hétköznapi a felhasználási módja és nincs róla még “MSIL 21 nap alatt” könyv sem.
Viszont a fejlesztési vezetőnk ellentmondást nem tűrve a megoldás útjára lépett és saját maga valósította meg. Ilyenkor kis csendet szokott kérni, de ez most 4 órán át tartott. Megszületett egy már működő megoldás. De ez még nem volt elég jó a felhasználásra.

4. Jó megoldás

További 2 órába telt, hogy megoldjuk a problmát, ugyanis az újonnan létrehozott osztálynak van egy őse, amelynek van egy két paraméteres konstruktora. MSIL nyelven kellett megoldani a base konstruktor hívását és a paraméterek átadását.

5. Összefoglalás

Keretrendszerünk már ezt is tudja, általános osztályt csináltunk belőle, amelyet alant közzéteszünk. Hogy izgalmasabb legyen, egy hibát rejtettünk el benne a 32-33. sor környékén. Aki a hibát kijavítja, +1 pontot kap önéletrajza leadásakor a HR osztálytól.

using System;
using System.Collections.Generic;
using System.Data;
using System.Reflection.Emit;
using System.Reflection;

namespace SymbolTech.BaseProject.FrameWork.Common
{
    public class RuntimeTypeFactory
    {
        private TypeBuilder tb;

        public RuntimeTypeFactory(string assemblyname, string typename, Type baseclass)
        {
            AssemblyName assname = new AssemblyName(assemblyname);
            AssemblyBuilder assbuilder = AppDomain.CurrentDomain.DefineDynamicAssembly(assname, AssemblyBuilderAccess.RunAndSave);
            ModuleBuilder mb = assbuilder.DefineDynamicModule(assname.Name, assname.Name + ".dll");

            tb = mb.DefineType(typename, TypeAttributes.Public, baseclass);

            //Override base constructors
            if (baseclass != null)
                foreach (ConstructorInfo ci in baseclass.GetConstructors())
                {
                    List<Type> types = new List<Type>();
                    foreach (ParameterInfo pari in ci.GetParameters())
                        types.Add(pari.ParameterType);

                    ConstructorBuilder ctor = tb.DefineConstructor(MethodAttributes.Public, CallingConventions.Standard, types.ToArray());

                    ILGenerator ctorIL = ctor.GetILGenerator();
                    for (byte i = 0; i < types.Count; i++)
                        ctorIL.Emit(OpCodes.Ldarg_0, i);
                    ctorIL.Emit(OpCodes.Call, ci);
                    ctorIL.Emit(OpCodes.Ret);
                }
        }

        public static CustomAttributeBuilder CreateCustomAttributeItem(Type attributetype, Type[] constructorparametertypes, object[] constructorparameters)
        {
            return new CustomAttributeBuilder(attributetype.GetConstructor(constructorparametertypes), constructorparameters);
        }

        public void AddProperty(string name, Type type)
        {
            AddProperty(name, type, null);
        }

        public void AddProperty(string name, Type type, params CustomAttributeBuilder[] customattributes)
        {
            if (String.IsNullOrEmpty(name) || type == null)
                return;

            PropertyBuilder newprop = tb.DefineProperty(name, System.Reflection.PropertyAttributes.HasDefault, type, null);
            if (customattributes != null)
                foreach (CustomAttributeBuilder cab in customattributes)
                    if (cab != null)
                        newprop.SetCustomAttribute(cab);

            FieldBuilder newfield = tb.DefineField(name.ToLower(), type, FieldAttributes.Private);
            MethodAttributes getSetAttr = MethodAttributes.Public | MethodAttributes.SpecialName | MethodAttributes.HideBySig;

            MethodBuilder methodget = tb.DefineMethod(String.Format("get_{0}", name), getSetAttr, type, Type.EmptyTypes);
            ILGenerator methodgetil = methodget.GetILGenerator();
            methodgetil.Emit(OpCodes.Ldarg_0);
            methodgetil.Emit(OpCodes.Ldfld, newfield);
            methodgetil.Emit(OpCodes.Ret);

            MethodBuilder methodset = tb.DefineMethod(String.Format("set_{0}", name), getSetAttr, null, new Type[] { type });
            ILGenerator methodsetil = methodset.GetILGenerator();
            methodsetil.Emit(OpCodes.Ldarg_0);
            methodsetil.Emit(OpCodes.Ldarg_1);
            methodsetil.Emit(OpCodes.Stfld, newfield);
            methodsetil.Emit(OpCodes.Ret);

            newprop.SetGetMethod(methodget);
            newprop.SetSetMethod(methodset);
        }

        public Type CreateType()
        {
            return tb.CreateType();
        }
    }
}

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

Mi ilyenkor a teendő?

Vannak félmegoldások arra vonatkozólag, hogy hogy lehet életet lehelni a betegbe. Telepítsd ide, majd másold át oda, majd indítsd újra és kattints oda. Utána nézd meg, hogy elindult-e. Ha nem, akkor az ünnepek után hívd az ügyfélszolgálatot… van ennél jobb megoldás is: Symbol Ügyvitel!

Már a tervezésnél nagy hangsúlyt fektettünk arra, hogy rendszrrünk 64bites operációs rendszeren is fusson és Önnek ne kelljen bonyolult telepítési módokat végigkattintgatnia. A telepítőkészlet méretét nem szerettük volna növelni a 64bites csomagokkal. Ezt a telepítő alternatív tükörszerverekről tölti le, amennyiben szükség van rá.

• 64bites .NET framework letöltésre kerül, ha szükség van rá. Ez a Windows7-nek része, de a 64bites XP-nek még nem.
• A 64bites adatbáziskezelő is jobban kihasználja a gépekbe rakott 4GB (vagy több) RAM-ot, sőt csak ez használja ki. 32bites operációs rendszer nem fogja ezt kezelni. Nálunk erre is van lehetőség, sőt automatikusan ez települ, ha szükség van rá.
• A Symbol Ügyvitel alkalmazás pedig elkészültekor is már 32/64 bites operácisó rendszeren is futtatható formában valósult meg.

És mivel jövőre jönnek a 128 bites szerverek, elkezdtük ennek a technológiának a feltérképezését is.

A Symbol Ügyvitel új verziójában egyszerre jelent meg a csekkes számlaformátum és a példányok külön nyomtatása, természetesen tömegesen is.

A csekkes számlaformátum külön bizonylattömbbe szervezhető, amely praktikus is, hiszen egyik vevőm csekkes, másik nagy összegű, átutalásos. Minden bizonylatnál a tömeges nyomtatási lehetőségnél választhatunk az első példány, a nem első példány és a minden példány között.

Természetesen nem csak számla, hanem az ÁFA spóroló díjbekérő is nyomtatható csekkes formátumban.

Tipikus felhasználási mód a tömeges számlakiállítás nyomtatás nélkül, napi 7.5 órában. Majd a munkaidő előtti fél óra felhasználható a nap folyamán kiállított számlák első példányának csekkes nyomtatására, majd a 2./3. példányok normál papírra való nyomtatására.

És a fél óra alatt csak kettőt kell kattintanunk, azaz még két bögre tea is belefér…

Régóta működik a bevezető karakter is. A vonalkódolvasó az olvasás megkezdésekor is tud küldeni egy karaktert. Rendszerünk – amennyiben ez az általában is elfogadott F9 billenytű – támogatja a bevezető karaktereket is. Bizonylatok tételei automatikus kitöltésre kerülnek az F9 hatására, a főablakon pedig gyors termékinformációk jeleníthetők meg egyetlen csippantással.

Információ: http://www.symboltech.hu/features/vonalkod/

Mert amiről nem tudunk, arra nem is vágyhatunk!

Évek óta problémát jelent, hogy ügyfélkapcsolati oldalon kultúrált, formázható szöveges dokumentumokat állítsunk elő és ezeket ügyfeleinknek ki tudjuk küldeni. Az eddigi megoldások hátrányai:

• Word-ben megírt dokumentumban kézzel kell elhelyezni a vevőinformációkat.
• Az ügyviteli rendszerbe integrált word-illesztés érzékeny arra, hogy milyen verziójú Office rendszer van a gépünkön. Az ingyenes OpenOffice-nak semmilyen verzióját sem támogatják a mai rendszerek.
• Dokumentum előállító és iktató rendszerek nem illeszthetőek ügyviteli rendszerhez, illetve külön támogatást igényelnek, azaz nem dobozosak.

A Symbol Tech csapata előállt egy beépített szövegszerkesztővel. Ennek felhasználásával Ön a fizetési felszólításokat és egyenlegközlőket sablon szerűen szerkesztheti, formázhatja és ügyfél/egyéb mezőket helyezhet el benne. Hasonlóan a Word körlevél funkciójához. De nem szükséges a word-öt a számítógépre telepíteni.

További információ: http://www.symboltech.hu/features/fizetesifelszolitas/

Az automatikus adatbázisfrissítés többször bizonyított, minden ügyfelünk frissítette a rendszerét. Ez “szokott menni”.  Ami ennél izgalmasabb: Villáminformációk és Eszköztár.

A főablakon a legfontosabb céges villáminformációk megjelennek, ezeke duplakattintással működésre is lehet bírni. Mire jók ezek? Nem arra, hogy elfogyasszuk az ott lévő elemeket. Nem lehet minden nyitott árajánlatot lezárni, mert az ügyfél még gondolkodási időt kér. A rendezetlen számlákat nem lehet egy nap alatt behajtani. De arra jó, hogy az ember a reggeli munkakezdéskor kicsit összeszedettebb lesz, mert tudja, hogy egyáltalán hány feladata van, amivel foglalkoznia kell. Nem lehet kifogás, hogy elfelejtettem megnézni a függőben lévő ajánlatokat!

A másik a Symbol Ügyvitel Eszköztár. Egy ügyviteli és egyéb irodai szoftvert egész nap használunk, bámuljuk, jobb esetben berakjuk a gyermekünk képét háttérképnek. De ott van, nézni kell. Ha lecsukom, akkor meg nem látok semmit. Ezt hivatott az eszköztár első, béta verziója megoldani. Kis méretben az ablakon egy kis helyet foglal el, de mégis elérhetőek róla a legfontosabb funkciók, amikkel új számlát, rendelést, stb. vehetünk fel. És nem zavar a böngésző használatában sem, mert a pozíciója egérrel változtatható (elmozdítható – a szerk.).

Várjuk a felhasználók visszajelzéseit a fenti funkciókkal kapcsolatban!

Bonyolultságát tekintve már évek óta (SQL2000/MSDE) olyan tudású volt az adatbázis szerver, hogy ahhoz rendszergazdára volt szükség. A 2005/2008 telepítése pedig már több időt vett igénybe, mint egy Windows7 telepítés. Az adatbázis szerver bizonyított nagy rendszerek esetében is. A lépés, hogy az Oracle-lel konkuráljon, logikus volt.

De mi lesz a kis felhasználókkal? Számukra továbbra is lehetőség nyílik az Express változatra, de azt sajnos el kell felejteni, hogy egy 50MB-os telepítőbe belezsúfolva, csak úgy mellékesen a gépre települ a DBserver.

A Microsoft-nak erre is van megoldása:

1. MsSQL CE néven fut a kicsit butácska SQL server, amelyben nincs trigger, tárolt eljárás. Viszont egy gépen fut.
2. Másik megoldás a rendszergazdával ellátott céges számítógépes rendszer. Végy egy rendszergazdát (hiszen ki tartja karban a licenszkulcsokat, ki frissíti a gépeket, ki szerzi be a tonert, stb.), aki feltelepíti az SQL szervert, beállítja a jogosultságokat és telepíti az ügyviteli rendszert.

Lassan ideje elgondolkozni, hogy milyen dobozos alternatívái vannak az MsSQL servernek!

Addig is az újdonságok: http://www.microsoft.com/sqlserver/2008/en/us/whats-new.aspx

Persze nem kell kivágni, elég felírni a promóciós kódot és nálunk például a Symbol Ügyvitel vásárlásánál beváltható a kedvezmény.

A Symbol Ügyvitel kupon itt elérhető: Symbol Ügyvitel kupon

Egyébként ezt integrálták a Google Maps szolgáltatásba, azaz gyakorlati haszna a cég üzletének térképen való megjelenítése és a térképes találat meghálálása egy kuponnal.

Persze tartozik hozzá Google API is, azaz programozottan is elérhető, nem kell a cégvezetőnek egész nap a google weboldalán kattintgatnia: http://code.google.com/intl/hu/apis/coupons/

Kezdjük egy kicsit távolabbról. Évente jelennek meg újabb és újabb felhasználói élményt fokozó és a háttérben technológiai előrelépést jelentő fejlesztések. Gondoljunk csak (időrendben) a Java WebStart-ra, a Web2-re, az IWIW web-es átalakítására, amikor is nem HTTP POST-ok szaladgálnak a hálózaton, hanem AJAX-os kérések. Tovább is gondolhatjuk az ötletfolyamot! Vegyük észre a SilverLight előretörését, nem beszélve a web-es számlázókról, amelyek nem használhatóak ugyan nagy mennyiségű ügyfél gyors kiszolgálására, de megvan a maguk előnye hordozhatóság szempontjából. Nézzük csak meg a Vista widget-es megoldását, a hordozható miniszámítógépeken, PDA-kon megjelenő minialkalmazásokat, amelyek web-en mindent összekötnek. Nem utolsóként pedig a Google fejlesztéseit se felejtsük el, a GSM adótorony információkból meghatározott GPS koordináták kérdéskörét.

Ezek mind a felhasználókért vannak, az adatok valahol az interneten keringenek. A felhasználó a @google.com email címe alapján kerül azonosításra és a levelei mellett rögtön beszélgethet a barátaival, twitter-en hozzászólhat valamihez. Mindehhez 3 perc számítógép előtt eltöltött idő elég.

Vannak a nagy, céges rendszerek, a maguk 5-10 fős rendszergazda csapatával, adatbázis klasztereivel, központosított telepítési szabályaival. Nagy pénzintézeket, közmű szolgáltatók nem is tudnának másképp működni.

És vannak az otthon telepíthető, de mégis céges viszonyokat emuláló rendszerek. Ezek a dobozos ügyviteli rendszerek, amelyek közül már szinte csak a számlázórendszerek hálózatosak. A könyvelőprogramokat egy személy használja. (Általában – szerk.) Na ez MsSQL szrverrel olyan, mintha a webes google levelező helyett SmallBusiness szervert telepítenénk és csak Exchange szolgáltatáson keresztül levelezhetnénk. És mindezt a nagymamámnak kellene telepítenie. Fura, nem?

A cégek jelentős része MsSQL Express-t használ. Ingyenes, belefér a telepítőkészletbe, parancssorból telepíthető, gondozást nem igényel. De ez szerintem csak véletlen. Ez nem oda való! Ne gondoljuk, hogy azért mert laboratóriumi körülmények között működik, kiadható 100-1000, esetleg még több ügyfélnek és felelősséget lehet érte vállalni. Ehhez rendszergazda kell!

A Microsoft is határozottan jelzi, hogy van a nagyvállalati MsSQL szerver, annak a kis méretű kiadása hobbi informatikusoknak, 4GB terjedelemig. (De nem a nagymamámnak való!) És van az egygépes, telepítést és gondozást nem igénylő MsSQL compact (3.5) Ebben sajnos nincsenek meg a nagyvállalati működést támogató komponensek (triggerek, tárolt eljárások, stb.). De a célja nem is az, hogy dobozban áruljunk egy vállalatirányítási rendszert!

Az idő múlásával a fenti gondolat beigazolódni látszik. Már a .NET 3.5 is 1.5 órán át (!!!) települ, hozzá az SQL szerver még egy fél óra. Ez nem a dobozos kategória!

A Windows 7-tel ugyanez a probléma. A biztonsági házirend már nem engedi meg, hogy a felhasználó a webről bármit letöltsöm, majd az gyorsan telepítse. Annyi a kéretlen program, hogy már bizalmi elven nem telepítünk semmit. Azok a dobozos alkalmazások, amelyek még építenek arra, hogy “Úgyis lehet írni a program files-ba”, jobb esetben nem indulnak el, rosszabb esetben nem megfelelő működést eredményeznek. Erre példa a program files-ba telepített DBF-es számlázó Vista-n. Más-más felhasználóval belépve a Virtualizációnak “köszönhetően” ugyanyolyan sorszámú számlákat lehetett kiállítani és virtuálisan két számlázórendszer futott egymás mellett. Ez aztán az ügyvitel!

Kicsit hosszúra sikerült írásomat hadd zárjam egy élménnyel, amely egy Vista/Win7-re telepített ügyviteli rendszer indításakor ért. Egy MsSQL szerver-t használó programot telepítettem, de mégis további két alkalmazás kérte, hogy engedjem meg nekik publikus portok kinyitását. WTF? Az egyik alkalmazás egy MySQL szerver volt, a másik pedig egy Apache böngésző. A számlázóprogramom egy nem telepített, hanem csak odamásolt, tudja az ég milyen verziószámú szolgáltatást indított el és webszerverré tette a gépem. Abba már bele se merek gondolni, hogy mi lett volna, ha már van egy webszerver a gépen, amire telepítem (mert például az a cégünk belső intranetjének kiszolgálója)?

2009-ben már kevés, ha azt mondjuk, hogy működik ez, csak X, Y és Z gombot kell egyszerre megnyomni és valami valahonnan valahova kell másolni! A technológia és innováció legyen Veletek! Az MySQL és Apache párost hagyjátok meg másnak!

Új számológép. A calc.exe megújult. Tud dátumok közt különbséget számolni, autólizing maradványértékben gondolkodni. És közben az adatokat programozói módban megjeleníteni, ha jól láttam 128bites adatok formájában is.

Beépített Sticky-notes. Soha nem bíztam a 3rd party alkalmazásokban, ezért nem volt ilyen alkalmazásom. De most lehet, hogy a saját asztalomra teszem az eddig notebookra ragasztott sárga kis cetliket. Arról nem beszélve, hogy a színét is tudom változtatni, nem számít, hogy milyet lehet kapni az OfficeDepot-ban.

Letölthető HUN. Igen, végre elékeztünk oda, hogy a Windows7 nem kerül kiadásra EN, majd HU nyelven, hanem egy-egy 40MB-os letölthető csomag segítségével a felhasználói felület magyarítható. Ki/bejelentkezés kell hozzá és a Welcome szüveg nem lesz magyar a login-kor, de minden program nyelve megváltozik. Újratelepítés nélkül. 2009-ben már ideje volt.

Pasziánsz is új. Ez is megváltozott. Félek leírni, de tényleg elhihetitek, hogy csak azért indítottam el, hogy kipróbáljam hátha a számológéppel ez is megújult. És igen.

Shield-ikon. Shield ikon kék-sárga lett. Az eddigi színes jobban tetszett, de majd ezt is megszokom.

Vezérlőpult. ControlPanel lenne a neve, de ugye a 40MB-os HUN csomag. Méginkább böngészős (vissza gomb, URL mező) lett. Tetszik.

Alkalmazások visszajelzése. Az alkalmazások az eddigieknél sokkal több információt tudnak visszaadni az operációs rendszernek. A folyamataikat jelezhetik a taskbar-on (bocsánat a tálcán, 40MB!), korábbi tevékenységeikről információt adhatnak vissza, jump list. (böngészési előzmények a Start Menüben, stb.)

A cikk bevezetője:

“A Symbol Ügyvitel sok funkcióval rendelkező, nagy tudású, professzionális számlázó program. Alkalmas forintos- és devizás számlák kiállítására, szállítólevelek, díjbekérők (pro forma) készítésére, vevői megrendelések nyilvántartására, projektek kezelésére. A részletes terméknyilvántartás korlátlan számú eladási árat, akciót, időszaki kedvezményt, terméktulajdonság megadását támogatja. Felár ellenében árajánlat készítéssel, házipénztár- és bank modullal, valamint szerződések kezelésével is kibővíthető. A Symbol Ügyvitel könnyen telepíthető, pendrive-on is hordozható, bárhol használható, mobilis szoftver. Kezelőfelülete nem csak a lehető legkorszerűbb, hanem számtalan kényelmi funkciója miatt kifejezetten felhasználóbarát is. ”

Symbol Ügyvitel-ról szóló cikk teljes változata

Jópár hónapja, aki számítógépet vásárol és a neves gyártók termékét választja vagy egyszerűen saját maga rakja össze a számítógépét, nehezen tud olyan processzort választani, amely ne lenne 64bites üzemmódra képes. A 32bit és 64bit közti átállás még jónéhány évig el fog tartani, jelenleg az a trend bizonyult tartósnak, mely szerint a processzorok belső felépítése 64bites, de a rajtuk futó operációs rendszer 32bites.

Miért így használjuk?

A számítógépek gyártói, akik OEM operációs rendszerrel telepítve értékesítik termékeiket, nem véletlenül választották ezt a kombinációt. A 64bit kihasználásához legalább 4GB ram vagy több szükséges és a teljes funkcionalitást csak olyan szerverekben lehet kihasználni, ahol 1-nél (sőt 8-nál is) több processzor végzi a dolgát. Ez egyelőre nem jellemző az asztali munkaállomásokra vagy notebookokra.

A Microsoft a Windows XP 64bites változatát nem is jelentette meg magyarul, ezzel is jelezve, hogy úgysem érdemes az operációs rendszereket egyelőre ennyire átalakítani. A szoftverek sincsenek még felkészítve rá (Office, Photoshop, Nero, stb.) Használjon mindenki 32bites XP-t, Vista-t a számítógépén, legyen az akárhány bites processzorral felszerelve.

A régi ügyviteli és számlázó rendszeremmel mi lesz?

A korábbi fejlesztőeszközökkel készült termékek (Delphi, FoxPro) hallgatólagosan működnek a Windows XP 64bites változatán is, hála a processzorok azon kiegészítésének, amely a 32 bites programok működését támogatja. Ezek az alkalmazások egy 32 bites számítógépet látnak, maximum 2GB rammal. Ezen kívül számos probléma adódik abból, hogy a szükséges szoftverkomponensek (Jet driver, ActiveX könyvtárak) nem állnak rendelkezésre 64bites verzióban.

Mi a helyzet a Symbol Ügyvitellel?

A Symbol Ügyvitel már a tervezésekor arra készült, hogy futtatható legyen 64bites operációs rendszeren is, sőt a program futtatható állományai ilyen esetben 64bites működésre optimalizáltak. Minden összetevőjének (adatbázis szerver, kliens könyvtárak) létezik 64bites változata. A telepítő a környezetnek megfelelő komponenseket telepíti és ha kell, kihasználhatja a 4GB-nál több memóriát is.

Hogy a telepítőkészlet méretét minimalizáljuk, a ritkán használt, 64bites összetevők telepítéskor az internetről töltődnek le.

A 64bites processzorokról olvasható egy részletes leírás itt: http://en.wikipedia.org/wiki/X86-64

További 64bites információk magyarul: http://www.start64.hu

A LAB oldalon megjelenő információknál több, kevésbé szakmai hirdetményeket jelenítünk meg.

Kövess minket Te is itt: SymbolTech on Twitter

Ettől még jól használható, pláne, ha már a VS2005-höz is létezett VB-ben írt makró, ami becsukja a fát. Ennek volt kezdetleges változata, amely csak 1-1 szintet csukott be. És volt, ami már rekurzívan is működött. A tegnapi napig…

Egy VS2008 biztonsági frissítés feltelepítése óta nem működik. Lenne erőforrásunk debugolni, de csak-csak van más megoldás is, mondjuk egy ingyenes Microsoft tool!

A szoftverfejlesztő cégek mindegyike pénzért adja a termékeit. Bizonyos “kultúrákban” a termék ingyenes, a támogatás, ami által a tényleges előnyt szerzed, viszont fizetős, lásd Apache, Linux, MySql. Ebből kiindulva nem is keresgéltünk nagy tudású, de mégis ingyenes, “5 éve fejlesztjük, nagyon jó” termékek irányába, hiszen semmi nincs ingyen.

És találtunk egy tool-t, amely megfelel a céljainknak, hivatalos Microsoft termék, ingyenes, gyakorlatilag egy extension, amelyet minden bizonnyal a Microsoft is használ saját berkein belül. Talán a létrejötte is annak köszönhető, hogy valamelyik fejlesztő majdnem fellázadt a saját eszközük ellen.

Letölthető erről az oldalról.

PowerCommands for Visual Studio 2008

KeyValue párokat szerettünk volna tárolni, Key szerint keresni, Value-kat kinyerni. Jött az ötlet Dictionary<Key, Value>. Specifikáció szerint viszont ennek egy Key-je egyszer szerepelhet a gyűjteményben, minden további értékeadás felülírja az előzőt. Azaz a Key-eknek egyedinek kell lenniük. Pár éve már sejtettük ezt.

Nekünk viszont irányítószámokat kell tárolnunk és hála a magyar közigazgatásnak nem minden település kap saját számot, előfordul, hogy egynél több település fut ugyanolyan “kód” (irányítószám) alatt. Az ötlet, mely szerint Dictionary<int, List<string>> adatszerkezetbe rakjuk az információkat, jónak tűnt, de hátha ezt már valaki kidolgozta.

És ekkor találtuk meg többedszerre az NGenerics családot, amely számos, C#-ból kimaradt, bonyolultságuk és sokrétűségük miatt speciális tudást igénylő generikus típussal engedi bővíteni a készletet. Ennek HashList osztályát használtuk, amely az alábbi nyelvi konstrukcióban engedte feltölteni ZIP (IRSZ) törzsünket.

citylist.Add(2066, "Szár");
citylist.Add(2066, "Újbarok");

Az osztálygyűjtemény nagyon nagy. Szerettük volna kerülni az irányítószám kezelés miatt akár 30-40 másodperccel is megnövekedett fordítási időt. Ezért csak bizonyos részeket használtunk fel belőle. Matematikusok tervezték, tele van interfésszel, látogató termintával és minden szépséggel, emiatt az általunk használt osztályhoz a következő fájlok mindegyikére szükség volt:

HashList.cs
IVisitable.cs
IVisitableCollection.cs
IVisitableDictionary.cs
IVisitor.cs
VisitableHashtable.cs

Projektünk sikeresen kiadásra került, a projektben résztvevő személyek mindegyike sikeresnek értékelte a megoldást. Köszönjük NGenerics!

Az üzletkötőink, ügyviteli szakembereink sem értették, hogy mit akarunk ezzel, miért nem jó szerintünk a sima kis lista. Csak a végén értették meg, hogy mit is akartunk.

Ezt:

Hogyan is jött létre ez a – joggal innovációnak nevezhető – modul, amely minden ügyviteli termékünkben megjelenik és sok pozitív felhasználói visszajelzést indukált? A bizonylatok és egyéb adatelemek közti reláció, adatkapcsolat adott, erre épül maga az alkalmazás. No de ezt hogy jelenítsük meg egy gráfban, hogy  felhasználó is kedvet kapjon és használja?

Csapatunk 3 napon keresztül tervezett, brainstormingolt. Számos ötlet jelent meg a fejekben és a nagy prezentációs falon, ezen ötletek kb. 50% bele is került a megvalósult rendszerbe. Az elvárások tisztázása után kezdődött a fejlesztés. Programnyelv C#, ennek GDI és GDI+ lehetőségei kiváló kiaknázásra való területet jelentettek számunkra.

Lépések:

• Építsünk egy saját controlt.
• Bármilyen megjelenni kívánó objektum feleljen megy egy IDiagramDrawItem interfésznek, amely egy metódust definiál void Draw() és információt szolgáltat arról, hogy melyik rétegben jelenik meg a kirajzolandó adatelem int ZOrder { get; }.
• Rajzolás megvalósítása
  • override Paint()
  • void ClearAndDrawBackground()
  • void SortByZOrder()
  • foreach(... item.Draw()...)

Már a tervezési fázisban is láthatóvá vált, hogy lesznek optimalizálási kérdések, problémák, amelyek a témakör izgalmasabb részét jelentik.

Repository, hogy ne szaggasson a kép. Egyedileg rajzoló eljárások rákfenéje a sok GDI objektum, amely memóriában és időben is költséges. A memóriabeli költségeket, mivel IDisposasble, meg lehet oldani, de sokáig tart minden OnPaintben Font-os, Pen-t és Brush-t létrehozni. Erre született megoldásként, hogy a diagram ezeket publikálja, tárolja, elérhetővé teszi eg példányban, egy alkalommal való létrehozással a rajzolni képes objektumok felé. Performancia mérést végeztünk, egy átlagos diagram 740 alkalommal tud kirajzolódni egy másodperc alatt. Nem rossz, megfelel.

GraphicsPath, hogy lekerekített sarkú legyen a doboz. A C# GDI+ lehetőséget kínál arra, hogy vonalak és görbék segítségével egy “utat” hozzunk létre, amely felhasználható rajzolásra és kitöltésre egyaránt. Megvalósítottuk. Mivel ez is költséges, minden objektum a mérete alapján (amely nem állítható megjelenítés közben) első felhasználáskor (late-init) létrehozza a GraphicsPath objektumot.

LinearGradientBrush, hogy átmenetes legyen a dobozok háttere. A legnagyobb kihívás a színátmenetes doboz volt, amely egy pontoktól függő GradientBrush lett. Ennek szintén elég egy példányban léteznie, de a doboz pozíciójának függvényében kell felparaméterezni. A (rendszer által) mozgatható dobozok pedig ezen tulajdonságukat gyakran változtatják, de erre is született megoldás: late-init és re-init-by-move.

És ekkor még nem ért véget a gondolkodás, a dobozok esztétikus elhelyezésének algoritmusa felér egy komolyabb diplomamunka témakörével, erről egy következő cikkben.