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: ,,
Kategóriák:Adatkezelés Címke: ,

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!

 

Kategóriák:Webfejlesztés Címke: , ,

Öröklésnél elveszik az Error message tulajdonsága

Ilyen kódot már mindenki látott:

try {
  throw new Error('Oh, nooooo!');
} catch (e) {
  console.log(e.message);            // Oh, nooooo!
  console.log(e instanceof Error);   // true
}

Ha nagyon sok hasonló keletkezik, akkor előbb-utóbb az ember rájön, hogy szükség lenne saját hiba osztályokra, még JavaScriptben is. Jó ötletnek tűnhet valahogy így létrehozni egyet:

function OhNoooError() {
  Error.call(this, "Oh, nooooo!");
  this.name = "OhNoooError";
}

Az eredmény azonban meglepő lehet:

try {
  throw new OhNoooError();
} catch (e) {
  console.log(e.message);                 // undefined
  console.log(e instanceof OhNoooError);  // true
  console.log(e instanceof Error);        // false
}

Az elkapott kivételünk ugyanis nem számít klasszikus Errornak (nem abból származik), és elveszítette a message tulajdonságát is.

Íme egy módszer, amivel ezeket a hibákat orvosolni lehet:

OhNoooError.prototype = Object.create(Error.prototype);
OhNoooError.prototype.constructor = OhNoooError;

function OhNoooError() {
  this.message = "Oh, nooooo!";
  this.name = "OhNoooError";
}

A kimenet is szebb lesz:

try {
  throw new OhNoooError();
} catch (e) {
  console.log(e.message);                 // Oh, nooooo!
  console.log(e instanceof OhNoooError);  // true
  console.log(e instanceof Error);        // true
}

A lényeg tehát, hogy a message tulajdonságot kézzel kell beállítani. Ha az öröklést esetleg CoffeeScriptben az extends kulcsszóval valósítjuk meg, a message tulajdonsággal akkor is manuálisan kell elbánnunk.

 

Technorati-címkék: ,
Kategóriák:Webfejlesztés Címke: ,

WebStorm, ne keresgélj a node_modules mappában!

Idegesít, hogy szinte bármire keresel egy node.js projektben, a WebStorm legalább ezer találatot hoz a node_modules mappából?

Semmi gond, irány a Project ablak, jobb klikk a problémás mappán, majd Mark Directory As –> Excluded:

webstorm-exclude-folder-from-search

Nem fog eltűnni a mappa a Project ablakból, de már nem fognak innen bekerülni találatok a keresésbe.

Visszatenni is ugyanitt lehet: Mark Directory As –> Cancel Exclusion

webstorm-exclude-folder-from-search-cancel

 

Technorati-címkék: ,
Kategóriák:Webfejlesztés Címke: ,

Open source fejlesztés Visual Studioval

A legutóbbi LogMeIn-Microsoft Enterprise Developer Meetup utáni beszélgetésünk során az egyik résztvevő mesélte, hogy bár náluk mindenkinek van jogtiszta Visual Studioja, a cég megvásárolt több tucat licencet egy másik fejlesztőeszközhöz, mert a következő projektjüket nyílt forráskódú technológiákkal, node.js alapon fogják megvalósítani, és “ahhoz ugye a Visual Studio nem jó”.

Bár korábban a Visual Studio tényleg elsősorban .NET-es alkalmazások fejlesztésére volt ideális, az utóbbi időben a Microsoft igen komolyan nyit a nyílt forráskódú világ felé, ezért szerintem érdemes egy próbát tenni, és saját véleményt alkotni. Csináljunk hát egy egyszerű node.js projektet, pakoljunk hozzá mindent, amit ilyenkor szokás, és nézzük meg, hogy mennyire kellemes élmény mindezt Visual Studioval megtenni!

 

Repository létrehozása

Az első lépés egy közös tárhely létrehozása a kódunk számára, ami mi más lehetne mint egy Github repository. Akinek még nincs felhasználói fiókja a Githubon, pillanatok alatt létrehozhat egyet, csak el kell látogatni a github.com oldalra és ki kell tölteni ezt a roppant bonyolult űrlapot:

01v

Username-ként érdemes olyat választani, ami nem túl hosszú, és URL-ben is jól mutat.

Ha ez megvan, akkor a jobb felső sarokban a nevünk mellett található “+” ikonra kattintva csalhatjuk elő a Create menüt, amiben a New repository menüpontra kattintva haladhatunk tovább:

02v

Az új repó létrehozása igen egyszerű, az űrlapon csak a név kitöltése kötelező, de célszerű rögtön a leírás rovatot is kitölteni, mert ha belejövünk a repó gyártásba, fél év múlva fogalmunk sem lesz, hogy ezt éppen mihez hoztuk létre:

03v

Az űrlap alján van három alapból nem bekattintott opció, amivel szerintem érdemes élni:

Ha bekapcsoljuk az Initialize this repository with a README opciót, akkor a repóban rögtön lesz egy README.md nevű (így nagybetűvel, kis kiterjesztéssel) szövegfájl, ami gyakorlatilag a projektünk kezdőlapjaként viselkedik. Bátran kapcsoljuk be, így nem kell később nekünk létrehozni, és sokkal jobb érzés lesz, hogy a kódtárunk (mi a repository szó jó fordítása?) nem kong az ürességtől, máris publikáltunk benne valamit.

Az Add .gitignore megértéséhez először azt kell megtanulnunk, hogy mi az a .gitignore. Git verziókezelő esetén a repó gyökerében lévő .gitignore fájl (így kisbetűvel, név nélkül, csak kiterjesztéssel) segítségével határozhatjuk meg, hogy mik azok a fájlok, amiket nem szeretnénk betenni a közösbe. Alapértelmezés szerint ugyanis minden fájl, ami a könyvtárban van, bekerül a repóba és eljut a többi fejlesztőhöz is. Csakhogy tipikusan nem akarunk megosztani helyi naplófájlokat (*.log) vagy a fordító kimenetét, és pont az ilyen kivételeket lehet felsorolni a .gitignore-ban. Mivel egy adott fejlesztőkörnyezetre/platformra jellemző, hogy tipikusan minek nem kell bekerülnie a verziókezelő rendszerbe, ezért a Github már tartalmaz egy rakás előre gyártott .gitignore fájlt, nekünk csak választani kell a listából, de persze később módosíthatjuk majd a fájlt.

Mivel itt node.js projektet fogunk készíteni, válasszuk a Node opciót, de .NET projektek esetén a VisualStudio.gitignore jobb választás. A fájlnak van egy nem bonyolult, de sajátságos szintaktikája, amiről a dokumentációt megtalálhatjuk itt.

Az Add license opcióval egy csapásra létrehozhatunk a repónkban egy LICENSE nevű (így nagybetűvel, kiterjesztés nélkül) szövegfájlt, ami a kódunkhoz tartozó licenc szövegét tartalmazza. A különböző licencek közötti eligazodásban nekem legjobban a TLDRLegal oldal segített, de ha tudtok jobbat (akár magyar nyelvűt), kérlek írjátok meg kommentben.

Végre kattinthatunk a Create repository gombra, és pillanatok alatt el is készül forráskódunk új otthona, felül a generált fájlok, alul a README tartalma, jobb oldalt pedig az opciók:

04v

 

Repository klónozása

Az eddigi lépéseket csak a weboldalon tudjuk elvégezni, nem is szokás közvetlenül a fejlesztőkörnyezetet használni ehhez a művelethez. A következő lépés, hogy ez a repository megjelenjen a saját gépünkön, amihez –  ősmagyar szakkifejezéssel élve – le kell klónoznunk azt. A klónozáshoz szükséges a repository URL-je, amit a jobb oldalon található Copy to clipboard gombbal gyorsan a vágólapra menthetünk.

A klónozáshoz már bátran használhatjuk a Visual Studiot (én a VS 2015 CTP 6-ot fogom használni), azon belül is a Team Explorer ablakra lesz szükségünk:

05v1

A Team Explorer ablakban kattintsunk először Clone linkre, majd töltsük ki a mini űrlapot:

05v2

Az URL-t másoljuk be a vágólapról, helyi mappának pedig tetszőleges mappát megadhatunk, ami mostantól a repó gyökereként fog viselkedni. Mivel nyílt forráskódú projektek esetén nem ritka a mély könyvtárhierarchia, ami akár problémát is okozhat, célszerű rövid útvonalat választani. A sikeres klónozásról a Team Explorer közepén kapunk tájékoztatást:

06

A Team Explorer ablak alján, a Local Git Repositories részben láthatjuk felsorolva a Visual Studio által ismert összes repót, ahol most már a saját projektünk is megjelenik. Mivel ezzel szeretnénk dolgozni, kattintsunk rá duplán!

Bátran nyissuk meg a projektünk mappáját Windows Explorerben is, ahol ezt fogjuk látni:

08

A Git verziókezelő rendszer összes okossága a rejtett .git mappában található, ezért vigyázzunk erre a mappára.

 

Repository konfigurálása

Visual Studioban a projekt nevére kattintva a Team Explorer ablak Home oldalára jutunk:

07v

Itt a Settings…,

09v

majd a Global Settings gombokra kattintva azokat a Git specifikus beállításokat csalhatjuk elő, amik minden Gites projektünkre vonatkozni fognak:

11v

Hol tárolódnak ezek a beállítások? A bejelentkezett felhasználó profil mappájában lévő .gitconfig fájlban:

12

Ez egy szöveges fájl, simán megnyithatjuk Studioval, ha úgy kényelmesebbnek tűnik a szerkesztése, de ehhez érdemes elolvasni a hivatalos dokumentációt is:

13v

A Settings ablakban feltűnhetett egy Install 3rd-party tools, amire kattintva ez a képernyő fogad:

14v

Sajnos ez a képernyő csak azt mondja el, hogy mivel fog telepíteni, azt nem, hogy mit. Az Install gombra kattintva egy msysgitvs.exe akar letöltődni:

15v

Ez tartalmazza a beígért Web Platform Installert, majd azzal telepíti a Git for Windowst (msysgit), ami az eredetileg Linuxos Git Windowsos változata. Nagy baj nem lehet belőle, bátran telepíthetjük.

Ezzel meg is ágyaztunk a projektnek a gépünkön, nincs más hátra, mint kódot írni bele!

 

Értékelés

Ebben a részben a forráskód alapjait raktuk le, és ehhez szerintem a Visual Studio tökéletesen megfelelt. Hogy a Team Explorer ablak mennyire optimális és felhasználóbarát, azon lehet vitatkozni, de az tény, hogy a szükséges műveleteket egyszerűen el lehetett végezni vele. Aki nem hiszi, próbálja ki, a projekt elérhető a https://github.com/balassy/vs-node-example címen.

 

(Folytatás következik…)

Technorati Tags: ,,
Kategóriák:Visual Studio Címke: , ,

Kértem és kaptam egy .vs mappát és a Visual Studio csapattól

Biztos mindenkinek feltűnt már, hogy a Visual Studio új fájlokat hoz létre a solution mappájában, akár tetszik, akár nem. Az egyik ilyen a .suo kiterjesztésű Solution User Options fájl, ami az adott fejlesztői géphez kapcsolódó beállításokat tartalmazza, és hiába töröljük le, hamar visszanő.

vs_2013_suo

Az ilyen fejlesztő vagy fejlesztői gép szintű beállításokat tartalmazó fájlokra különösen forráskódkezelő rendszer esetén kell figyelni, hiszen nem szabad őket megosztani a többi fejlesztővel. Nem véletlen, hogy a Visual Studios projektekhez ajánlott .gitignore fájlban is első helyen szerepel a *.suo.

Sajnos nem ez az egyetlen ilyen jellegű fájl, különböző projekt típusok esetén ezek szépen el tudnak szaporodni, ami meg tudja keseríteni az életünket. Mennyivel szebb lenne, ha az összes ilyen jellegű fájl egyetlen mappában lakna!

Szerencsére a Visual Studio 2015-ben ezt már megoldották, és bepakoltak mindent egy külön mappába, amit más fejlesztőkörnyezetekhez hasonlóan .vs-nek hívnak:

vs_2015_suo

A .vs egy rejtett mappa, tehát be kell kapcsolni a Windows Explorerben a Show hidden files, folders, and drives opciót a megjelenítéséhez, ha nézegetni szeretnék (de miért is szeretnénk?). Jelenleg (Visual Studio 2015 CTP6) a .suo fájl és a Visual Basic illetve C# fordítók IntelliSense adatbázisai kerülnek ebbe a mappába, de szépen sorban minden ide fog átköltözni, és reméljük ezt a gyakorlatot az add-in gyártók is követni fogják. Amikor meglévő solutiont frissítünk VS 2015-re, nem fognak automatikusan letörlődni a korábbi fájlok, hogy minden beállításunk megmaradjon, ha ugyanarra a projektre a Visual Studio korábbi verziójával rányitnánk.

A legszebb az egészben, hogy ezt a mappát nem a Visual Studio fejlesztőcsapat találta ki. Azért került a termékbe, mert én kértem. Meg még rajtam kívül 2822 másik ember a Visual Studio UserVoice oldalon. A csapat elolvasta, átgondolta, elfogadta és megcsinálta.

Kellemes érzés, amikor a fejlesztők figyelnek a felhasználókra.

 

Technorati Tags:
Kategóriák:Visual Studio Címke:

Node.js frissítése Windows-on

Múlt héten megjelent a Node.js 0.10.36 verziója, ami sokak számára fontos lehet, mert egy olyan hibakereséssel kapcsolatos javítást is tartalmaz, amibe sokan belefutottak.

Windows esetén a legegyszerűbben úgy frissíthetjük a gépünkön lévő futtatókörnyezetet, hogy letöltjük a legfrissebb MSI fájlt, majd next-next-finish-sel végigmegyünk a telepítőn. Utána pedig a node –v paranccsal tudjuk ellenőrizni, hogy valóban sikerült-e a megfelelő verziót telepítenünk.

 

Technorati-címkék:
Kategóriák:Webfejlesztés Címke:
Követem

Értesítést küldünk minden új bejegyzésről a megadott e-mail címre.

Csatlakozz a 88 követőhöz

%d blogger ezt szereti: