WebSyX beépülő modulunk megváltozott vagy teljes adathalmazokat tölt fel webáruházak felé. A feltöltött adatok jól tömöríthetőek, TCP szinten tömörítjük is őket, de ez néha nem elég.
Több ügyfelünk jelezte, hogy a webszerver nem tud 1-2MB-nál nagyobb POST adatokat fogadni. Ezen lehet állítani, de ha a szerver nem saját, akkor a szolgáltató általában elhárítja az ilyen kéréseket. A WebSyX már korábban is darabolt bizonyos adatokat. Azok az adatok, amelyek biztosan nagyok (termékképek, dokumentumok) már eddig is 10-es, 20-as csomagokban utaztak. Bizonyos esetekben azonban a termék készlet feltöltése is elérheti az 1-2MB-ot.
Hogy az ügyfeleink (pontosabban az ő webesük) meg tudja oldani a szinkront, egy új beállítást vezettünk be. Az adatokat tömörítve is lehet küldeni. Ilyen esetben a megérkező adat egy csomagolt XML.
Feltöltés oldalon használt: DeflateStream sw = new DeflateStream(ms, CompressionMode.Compress)
Webszerver oldalon használt: $data = gzinflate(base64_decode($_POST[“xmldata”]));
A bejegyzés azért íródott, mert ismét belefutottunk az informatikai inkompatibilitásba. Még a Concorde Értékpapír Zrt-nél találkoztunk azzal, hogy a Corba (akkor még XML helyett ez volt) másképp kezeli a dátumokat Delphiből és Javaból. Itt is hasonló a helyzet. A sima GZipStream-mel előállított, tömörített adat csak nem akart kicsomagolódni gzdecode()-dal és gzuncompress()-szel, a gzinflate() lett a megoldás. Sőt az gzdecode() függvény az alap PHP-nak nem is része, míg a gzencode() igen. Ez is érdekes…
https://www.symboltech.hu/wp-content/uploads/2014/09/UT8-Compression-Large-Strings.png411676adminhttps://www.symboltech.hu/wp-content/uploads/2017/01/ST_logo-1-300x154.pngadmin2014-09-02 09:33:262014-09-02 09:33:26Tömörített adatok átvitele C# és PHP között
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.
https://www.symboltech.hu/wp-content/uploads/2014/08/lab.jpg336448adminhttps://www.symboltech.hu/wp-content/uploads/2017/01/ST_logo-1-300x154.pngadmin2009-08-07 08:45:522009-08-07 08:45:52Még mindig nagyon gyenge a .NET Entity Framework 4.0 béta
Gyakran fordul elő, hogy homokórát kell megjelenítenünk, mert valamilyen művelet hosszabb időt vehet igénybe. A felhasználó pedig várakozzon, ahelyett, hogy a beviteli mezőket próbálja szerkeszteni vagy a gombokat működésre bírni.
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:
A műveletek minden esetben “homokórázni” fognak.
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.
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.
https://www.symboltech.hu/wp-content/uploads/2014/08/lab.jpg336448adminhttps://www.symboltech.hu/wp-content/uploads/2017/01/ST_logo-1-300x154.pngadmin2009-07-12 10:13:562009-07-12 10:13:56Ha várni kell a Windowsban – A jó öreg homokóra
Tesztelő csapatunk fura hibával állt elő, nemsokára megjelenő program release-ünk áttekintésekor. A TAB-bal való navigáció – amely a Win95 környékén jelenhetett meg és minden felhasználó hozzászokott az elmúlt 15 évben – valahol elveszti működését és megáll.
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.
https://www.symboltech.hu/wp-content/uploads/2014/08/lab.jpg336448adminhttps://www.symboltech.hu/wp-content/uploads/2017/01/ST_logo-1-300x154.pngadmin2009-07-09 20:35:552009-07-09 20:35:55TabCsapda – hol a kurzor?
A kivételkezelés alatt sok fejlesztő a catch ág megvalósítását gondolja, de ugyanolyan fontos a kivételek eldobása is. Nem szabad azzal megelégedni, hogy dobunk egy ApplicationException-t, sokkal precízebb, ha a típusos esetekben (rossz paraméter, nem jó képformátum) a beépített kivételosztályokat használjuk.
Lássuk, mik ezek:
Kivétel osztály
Kiváltás oka
SystemException
Futásidejű hiba, a kivételes ősosztálya
AccessException
Egy típus elemeléréseinek hibája (metódus, mező, property)
ArgumentException
Metódushívás esetén hibás paraméter
ArgumentNullException
Metódushívás esetén null paraméter, ha azt a metódus nem tudja kezelni
ArgumentOutOfRangeException
Paraméter értéke adott határokon kívül esik
ArithmeticException
“Matematikai” hiba
ArrayTypeMismatchException
Típusos tömbön végzett művelet egy idegen típussal
BadImageFormatException
Rossz képformátum
CoreException
Futásidejű kivételes ősosztálya
DivideByZeroException
Nullával való osztás
FormatException
Argumentum formátuma nem helyes (pl: String.Format)
IndexOutOfRangeException
Tömb indexelése túlmutat a határokon
InvalidCastExpression
Futásidejű Cast művelet nem hajtható végre
InvalidOperationException
Nem megfelelő (idejű?) művelet hívása
MissingMemberException
DLL verziószám ütközés, eltérés metódushívás közben
NotFiniteNumberException
Nem valós szám (decimal, float; NaN, Infinity)
NotSupportedException
Nem létező metódus hívása (reflection?)
NullReferenceException
NULL értékű változó által hivatkozott objektum elérése
OutOfMemoryException
Memória elfogyás
StackOverflowException
Verem műveletek memória elfogyása (rekurízió)
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.
C#, remek nyelv. Szinte mindent lehet sorosítani, XML-be menteni. Nem is kell kézzel ezeket megírni, összerakni. De egy pár dolog kimaradt. Talán oka is van, hogy miért, de ez nem lényeg. A lényeg, hogy meg lehet valósítani.
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));
public void WriteXml(XmlWriter writer)
{
XmlSerializer keySerializer = new XmlSerializer(typeof(TKey));
XmlSerializer valueSerializer = new XmlSerializer(typeof(TValue));
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.
Ügyviteli rendszereknél ritka, hogy diagramot jelenítünk meg valamit, hiszen minden adat táblákban van, azok megjelenítéséhez pedig ideális valamiféle grid. Néha szoktak beépített grafikon segítségével felhasználókat elképráztatni, de az egyedi rajzolásos digram nem mindennapos.
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.
https://www.symboltech.hu/wp-content/uploads/2014/08/lab.jpg336448adminhttps://www.symboltech.hu/wp-content/uploads/2017/01/ST_logo-1-300x154.pngadmin2009-07-06 07:50:382009-07-06 07:50:38Diagram engine – miért C#
Napvilágot látott (le is tölthető, meg is vásárolható lassan) a Microsoft új operációs rendszere, amely felhasználói szemmel újdonság, fejlesztői szemmel kihívás.
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:
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:
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.