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.

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.

Ingyenes megoldás

Adatbázis műveleteink optimalizáltsága miatt egy 2/2 Mbit-es kapcsolaton működő szerver (amely lehet Linux is) alkalmas a rendszer kiszolgálására 15 munkaállomásig. A munkaállomások számának növekedésével felfelé skálázni kell a kapcsolat sebességét.

A kapcsolat nyilvánvalóan publikus, bárki számára elérhető, emiatt lehet hozzá egyszerűen csatlakozni. De nézzük meg, milyen információkat kell tudnunk ahhoz, hogy a kapcsolat létrejöhessen. Szükség van tehát:

• IP címre vagy host névre
• port számra (alapértelmezett 3050 helyett)
• adatbázisfájl fizikai helyének megadására

Az első kettő a mai számítógépes teljesítménnyel pár óra alatt kideríthető, ha máshogy nem, próbálkozással. A legutolsó azonban olyan mértékű kombinációs lehetőséget jelent, hogy számítógép legyen a talpán, aki ezt kitalálja. Nézzük, milyen példák lehetnek:

Windows-on: c:\SymbolUgyvitelDB\kiscegem\db1\default.database

Linux-on: /var/lib/database/Symbol/CoMPaNY_1580/default.database

Ez utóbbi még betűnagyság érzékeny is. Matematikus kollégák véleménye szerint a lehetőségek száma elég nagy ahhoz, hogy valaki ezt ne találhassa ki. Konkrétan 26*2+10+5 a 49-ik hatványon, ami egy 3-as és mögötte 89 (!!!) darab nulla. Szemléltetve ez ennyi:

1 :

30000000000000000000000000000

000000000000000000000000000000

0000000000000000000000000000000

Azaz kicsi az esélye, hogy valaki el tudja találni, hol az adatbázisom. Ezt még egy kicsit erősíteni lehet, ha a helyet havonta cseréljük.

Ingyenes, előkészületet igénylő megoldás

Továbbra is ingyenes, de felkészültséget igénylő megoldás a kézzel kiépített SSL tunnel. Ezt például a putty programmal is megtehetjük. Ilyenkor az előző biztonságot növeljük azzal, hogy titkosított csatornán keresztül közlekednek az adatok. A csatorna kiépítése ilyenkor a felhasználó feladata.

Vállalati meegoldás, VPN

Egy igazi megoldás, amely pénzbe kerül a Virtual Private Network. Ez egy virtuálisan kiépített helyi hálózat, amely a számítógépet úgy emulálja, mintha a számítógép az irodában lenne. Ehhez valamilyen VPN szerverre szükség van.

…nevet még nem írhatok

Egy nemsokára megszülető megoldásunk – amelynek van már neve, de nem publikus – célja ponz az lesz, hogy biztonságos és stabil infrastruktúrális megoldást biztosítsunk ügyfeleinknek. Erről majd később.

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.

Nem fatális, banális hibát ejtettünk. A verzió történet azt a célt szolgálná, hogy minden felhasználó információt kapjon a változásokról. Sok partnerünknél a rendszergazda csak akkor telepíti az új verziót (pedig pofon egyszerű az upgrade), ha van benne valami fontos vagy súlyos javítás.

Legutolsó verziónkban a verzió történet ablak nem jelent meg. A működése pofon egyszerű, nem is tudtuk mire vélni a hibát, majd 4 perc alatt megláttuk a hiba okát: a kiadás előtt pár perccel, amikor a helyesírást még egyszer megnézzük végső lépésként, egy & jelet tettek a kollégák az XML fájlba (Drag&Drop), amely a changelog adatait tartalmazza. Az XML parser működése ismert, de nem programozók szerkesztik a changelog-ot. Fene gondolta volna…

Új verziónk első hibabejegyzése az lesz, hogy “Nem jelent meg a verzió történet”. Addig is partnereink megértését kérjük a hiba miatt – és javasoljuk nekik a http://mit-hogyan.symboltech.hu/2011/01/1-66-48-4030-as-verzio-ujdonsagai/ linkeket, ahol ugyanazokat az információkat láthatják.

A fenti bejegyzés nem is készülhetett volna el, ha a Symbol Ügyvitel nem tartalmaz havi szinten 20-30 újdonságot, változást. Ennek ez az ára

Verziószámaink felépítése a következő (x.y.z.w)

X: Főverzió száma, amely jelenleg 1. Nagy szoftver ugrást tervezünk jövő év közepén (bár eddig sem ugrottunk kicsiket), akkor fogjuk kettesre módosítani.

Y: Alverzió, amely a főverzión belüli újdonságokat tartalmazza. Azok a cégek, akik részt vesznek partnerprogramunkban és már a kiadás előtti verziókat is megkapják, általában kapnak páratlan verziót is, de a hivatalos verzióink mindig párosak (1.60, 1.62, 1.64 nemsokára)

Z: Adatbázis verziószáma. Amikor olyan jellegű változtatás történik (az utolsó egy évben gyakran), amikor szükség van új adatbázis működésre, a számot változtatva az adatbázis automatikusan frissül.

W: Ez a cikk fő témája, a 2001. jan.1 óta eltelt napok száma. Ez a szám egyértelműen azonosít egy program kiadást, azaz a kinyomtatott számla alján látható szám alapján tudjuk, hogy melyik napok adtuk ki azt a verziót, amivel a számlát nyomtatták.

4000 napja élünk a 21. században, a Symbol Ügyvitellel pedig lehetősége van arra, hogy 21. századi ügyviteli rendszert használjon.

Minden kérdésére készségesen válaszolt Balázs Csaba fejlesztési vezetőnk, aki talán a legkompetensebb a témában.

FP: Miért ilyen gyakran?
BCS: Röviden? Mert képesek vagyunk rá.

FP: És kicsit hosszabban?
BCS: Van mit és tudjuk, hogy hogyan. Általában 3-4 heti gyakorisággal gyűlik össze annyi újdonság, hogy érdemes legyen egy csomagként megjelentetni. Próbálkoztunk már kéthavi kiadással, de olyan mennyiségű volt az újdonság, hogy két nyílt napon tudtuk csak bemutatni a programot. Pontosítok, a program újdonságait.

FP: Ennyi javítanivaló van?
BCS: Újdonságokat említettem az előbb is. Újdonságok teszik ki a fejlesztés 75-80%-át. Van benne javítás is, ezek általában apróbb felhasználói visszajelzések, nem komoly hibák. És igen, több, mint 3/4-e újdonság. Ezek vagy a programunk újdonságai, vagy valóban ügyviteli újdonságok.

FP: Valóban folyamatos a fejlesztés?
BCS: A jó szoftver sosincs kész. Ahhoz a programhoz nem készülnek új fejlesztések, amelyet nem használnak. Nálunk, a folyamatos használatból adódóan mindig merülnek fel igények.

FP: És ezeket a programba beépítitek?
BCS: Mindig mosolyogni szoktam a felhasználói igényeken, persze nem gúnyosan. Elmondhatjuk, hogy nagyon ritka a valóban új igény. A programunk alapja egy négy generációt megélt ügyviteli rendszer, amelyet cégünk egy akvizíció során már magáénak tudhat. Ezen a négy verzión már nagyon sokat tapasztaltunk. Legyen szó általános igényekről vagy speciális üzleti folyamatról, a nagy részük már tervbe van véve nálunk. Azaz nemsokára a polcról tudjuk kiszolgálni az olyan igényeket is, mint a munkaruha kihordási idő nyilvántartása. Tavaly év végén 2011.decemberéig volt meg a fejlesztéi tervünk, van mit csinálni.

FP: És most?
BCS: 2012. Karácsonya is munkával fog telni (nevet)

FP: Érdemes akkor még várnom 24 hónapot?
BCS: Dehogy! A termékünk a maga nemében már megjelenése után jól állta a sarat, mert szükség volt valami modern rendszerre. Az akkori rendszerek 6-10 éve készültek, ebből adódóan legalább 7-11 éves technológiával. Felkevertük az állóvizet. A termék egy évvel a megjelenése után jól szerepel, számos funkciójában lekörözte versenytársait.

FP: De ha még nálatok is vannak fejlesztési tervek, akkor más, 6-8 éves termékekben ezek miért nem találhatóak meg?
BCS: Megtalálhatóak. A maguk módján. Minden rendes ügyviteli szoftver megvalósítja az évek során összegyűlt funkciókat, de azok vagy ügyfél igények alapján készültek – ügyviteli szakértelem nélkül – vagy csak fejlesztői gondolatokat figyelembe véve. Ez pedig a valóságtól messze van. De egy még fontosabbat kiemelnék, a precizitást. Minden dolgot több féle módon megvalósíthatunk, de kevés termék van, ami a felhasználói kényelmet és a legapróbb igényt is megvalósítja. Mi erre törekszünk, azaz hogy legyen élmény az ügyvitel!

FP: Mondasz erre egy példát?
BCS: Jó példa a gyári szám kezelés. Minden szoftverterméknek része, de vajon használható-e? Nálunk nem az a cél, hogy a gyári számok a számlán megjelenjenek, hanem valóban ki tudjam mutatni, hogy milyen gyári szám hányszor és mikor fordult meg nálam. És ezt még Symbol-osan megspékeljük azzal, hogy termékenként a gyári szám bevitele maszkolható. Azaz mobiltelefonoknál nem tudunk nem 15 jegyű IMEI számot beírni, nem tudjuk elgépelni.

FP: Azt hiszem, erre mondjátok, hogy innovatív
BCS: Meg az egészre, amit itt csinálunk. 80% gondolkodás, 20% munka.

FP: Elején említetted, hogy tudjátok a hogyant is. A konkurencia nem tudja?
BCS: Pontosítsunk. Nem szeretem a konkurencia szót. Azt sugallja, hogy egy van, aki a legjobb és a végén is csak egy maradhat. Inkább használjuk a versenytárs szót, hiszen verseny azért van.

FP: Szóval, a versenytársak nem ismerik a hogyant?
BCS: Mindenki ismeri a saját hogyanját. A miénk lehetővé teszi, hogy 3-4 hetente kiadjunk egy verziót, amely az ország több száz számítógépén tökéletesen frissül – még soha nem volt ezzel kapcsolatban hiba – és megoldást szállít a problémákra. Sokáig terveztük a saját rendszerünket, a cél pont az volt, hogy könnyen tudjunk hozzáilleszteni, könnyen lehessen bővíteni.

FP: Említetted, hogy problémák vannak…
BCS: Mindenkinek, Neked is, ha valami nem működik vagy nem elég hatékony, akkor az probléma. A remek ötleteidet rajtad kívül álló okok miatt nem tudod megvalósítani, a fránya számítógép vagy a számlatömb a szűk keresztmetszet. Ezek a problémák, amikre megoldást nyújtunk. Valódi megoldásokat.

FP: Mik a jövőbeni tervek?
BCS: Decemberben is marad a 3 heti gyakoriság, sőt egy kicsit bele is húzunk, két kiadás is lesz. Amíg a többiek pihennek, addig mi dolgozunk, mert az ügyvitel a szenvedélyünk. (nevet) Ismét 42 újdonságra jut 13 javítás, módosítás, lesz benne iparági újdonság is, mint amilyen a Symboogle volt. De erről többet majd a szoftverkiadáskor.

FP: 2012 decemberében folytatjuk a beszélgetést?
BCS: Ismételjük meg gyakrabban! Büszkék vagyunk a munkánkra, ezt kívánjuk továbbra is csinálni. Nagyon jó visszajelzések érkeznek. A kedvencem a: “Hol voltak maguk idáig???“

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();
        }
    }
}

A Symbol LAB több változat eldobása után egy felhasználói élményekben és főleg operatív használhatóságban élenjáró megoldással örvendezteti meg jelenlegi és jövőbeni ügyfeleit.

A végleges fejlesztés sok munkaórát igényel még, várhatóan jövő év első heteiben jelenik meg, de egy pár képernyőképpel már most is szolgálhatunk, a tervezési fázis állapotáról.

A képlopó program nem volt képes az egérkurzort a képernyővel együtt menteni, ezért nem látható. De várjuk csak ki a végét! Nem csak sima egérkurzorról lesz szó… Fogd és vidd újraTÖltve!

Valljuk be, sok bosszúságot okozott egy fájl drag&drop-pal való mozgatása. vagy lemásolódott vagy átmozgatódott vagy parancsikon készült hozzá a leglehetetlenebb helyeken, az asztalon vagy a dokumentumok mappában. Ezért inkább nem használtuk.

De egy programon belül az adatok mozgatásának kézenfekvő módszere. Lenne. Ha a böngészők nem lehetetlenítették volna el a technikát. Eddig egy logikus használati módját láttam a böngészőben. LogMeIn parancsikont helyezhettem az asztalomra. Persze az Internet Explorer 3 kérdést tett fel előtte, hogy valóban lemondtam-e az életemről, stb.

Külön csoportot hoztunk létre, hogy a drag&drop-ot felélesszük. Még keressük a megfelelően kézreálló és informatív megoldást, hogy a felhasználó tudja, mi fog történni, ha elengedi az adatokat (akarom mondani elengedi az egég bal gombját). Eddig a proof-of-concept tanulmánymunkáink pozitív sikerről számoltak be. Nemsokára be fogjuk vezetni a darg&drop széles körű használat, de a teljes kidolgozottsághoz még idő kell.

A http://lab.symboltech.hu/2010/09/telepites-helyett-parancssori-hasznalat/ link alatt olvasható cikkben leírtuk, miként lehet telepítés nélkül futtatni hálózaos programunkat. Ezeket az információkat felhasználva egy további telepítési módot mutatunk be.

1. A cikkben szereplő módon csomagoljuk ki az EXE fájlt egy megosztott meghajtóra.

2. Készítsünk egy parancsikont, amely a /server opcióval a megfelelő helyre mutat. A megosztott meghajtóra helyezhetjük a parancsikont is.

2/a. Linux-os megosztás esetén (Samba) az EXE neve kezdődhet ponttal is, így láthatatlan lesz a felhasználók számára.

3. Minden felhasználó a megosztott mappában lévő LNK parancsikon fájlra kattintva elérheti a Symbol Ügyvitel programot.

Előnyök:

A. A rendszergazda központilag tudja cserélni a futtatható állományt (symbolugyvitelsetup.exe /x)

B. Mindenki ugyanarra az adatbázisra fog mutatni.

C. Senki nem fogja “véletlenül” frissíteni a rendszert.

További lehetőség, ha a felhasználó azonosítás a Windows bejelentkezéssel történik, akkor mindenki haszálhatja a központi parancsikont, de mégis jelszó beírása nélkül indul a Symbol Ügyvitel (korlátlan felhasználó definiálható!).

Cégek rendszergazdái, főleg azok, akik több céget kezelnek vagy több cégben vezető beosztást betöltő személyek kedvence lehet az a telepítési mód, amikor magát a telepítőkészletet nem is telepítjük, csak az EXE-t másoljuk egy megfelelő helyre és parancsikont hozunk létre hozzá kézzel. Ennek előnye, hogy különböző parancsikonok különböző adatbázis szerverekre tudnak mutatni.

1. lépés, a futtatható állomány kicsomagolása.

Telepítőink új változatai (1.58-tól) parancssori paraméterrel is meghívhatóak. A /x és /xv kapcsolók a telepítés/frissítés helyett az EXE kicsomagolását ajánlják fel (/xv esetén a verziószámmal együtt). Így a felhasználó tetszőleges helyre mentheti az alkalmazást, anélkül, hogy telepítenie kelljen.

A SymbolUgyvitel.EXE önállóan képes hálózatos működésre, nem kell telepíteni, nem szükséges hozzá semmilyen DLL (Firebirdclient.dll sem), alapértelmezetten telepített Windows XP/Vista/7 alkalmas a program futtatására.

2. lépés, a parancsikon létrehozása.

Hozzunk létre egy vagy több parancsikont, amelyeknél a /server=<szervernév>:<mappa> formátumban meg tudjuk adni, hogy hova csatlakozzon. Opcionálisan a /firstonly kapcsoló használatával az első adatbázist használja, nem is keres többet.

Például LINUX szerverhez csatlakozva: symbolugyvitel.exe /server=center.cegnev.hu:/opt/db/symbolugyvitel /firstonly

Mivel ilyen esetben a program nem kerül telepítésre, a telepítő alkalmazás futtatása új telepítésként értelmezi a működését. Érdemes az automatikus frissítést kikapcsolni és az hírlevélből értesülhet a felhasználó arról, hogy új verzió jelent meg.

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.

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

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.

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!

Azok az ügyviteli rendszerek, amelyek a megszokott, összekattintgatós módszerrel készültek (“Programozzunk könnyen gyorsan Clipperben/Delphiben”), egy számítógépen tökéletesen futnak. A hálózatos működés is megvalósult, bár itt, amig valaki számlát állít ki, addig a többiek néha várakoznak. 2-3 éves fejlesztés után (miközben az ügyfelek jelezék, hogy mi hol nem megy hálózatban) minden flottul ment. A Windows7 hálózati kezelése kicsit felboríthatja a terveket, de ha XP-t használnak, akkor működik a dolog. Amig van kábel a szerver és a gép között. WIFI-n a programok nem működnek, mert annyira gyakran és olyan sok adat utazik (utazna) a hálózaton.

Cégünk egy emberévig (fejlesztés mértékegysége), gyakorlatban 3 ember, 4 hónapig fejlesztette azt az adatbáziskezelési technológiát, amely WIFI hálózaton is alkalmas a program működtetésére. Az unalmas részleteket nélkülözve annyit érdemes tudni, hogy a bizonylatok kiállításakor szinte minden információ rendelkezésre áll, hogy a munkát elvégezhessük, nincs szükség állandó kapcsolatra.

Emiatt Symbol Ügyvitel termékünk dobozos változatának csomagolásán is ott virít a felirat:

“Vezeték nélküli hálózaton is használható“.

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/

(Symbol Ügyvitel is FB 2.1 alapokon fut, ennek architektúrális okai vannak, a Delphi-s indíttatás elenyésző – a szerk.)

És közben magát nagyon jól pozicionálva megjelent a VistaDB4. http://www.vistadb.net/vistadb

Talán régebben választották neki a nevet, mint ahogy a Microsoft operációs rendszere megszületett.

Mit is tud általában?

Beépített. Ez azt jelenti, hogy nem kell szervert telepíteni, minden művelet, megoldás az applikációban kap helyet.

T-SQL-t érti. Az MsSQL tárolt eljárás nyelvét egy az egyben futattni képes, sőt a CLR-t is fel tudja használni.

MSSQL funkciók. Számos olyan funkció beépítésre került, amely a “nagy” MsSQL-nek része, de a CE (compact edition) változat nem tatalmazza: triggerek, tárolt eljárások. Így alternatívája lehet az MSDE/MsSQL-CE-nek.

Mi egyebet kapunk?

• Visual Studio integráció
• Adatmodellező eszköz
• .NET framework teljes integráció

 Mibe kerül ez nekünk?

• Természetesen ára van, mert semmi nincs ingyen.
• $59 az alapértelmezett, Light csomag, ebben sajnos kevés a funkcionalitás.
• $359 az ideális választás /fejlesztő.
• A runtime komponensek felhasználókhoz való eljuttatása természetesen ingyenes.

Jó választás, jó a verseny, egy kiforrott alternatíva lehetősége a korábbiak mellett, amelyek már kinövik saját méretüket. Lásd MsSQL 200MB-os telepítő!

VistaDB

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

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

Lássunk egy ilyen statisztikát nálunk:

• Táblák: 73
• Mezők: 842
• Indexek: 103
• Egyediségi megszorítások: 24
• Idegen kulcsok: 221
• Tárolt eljárások: 26
• Triggerek: 23
• Kivételek: 9

“És ez még csak az egyik projektünk” lehetne hallani 10 évvel ezelőtt. Az adatbázisok normalizálása miatt a táblák száma már nem releváns információ. Persze (m)értéket képvisel két olyan rendszer összehasonlításakor, amikor egy 5 táblás és egy 470 táblás adatbázis találkozik.

De mi lehet akkor a modern kori mérőszám az üzleti logika mértékére? Nálunk a generált kód mennyisége az. Lássuk, mi mennyi:

• Sorok száma: 171.591 sor
• Karakterek száma: 5.784.477 betű
• Fájl bájtok: 13.779.968 bájt

Persze nem kézzel gépeltük ezt be. A kód generált, a saját üzleti logika erre épül. Annak mérete pedig titok…

Vajon az ok/mégse koncepciót a lusta programozók találták ki?
Mert miről is szól ez a dolog?! Az ember kitölt egy űrlapot, ami mondjuk az alkalmazottak adatait tartalmazza. Miután ezt kitöltöttük bezárjuk az űrlapot (Mentés/Ok gomb). Na most ha meg akarjuk nézni az adatlapot, akkor megnyitjuk a listából egy kivetítő ablakon, amit módosítani nem lehet. Bezárni a jól ismert X gombbal lehet. Ha módosítani szeretnénk, akkor megnyitjuk szerkesztésre. Majd bezárjuk a módosított űrlapot (Mentés/Ok gomb).

Tehát, ha új alkalmazottat veszünk fel és nincs Mentés vagy Ok gomb, akkor bezáráskor csak is akkor mentjük el, ha ki lett valami töltve. (Így nem kell Ok vagy Mentés gomb) Ha megnézésre nyitjuk meg, akkor kivetítő ablak. (csak x gombunk van úgyis) Ha módosítani szeretnénk, akkor megnyitjuk szerkesztésre az űrlapot és bezáráskor csak akkor mentjük el, ha változott. (Így sem kell Mentés vagy Ok gomb)

Viszont van egy hatalmas probléma, amit ezzel a módszerrel nem lehet kivédeni: az emberi tényező! Mert az ember egy olyan fajta, aki tévedni szokott. Ezért, megnyithat és beleszerkeszthet egy másik alkalmazott adatlapjába és csak módosítás közben jön rá -> Mégse gomb. Vagy rosszabb esetben kitöröl egy olyan mezőt, amit nem kellett volna, és nem emlékszik mi volt benne -> Mégse gomb, majd újra megnyit.

És mi volt ennek a gondolat mentenek a kiindulópontja? A Safari nevű böngésző beállítások “űrlapja”:

A kérdéssel és a koncepció elgondolásával jövőben projektjeinkben foglalkozni fogunk.

Kb. 10 évvel ezelőtt jelentek meg azok az ügyviteli alkalmazások, amelyek hálózatban is működtek és kihasználták az adatbázis szerverek adta lehetőségeket. (Sajnos még jelenleg is eladósorban vannak olyan termékek, amelyek hálózatosak ugyan, de a működésük sokkal inkább hasonlít egy közös mappában megosztott, egyszerre egy felhasználó által írható Excel fájlra!). A fejlesztőcsapatok szinte mindegyike az MsSql szervert választotta, akkor még a 7.0-s változatot. Azóta előreléptek és az egyik legnagyobb (árbevétel szempontból, hála a magas követési díjaknak) ügyviteli gyártó is nemrég tért ár MsSql 2005-re. Még 10 évvel ezelőtt indultak el ezen az úton.

Korábban plusz költséget jelentett, hogy egy cég Windows alapú szervert állítson be ügyvitele és egyéb rendszere működtetéséhez. Gyakran ajánlották, hogy inkább valamelyik kliens munkaállomáson kerüljön telepítésre a szerver. Gondolom, nem kell mondani, hogy ezáltal annak a munkaállomásnak állandóan bekapcsolva kell lennie (vagy reggel és este kötött sorrendben kell a számítógépeket elindítani) és az adatvesztés veszélye többszörösen jelentkezik, hiszen egy felhasználói számítógép könnyebben fertőződik meg vírussal vagy megy tönkre, mint egy szerver célokat szolgáló számítógép.

Akkor is és most is jellemző, hogy “Úgyis van egy Windows szerveretek, hiszen most alapítottátok a céget!” jellegű mondatok hangzanak el, előfeltétellel élnek arra vonatkozóan, hogy milyen egy cég informatikai felépítése.

Az ilyen jellegű architektúrális kiépítés közel kétszeresése növelheti a bevezetés költségét, hiszen külön számítógépen, speciális szerver operációs rendszert kell üzemeltetni. (Itt ismét felejtsük el azt a félmegoldást, mely szerint valamelyik munkaállomás lesz a szerver!) Ilyen magas bevezetési költségek szembeötlőek, ha az ügyviteli piac dobozos termékeit 5 (esetleg 6) számjegyű összegekből kívánjuk megvásárolni.

Akkor is és most is jellemző, hogy valamilyen ingyenes megoldással valósítják meg a szerver számítógépek szoftveres szintjét. Komplett megoldások vannak fájlrendszer, domain-controller, levelező szolgáltatások megvalósítására Linux operációs rendszerrel.

De ezen nem futnak az eddigi ügyviteli rendszerekhez szükséges szerver komponensek!

A Symbol Ügyvitel a pendrive-on való egygépes működéstől kezdve, az egygépes, de telepített verzión át, a hálózatos működésig olyan adatbázis szervert használ, amely Windows-on kívül számos operációs rendszerre engedi telepíteni az adatbázis kiszolgálót. A következő operációs rendszereken van Önnek lehetősége kialakítani az adatbázis-környezetet:

• Linux x86
• Linux x86 (+NPTL)
• Linux AMD64
• MacOSX Intelx86
• MacOSX Intelx64
• MacOSX Motorola PowerPC
• Solaris 10 i386
• Solaris 10 AMD64+EMT64
• Windows x86
• Windows x64 

Linux esetében az ajánlott disztribúciók:

• Red Hat Enterprise Linux
• Suse Linux
• Mandrake and Mandriva
• Ubuntu Server
• Debian
• Slackware
• CentOS
• Gentoo

Windows esetében az ajánlott generációk:

• Windows XP 32/64
• Windows Vista 32/64
• Windows 7
• Windows Server 2003
• Windows Server 2008
• Windows Server 2010

A lehetőségek sokszínűségével Ön időt és pénzt takaríthat meg!

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

Hogy is működik?

A Delphi, mint fordítóprogram tartalmazza a fordításkor felhasznált bináris részek (ami miatt egy üres Delphi alkalmazás kb. 320kB) forráskódját is. (Ezt gyakran a programozók ki is szokták használni, például amikor az Igen/Nem kérdést feltevő ablakon nem a YES/NO feliratokat akarják látni). A vírus ezen forrásfájlok közül a SysConst.pas fájlt átírja, kibővíti, majd rögtön le is fordítja a gépen lévő Delphi-vel és .DCU állományt állít elő belőle. Bármilyen lefordított EXE, akár egy piaci termék, akár egy cég belső használatára szánt terméke tartalmazza a vírust és annak terjedéséhez minden rendelkezésre áll. Ha van a gépen Delphi.

Vesézzük ki egy kicsit, hogy is tud ténylegesen terjedni?

Valamelyik Delphi-vel foglalkozó szoftverfejlesztő cég (Magyarországon sok ilyen van) feltelepíti a konkurrens cég termékét, amely vírusos. Ezek után az ő termékei is vírusosak lesznek. Ilyen pofon egyszerű?

Mikor nem tud terjedni a vírus?

A fenti példa azonban túl speciális. Cégen belül általában a vírus terjedése meg kell, hogy álljon a fejlesztői gépeken, sőt azok között sem tud könnyen terjedni. Általában a fejlesztett programokat forrásfájlokból fordítja le egy fejlesztő. Így az EXE-k nem cserélődnek fejlesztők között. A cég többi munkatársa, akik EXE-ket kap (telepítő készlet, tesztelés, értékesítés, terméktámogatás) pedig általában nem birtokol Delphi-t a gépén.

Ahogy mi gondoljuk…

A korábban írtak szerint a terjedés egyik módja a kis szoftverfejelsztő cégek, akik egymás konkurrens termékeit a fejlesztőkkel próbáltatják ki, táptalajd adva a vírusnak. A másik terjedési mód, ha a Delphi-t gyártó cég teszi közzé a fejlesztőeszköz egy vírusos példányát. A legvalószínübb azonban, hogy valamilyen “Harmadik gyártó (3rd party)” eszközének telepítése során kerül rá a fejlesztői gépre a vírusos tool. De a terjedésnek itt is meg kellene szakadnia. Mégsem így történik.

Néhány technikai adat, félelemkeltés helyett

Szükséges Delphi verziók: D4, D5, D6 vagy D7. BDS vagy Delphi for .NET nem alkalmas erre.

Csak koncepció: A vírus kárt nem okoz, a terjedés módszerének igazolására készült.

Magyarországon csak egy: Hazákban állítólag csak egy helyen jelent meg, és mivel terjedése lassú, nem várható nagy fertőzés.

Víruskeresők már ismerik: Pár napja a víruskeresők már felismerik a kártékony kódot. Mindezt abban a pillanatban, amikor a fejlesztő az EXE-t előállítja. Pontosabban amikor nem állítja elő, mert a víruskereső karanténba zárja azt.

Microsoft .NET: A .NET-re a vírus veszélytelen, a közös kódrészletek mind az operációs rendszer részei (illetve a futtatókörnyezet részei), ilyen jellegű kódelhelyezésre nincs lehetőség.

Cégünk termékei a fenti jellemzők miatt nem tartalmazhatják a vírust

Évekkel ezelőtt nem értettük, hogy miért “éri meg” egy nem operációs rendszerbeli programmal elváltoztatni azt a kinézetet, amit nagy cégek verejtékes munkával összeraktak. De már tudjuk, hogy mindenki egy kicsit egyedit szeretne, kicsit szeretné a sajátjának érezni a számítógépet abban a 8 órában, amig előtte ül.

Pár hónappal ezelőtt ezért határoztuk el, hogy minden rendszerünkben a felhasználó testreszabhatja a kinézetet. Kicserélheti a háttérképet, beillesztheti a háttérbe gyermekét, kutyáját vagy akár ellenségét…

További képernyőket nézhetünk meg ide kattintva!

Ezen kívül pedig választhat számos előredefiniált kinézet közül. Lássuk, mit láthatunk!

MacOS

“Új hullám”

A Sötét iroda bűvöletében

Mi mindenből lehet választani…

Nemsokára megjelenik Windows7 (seven) operációs rendszert idéző kinézetünk is…

http://blogs.sun.com/GullFOSS/entry/prototyping_a_new_ui_july

Ez csak prototípus, nem végleges, ebben a formájában még nem felhasználóbarát. De emlékeztet az MS Office hasonló célú eszköztárára. Számos felhasználó már aggályát fejezte ki, hogy “ez egy gyilkos tulajdonság”. De ha a Sun is belemegy a GUI játékba, akkor nem lehet annyira rossz az elképzelés. Mivel a funkció csak 6-os JAVA verzióval érhető el, nem tudjuk, hogy mennyire lesz a Java keretrendszer része a ribbon. Ha a Java része lesz, akkor minden Microsoft alkalmazás felkötheti a gatyáját, hiszen robbanásszerűen fognak elterjedni az ilyen Java-s alkalmazások. Már ha a felhasználók nem aggályoskodnak tovább…

Közben a Microsoft az Office 2010 termékismertetőjében már a Ribbon továbbfejlesztéséről beszélt, néhány képpel szeretnénk is bemutatni, mire is gondoltak és milyen lesz a Ribbon v2.0.

Felhasználóink már értesülhettek róla, hogy cégünk is adoptálja a v2.0-ás ribbon funkciókat és termékeink ősszel megjelenő verzióiban követjük a trendet, amit elkezdtünk: http://www.symboltech.hu/features/szalag/ 

Mindenki nagyon várja. Marketingre sokat költ a Microsoft. A fejlesztői portálok tele vannak vele, mert remek eszköz. Nem a megjelenítést szolgálja, azaz nem GUI. Mindenki használja. Mindenki meg van vele elégedve. Mindenki szidja. Mindenki mondja, hogy nem baj, a következő releaseben megoldják. Nagyon gyorsan, akár félévente jön ki belőle új release. Adatbázissal kapcsolatos. Adatbázist érünk el vele.

Igen, kitalálhattátok, hogy EntityFramework. Témánál vagyunk.

Megjelent a 4.0 béta és az alábbi bejegyzést döbbenten olvastam. Itt kell tartani egy termék 4.0-s verziójával? Ezek a nagy előrelépések a 3.0-hoz képest? A cikk itt olvasható.

Nézzük megy egy kicsit jobban, mire is gondoltam, amikor a döbbenet szót használtam. Kollégáim már tudják mire gondolok, de tudja meg más is!

• Egy ilyen készültségi szinten lévő projektben kell olyan optimalizációs lépéseket megtenni, minthogy nem hoz le minden oszlopot egy subselect, csak ami kell nekünk?
• COUNT(1) nyelvi elem direkt használata, amikor az a célszerű.
• A legnagyobb, az IN SELECT. Komolyan gondolja valaki, hogy a 4.0-ig kell várni egy kliens oldalon is jelenlévő adatstruktúra (tömb) és SQL oldalon is elérhető nyelvi konstrukció (WHERE xx IN (x,y,z…)) összekapcsolására?

Igen, emiatt van tele minden fejlesztői portál olyan jellegű kérdésekkel, hogy “Hogy tudok két táblát összekapcsolni LINQ-ban, EntityFramework-kel?” Ezek szerint nem segítség, hanem csak egy hozzászoktató eszköz, ami függőséget okoz és ha függő lettél, akkor minden fejlesztéshez a megrendelővel vetetni fogsz MsSQL Server 2010-et, supporttal, majd kell még 5 profi kolléga, aki natív SQL-hez nem ért, de kiválóan függő EntityFramework-kel.

A saját, fentihez hasonlító dolgokat megvalósító keretrendszserünk első bétája ennél sokkal több dolgot valósított meg. Mert a való életre próbáltuk alkalmazni és a tervezéskor használt use-case-ek a tapasztalatból táplálkoztak.

Az adatkötésben van egy kis automatizmus, mégpedig az, hogy a rendszer egy vezérlőhöz (UI elem) történő adatkötés során megpróbálja kitalálni, hogy melyik adatkötési mechanizmust akarjuk használni. Egészen pontosan, ha egy TextEdit-hez szeretnénk egy property-t kötni, akkor két dolog történhet.

1. Amennyiben a forrás objektum egy “sima” objektum, úgy az adatkötés a megnevezett (stringként átadott) property-hez megtörténik. Ha jól paramétereztük fel az adatkötést, akkor a beviteli mező változása a property-ben rögtön megjelenik és vica-versa.
2. Ha a forrás objektum valamilyen gyűjtemény (IList, IBindingList, Array), akkor a megnevezett property, amihez kötni szeretnénk a gyűjtemény elemeiben kell, hogy létezzen. És az adatkötés is ide történik. List<Customer>-hez való adatkötésnél például a “Name” propertynek a Customer osztályban kell léteznie. Ilyenkor (gyűjtemény esetén) a gyűjtemény elemét vizsgálja a databinding és ott keresi a property-t.

Ez utóbbi teljesen kézenfekvő, hiszen ha egy listát akarunk valahova kötni, akkor a lista egy oszlopát akarjuk valahova kötni. Első esetben egy PropertyManager jön létre, utóbbi esetben pedig egy CurrencyManager. Mindkettőn értelmezett a lépkedés, de az elsőn nincs nagyon értelme.

A mi problémánk viszont a következő. Nem tudjuk befolyásolni, nem tudjuk elérni, hogy egy gyűjtemény típusú forrás objektum adott property-jéhez kössünk vezérlőt. Egy listának is van Count-ja. Ehhez nem tudtunk hozzákötni mondjuk egy Label-t, mert az adatkötés problémaként adta vissza nekünk, hogy a Customer objektumnak nincs Count-ja. De nem is oda akartunk kötni!!!

A probléma megoldása abban rejlik, hogy a property nevét nem szabad kitölteni. Ez már amolyan vicces dolog, hogy egy “változó” megadok a rá való hivatkozással, majd/és opcionálisan még stringként is hozzáírhatom a metódushoz a “változó” nevét.

Jó megoldás: label.DataBindigs.Add("Text", list.Count, "")
Nem jó megoldás: label.DataBindigs.Add("Text", list, "Count")

Hmm, állítólag WPF-ben az adatkötés jobb. Nemsokára úgyis indul egy WPF-es koncepció-projektünk, majd kiderül…

Ügyfelünk dokumentumokat szeretne készíteni úgy, hogy azokat dolgozóadatokkal tölti fel. Ne kelljen az újonnan belépő dolgozónak word-ben megszerkeszteni a belépőkártya igénylő lapját, a munkaidőnyilvántartó lapját. És még sorolhatnánk…

Office dokumentumok kicsit nehézkesen kezelhetőek, célunk volt, hogy az adatok behelyettesítése után a lapok elküdhetőek legyenek a nyomtatón kívül PDF-be, vágólapra, stb. Ezért jött az ötlet, legyen RTF. Van jól használható RTF editorunk, abban a felhasználó a dokumentumait elkészíti, adatbázisban tárolhatja. Persze elhelyez benne helyettesítő maszkokat: #NEV#, #SZULDATUM#. (Ezek formátuma a régi rendszerről való átállás miatt kötött volt).

A projekt ezen része elkészült, az adatok a megfelelő algoritmus szerint cserélődtek, a #NEV# helyére bekerült a dolgozó neve és így tovább. A tesztek során kiderült, hogy átlagos felhasználás (nem programozói, azaz laboratóriumi környezetben) a maszkok kicserélése nem is megy olyan szépen, mint azt hittük. Kiderült a turpisság: Ahogy a felhasználó szerkeszti a szöveget és néha-néha visszatöröl, újra beleír, az RTF szerkesztő új szekciót nyit neki az RTF forrásban. A megjelenítést ez nem befolyásolja, de a cserénél előfordul, hogy a szöveget nem tudjuk cserélni, mert a #NEV# maszk 3 részre bomlott és #N, EV és # lett belőle. String.Replace() pedig csak nevetett rajtunk.

Normalizálnunk kellett az RTF-et. Egy teljes RTF értelmezőt (szétbontó, építő) írni nem lett vona kivitelezhető, tekintve a projekt ezen moduljának költségvetését. Azonban egy minimális korrekciós algoritmus belefért, amely az egymás után következő, egyformán formázott elemeket összevonja eggyé:

{\f1\cf0 Ar}{\f1\cf0 ra szeretnék}{\f1\cf0 rámuta}{\f1\cf0 tni}

Tervezésünket siker koronázta, végre megmozgattuk SQL parancsokban ellaposodott, algoritmikus “agyféltekénket” is.

Sok energiát fektetünk abba, hogy minél jobban kiismerjük a rendszer újdonságait és ezeket a jövőben ki is tudjuk használni. Rendszereink kompatibilisek maradnak a korábbi Office verziókkal is, de terveink szerint számos új lehetőséget fogunk felhasználni következő programverzióinkban.

Egy nagyon jó marketing film (úgynevezett trailer) érhető el itt.

Felhasználói szintű információkat tett közzé a Microsoft az alábbi oldalon.

Sharepoint 2010 sokkal szakmaibb szemmel (úgynevezett sneak videón) az alábbi linken.

Igazán nagy kihívás lesz számunkra, hogy ezeket az eszközöket a hazai környezetbe illesszük, tekintettel az itthoni cégek finanszírozási kérdéseire és nem utolsó sorban az újdonságtól való “félelem” leküzdésére.

Régebbi programozási nyelvekben (Delphi, FoxPro) a hosszú műveletek automatikusan beállították a homokóra üzemmódot. Viszont nem kezelték jól a beágyazott műveleteket, azaz 10 darab SELECT végrehajtása egymás után 10 homokórás villogást eredményezett. Ez a mai világban inkább szégyenletes, mint felhasználóbarát.

Ezt a problémát oldottuk meg az alábbi kódrészlettel:

using System;
using System.Windows.Forms;

namespace SymbolTech.Common
{
    public class WaitCursor : IDisposable
    {
        private static int waitcursorlevel = 0;

        public WaitCursor()
        {
            waitcursorlevel++;
            if (waitcursorlevel > 0)
                Cursor.Current = Cursors.WaitCursor;
        }

        public void Dispose()
        {
            waitcursorlevel--;
            if (waitcursorlevel == 0)
                Cursor.Current = Cursors.Default;
        }
    }
}

Minden (hosszabb) műveletet beágyazunk egy using(new WaitCursor()) blokkba. Ezzel a következő előnyöket érjük el:

1. A műveletek minden esetben “homokórázni” fognak.
2. A beágyazott műveletek (külső blokk már homokórában dolgozik, a belső, mondjuk 100 iteráció is bekapcsolja a homkórát) nem fogják villogtatni a kurzort.
3. Véletlenül sem felejtjük el visszakapcsolni az alapértelmezett kurzort, amennyiben a műveletek végrehajtásra kerültek.

Lássunk egy példát, a használatára:

        private void DummyMethod()
        {
            using (new WaitCursor())
            {
                Thread.Sleep(100);
            }
        }

        private void button1_Click(object sender, EventArgs e)
        {
            using (new WaitCursor())
            {
                Thread.Sleep(500);
                for (int i = 0; i < 10; i++)
                    DummyMethod();
            }
        }

A példában egy beágyazott, többször (10x) végrehajtott műveletet látunk, amelyek összességében 1.5mp-re átkapcsolnak homokórára, de közben nem villog a kurzor.

A GridControl volt a hibás, ugyanis furcsa működéséből adódóan egy táblázatban is lehet tabbal lépkedni, vagy a sorok vagy a cellák között és amikor a végére érünk, nem tudunk merre menni. Nem is tudom, hogy miért ez az alapértelmezett működés, de kikapcsoltuk. Sok dolgunk nem volt, 2 (!!!) sort kellett a megfelelő helyen adaptálni és az összes termékünk következő kiadásában megjelenik a TabCsapda elleni megoldás.

Lássuk, mik ezek:

A fenti lista számos lehetőséget kínál a fejlesztőknek a megfelelő kivétel eldobásában. Ezek használata nagyban megkönnyíti a hibakezelést és hibakeresést, a metódus írója pedig publikálhatja, hogy mit várt és mit kapott.

A generic List<>-et lehet sorosítani, de előtte kell egy plusz származtatási szinten készíteni. Dictionary<T,U>-t nem lehet. De van megoldás. Csináljunk egy sorosítható Dictionary-t.

    [XmlRoot("Dictionary")]
    public class SerializableDictionary<TKey, TValue> : IXmlSerializable
    {
        public XmlSchema GetSchema()
        {
            return null;
        }

        public void ReadXml(XmlReader reader)
        {
            XmlSerializer keySerializer = new XmlSerializer(typeof(TKey));
            XmlSerializer valueSerializer = new XmlSerializer(typeof(TValue));

            bool wasEmpty = reader.IsEmptyElement;

            reader.Read();

            if (wasEmpty)
                return;

            while (reader.NodeType != XmlNodeType.EndElement)
                try
                {
                    reader.ReadStartElement("Item");
                    reader.ReadStartElement("Key");
                    TKey key = (TKey)keySerializer.Deserialize(reader);
                    reader.ReadEndElement();

                    reader.ReadStartElement("Value");
                    TValue value = (TValue)valueSerializer.Deserialize(reader);
                    reader.ReadEndElement();

                    reader.ReadEndElement();

                    reader.MoveToContent();

                    this.Add(key, value);
                }
                catch { }
            reader.ReadEndElement();
        }

        public void WriteXml(XmlWriter writer)
        {
            XmlSerializer keySerializer = new XmlSerializer(typeof(TKey));
            XmlSerializer valueSerializer = new XmlSerializer(typeof(TValue));

            foreach (TKey key in this.Keys)
            {
                writer.WriteStartElement("Item");
                writer.WriteStartElement("Key");
                keySerializer.Serialize(writer, key);
                writer.WriteEndElement();

                writer.WriteStartElement("Value");
                TValue value = this[key];
                valueSerializer.Serialize(writer, value);
                writer.WriteEndElement();

                writer.WriteEndElement();
            }
        }
    }

Ahogy látható, csak a saját szintünket kell megvalósítani, a TKey és TValue elemek sorosításával már a saját osztályuk foglalkozik. Extrém eset ha a TValue is egy sorosítható Dictionary (valós példát nem tudunk jelenleg mondani), ilyenkor ennek az objektumnak a sorosításakor szintén a fenti algoritmus fog lefutni.

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.

Az alábbi linken pár információval szolgálnak arról, mik is ezek az újítások. Én csak a tálca újdonságait emelném ki. Ezidáig a felhasználót a jobb alsó sarokban lévő úgynevezett értesítési területen lehetett informáli dolgokról. Milyen folyamatok futnak, mennyi ideig tart még a DVD megírása, a fájl letöltése.

Ezt most egy kicsit megbolondították és elérhetővé tették folyamatjelzők és ikonok megjelenítését a tálcán, ahol eddig a program főablakának címe szerepelt és jobb esetben az alkalmazás ikonja (számos fejlesztő felejt el ikont adni). A lehetőségek között szerepel:

• Véges folyamatjelző
• Végtelen folyamatjelző (nem kiszámítható befejezési idővel)
• Hibajelző (piros)

És ehhez elég lesz a .Net framework 4.0?

Elég, sőt 3.5-tel is működni fog, le kell hozzá tölteni a WindowsApiCodecPack-et (4MB, súgóval együtt 19MB), amely forrásfájlokat szolgáltat számunkra, hogy a Windows7 fenti szolgáltatásait elérjük. DirectX is kell hozzá a leírás szerint, de ez valószinüleg akkor szükséges, ha a CodecPack DirectX-es szolgáltatásait is szeretnénk használni.

Lehetőségünk lesz elérni a ITaskBarList3 interfész SetOverlayIcon, SetProgressState és SetProgressValue metódusait, amivel lehetőségünk van a felhasználóinkat informálni egy hosszabb programfolyamat állapotáról.

Referenciaként a Core és Shell szerelvényeket kell a projekthez hozzáadni, ezen névterekben pedig megtalálhatóak a szükséges osztályok:

• Microsoft.WindowsAPICodePack.Shell.Taskbar
• Microsoft.WindowsAPICodePack.Shell.Taskbar.ProgressBar
• Microsoft.WindowsAPICodePack.Shell.Taskbar.OverlayIcon

Ezen kívül a ProgressBarExt és OverlayIconExt osztályok segítségével a Windows XP óta, a sok ablak megjelenítésekor összecsoportosuló programablakok mindegyike külön folyamatjelzővel látható el.

Tesztelés folyamatban…