Symbol LABoratory

Elméleti szinten oktatják a rendező algoritmusokat. Sok geek (megszállott) ennek jelentősséget is tulajdonít, pedig már nem számít. Gondoltuk a múlt hétig.

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.

Van, aki kíváncsiságból és van aki tudatosan pásztázza a konkurenciát. Pontosabban hívjuk versenytársnak! A végén kiderül, hogy miért inkább ezzel a jelzővel illetjük őket. Mi is néha napján körbenézünk.

É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

Ennyire lehet megbízni az EU adószám nyilvántartó rendszerben.

Tegnapi nap folyamán érkeztek a bejelentések, hogy az EU közösségi adószámok ellenőrzése nem mindig jó. Megvizsgálva azt láttuk, hogy az URL megváltozott. De mint kiderült, nem csak az URL, hanem az adatok formátuma is megváltozott. De erről sajnos nem kaptunk értesítést.

Ez azért zavaró, mert egy szolgáltatást veszünk igénybe, amelyet továbbadunk ügyfeleink felé. És ők joggal panaszkodnak.

Tapasztalat, hogy a SaaS-ként emlegetett szolgáltatásokban azért annyire nem érdemes megbízni!

Sajnos mi is követünk el hibákat. Egyik volt főnököm szerint csak az nem hibázik, aki nem dolgozik. Mi dolgozunk…

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

Ha ma kiadnánk a Symbol Ügyvitel új verzióját, akkor a 4000-es számot kapná a verziószám végén: 1.62.44.4000. Hogy miért? Mert ma van az évezred 4000. napra, 4000 nap telt el 2001. január 1-e óta.

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.

Legutóbbi nyílt napunkon Fehér Péter, több sikeres vállalkozás (www.uzletitervek.hu, stb.) tulajdonosa kérdezett minket arról, hogy miért jelenik meg három hetente Symbol Ügyvitel frissítés. Elégedett felhasználóként nem is érti, mire föl a frissítési ablak.

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???“

“Azok a programozók, akik a régen “szabványos”, úgynevezett procedurális programozáson nevelkedtek egy évtizede megtanulták az objektumorientált programozást. Mert meg kellett.” - graffity 2004-ből.

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