György Balássy bejegyzései

BKK Futár Microsoft Bandre (1. rész)

ms-band-1Nem rég szerencsés tulajdonosa lettem egy Microsoft Bandnek, és természetesen legjobban arra voltam kíváncsi, hogyan készíthetek rá saját alkalmazást. Első célul azt tűztem ki, hogy a BKK Futártól származó információkat fogom rajta megjeleníteni, hiszen milyen jó lenne, hogy amikor kilépek a lakásból csak ránézek az órámra, és rögtön látom, hogy mikor jön a következő buszom. Bandiban van GPS, a telefonon keresztül kilát az internetre, így első körben ez a feladat megvalósíthatónak látszott.

Korlátlan lehetőségek fejlesztőknek

A Microsoft Band “For Developers” oldalára ellátogatva gyorsan fel tudjuk mérni, hogy fejlesztőként háromféle irányból támadhatjuk meg ezt az eszközt.

A Band SDK-t felhasználva készíthetünk egy Windows, Android vagy iOS alkalmazást, ami képes kommunikálni a Band-del. Van szép PDF dokumentáció sok példakóddal, sőt még design guidelines-t is kapunk. A telefonon futó alkalmazás eléri a szenzorokat, új csempéket, azon belül pedig oldalakat és UI vezérlőket tud megjeleníteni.

Készítethetünk Web Tile-t, amihez még különösebb fejlesztői tudás sem kell. Egy böngészőben futó varázsló segítségével kiválaszthatjuk, hogy milyen URL-ről érkező adatokat milyen formában szeretnénk megjeleníteni. A web tile JSON vagy RSS adatokat tud letölteni és megmutatni, sőt még arra is képes, hogy ha a letöltött adatok megfelelnek az általunk megadott feltételnek, akkor a Band megjelenít egy értesítést. Ezek a lehetséges elrendezések:

ms-band-2-tile-layouts

Az elkészült Web Tile-t a készítő feltöltheti egy galériába, ahonnan bárki két kattintással letöltheti azt a telefonjára, majd onnan a Bandjére.

A harmadik lehetőség a Microsoft Health Cloud API használata, ahol egy szép REST API-n keresztül kérhetünk le adatokat a felhasználóról és edzéseiről. Az API kevés végpontot tartalmaz, de ezek sok adatot tudnak visszaadni:

ms-band-3-swagger

A korlátlan lehetőségei korlátai

Első körben tehát el kell döntenünk, hogy hogyan akarjuk megközelíteni a problémát: SDK-val, Web Tile-lal vagy felhős API-val.

SDK

Az első lehetőség az SDK, ami a dokumentáció alapján nagyon izgalmasnak tűnik, de fontos megérteni, hogy

nem a Bandre írjuk az alkalmazást.

Készítünk egy telefonos vagy Windowsos alkalmazást, ami használja a Bandet, de nem a Banden fut. Nincs új projekt típus a Visual Studioban, sőt még azt sem mondhatjuk el, hogy a Banden is Windows 10 futna, mert nem (még). Az alkalmazásunk szempontjából a Band leginkább egy érintőkijelzőre hasonlít, amiben vannak egyéb szenzorok is.

Ez sajnos rögtön magával hozza azt a korlátozást is, hogy a telefonos alkalmazás tudja elérni a Bandet, nem pedig a karperec a telefonos alkalmazást. Tehát készíthetünk egy olyan mobil appot, ami elkéri a Bandtől a pulzusszámunkat vagy a napi kalória fogyasztásunkat, de azt nem lehet megoldani (még), hogy az óránkon kezdeményezzünk bármit, mert a telefonos alkalmazás nélkül a Banden sem történik semmi. Azaz a telefonos alkalmazásnak mindig futnia kell, ami például Windows Phone-on egyelőre csak elég korlátozottan oldható meg (ebben a Windows 10 és a DeviceUseTrigger tud segíteni). Kivétel ez alól a Cortana, mert a Bandről indított hangvezérléssel lehet alkalmazást aktiválni a telefonon, de nálunk ugye nincs Cortana.

A második erős korlátozás a UI. Nem elég, hogy kicsi a képernyő, a felhasználható vezérlők  listája is elég rövid:

  • Egyszerű vezérlők:
    • TextBlock
    • WrappedTextBlock
    • Icon
    • Barcode
    • TextButton
    • FilledButton
  • Konténer vezérlők:
    • FlowPanel
    • ScrollFlowPanel
    • FilledPanel

A jó hír, hogy van gomb, de ne feledjük, hogy csak akkor ér valamit, ha a hozzá tartozó eseménykezelőt tartalmazó telefonos alkalmazás fut éppen.

A rossz hír, hogy gyakorlatilag nincsenek input vezérlők, se szövegdoboz, se lista, semmi. Pedig a Banden még mini billentyűzet is van, hiszen SMS-ekre tudunk onnan válaszolni, ez azonban jelenleg nem érhető el más alkalmazások számára. Arról se álmodjunk, hogy akkor majd mi megoldjuk egyszerű vezérlőkből, ugyanis azokból maximum 10 lehet egy oldalon (page-en).

Ezek után az, hogy a vezérlőkre a számukkal kell hivatkozni, és a gomb eseménykezelőt nem is a gombhoz, hanem az egész csempéhez (lényegében az alkalmazáshoz) kapcsoljuk, és a kódban kell megvizsgálni, hogy melyik gombra nyomott a felhasználó, már nem is tűnik komoly korlátozásnak.

A szenzorok között vannak olyanok (nem mind, de például a szívritmus), amit a felhasználó tudta nélkül nem lehet kiolvasni. Ez a gyakorlatban azt jelenti, hogy az alkalmazásnak először egy GetCurrentUserConsent() függvényt kell hívnia, ami feldob egy engedélykérő ablakot, ahol a felhasználó eldöntheti, hogy az app olvashatja-e azt a szenzort vagy nem. Ez rögtön meghatározza, hogy olyan alkalmazást kell írnunk, amihez tartozik felhasználói felület, azaz háttérben futó windows service-ek és headless IoT alkalmazások kizárva. Nem barkácsolhatunk olyan ventillátort, ami Bluetooth-on keresztül közvetlenül a Bandről olvassa a szívverésemet, és ha magas szívritmust érzékel, bekapcsol, mert a kijelző nélküli ventillátor nem tud engedélyt kérni a HeartRate szenzor olvasásához. Mindenképpen szükségünk van a telefonra az engedélyezés miatt.

Web Tile

A Web Tile egyszerűen elkészíthető és praktikus megoldás például hírportálok információinak megjelenítésére: csak rákötöm a meglévő RSS feedre és már készen is van. Érdemes azonban átgondolni, hogy valóban a meglévő JSON-os végpont vagy RSS feed a legoptimálisabb-e a Band számára, mert a kijelző mérete korlátos, és a web tile nem képes a letöltött adatokon semmilyen formázást elvégezni. A varázslóban csak azt tudjuk megmondani, hogy a szervertől kapott JSON válasz egyes property-jei melyik TextBlockokban jelenjenek meg. Ha a szöveg túl hosszú, nem fog kiférni (kivéve a görgethető elrendezés esetén), hanem egyszerűen levágódik. A legbonyolultabb művelet a sztring összefűzés (több property megjelenítése egy TextBlockban), de arról ne is álmodjunk, hogy számot fogunk dátummá konvertálni, vagy kiszámoljuk az eltelt időt két időpont között.

Ahogy a fenti képen is látszik, a varázsló felkínálja, hogy válasszunk a 6 előre definiált oldalrendezés közül. Más lehetőségünk nincs, ezek valamelyikén (vagy több oldalon) kell elrendeznünk a megjeleníteni kívánt információkat. A hatból 3 elrendezés képes képet megjeleníteni, ezek azonban csak kis méretű, átlátszó hátterű, fehér ikonok lehetnek, amik már a tile telepítésekor rendelkezésre állnak. Arra például nincs lehetőségünk, hogy fotót vagy szerverről letöltött képet jelenítsünk meg (például árfolyamok alakulása on-demand rajzolva). Jó hír viszont, hogy a csomagba tehetünk több ikont, és meghatározhatjuk, hogy feltételtől függően melyik jelenjen meg (például különböző időjárás ikonok).

