Ö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:

Még 3 nap a WP 7-nek

December 31. nagy nap lesz a Windows Phone 7 életében: ez lesz az utolsó nap, amikor még lehet 7.x telefonokat developer unlockolni (mi erre a hivatalos és érthető magyar kifejezés?). Azok a készülékek, amiken eddig elvégezzük az unlockot, két évig még használhatóak lesznek tesztelésre, viszont január elseje után már csak 8.x verziószámú készülékek unlockolása lesz lehetséges. Persze emulátorban később is tudunk majd a korábbi operációs rendszer verzión tesztelni.

Magyarul, aki még WP 7-re fejleszt, annak célszerű a legújabb készülékét is bevonni, mert ha most nem teszi, később nem fog menni. Ha elromlik a most tesztelésre használt eszköz, akkor hiába vásárolunk egy régit használtan, nem fogjuk tudni unlockolni és csak akkor tudunk rajta saját alkalmazást futtatni, ha előbb azt publikáljuk az Áruházban.

Ez a határidő sem a WP 8 készülékeket, sem pedig végfelhasználókat nem érinti.

Mi fog kisülni ebből? Szerintem az, hogy egyre több lesz az olyan alkalmazás, amik már csak a 8.x operációs rendszeren fognak futni, korábbi készülékeken nem. Ez azért különösen szomorú, mert már most nagyon sok olyan app van, ami látszólag semmi olyat nem használ, amihez 8.x kellene, simán futhatna 7.x-en is, ha a fejlesztő venné a fáradságot is úgy is elérhetővé tenné. Sajnos ez a pofon egyre többször csattan a 7.x tulajdonosokon, akik csak úgy válhatnak a legújabb alkalmazások felhasználóivá, hogy telefont cserélnek, ami drága mulatság lehet.

Mit tegyen mondjuk egy Lumia 800 tulajdonos, aki megvárta, hogy kijöjjön a 7.5 (mert nem akart első generációs készüléket venni), majd drágán megvette a felső kategóriás készülékét, de a boldogsága csak addig tartott, amíg ki nem derült, hogy nem fog tudni 8.0-ra frissíteni? A hardver vígan működik, csak egyre kevesebb friss alkalmazás lesz rá.

Szerintetek ez jó politika a cég részéről?

 

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

E-mail címeket karácsonyra

Karácsony előtt megnövekszik azoknak a kéretlen leveleknek a száma, amik valamit rá akarnak sózni az emberre. Az alábbi egy kicsit kilóg a sorból:

email-lists-1

Igen, e-mail cím listákat árulnak, néhányszor tíz dollárért, országonkénti bontásban. Összesen 228 ország szerepel a listában, az árak 50 és 500 dollár között változnak, Tanzánia például az olcsóbb kategóriába esik, a legdrágább pedig az Egyesült Királyság. Az ár szempontjából Magyarország igen előkelő helyet foglal el:

email-lists-2

Alig több, mint 100 ezer forintért közel 423 ezer e-mail címet vásárolhatunk, azaz egyetlen címért körülbelül egynegyed forintot kell fizetnünk. Ennyit ér tehát a postaládánk a feketepiacon. (Talán itt érdemes egy pillanatra megállnunk és elgondolkodnunk, hogy nekünk mennyit ér.)

Nézzük, hogy ez mit jelent a többi országhoz képest, például tekintsük azokat, akik velünk egy árkategóriában ($400) vannak:

Ország Darabszám Egységár
Oroszország 2.006.321 0,05 Ft
Franciaország 1.393.935 0,07 Ft
Kanada 1.288.691 0,08 Ft
Csehország 1.236.800 0,08 Ft
Olaszország 1.207.026 0,09 Ft
Japán 1.170.301 0,09 Ft
Ausztrália 1.087.139 0,09 Ft
Lengyelország 796.495 0,13 Ft
Kína 604.476 0,17 Ft
Magyarország 422.919 0,24 Ft

A táblázat szerint nem csak a nagy országokéhoz, hanem a környező országok áraihoz képest is drága a magyar e-mail cím. Minőségi magyar termék ;-)

Persze modern karácsonyról lévén szó, nem egyszerű termékről van szó, hanem SaaS ajánlatról, ami ezúttal Spam az a Service-t jelent:

email-lists-3

Ha ismét matekozunk egy kicsit, akkor az jön ki, hogy 5 fillérért küldhetünk ki egy kéretlen levelet bármelyik országba. Sokkal kedvezőbb, mint a hagyományos posta!

Ráadásul biztosak lehetünk abban, hogy a szolgáltatás működik, hiszen én is megkaptam ezt a kéretlen levelet. Ha nem érdekel, vajon kattintsak a levél végén található “Unsubscribe” linkre? ;-)

 

Technorati Tags: ,,
Kategóriák:Biztonság Címke:
Követem

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

Csatlakozz a 87 követőhöz

%d blogger ezt szereti: