Symbol LABoratory

Ügyféligényként érkezett a megkeresés, hogy a CE (Conformité Européenne = európai megfelelőség) jelölést és néhány más piktogramot lehessen a termékcímkéken megjeleníteni. A grafikával (is) foglalkozó kolléga elkezdte keresni, hogy honnan lehet beszerezni szép (nagy?) méretű piktogramokat. Gyúlékony, Nem érheti víz, Nem pakolható egymásra, stb.

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.

Ha egy program működik és azt csinálja, amit kell, akkor arra azt mondják jó. Hogy a jóból kiváló legyen, ahhoz a minőségre is hangsúlyt kell fektetni. A minőségi program egyik ismérve, hogy nem akad, nincsenek benne lassú műveletek.

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

Már régóta (2004-2005) lehet ékezetes domain neveket regisztrálni, de ennek sokak szerint csak marketing és SEO értéke van. A cégnek biztosan van egy “rendes” domainje, amelyeken a weboldal és a levelező szolgáltatás üzemel és mellette van egy kereső-barát domain ékezettel. Azzal még nem találkoztunk, hogy valakinek ékezetes email címe legyen. Nemrég befutott ez az igény is…

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!

Próbálták-e már a Symbol Ügyvitelt Londonban elindítani? És Los Angelesben? Londoni kiruccanásunk alatt a Temze partján elindítottuk a szoftvert és egy ablak fogadott minket, miszerint a számítógépünk órája eltér a szerver idejétől. Miért írja ki és miért fontos ez?

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.

Bár nem használunk MsSQL szervereket, de mégis örömmel tölt el, hogy a Microsoft is lépést tart a világgal és a helyes irányba mozdul.

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 HTTP szabvány szerint a HTTP hibakódoknak működniük kellene (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). Sok esetben – főleg tárhely szolgáltatónál működtetett PHP kiszolgálón – nem működik minden hibaüzenet. Ilyen hibaüzenet a 413-as hiba is. Ez akkor jelentkezik (jelentkezne), ha a beállított, fogadható adatmennyiségnél többet akarunk ráerőltetni, feltölteni a szerverre.

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.

Ezúton (is) felhívjuk partnereink figyelmét, hogy adatbázis kezelő rendszerünkben módosításokat hajtottunk végre. Felhasználóinkat ez nem érinti, ők nem vesznek észre semmit, de fontos, hogy azok a partnerek, akik a mi PDO-nkkal dolgoznak, olvassák el figyelmesen a bejegyzést!

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.