Ö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: JavaScript,NodeJS

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:

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

 

Technorati-címkék: WebStorm,node.js

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:

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:

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:

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:

 

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:

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

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:

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:

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:

Itt a Settings…,

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

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

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:

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

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:

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: Visual Studio,Git,open source

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ő.

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:

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: Visual Studio