Érdemes egyébként elolvasni a web tile specifikációt, mert a varázsló csak a fontosabb paramétereket állítja be, nem kérdez rá mindenre. Az egyik ilyen kimaradó paraméter a refreshIntervalMinutes, amivel azt állíthatjuk be, hogy milyen gyakran frissüljön a csempe. Ennek az értéke alapértelmezés szerint 30 perc, de akár 15 percre is állíthatjuk (sűrűbbre nem). Ehhez nevezzük át a varázsló által generált .webtile fájlt .zip-re, csomagoljuk ki, majd módosítsuk a benne található manifest.json fájlt.

Sajnos a gyakorlatban azt tapasztaltam (és a StackOverflow szerint nem vagyok ezzel egyedül), hogy az adatok néha a megadottnál jóval ritkábban frissülnek, nálam volt olyan, hogy 3 óra is eltelt két frissítés között. A sikeres frissítéshez a HTTP válasznak 200 OK-val kell visszatérnie, és a szokásos kliens oldali gyorsítótárazási módszerek itt is bezavarhatnak.

A web tile által hívott URL fix és csak GET lehet, tehát ne is álmodozzunk például arról, hogy majd így küldjük fel az UV szenzor által mért értékeket.

 

Ezek alapján szerintetek hogy lenne a legpraktikusabb megvalósítani a BKK Futárt Microsoft Bandre?

 

(Folytatás következik…)

 

Technorati-címkék: ,
Reklámok

Kedvencek és bookmarkletek Microsoft Edge-ben

A Windows 10 megjelenése óta a Microsoft Edge az elsődleges böngészőm, és alapvetően meg vagyok vele elégedve. A pluginek nem hiányoznak, a minap viszont egy bookmarkletet próbáltam menteni és macerásabb volt, mint gondoltam.

Példaként vegyük a Pinterest bookmarkletet, a Pin It Buttont. Bármelyik másik böngészőben elnavigál az ember az adott weboldalra, megfogja a JavaScript kódot tartalmazó hivatkozást az oldalon, és feldobja a kedvencei közé. Ez Edge-ben biztonsági okokból nem megy, de körül lehet táncolni.

A 2015. novemberi nagy frissítés előtt egyszerűbb volt a helyzet, a kedvencek ugyanis közvetlenül a fájlrendszerben ültek, ebben a mappában:

C:\Users\{FELHASZNÁLÓNÉV}\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC\MicrosoftEdge\User\Default\Favorites

Az interneten fellelhető források szerint most viszont már a spartan.edb ESE adatbázisban laknak, itt:

C:\Users\{FELHASZNÁLÓNÉV}\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC\MicrosoftEdge\User\Default\DataStore\Data\nouser1\120712-0049\DBStore

Ezt sajnos macerás szerkesztgetni, de úgy tűnik, hogy szerencsére a böngésző a registry-t is használja, ezen az útvonalon megtaláltam az elmentett kedvenceket:

HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\FavOrder\FavBarCache

Ezt kihasználva a következő módon tudtam magamnál Pinterest bookmarkletet menteni:

  1. Ellátogattam a Pinterest bookmarklet oldalára, majd a “Pin It” gombra jobb egérrel kattintva, és a megjelenő menüből a Copy Link menüpontot választva elmentettem a vágólapra a bookmarklet JavaScript kódját.
  2. Ezután felvettem a kedvencek közé ezt az oldalt csak azért, hogy a Pinterest ikonja jelenjen meg a böngészőben a bookmarkletem mellett.
  3. Megnyitottam a Regeditet, és elnavigáltam a fenti útvonalra.
  4. A legnagyobb számú mappa volt az utoljára létrehozott, azon belül az url kulcsba bemásoltam a vágólapról a JavaScript kódot.
  5. Újraindítottam a böngészőt.

bookmarklet-regedit

Ez abszolút nem hivatalos, nem támogatott és nem is tuti megoldás, nálam működik.

 

Chocolatey és a biztonság

