Az AJAX egy olyan technika, amellyel hozzáférhetünk a szerverhez a weboldalunk használatával. A neve az Asynchronous Javascript And XML akronímja. Használatának előnye, hogy:
A jQuery fogalmát legelőször a bootstrap áttekintőben említettem meg, de mi is ez valójában? Legegyszerűbben fogalmazva egy JavaScript könyvtár. Lehetőség van a következő dolgokra a segítségével: Continue reading
Egyik eszköz, amely az MVC webes projektem megvalósítása során használatba lett véve a Bootstrap nevezetű keretrendszer lett. A Bootstrap egy igen hasznos kis keretrendszer, melynek segítségével dinamikusabban, és egyszerűbben mehet a weboldal fejlesztése, ugyanis kínál egy alap felhasználói felületet, amit később a fejlesztők személyre tudnak szabni. Ez egy jó dolog az olyan fejlesztőknek, akik nem kifejezetten vannak megáldva a weblap design tehetségével, vagy időt akarnak vele spórolni. Continue reading
Az Entity Framework Code First -öt a projektben főleg a rugalmasabb adatbázis létrehozására, alakítására, optimalizálására fogom használni. Az EFCF feladata elsősorban az lesz, hogy a C# -ban létrehozott osztályok, kontextus osztályok alapján adatbázisokat hozzon létre. Így nagyobb hangsúlyt lehet fektetni magára az oldal designra, ahelyett, hogy a régi módszer szerint felépített adatbázis köré tervezett oldalt fejlesztenénk. Continue reading
A következő API, amelyre sort kerítettem a Microsoft Graph API, amellyel az összes létező Microsoft API elérhető egyetlen token segítségével, így azt nem kell minden API -nál külön kérni. Az MS Graph felhő szolgáltatásába beletartozik az Azure Active Directory, Office365, SharePoint, OneDrive, OneNote, és Planner is.
A hozzáféréshez igyekeztek a többi nagy felhő szolgáltató által alkalmazott szabványhoz igazodni, így is könnyebbé téve a rendszer használatát. Először is szükségünk lesz egy Microsoft fiókra, amiben regisztrálnunk kell egy új alkalmazást. A regisztráció kezdetén csak az alkalmazást kell megadnunk, a mi esetünkben az legyen mondjuk GraphAPItest. A program legenerálása után megkapjuk az alkalmazás azonosítóját, lejjebb pedig generálhatunk alkalmazás titkot hozzá.
Következőnek a Facebook API irányába indultam el kutatásom alatt. A hivatalos Facebook SDK beszerezhető a https://github.com/facebook-csharp-sdk/facebook-csharp-sdk oldalról. A dokumentáció, ami segítségemre volt pedig a https://developers.facebook.com/docs/ oldalon érhető el. Ebben az esetben egy elég egyszerű oldalt készítettem el, amely egy gombot tartalmaz.
A következő szociális oldal API, aminek nekiálltam a LinkedIn , azon belül is a Sparkle.LinkedIn nevű API. Az API beszerezhető a https://github.com/SparkleNetworks/LinkedInNET oldalról, vagy a Visual Studióban, a Nuget csomagkezelőn keresztül az Install-Package Sparkle.LinkedInNET parancs futtatásával. Egy alap dokumentációt, ami a REST API, és OAuth részeket nagyjából lefedi a https://developer.linkedin.com/docs címen érhetjük el. Ezek segítségével valósítottam meg a kis kód részletet, amellyel felhasználói adatokat tudtam lekérdezni a LinkedIn oldaláról.
EmguCV használata a projektben
Legkönnyebben: NuGet-tel le lehet tölteni, bár a frissítés dátuma alapján, nem egy friss változat, közel fél évvel le van maradva a hivatalos kiadástól. (Changelog-ok alapján nekem ez is megfelel.)
NuGet-tel: Install-Package EmguCV, az alábbi package-ek lesznek még hozzáadva a projekthez: ZedGraph és OpenTK. Az EmguCV részéről pedig három fájl:Emgu.CV.UI.dll, Emgu.CV.UI.GL.dll, Emgu.CV.World.dll.
Add Reference-féle importálásnál pedig a fent már említett három fájlt beimportáljuk, illetve célszerű a ZedGraph-ot is mellékelni.
Képfelismerés
A programozás a Visual Studio 2015-ben, C# nyelvben történt. A példaprogram jelenleg felismeri a négyzeteket, kigyomlálja azokat, amelyeket esetleg kétszer ismert fel. (Például ha vastag a vonal vagy rossz minőségű a kép.) A kód nagy része a hivatalos példából származik, de jónéhány változtatást eszközöltem rajta.
A program bal oldali képdobozában az eredeti, feldolgozásra váró kép jelenik meg. Ezután az Elemzés gombra kattintva megjelennek a program által talált négyzetek a jobb oldali dobozban.
Jobb oldali TextBoxban pedig az algoritmusom munkája látszik, megnézi, hogy a négyzetek közül melyek vannak bejelölve, illetve kiírja a négyzetek középpontjainak a koordinátáit. Amennyiben be van jelölve egy opció, akkor a válaszhoz tartozó négyzetet nem látja a képfelismerő, ahogy az a következő példán is látszik:
Továbbá már az érvénytelen választ (itt: egynél több van bejelölve) is képes kezelni. A válaszok kezelése (mi van bejelölve és mi nincs) lista segítségével van megvalósítva.
A négyzetfelismerést kipróbáltam létező kérdőíven is, mely kiváló eredményt hozott.
Tervezett főbb funkciók listája (2016. december)
Szakdolgozat II befejezésére:
Opcionális funkciók
Javítások kitöltés közben, hibakezelés
Sokakkal előfordult – velem is -, hogy kitöltés közben elkalandozott, vagy félrecsúszott a keze és rossz opciót jelölt be. Mivel a programot fel kell készíteni az összes lehetséges helyzetre, így erre is. Az általam látott kérdőívek többségénél az volt látható, hogy a véletlenül bejelölt választ egyszerűen csak lesatírozták, aztán a jót pedig nyilvánvalóan x-szel jelölték. Emiatt nekem az fordult meg a fejemben, hogy ha egy sorban az x adható válasz helyett x+n választ adtak, akkor össze kell hasonlítani a bejelölt válaszokat, az alábbi módon:
Algoritmus megtalálja a négyzeteket, azokat kivágja, majd összehasonlítja a kettőt, amelyikben több nem fehér (vagy háttérszín) pixel van, az lesz a kérdésre adott válasz.
Hibakezelés fontos dolog lesz, hiszen a hiányosan kitöltött kérdőíveket fel kell ismerni, nem akadhat be a program, hogy keresi az adott kérdésre a választ, de ahhoz vagy nem töltöttek ki semmit, vagy mindent kitöltöttek. Például amennyiben közel az összes választ bejelölte valaki, de csak egyet kellett volna, akkor azt a válaszát érvénytelennek jelöljük és ugrunk tovább a többire.
Kimutatásnál jól jöhet, hogy melyik kérdésre hány feldolgozható, érvénytelen és üres válasz érkezett, ezzel a kérdésekről is készülne visszajelzés, amelyek alapján talán lehetne azokon is javítani.
Programcsomag elképzelése
Az általam választott projekt nem csak egy kérdőív felismerést tartalmaz, hanem egy egész programcsomagot.
A programcsomag tervezett tartalma:
Kérdőív felismerő app:
A fő alkalmazás, elindítható külön is, illetve a programcsomag részeként is. A különbség ezek között, hogy ha az egész csomagot használják, akkor projektekbe szervezhetjük a különböző kérdőívek feldolgozását, az információk (SQL címe, táblák nevei, általános beállítások) mentésre kerülnek, így az app nem kér információkat a feldolgozáshoz, ha elkülönítve van futtatva, akkor nyilván kér.
SQL szerver konfigurációs panellel:
Terveim közt szerepel, hogy az adatbázisokból legalább kétfajtát támogatok (MySQL/PostgreSQL, MSSQL), mert a MSSQL rendszerigénye a többihez viszonyítva kicsit magasnak tűnik, az esély nagy rá, hogy a programcsomag nem egy i7|16GB ram|GTX1080 kategóriájú gépen lesz futtatva, illetve a rendszerigényt szeretném alacsonyan tartani. Egynél több adatbázisrendszert pedig egyszerű támogatni, mivel nem beleégetni szeretném az adatbáziskezeléses parancsokat, hanem egy interface-t létrehozni, majd arra osztályokat. Azure támogatása sincs kizárva, de erről majd egy későbbi bejegyzésben.
Kimutatást készítő modul:
Itt egyszerű dolgokra kell gondolni, diagram, táblázat. Természetesen törekedve arra, hogy lehetőleg vektor-grafikusan lehessen menteni a képeket a kimutatásokról.
Kézírást felvivő modul:
Habár jónéhány OCR elérhető, első körben a „manuális felismerést” szeretném majd implementálni, ami annyit takarna, hogy az app kivágja azokat a részeket, ahol szövegnek kellene lennie és van is. Ennek megvalósítása aránylag egyszerűnek tűnik, a lap szélessége*0,75 hosszú vonalakat keresek, vagy ha sikerült az egész lapot beazonosítanom, akkor kivágom az előre (sablonként) megadott részt. Névfelismerésre szintén ezt használni, további részletek ebből is egy külön bejegyzésben lesznek kifejtve.
Azure – „yay or nay?”
Azure használata egy nagyon kellemes döntés lenne, semmilyen új gépet nem kellene beilleszteni a hivatali ökoszisztémába, nem kellene semmit változtatni a benti hálózati topológián. Ugyanakkor két erőteljes kérdés felmerül ezzel kapcsolatban:
1. Megéri-e?
Erre a kérdésre még nem lehet egyértelmű választ adni, hiszen nem ismert az appom sebessége, hogy milyen teljesítményű virtuális gép kellene hozzá, illetve mennyi az egy kérdőívre fordítandó keret. Viszont kényelmesnek nagyon kényelmes lenne, VM felállít, bekonfigurál, képek (kérdőívek) feltöltése, majd egyszer csak jön egy üzenet, hogy készen van, adatbázis kimentés és VM leáll.
2. Szabad-e?
Kérdőívek személyes adatokat is tartalmaznak, melyek alapján tisztán beazonosítható a kitöltő, válaszai alapján akár a politikai hovatartozása is, ezért ezek érzékeny adatnak minősülnek, melyeket elvileg csak szabályozott körülmények között szabad kiadni. Erről meg fogom kérdezni a hivatalt, hogy mi az álláspont, a felhőben való feldolgozás adatkiadásnak minősül-e a jelenleg hatályos jogszabályok alapján. Szerencsére az Azure azzal is hirdeti magát, hogy törvényi előírásoknak megfelelően lehet adatokat tárolni, amennyiben az itthoni jog teret ad ennek és az Azure-ban ez nem jelentkezik többletköltségként, akkor megfontolandó egy Azure kompatibilitást is felvenni a tervezett feature listára.
