CE

A megoldáson már elkezdtünk dolgozni, sőt néhány ügyfél már látta is, de a verziókiadásunk után szokásos Code-Freeze (kód pihentetés, nem kell minden nap megváltani a világot) miatt jelenleg még nem teljes a megoldás. Türelmüket kérjük!

Annyit elárulhatok, hogy nagyon frappáns, pofon-egyszerű megoldással jelentkezik a Symbol LAB.

Ahhoz, hogy mérni tudjuk a kód sebességét, sok eszköz áll rendelkezésre, de minden eszköz sokat lassít a programon (közben persze precízen mér!), beépül, beleül minden hívásba… pedig én csak egy pici kódot, egy metódust szeretnék mérni. Erre kerestünk megoldást az alábbi ismérvekkel:

1. Könnyen be lehessen építeni a forráskódba
2. Tudjon többféle kimenetet produkálni
3. Precízen mérje az időt

Megint az IDisposable lett a barátunk! A using segítségével könnyen beépíthető a kódba, pofon egyszerű a használata, sőt kikommentezni is könnyedén lehet.

Az alábbi minimál kód lett a megoldás:

public delegate void RunTimerResult(long ticks);
public class RunTimer : IDisposable
{
  private long starttick;
  private RunTimerResult runtimerresult;

  public RunTimer() : this(null) { }

  public RunTimer(RunTimerResult runtimerresult)
  {
    this.runtimerresult = runtimerresult;
    starttick = DateTime.Now.Ticks;
  }

  public void Dispose()
  {
    long endtick = DateTime.Now.Ticks;
    if (runtimerresult != null)
      runtimerresult(endtick - starttick);
    else
      Debug.WriteLine(String.Format("{0}ms", (endtick - starttick) /
                      TimeSpan.TicksPerMillisecond));

  }

  public static void RunTimerResultMessageBox(long ticks)
  {
    MessageBoxInfo.Show("Time elapsed", String.Format("{0}ms", ticks /
                                        TimeSpan.TicksPerMillisecond));
  }

Használata például (Console/Debug ablakba írja a futásidőt)

using(new RunTimer())
  DoSomethingSlowly()

vagy (MessageBox-szal jeleníti meg a futásidőt)

using(new RunTimer(RunTimer.RunTimerResultMessageBox))
  DoSomethingSlowly()

A hosszú ékezetekkel van a legnagyobb baj

Körülnéztünk a meglévő megvalósítások között (Gmail, Outlook, böngészők) és azt tapasztaltuk, hogy az ékezetes domain neveket mindegyik kezeli, azaz küldéskor a rendszer átalakítja a domain-t, ez alapján megtalálja a megfelelő szervert és oda a leveleket elküldi. A teljes folyamat során sehol sem látszik az ékezetes domainek kódolása. Ez remek hír volt.

De mi ez a kódolás?

UTF8/Unicode helyett valaki megálmodta, hogy a “@levelező.cégemékezetrevált.hu” domain-t a levelezőszerverek és webkiszolgálók az alábbi formában azonosítják:

@xn--levelez-8mb.xn--cgemkezetrevlt-6gb0jd.hu

Azaz szavanként kell kódolni és “xn--”-lel jelölni, ha ékezetet tartalmaz.

Mi a helyzet a @ előtti adatokkal?

Ezen lepődtünk meg a legjobban, mert a példa@symboltech.hu e-mail címet nem tudtuk megcímezni semmilyen eszközzel. A @ előtti részben nem szerepelhet ékezet? Pedig létre tudunk hozni ilyen felhasználót. A specifikációban nem találtunk erre vonatkozó leírást, talán nem is a domain felügyelet dolga a @ előtti részről dönteni. De erre is kell valami megoldás!

Eredmény

Rászántuk az időt, kerestünk egy ékezetes domain nevet a tarsolyunkban (nem árulom el melyik az, mert nemsokára új termékkel jelenünk meg a piacon) és elkezdtük megvizsgálni, majd megoldani a problémát helyzetet.

Sikeres eredmény született, kollégáink megoldották, hogy közvetlen SMTP illetve Symbol Comm Center-rel történő levél küldés esetén is hibátlanul átküldésre kerülnek az e-mail üzenetek, azt a fogadó oldal levelező programja is helyesen jeleníti meg. Programunk új verziójában (v1.90) az ékezetes levél küldés is működőképes lesz, még akkor is, ha a @ előtt van benne ékezet. Köszönjük LAB!

A szoftver korai verziójában biztonsági célból beépítésre került egy dátum/idő ellenőrzés, hogy a számítógép rosszul beállított órája ne okozzon eltérést a bizonylatok folytonosságában. 10 percnyi eltérésre már figyelmeztet, 6 óránál nagyobb eltérés esetén nem is engedi a programot elindítani. A felhasználói bejelentések között két alkalmat találtunk, amikor ügyfeleknél megjelent a dátum eltérés információs ablak. Most a saját bőrünkön tapasztaltuk meg és gondolkozni kezdtünk…

Időzónák

Miért ne fordulhatna elő, hogy valaki külföldről éri el a céges szervert? Ilyenkor mit jelent, hogy nála 17 óra van, nálunk csak 14? Mi legyen a “fő-idő”? Jó lenne erre a Greenwich Mean Time, azaz a GMT? Az a logikus döntés született, hogy a Symbol Ügyvitel szerverének ideje lesz a mérvadó. Ezt kell (fizikai helytől függetlenül) GMT+1-re (Budapest, Bukarest) beállítani és minden kliens alkalmazás ehhez fog igazodni.

A gyakorlatban ez azt jelenti, hogy a szerver dátuma/ideje az az érték, amely alapján létrejönnek a bizonylatok, elkészülnek a hozzászólások, naptárbejegyzések. Hogy a felhasználónak ne okozzon gondot a dátum anomália, 30 percnyi eltérés után (vannak fél órás időzónák is!) a főablakon, a jobb alsó sarokban megjelenik a szerver idő, amely eltér a számítógép idejétől és attól az időtől is, amit az ablakon kinézve látunk.

Ha valaki magyar időhöz viszonyítva +12 órában van – azaz nálunk 21h-kor ott már reggel 9h van – azt fogja látni, hogy a bizonylatok még “tegnapi” dátummal kerülnek kiállításra, hiszen a szerver ideje szerint még tegnap este 21h van.

A fentiekkel remélhetőleg kihúztuk a “méregfogát” a világ időzónáinak és univerzális megoldást adtunk arra, hogy a világon bárhol is vagyunk, a magyar időt tekintjük az ügyvitel alapjának.

Eddig az automatikus sorszámozást AutoInc mezőkkel (pontosabban egy INT/LONG mező autoinc tulajdonságának beállításával) lehetett elérni. Ezen most változtattak. Példa lehet(ett) az Oracle vagy a Firebird/Interbase, amely évek óta ezt a technológiát használja.

Az MsSQL-es megvalósításnak a nyelvi szintaktikája is pont ugyanolyan:

http://www.kodyaz.com/sql-server-2012/number-of-sequences-in-sql-server-2012-using-sequence-objects.aspx

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

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

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

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

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

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

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

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

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

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

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

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

Mi is az API?

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

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

SaaS

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

Az adatbázis állandó?

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

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

Akkor mi a megoldás?

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

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

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

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

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

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

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

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

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

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

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

És, hogy mit látunk?

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

Ki mutat újat?

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

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

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

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

Mitől versenytárs?

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

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

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

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

Kérem kövessenek!

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

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

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!

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.

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

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

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

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

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

Számos alkalommal finomítottunk:

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

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

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

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

Konklúzió.

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

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

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

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!

Külön kerül értékesítésre a fehér színű fejlesztői változat és a fekete végfelhasználói.

Fejlesztői változat tartalmazza:

• Surface Software license consisting of Surface Platform runtime 1.0 SP1 software
• Windows Vista Business SP1
• Surface SDK 1.0 SP1

A végfelhasználói változatnak nem része az SDK. Talán ezét kerül többe (!!!) a fejlesztői változat. Pedig a logikus az lenne, ha a promóció miatt a fejlesztés olcsóbb lenne. Úgyis meg kell venni a végfelhasználóit, ha telepíteni is akarom a célközönségnél.

Az ára 13.000€, azaz kicsit több, mint 3.5M Ft. Nem kevés, de minden bizonnyal az elterjedés után nyomottabb áron is elérhető lesz.

Természetesen cserealkatrészek is elérhetőek hozzá.

Elérhető itt: http://www.microsoft.com/surface/Pages/HowToBuy/HowToBuy.aspx

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/

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

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

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

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

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

(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

Mindenki, aki ilyen típusú autóval kereskedik, saját cégneve alatt létrehoz egy domain-t (www.bmw-cegnev-kft.hu), majd keresőbaráttá teszi. És tőle vásárolnak. Most egy még újabb trend-forduló van kialakulóban. Még cselesebb!

Sok cégnek nem sikerült említésre méltó brand-et kialakítani vagy pont presztízs veszteség(!!!) lenne a cégnevet feltüntetni. És kialakult a www.a-termekcsoport-neve.hu domain felépítés. Lássunk néhány példát erre:

ARendszergazda Kft. által üzemeltetett, kifejezetten értékesítési célú weboldal:
www.a-szamlazo-program.com

Diamond Stúdió Kft cégkapcsolatait kihasználó:
www.ugyvitel.com

QualitySoft Kft célirányos domainje:
www.szamvitelirendszer.hu

Természetesen nem emelhetünk kifogást minden ellen, ami tartalmaz valamilyen célravezető fogalmat. A www.ugyvitelbazis.hu neve hűen tükrözi azt, amivel foglalkoznak. A leginkább polgárpukkasztóak az olyan domainek, amelyek a/az névelővel kezdődnek:

www.akereskedo.hu

www.abroker.hu

www.abolt.hu

www.akereso.hu

(www.atv.hu nem tartozik ebbe a kategóriába, nekik a brand nevük kezdődik A-val!)

Még messze vagyunk tőle, hogy ez a félrevezetés kategóriájába tartozzon jogilag, hiszen, amit nem tilos, azt szabad. De megkérdőjelezhető, hogy a www.az-ugyviteli-program.hu domain mennyire félrevezető, hiszen azt az érzést kelti, hogy ez a termék a piac legjobbja, sőt csak ez létezik a nagyvilágban.

(Elnézést mindenkitől, aki a listában nem szeretne szerepelni, de egy kis link-marketing-ért csak nem fog neheztelni!)

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

Ha levetítjük, akkor 12Ft/munkanap az ára. Ez így jól is hangzik, de vajon mit kapunk három McChicken szendvics áráért. Milyen támogatásban részesít minket a nagy testvér?

Érdekes megközelítés az, amikor a nagy értékesítési mennyiség reményében olyan alacsony áron kerülnek forgalomba termékek, amelyek semmilyen módon nem tudják fedezni a velük járó költségeket. A kereskedelemben szabályozott, hogy bekerülési ár alatt nem értékesíthető semmi. De ez a szolgáltatási szektorban, ahova a szoftver is tartozik nem működhet. Csupán az jelenthet gátat, ha a minimális járulékokat sem fedezi, miközben legalább egy ügyfélszolgálatos kollégát fent kell tartani.

Az értékesítési partnerek is vonakodnának egy ilyen ár hallatán. 10%-os üzletszerzési jutalék esetén 288Ft/darab? Hmm…

Ön mit adna 2880Ft-ért, ha utána azt karban is kell tartani? Igen, igaza van, egy nagy semmit…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Forrás]
Egyszer a követel van végrehajtható sikeresen, fatörzs távoli és fatörzs hátul -hoz lát a ügyintéző számla helyben. Ha sírnod kell megbénít hátul, típus a követel- háló felhasználó ügyintéző aktívság: és a ügyintéző számla lesz meghibásodott.

[Szerk.]
Ha helyben számlázol, akkor legyen távol és hátul egy fatörzs. Ha sírnod kell számlázáskor, ne aggódj, hátul meg leszel bénítva. De én nem hátul sírok…

[Forrás]
Mindig ön képessé tesz vagy megbénít a számla, lesz szükség -hoz fatörzs távoli vagy fatörzs -ban -hoz lát -ban tett.

[Szerk.]
A következő bekezdésben a számla bénít meg, de a fatörzs itt is jó szolgálatot tesz.

[Forrás]
Vagylagosan tudod is képessé tesz vagy megbénít a ügyintéző számla -ból Helyi Politika. Kettyenés -on elkezd étlap és típus secpol.msc -ban kutatás büfé és kettyenés belép.

[Szerk.]
Tehát vagy tudok számlázni vagy le leszek bénulva. És ehhez a politikának is köze van. De sebaj, mert kettyenés kell, amikor az étlapod kezded a büfében. A kettyenés az étlap előtt, a büfébe való belépéskor is kell.

[Szerk.]
Összefoglalva. A számlázás alapvetően egy fatörzzsel indul, de politikai behatásra kettyenés kell hozzá a büfében. A fatörzs itt lehet, hogy a büfében kapható sütemény típusa.

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

Ez jó így, mert a célközönség intelligens, szakmaiságára büszke fejlesztőcég vagy freelancer fejlesztő. Nekik nem lehet eladni egy terméket a szépen PhotoShop-olt (vagy Paint.NET?) főképernyővel.

Pár fontos dolgot fedeztünk fel benne, áttekintve a bemutató videókkal megfűszerezetett starting kit-eket

F#. Azaz effshárp! Ismét nekifutnak, hogy nagy plénummal is megismertessék ezt a programnyelvet. Sem a lehetőségeket, sem az újdonságokat nem fogja értékelni az, aki csak WinForms vagy “adatbázisos” alkalmazásokat fejleszt. Ehhez bizony progmat és/vagy BME végzettség kell.

WorkFlow. Kezdi kinőni gyermekbetegségeit a folyamatkezelésre szakosodott keretrendszer. Ennek épp itt volt az ideje, hiszen a 4.0-s verziónál járnak.

Pararrel extension. Ehhez csak annyit kell mondanom, hogy Task<T>. Ebből mindenki tudni fogja mire gondolok. Az eddiginél is típusosabb párhuzamosság kezelést valósítottak meg. Ez valószínüleg nem egy nagy innovávió, sokkal inkább hibabiztosabb hibatűrőbb programokat eredményezhet. De csak ezért .NET 4.0-ra váltani nem érdemes.

… és a szokásos újdonságok: velocity, multi-touch gestures, surface, stb…

További információk az alábbi linkeken:

http://www.hanselman.com/blog/VisualStudio2010Beta2.aspx

http://blogs.msdn.com/somasegar/archive/2009/10/19/announcing-visual-studio-2010-and-net-fx-4-beta-2.aspx

http://geekswithblogs.net/jolson/archive/2009/10/20/visual-studio-2010-beta-2-training-kit-published.aspx

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…

A http://www.geekzone.co.nz/paulspain/6799 bejegyzésben olvashatjuk, hogy 1000-nél több fejlesztő dolgozik az új platform kialakításán. További 65-70 betöltendő pozíció van szabadon. Ez persze nem összehasonlítható a hazai fejlesztőcégek kapacitásával, sem cégméret, sem pedig az előállítandó termék “fontosságának”, pénzügyi, iparági befolyásának tekintetében. De mégis elgondolkodtató.

1. Elképzelhető, hogy tényleg sok a munka, számos feladat vár megoldásra vagy mert nemsokára meg akarnak vele jelenni vagy mert túl sok hibát találtak és a szokásos 50-80 fős csapattal ez nem oldható meg.
2. Másik gondolatom szerint olyan mennyiségű és értékű innovációt építenek bele a termékbe (amely platform és platformra épített alkalmazások együttese), amelyet nem tesznek publikussá egy 15 fős csapat számára. Azaz mindenki csak egy kis szeletet lát belőle. Attól, hogy valaki ott fejlesztő, még nem férhet hozzá a know-how-hoz. Az Apple-lel vívott harcban ez létfontosságú.

Belső üzenőfalunkon ezt foglalta össze kollégánk:

“Gondolom egy olyan stratégiát próbálnak használni, ahol a feladatokat annyira szét osztják, hogy önmagában ne érjen semmit. Így nem tud elég sok infó kiszivárogni a termékről. És az erőforrások rendelkezésre állása is megnő, fizetni pedig az elvégzett munkáért kell. Leszűkül az üresjárati idő, ami a munkába járós, napi 8 órában foglalkoztatottaknál előfordul (Kávészünet, ebédszünet, óránként 10 perces kötelező szünet…)”

Lehet benne valami…

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.

Egy érdekes, még éppen elolvasható hosszúságú bejegyzésre bukkatunk. Bevezetője is gondolatébresztő.

“2003 óta ismert a “ráguglizok” avagy angolban a “to google” kifejezés. 1998-as alapítása óta a Google naponta 200 millió keresést fogad, és vagyona akkorára növekedett, hogy alapítói méltán bekerülhatnek a világ leggazdagabb emberei listába. De felmerül egy kérdés: Honnan származik a Google pénze?

A cég az újításairól ismert. Na persze ez a fenti képen, amely az első google felületet mutatja 98-ból nem igazán látszik – hisz immár 11 éve ugyanaz az unalmas felület fogad minket. A stratégia egyszerű: Kell néhány fizetős szolgáltatás, majd a profitot a többi ingyenes szolgáltatásba nyomni. Így nő a népszerűség – még többen használják a fizetőseket, azt a pént ismét visszaforgatni és így továbbb… Ördögi kör.”

A teljes tartalom elolvasható itt: http://numlockholmes.blog.hu/2009/07/24/title_97900

A cikk bevezetője:

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

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

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

Ha egy királyságban 25% áfát vetnek ki a polgárokra és egy termék nettó ára 9876 fabatka, akkor a bruttó árcímkén 12345 fabatka fog szerepelni.

9876 – 12345 minden számjegyet pontosan egyszer használtunk fel.

Van egy nagyon fontos dolog, amit egyszer sem említenek a programozásról és szoftverfejlesztésről szóló könyvek, és amiért néha félreértjük egymást. Te szoftverfejlesztő vagy. Én is. Ám nem biztos, hogy ugyanolyan céljaink és követelményeink vannak. Tulajdonképpen a szoftverfejlesztésből több fajta létezik, és mindegyik külön világra más és más szabályok érvényesek.

Ha egy UML-ről szóló könyvet olvasol, sehol sem találod meg benne, hogy az alkalmatlan eszközmeghajtók írásakor. Vagy olvashatsz egy olyan cikket, ami azt írja, hogy „A 20MB-s futtatókörnyezet (a .NET-hez) nem lehet akadály”, de nem mondja ki a nyílvánvalót: ha csak egy 32KB ROM-al rendelkező csipogóba írsz, akkor igenis van jelentősége!

Úgy gondolom, öt különálló világról beszélhetünk, amik néha átfedik egymást, de gyakran nem. Ezek:

1. dobozos
2. belső
3. beépített
4. játék
5. egyszer használatos

Ha a legújabb Extrém Programozásról szóló könyvet olvasol, vagy Steve McConnel remek könyveit, vagy akár a Joel on Software-t, esetleg a Software Development magazint, egy rakás olyan kijelentéssel találkozhatsz, hogy így vagy úgy fejlessz szoftvert, de arról nem szól a fáma, miféle fejlesztésről is beszélnek. Ez azért nem szerencsés, mert a különböző világokban lehetséges, hogy másképp kell csinálnod a dolgokat.

Nézzük át röviden a kategóriákat!

Dobozos az a szoftver, amit „a vadonban” használ nagy számú felhasználó. Talán még be is dobozolják, és a CompUSA-ban is árulják, de akár internetről letölthető is lehet. Lehet pénzes vagy shareware, nyílt forrású, GPL-es, akármi – a lényeg az, hogy akár ezrek vagy milliók használják.

A dobozos szoftvernek van néhány problémája, ami két különleges tulajdonságából adódik:

• mivel olyan sok felhasználó van, akiknek más megoldások is rendelkezésükre áll, a felhasználói felületnek az átlagosnál egyszerűbbnek kell lennie, hogy sikeres lehessen
• mivel olyan sok számítógépen kell futnia, a kódnak különösen rugalmasnak kell lennie, már ami a különböző konfigurációkat illeti. Múlt héten kaptam egy olyan hibát a CityDesk-re, ami csak lengyel Windows-nál fordul elő, mivel az operációs rendszerben a jobb Alt-ot kell használni a speciális karakterek beírásához. Kipróbáltuk Windows95-ön, 95OSR2-n, 98-an, 98SE-n, Me-n, NT 4.0-n, Win2000-en, és WinXP-n. Teszteltük IE 5.01-en, 5.5-ön, és 6.0-n. Teszteltük amerikai, spanyol, francia, héber, és kínai Windows-szal. Ám még nem foglalkoztunk lengyellel.

A dobozos szoftver három nagyobb fajtája létezik. A nyílt forrású szoftvert leggyakrabban úgy fejlesztik, hogy senki sem kap pénzt a fejlesztésért, ami a dinamikát nagyban befolyásolja. Például azokat a funkciókat, amik nem élvezetesek, nem készítik el a lelkesedésből fejlesztő csapat, és, ahogy Matthew Thomas ékesszólóan rámutat, ez a használhatóságot ronthatja. A fejlesztés valószínűleg nagy földrajzi távolságokat ölel át, ami a csapat kommunikációját radikálisan megváltoztathatja. A nyílt forrású világban elég ritka a személyes megbeszélés, ahol táblára dobozokat és nyilakat rajzolnak. Így a tervezési döntéseket, amik pont a dobozok és nyilak rajzolásából nyernék lényegüket, csak kis hatékonysággal hozzák meg. Végeredményben a földrajzilag szétszórt csapatok sokkal jobbak meglévő szoftverek lemásolásában, ahol elenyésző mennyiségű tervezés szükséges.

A tanácsadószoftver tulajdonképpen csak egy változata a dobozos szoftvernek, amit annyit kell finomhangolni és installálni, hogy egy sereg tanácsadóra van szükség a bevezetéshez, aranyárban. Többnyire a CRM és CMS csomagok esnek ebbe a kategóriába. Az ember könnyen úgy érezheti, hogy ezek valójában nem csinálnak semmit, és ez csak egy indok, hogy tanácsadók tucatjait szabadítsák rá, 300 dolláros órabérrel. Bár a tanácsadószoftver dobozos szoftvernek van álcázva, az implementáció magas költsége alapján inkább belső szoftvernek minősül.

A kereskedelmi webalapú szoftver, mint a Salesforce.com, vagy az eBay változatok még mindig igénylik a könnyű kezelhetőséget, és hogy minden böngészőn fussanak. Bár a fejlesztők megengedhetik maguknak azt a luxust, hogy (legalább egy kicsit) ellenőrizhessék a telepítési környezetet – a számítóközpontban levő gépeket –, kezelniük kell a böngészők széles skáláját, és a felhasználók nagy számát, így ezt én a dobozos szoftver kategóriájába sorolom.

A belső szoftvernek csak egy cég számítógépein kell futnia, ugyanolyan szituációban. Ezt lényegesen egyszerűbb fejleszteni. Számos olyat feltételezhetsz, ami a futási környezettel kapcsolatos. Megkövetelheted az Internet Explorer, a Microsoft Office, vagy akár a Windows egy verzióját. Ha grafikont akarsz csinálni, arra ott lesz az Excel. Nálunk mindenkinek van Excelje. (Ám próbálnád ugyanezt a dobozos szoftverednél, és már el is vesztetted a potenciális vásárlóid felét.)

A használhatóság kevésbé fontos, mivel csak meghatározott számú felhasználónak kell a programot használnia, és ők sem választhatnak másik szoftvert maguknak. A fejlesztési sebesség sokkal fontosabb. Mivel a fejlesztési költségek csak egy cégen belül oszlik el, az elosztható fejlesztési erőforrások is lényegesen kevesebbek. A Microsoft megengedheti magának, hogy ötszáz millió dollárt költsön egy operációs rendszer fejlesztésére, ami egy átlagembernek csak 80 dollárjába kerül. Ám amikor a Detroit Edison energiakereskedelmi szoftvert fejleszt, a befektetésnek ésszerűnek kell lennie az egész társaságnak. Értelmes ROI eléréséhez nem költhetsz annyit, amennyit egy dobozosra költenél. Így sajnos a belső szoftverek nagyon csúnyák.

A beépített szoftverek annyiban egyediek, hogy egy hardverbe kerülnek, és szinte sosem frissíthetők. Ez egy teljesen más világ. A minőségi követelmények itt sokkal magasabbak, mert nincs második lehetőség. Valószínűleg lényegesen lassabb processzorral kell dolgoznod, így sokkal több időt kell szánnod optimalizálásra. A gyorsaság lényegesebb, mint a kód szépsége. Kevesebb be- és kimeneti eszköz állhat rendelkezésre. A múlt héten bérelt autómban a GPS rendszer IO rendszere annyira szánalmas volt, ami szinte teljesen használhatatlanná tette. Próbáltál már ilyen ketyerén beírni egy címet? Megjelenik a képernyőn egy „billentyűzet”, és a nyilakkal kell kiválasztani az öt, egyenként 9 karaktert tartalmazó mátrixból a betűket (a link további illusztrációkat tartamaz a felhasználói felületről. A saját kocsimban levő GPS érintőképernyős, ami a felületet remekül feldobja. Ám elkalandoztam).

A játékok két okból kifolyólag egyediek. Előszöris a játékfejlesztések ökonómiája sikerorientált. Néhány játék sikeres lesz, de sokkal több van bukásra ítélve. Ha pénzt akarsz keresni a játékpiacon, jó, ha ezt felismered, és tartasz néhány sikeres játékot a portfóliódban, hogy a kirobbanó siker nyeresége fedezze a megbukott játékok veszteségeit. Ez inkább a filmszakmához hasonlít, mint szoftvereshez.

A játékfejlesztések nagyobb problémája az, hogy itt is csak egy verziód van. Ha már egy felhasználód végigjátszotta a Duke Nukem 3D-t, nem fog a Duke Nukem 3.1D-re frissíteni csak néhány hiba és pár új fegyver miatt. Néhány kivételtől eltekintve ha valaki már végigjátszott egy játékot, már unni fogja az újra játszást. Így a játékoknak ugyanolyan minőségi követelményeik vannak, mint a beépített szoftvereknek, és hihetetlen nagy pénzügyi szükséglet, hogy elsőre jó legyen. A dobozos szoftverek fejlesztőinek megadatott az a luxus, hogy ha az 1.0-ás verzió nem felelt meg az emberek igényeinek, a 2.0-s talán meg fog.

Végül az egyszer használatos kód az, amit csak azért ácsolsz össze ideiglenesen, hogy valami mást elérj, amit nagy valószínűséggel sosem kell többet használnod, miután azt a valamit elérted. Például írhatsz egy olyan kis shell szkriptet, ami egy bemeneti fájlt úgy masszíroz meg, hogy az olyan formátumba kerül, amit már valami más program már fel tud dolgozni.

Lehetnek még olyan szoftverfajták, amiket kifelejtettem.

Egy fontos dolgot tudnod kell: amikor olyan könyveket olvasol programozási metodológiákról, amiket egy teljes munkaidős szoftverfejlesztő guru / konzulens írt, szinte teljesen biztos, hogy belső céges szoftverfejlesztésről ír. Nem dobozos termékről, nem beépített szoftverről, és biztos, hogy nem játékról. Hogy miért? Mert a cégek bérlik fel ezeket a gurukat. Ők fizetik a számlát (hidd el, az id software nem fogja felvenni Ed Yourdon-t, hogy a struktúrált analízisről beszéljen).

Múlt héten Kent Beck azt állította, hogy valójában nincs is szükség hibakövető adatbázisokra, ha Extrém Programozást használsz, mert a páros programozás (folyamatos kódvizsgálattal) és a teszt-irányított fejlesztés (ami garantálja, hogy az automatikus tesztek 100%-osan lefedik a kódot) azt eredményezi, hogy nem lesz egy hibád sem. Ez valahogy nem tűnt igaznak a szememben. Bele is néztem a saját hibakövető adatbázisunkba, mi is az, ami elfoglal minket.

Na lám csak, azt vettem észre, hogy nagyon kevés hibát vettünk volna észre páros programozással, vagy teszt-irányított fejlesztéssel. A legtöbb „hibánk”, amit XP-ben történetnek hívnak tulajdonképpen fejlesztési kérések. A hibakövető rendszert egyszerűen arra használjuk, hogy ne felejtsük el, priorizáljuk, és menedzseljük azokat az apró csiszolásokat és nagy funkciókat, amiket ki akarunk fejleszteni.

Sok más hiba pedig csak akkor került a felszínre, amikor már a „mezőkön” régóta használták. A lengyel billentyűzet dolog. Ezt páros programozással lehetetlen észrevenni. Aztán azok a logikai tévedések, amik nálunk sosem jöttek elő úgy, ahogy a különböző funkciók együttműködnek. Minél nagyobb és bonyolultabb egy program, annál több a párbeszéd olyan funkciók között, amire nem is gondolsz. Egy bizonyos nem várt karaktersorozat (ha tudni akarod, a „{${?” az) összezavarja a lexert. Néhány ftp kiszolgáló hibát generál, ha egy olyan fájlt akarsz törölni, ami nem is létezik (a mi ftp kiszolgálónk nem kiabál, így ez elő sem fordult nálunk).

Figyelmesen végigtanulmányoztam az összes hibát. 106 hiba közül, amit a CityDesk szervízcsomag kiadásában megjavítottunk, pontosan ötöt tudtunk volna páros programozással, vagy teszt-vezérelt tervezéssel kivédeni. Sokkal több hibánk volt olyan, amikről tudtunk, amikről úgy gondoltuk, nem fontosak (kivéve persze a vásárlóinkat!), mint olyanok, amiket az XP módszerrel kivédhettünk volna.

Ám Kent-nek igaza van a másik fajta fejlesztésben. A legtöbb céges fejlesztésű alkalmazásnál ezek egyike sem lett volna hiba. A program lefagy érvénytelen bevitelkor? Futtasd újra, de ezúttal figyelj a {${?-kre! Aztán úgyis csak egy fajta ftp kiszolgáló lesz, és a cégben senki sem fog lengyel Windows-t használni.

A szoftverfejlesztés legnagyobb része ugyanaz, akármiféle projekten is dolgozol, de nem teljesen. Ha valaki metodológiáról beszél, gondolkodj el azon, hogy ez hogy hatna a te munkádra. Gondolkodj el azon, hogy milyen környezetben is van a másik. Steve McConnell, Steve Maguire, és jómagam egy nagyon szűk sarokból jövünk: a dobozos tömegcikk táblázatkezelő alkalmazások világából, amit Redmondban, Washington államban írtak. Nálunk magasabb a léc az egyszerű használatnál, és alacsonyabb a hibáknál. Az összes többi módszertan guru azzal keresi a betevőt, hogy konzultál saját céges fejlesztéseknél, és ők erről is beszélnek. Bárhogyis, mindannyian tudnunk kellene tanulni egymástól.

Forrás: http://js.hu/jos/

• Precíz információkkal szolgáltak a kreatív elkészítéséhez (PSD források, leírás).
• Gördülékenyen intézték a rendelésfelvételt
• Határidőre teljesítették a vállalásukat

Az elkészült anyag (tok+lemez) mindenben megfelel az elvárásainknak.

www.szuperlemez.hu

Részletes információ: itt

Néhány érdekes témakör a konferencia sorozatból:

Cloud Computing

Simon Guest is the Senior Director of Technical Strategy in the Developer and Platform Evangelism (DPE) group at Microsoft, responsible for helping developers worldwide deliver practical and elegant solutions using Microsoft technologies. Since joining Microsoft in 2001, Simon has led the Microsoft Platform Architecture Team, acted as Editor-in-Chief of the Microsoft Architecture Journal, pioneered the area of .NET and Java 2 Enterprise Edition (J2EE) interoperability, worked with customers on mission critical .NET solutions, and has been a regular speaker at many conferences worldwide, including PDC, TechEd, and JavaOne. Before joining Microsoft, and with over 18 years in the IT industry, Simon held architect-level positions at many organizations, including Zoho Corporation, a Silicon Valley startup; Conchango, a UK based consultancy; and Herbert Smith, a leading law firm in the UK. He also worked for several years at GEC in its semiconductor manufacturing division. Simon was born in England, and has been living in the U.S. for approximately eight years. He holds a Masters Degree in IT Security from the University of Westminster, London, and a Higher National Certificate in Software Engineering from Plymouth College. Simon is the author of numerous technical articles and books about Java, Microsoft .NET, and Web technologies, as well as maintaining a blog at http://simonguest.com.

Green IT

Microsoft believes in the potential of software to drive innovations that can help address many of today’s tough environmental challenges. Find out how Microsoft products and technologies can help your organisation improve efficiency, save money, and minimise its environmental impact.

Unified Communication

Microsoft unified communications technologies use the power of software to deliver complete communications—messaging, voice, and video—across the applications and devices that people use every day. The Unified Communications track strengthens your knowledge of the Microsoft Unified Communications platform and technologies, including Microsoft® Exchange Server 2010, Microsoft® Office Communications Server 2007 R2, Microsoft Office Live Meeting and Microsoft® Exchange Online. Explore how you can streamline your organisation’s communications, build presence-aware applications, roll out an on-premise, hosted (or combination thereof) messaging and collaboration system, and much more!

Windows Embedded

Enhance your technical skills in the development and implementation of Windows® Embedded operating systems. Learn how to easily build reliable, powerful, and intelligent smart connected devices utilising our end-to-end development tools, support, and resources. Windows Embedded operating system technology has been deployed in the broadest and most demanding environments, and is at the forefront of providing a solid foundation for the next generation of 32-bit embedded devices. Windows Embedded products help you provide highly customised device designs on a flexible platform with easy-to-use development tools.

Mi ott leszünk. Legyél ott Te is, ha érdekel a témák valamelyike!

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/ 

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

Kövess minket Te is itt: SymbolTech on Twitter

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.

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

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

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

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

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

PowerCommands for Visual Studio 2008

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.

Annyira régi, annyira elterjedt, hogy bele sem gondolunk, azt valószínűsíthetnénk, hogy Kolombusz ültette el az első Admin fát az újvilágban vagy az amerikai kontinens Kazinczy-ja lehetett az első, aki ezt a kifejezést alkalmazta.

Csapatunkat mégsem hagyta nyugodni a dolog. Szóösszetételekben gondolkodtunk és beugrott egy kifejezés összetétel: Ad-Ministrator. A ministrator a miniszter szóra hasonlít, a latin minister-ből eredhet, ami szolgát jelent. Ennek politikai, közigazgatási jelentősségét most ne firtassuk! Az Ad pedig nyilvánvalóan hirdetést jelent, újkori rövidítése a szintén újkori advertisement szónak. (Ennek latin forrása nincs, régi korokban nem volt hirdetés).

Talán ráhibáztunk a kialakulás módjára is. A web-es, elektronikus hirdetések szolgáját, aki kezelte, adminisztrálta (önmagával magyarázzuk a dolgot?) a hirdetéseket hívhatták AdMinistratornak. Az, hogy a számítógéphez jól értő emberek a hirdetések mellett más dolgokat is kezeltek, nyilvánvaló következménye az eseményeknek.

A nálunk dolgozó Ad Miniszterek (adatbázis, IIS, Small Business) kérjük ne érezzék rosszul magukat a szolga szó olvasása közben, csapatunk nagyrabecsült tagjai ők, a szó régi jelentését már elfelejtettük.

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

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

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

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

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

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

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

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.

Eddigi fejlesztési tapasztalataink alapján összeszedtük, hogy mikkel találkoztunk eddig. Nem titok és nem szégyen, velünk is előfordul, mi is mulasztottunk már:

Direkt lassítás. Nem károkozás, sokkal inkább professzionális munkamódszer, amikor lassabb számítógépet emulálva szándékos lassításokat helyezünk el a kódban. Nem célszerű ezt a kiadott verzióban is benne felejteni.
Megoldás: #warning pragma használata

Felugró ablakok. Hibakeresési céllal sok programozó használ felugró ablakokat, sőt – bár nem illik, de néha az átlagosnál durvább verbális kifejezéseket is. Mivel ezek hibafelderítési célokat szolgálnak, általában ott maradnak benne a kódban, ahol csak alapos tesztelés során talál rá az ember/tesztelő. A végfelhasználónál megjelenő, nem értelmezhető, oda nem illő üzenetek presztízsrombolók.
Megoldás: Üzenet megjelenítése Debug.WriteLine()-nal.

A bűvös new Random(). A végfelhasználó nem veszi észre mindig, de számos helyen alkalmazunk véletlen tesztadatokkal való feltöltést. Nem szerencsés, ha a végfelhasználónál történő új vevő rögzítéskor a vevő neve és címe már kitöltésre került tipikusan “Kovács Géza” és “Kiss János” nevekkel.
Megoldás: new Random() konstruktorok megkeresése a forráskódokban.
Saját tapasztalat: Nem minden ilyen konstruktor kell, hogy megszűntetésre kerüljön. Legutolsó projektünk a tisztítás után 7 helyen használta a Random konstruktort.

Ideiglenes fájlok írása. XML vagy bármilyen más adatátvitel implementálása közben gyakran mentjük az átvitt adatokat átmeneti fájlokba. Sok esetben ez a C:\tempfile.dat, amely azon kívül, hogy az ügyfél számítógépén furcsán mutat, rendes biztonsági házirendet tartalmazó környezetben (a fájlírás letiltása miatt) IOException-t eredményez.
Megoldás: if DEBUG direktíva használata fájl írásakor.

Takarításra fel! 

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…