Úgy döntöttem, hogy a Windows 10-zel frissen újratelepített gépemre Chocolatey-vel fogom feltelepíteni az alkalmazásokat. Valójában az első ötletem az volt, hogy OneGet-et fogok használni, ami a Windows 10-ben megjelent csomagkezelő-kezelő, és aminek van egy előzetes Chocolatey providere, de mivel ezzel rövid kísérletezés után nem sok sikerélményem volt, maradtam közvetlenül a Chocolatey-nél.

Az első lépés a Chocolatey telepítése, aminek legegyszerűbb módja admin parancssorban annak az egysoros szkriptnek a futtatása, ami megtalálható a chocolatey.org honlapon:

C:\> @powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((new-object net.webclient).DownloadString(‘https://chocolatey.org/install.ps1’))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

Ezzel a paranccsal három dolgot érünk el egy csapásra:

  1. Letöltünk egy PowerShell szkriptet.
  2. Futtatjuk a letöltött szkriptet a saját gépünkön rendszergazdai jogosultságokkal.
  3. Kiegészítjük a PATH környezeti változónkat.

Nem tudom, ki hogy van vele, a 2. lépéstől kiráz a hideg. És ha már itt tartunk, álljunk meg egy pillanatra és gondoljuk végig, mire vállalkozunk: gyakorlatilag ismeretlen forrásból származó alkalmazásokat fogunk telepíteni a gépünkre, hiszen amikor kiadjuk mondjuk a

choco install adobereader

parancsot, akkor fogalmunk sincs, hogy honnan mi fog letöltődni és települni a gépünkre.

Mit tehetünk?

Először is csak olyan choco csomagokat telepítsünk, amiket moderátorok jóváhagytak. A moderálás egy manuális folyamat, csúszhat bele hiba, de mégis egyfajta ellenőrzés. Egy moderált csomag, például az Adobe Reader oldalán ez jelenik meg felül nagy zöld keretben:

This package was approved by moderator gep13 on 6/11/2015.

Egy moderátori ellenőrzésen nem átesett csomag, például a Notepad2 esetén ugyanott piros keretben ezt találjuk:

This package was submitted prior to moderation and has not been approved. While it is likely safe for you, there is more risk involved.

Ha már a csomag részletes oldalán vagyunk, érdemes elolvasni mindent, amit ott találunk. Például a 7-zip csomag oldalán ezzel a figyelmeztetéssel találkozhatunk:

NOTE: The installer for 7-Zip is known to close the explorer process. This means you may lose current work.

Ugyanitt találkozhatunk hasznos opciókkal is, például Firefox esetén megadhatjuk, milyen nyelvű verziót szeretnénk telepíteni:

choco install Firefox -packageParameters "l=en-US"

Ha pedig egy kicsit lejjebb görgetünk, a kommentek között találhatunk olyan utalásokat, amik eltántoríthatnak minket egy-egy csomag telepítésétől. A CDBurnerXP csomag kommentjei között megemlítik az OpenCandy nevű szemetet, amiről eszembe jutott, hogy bizony nem egy olyan telepítővel találkoztam már, amin ha ész nélkül next-next-finish-sel megyünk végig, kapunk “ajándékba” egyéb programokat is.

Az oldal közepe táján sok esetben megtaláljuk a telepítő PowerShell szkriptet, érdemes lehet átnézni, mert abból kiderülhet, hogy milyen telepítőcsomagot tölt le és honnan. Az Adobe Reader csomagjánál ez a szkript mindössze 6 sor, a közepén ott virít az URL és könnyen érthető, hogy mi történik. De ugyanezt nem lehet elmondani a Firefox csomag 117 soros szkriptjéről, vagy a Node.js csomag egyetlen soros szkriptjéről, ami két másik csomagra hivatkozik.

Összességében a Chocolatey használata véleményem szerint egy jókora lutri. Elvégezhetjük ezeket a manuális ellenőrzéseket, frissíthetjük az operációs rendszerünket, beüzemelhetünk egy víruskeresőt, kiszűrhetjük a csibész hostokat, de a végeredmény az, hogy ismeretlen szerző ismeretlen kódját futtatjuk a gépünkön, ami sehogy sem tűnik jó ötletnek.

Én ezeket a csomagokat telepítettem fel, egyelőre nem égett le a ház tőlük:

adobereader
7zip
emet
fiddler
filezilla
firefox -packageParameters "l=en-US"
gitextensions
google-chrome-x64
join.me
keepass
nodejs
paint.net
silverlight
skype
sysinternals
vlc

Ti mit gondoltok, használtok ilyet, meritek használni, és ha igen, milyen csomagokat szoktatok még feltenni?

 

Technorati-címkék: ,,

Bitlocker TPM nélkül

A közhiedelemmel ellentétben igenis használható a Windows beépített Bitlockere a merevlemez tartalmának titkosítására akkor is, ha nincs a gépünkben TPM chip. Azokat a meghajtókat, amik az adatainkat tartalmazzák, simán hagyja is a Windows titkosítani, mindössze egy jelszót kér, és felajánlja a recovery key mentését fájlba, USB meghajtóra, sőt akár a felhőbe is. Ha viszont a C: meghajtónkat akarjuk bebitlockerezni, akkor találkozhatunk ezzel a hibaüzenettel:

This device can’t use a Trusted Platform Module. Your administrator must set the “Allow BitLocker without a compatible TPM” option in the “Require additional authentication at startup” policy for OS volumes.

bitlocker-1-tpm-error

Szerintem ez egy egészen jó hibaüzenet, mert megmondja, hogy mi a gond, és azt is, hogyan tudunk kimászni belőle. Ha még azt is megmondaná, hol keressük pontosan ezt a beállítást, egészen tökéletes lenne!

A “policy” szóra keresve ugyanis léptem nyomon a Local Security Policy-ba futhatunk bele, pedig nem az kell. A Group Policy Object Editorra van szükségünk még akkor is, ha workgroupban van az adott gép és nem tartományban. (A csoportházirendekről nekem mindig a címtár jut eszembe…)

Indítsunk tehát egy Microsoft Management Console-t (mmc), majd adjuk hozzá a Group Policy Object Editor snap-int (katt a teljes képért):

bitlocker-2-mmc-add-snapin

Ezen belül a Local Computer Policy –> Computer Configuration –> Administrative Templates –> Windows Components –> BitLocker Drive Encryption –> Operating System Drives ág alatt találhatjuk meg a hibaüzenetben megjelölt beállítást:

bitlocker-3-policy-path

A beállításra duplán kattintva előbb válasszuk ki az Enabled lehetőséget, majd alul pipáljuk be az Allow Bitlocker without a compatible TPM jelölőnégyzetet:

bitlocker-4-policy-setting

Miután mindent leokéztunk még frissítenünk kell a házirendet, amit a gépünk újraindítása nélkül legegyszerűbben parancssorból a gpupdate parancs kiadásával tehetünk meg:

bitlocker-5-gpupdate

Ezután már gond nélkül titkosíthatjuk az operációs rendszert tartalmazó meghajtónkat is.

 

Technorati-címkék: ,,

Windows 10 telepítés: UEFI, secure boot, USB, GPT, error

Windows 10-et próbáltam telepíteni, amihez letöltöttem az ISO image-et az MSDN-ről, majd a jól bevált Windows USB/DVD Download Tool segítségével kiírtam pendrive-ra. Azonban a gép nem akarta felismerni a pendrive-ot, nem kínálta fel azt a lehetőséget, hogy bootoljak róla. A BIOS-ban a boot beállítások UEFI boot ON, secure boot ON értéken álltak, ami jól bevált az adott gépen korábban futó Windows 8.1 esetén, de most épp ez okozta a problémát. Ha átkapcsoltam ugyanis Legacy boot ON, secure boot OFF értékre, akkor máris megjelent a pendrive, és el is indult a telepítés. Itt azonban még nincs vége a történetnek, később ugyanis elakadt a telepítő

Windows cannot be installed to this disk. The selected disk is of the GPT partition style.

hibaüzenettel.

windows-install-gpt-error

Rövid guglizás után számos megoldást találtam arra, hogy lehet egy GPT partíciót MBR-re alakítani (a teljes diszken lévő adatok elvesztésével vagy 3rd party boot CD-vel), de szerencsére annál van egyszerűbb megoldás is.

 

Az egyszerűbb megoldás

A probléma valódi gyökere, hogy az UEFI boot nem megy NTFS-re formázott pendrive-val (legalábbis az én gépemen), a megoldás tehát, hogy

FAT32-es pendrive kell.

Sajnos az eszköz, amit az ISO image kiírásához használtam, mindenképp NTFS-re formázza a pendrive-ot, még akkor is, ha korábban már meg volt formázva, tehát máshogy kell előkészítenünk a telepítő pendrive-ot.

Például diskpart, ami egy beépített parancssori eszköz a Windows-ban.

Indítsuk el:

diskpart

Listázzuk a meghajtókat:

list disk

A listában meg fog jelenni a pendrive is (mert remélhetőleg előtte bedugtuk), a mérete alapján meg fogjuk ismerni. Válasszuk ki:

select disk 2 (a 2 helyére természetesen a valódi szám kerüljön)

Töröljük le (minden adat el fog veszni):

clean

Hozzunk létre rajta egy FAT32 partíciót:

create partition primary
select partition 1
active
format quick fs=fat32
assign

Ezután ki is léphetünk a diskpartból:

exit

Ezután már csak rá kell másolnunk a telepítőkészletet a pendrive-ra. Ehhez először mountoljuk fel az ISO-t, majd másolhatunk például így (a példában D: a felmountolt ISO, F: a cél pendrive):

xcopy d:\* f:\ /s /e

Ezek után már fel fogja ismerni a BIOS a pendrive-ot, és a meghajtó kiválasztásánál sem lesz probléma a GPT partícióval.

 

Technorati-címkék: ,,

Szerdán SQL-es developer meetup

Ezen a héten szerdán ötödik állomásához érkezik a LogMeIn és a Microsoft Magyarország közös szervezésében készülő Enterprise Developer Meetup sorozat. Erre az alkalomra csupa adatbázisos témával készülünk, lesz szó teljesítményről, biztonságról és természetesen a felhőről is. Várunk mindenkit, akit érdekelnek a Microsoft adatbázis platformjának újdonságai, akár távolabbról architektúra szintjén, akár közelebbről, kód szinten.

kalen-delaney

Az első előadónk Kalen Delaney, aki 26 éve foglalkozik az SQL Serverrel, így nem véletlen, hogy az ő nevéhez kötődik szinte az összes “inside” és “internals” könyv a témában. Kalen kifejezetten a LogMeIn meghívására érkezik hazánkba, és szerdán az SQL Server 2014-ben bevezetett, korábban “Hekaton” kódnéven futó SQL Server In-Memory OLTP-ről fog beszélni. A Hekaton lényege, hogy az adatbázis motort az adatok memóriában történő tárolására optimalizálták, amivel természetesen jelentős teljesítmény növekedést lehet elérni.

 

koszo-karoly

Második előadónkat, Kószó Károlyt a magyar SQL fejlesztőknek nem kell bemutatni, hiszen 1996 és 2013 között a Microsoft Magyarország munkatársaként számos rendezvényen adott elő az SQL Serverről. Szerdán az SQL Server jogosultságkezeléséről fog beszélni, kitérve olyan kevésbé ismert témákra is, mint a tulajdonosi lánc és az aláírt tárolt eljárások. Érdemes elmélyednünk a témában, hiszen a legféltettebb adataink biztonságáról van szó!

 

 

 

dudas-viktor

Harmadik előadónk, Dudás Viktor, korábban már szerepelt nálunk, akkor az Azure Machine Learningről és gépi tanulásról beszélt. He is back! Ezúttal a Tabular Analysis Servert veszi górcső alá, természetesen a felhőben.

 

 

 

 

A társaság jó, a részvétel ingyenes, a szervezés érdekében csak annyit kérünk, nyomjatok egy RSVP: Yes-t előre.

Bővebb információ és jelentkezés itt:
http://www.meetup.com/Enterprise-Developer-Meetup/events/221592899/

Szeretettel várunk mindenkit szerdán 19 órakor a LogMeInben (Paulay Ede u. 12.)!

 

Technorati-címkék: ,,

C# kód futtatása Node.js környezetben Roslyn segítségével

Amikor a Microsoft Managed Languages csapata 2013. decemberében bejelentette, hogy a korábbi C# és Visual Basic fordítót lecserélték, és már a Visual Studio következő verziójának napi buildjei is egy új fordítóval készülnek, hirtelen mindenki számára egyértelművé vált, hogy valami nagyon komoly dolog van készülőben. Az új, “Roslyn” kódnevű eszköz messze túlmutat a korábbi csc.exe és vbc.exe képességein és lehetőségein, nem véletlenül kapta végül a .NET Compiler Platform elnevezést.

Itt ugyanis nem egyszerűen arról van szó, hogy szeretnénk a forráskódunkat futtatható formára alakítani, hiszen arra már sok éve volt kiváló eszközünk. A Roslyn célja, hogy a fordító tudását API-kon keresztül megnyissa a fejlesztők és a fejlesztőkörnyezetek (például a Visual Studio) előtt, azaz egy fordító-mint-szolgáltatás (compiler-as-a-service) megoldásról beszélhetünk.

Miért van erre szükség? Leginkább azért, mert a fordítók nagyon összetett szerkezetek, és futásuk közben igen komoly mennyiségű információval rendelkeznek a forráskódunkról:

compiler-architecture

Ezt a tudást vétek bezárni egyetlen eszközbe, sokkal jobban járunk, ha a fordító által felhalmozott információkból más eszközök is mazsolázhatnak. A fordító az egyetlen eszközünk, amely valóban érti a forráskódunkat, hiszen a kód minden egyes betűjéről tudja, hogy az utasítás, adat, komment stb. Ezt felhasználva sokkal jobb fejlesztőeszközöket készíthetünk, például a Visual Studio 2015 kódszerkesztőjében számos funkció a Roslyn nélkül valószínűleg soha nem valósulhatott volna meg.

Az alábbi ábra a Roslyn platform felépítését mutatja (katt a teljes képért):

roslyn-architecture

Aki szeretne minden egyes dobozt megérteni, bátran látogasson el a projekt honlapjára, én itt most csak annyit emelnék ki, hogy a forráskód olvasásától az értelmezésén keresztül egészen a futtatható kód generálásáig megtalálható itt minden, és mivel platformról van szó, természetesen mindenhez van API.

A kulcs elem a sárgával bekeretezett Syntax Tree, ami a Parser által létrehozott belső reprezentációja a teljes forráskódunknak. Az ehhez tartozó API-t hívják Roslyn Syntax API-nak, aminek segítségével nem csak forráskódból értelmezhetjük a forráskódunkat, hanem módosíthatjuk is azt. Példaként vegyük az alábbi utasítást:

Regex.Match("my text", @"\pXXX");

Ebből a Roslyn az alábbi szintakszisfát építi fel:

Turner_Figure4_hires

(A példát az MSDN Magazine Use Roslyn to Write a Live Code Analyzer for Your API című cikkéből kölcsönöztem, amiben egy Visual Studio bővítményt készítenek erre alapozva.)

Hogy mi ezt a fát pusztán csak nézegetjük, elemezzük, vagy módosítjuk is, az már kizárólag csak rajtunk múlik.

Felismerte ezt a TypeScript csapat is, és az 1.3 verziótól kezdve már a Roslyn motor szolgáltatja Visual Studioban a kódszerkesztő funkciókhoz a szükséges adatokat. Ennek köszönhetően a TypeScript fordító architektúrája nem csak hogy jelentősen letisztult, hanem egyúttal könnyebben érthetővé is vált:

typescript-architecture

Történetünk szempontjából az egyik fontos komponens az alsó dobozban szereplő Parser, a másik pedig az Emitter. A Parser feladata, hogy felépítse az absztrakt szintakszisfát – jelen esetben a TypeScript forráskódból –, az Emitter feladata pedig, hogy a szintakszisfa alapján elkészítse a fordító kimenetét – jelen esetben JavaScript (.js), definíció (.d.ts) vagy source map (.js.map) formában.

Érdemes észrevenni, hogy a Roslyn és a TypeScript architektúrája teljesen hasonló: a forráskódból előbb fát építünk, majd a fából más nyelvű kódot generálunk. A Roslyn esetén ez C# –> fa –> IL, a TypeScript esetén egy TypeScript –> fa –> JavaScript.

Mivel a két fa azonos, összekapcsolhatjuk a kettőt és így máris eljutunk az alábbi megoldáshoz:

flow

Azaz a Roslyn és a TypeScript felhasználásával képesek lehetünk C# forráskódot JavaScriptre fordítani!

A módszer előnye, hogy mivel közvetlenül a C# forráskódból indulunk ki (ellentétben például a JSIL projekttel, ahol Common Intermediate Language kódot fordítanak JavaScriptre), minden olyan információ rendelkezésünkre áll, ami a forráskódban még elérhető (például láthatóság, öröklés stb.), de egyébként a C# fordító kimenetén már nem jelenik meg. Mindez meglepően hatékony optimalizálási lehetőségeket nyújt!

Példaként vegyük a JSIL projekt oldalán elérhető Raytracer demót. A teljes C# forráskód 429 sor, a JSIL által készített JavaScript kód 793 sor. Mondhatnánk,  hogy örülhetünk, hogy egyáltalán fut, csakhogy a memória kezelése korántsem optimális:

raytracer-memory

Ugyanezt a forráskódot a Roslyn Parser + TypeScript Emitter kombináción átfuttatva az alábbi eredményt kapjuk:

raytracer-memory-2

Az Internet Explorer Developer Toolsban (F12) lévő UI Responsiveness eszköz segítségével megmértük a CPU utilization és a Visual throughput (FPS) értékeket is, és mindkét mutató jelentősen jobb értékeket mutatott.

Persze a kedvezőbb memória gazdálkodás és a jobb teljesítmény nem jön ingyen, a generált kód nagyobb lett, összesen 1844 sor. A jelentős méretnövekedést az okozza, hogy az IL kóddal ellentétben a szintakszisfa tartalmaz információt az osztályokról és azokon belül a tagok láthatóságáról, amit JavaScriptben csak körülményesen lehet leképezni, de ha megtesszük (és a TypeScript Emitter meg tudja tenni), akkor több kód letöltése árán összességében jobb teljesítményt tudunk elérni. Más alkalmazások vizsgálata során is ugyanerre a megállapításra jutottunk.

A módszer természetesen nem csak böngésző alapú alkalmazásoknál, hanem natív JavaScript alkalmazásoknál, például Node.js környezetben is működik. A fejlesztés lépései a következők:

  1. Telepítsd a Node.js Tools for Visual Studio bővítményt, ami lehetővé teszi Node.js appok készítését Visual Studioval.
  2. Töltsd le a Node.js with C# bővítményt a Visual Studio Gallery oldaláról (hamarosan elérhetővé tesszük).
  3. Telepítés után meg fog jelenni Visual Studioban a C# projektek között egy “Node.js application” nevű projekt sablon, annak segítségével kell létrehozni a projektet.
  4. Írd meg az alkalmazásod forráskódját C#-ban, ehhez természetesen használhatod a Visual Studiot.
  5. A szokásos módon működik a debuggolás (F5) és a futtatás is. A projekt sablon tartalmazza a szükséges MSBuild targeteket, ami a Roslyn és a TypeScript segítségével előállítja a JavaScript kódot, amit azután a Node.js Tools for Visual Studio fog átadni a Node.js futtatókörnyezetnek.

Tesztelőket keresünk! A Visual Studio plugin publikálása előtt szeretnénk egy szélesebb körű tesztet végezni. Ha szívesen vállalkoznál erre, kérlek itt olvasd el az útmutatót, majd hagyj egy kommentet alább és felveszem veled a kapcsolatot!

 

Frissítés:

reddit-node

http://www.reddit.com/r/node/comments/31r872/write_your_nodejs_app_in_c_with_roslyn/