Coffeescript windows-on

Mostanság a node fejlesztők elszánták magukat, hogy felveszik a Windows operációs rendszereket a támogatott platformok közé. Tették ezt abból a megfontolásból, hogy a Microsoft megkereste őket egy - vélhetőleg visszautasíthatatlan - ajánlattal. Így kell a github-on pénzt csinálni kérem, a lehetőség mindenki előtt nyitva áll.
Aki még nem gazdagodott meg a szoftverbizniszből, de érdekli az egyik legtrendibbnek számító téma, de csak egy hétköznap Windows-os gépre futotta a bátorságából (Debian telepítése? parancssorból? Megőrültél?), vagy a pénzéből (Mac Mini? Ezt? Ennyiért?), azoknak sem kell tovább búsulniuk: rövid ismertető arról, hogyan lehet működő node-js + npm, valamint coffeescript környezeted.
Az első lépések részletesen, angol nyelven: Installing-on-Windows-Experimental
zanzásítva magyarul:

1. töltsük le a legutolsó stabil node.exe-t.
2. építsük fel a könyvtárstruktúrát, amire az npm vágyik. Legyen a példában a gyökérkönyvtárunk a C:\node.js
1. hozzunk létre egy bin alkönyvtárat: C:\node.js\bin
2. hozzunk létre egy lib alkönyvtárat is: C:\node.js\lib
3. helyezzük a node.exe-t a bin-be: C:\node.js\bin\node.exe
4. adjuk hozzá a PATH-hez a bin könyvárunkat: jobb klikk a My Computer-en, Properties, Advanced System Settings, Environmental Variables, path + ";C:\node.js\bin"
5. ellenőrizzük: node -v
6. Telepítsük a Git-et (ezt még kifejtem egyszer részletesebben)
7. húzzuk le az npm-et:
1. git config --system http.sslcainfo /bin/curl-ca-bundle.crt
2. git clone --recursive git://github.com/isaacs/npm.git
8. telepítsük fel:
1. cd npm
2. node cli.js install npm -gf 
9. ellenőrizzük: npm -v
10. az npm segítségével tegyük fel a coffeescriptet is:
1. npm install -g coffee-script
11. ellenőrizzük: coffee -v

Kész!

Elhunyt Dennis Ritchie

Az internet az iPhone alkotójának halálhírétől hangos, aki kétségtelenül nagy formátumú üzletember volt, de - talán mert nem rajongok a túlárazott agyon marketingelt dizájnkütyükért - az én értékrendem alapján sokkal nagyobb veszteség a világnak hogy Dennis Ritchie is eltávozott közülünk.
Ha esetleg nem ugrana be hirtelen, hogy ki is volt ő, érdemeit lásd itt.

A DataSet védőbeszéde

Mostanság egy olyan alkalmazáson dolgozom, ami a egy relációs adatbázisból publikál adatokat webszolgáltatásokon keresztül. Eddig semmi izgalmas nincs a dologban, sőt kifejezetten unalmas és hétköznapi a történet. Ami elgondolkodásra késztetett a dologban az az volt, hogy megszámoltam, hányféle modellben is kezeljük tulajdonképp az azokat a fránya adatokat? Relációs adatmodell az adatbázisban, objektum adatmodell az alkalmazás szintjén, és végül, a WCF legmélyén ott találjuk az XML-t is, ami nem adatmodell, de azért számoljuk csak ide, később kiderül miért.

Mikor egy alkalmazásban különféle komponenseket dobálunk egymásra, szembe kell néznünk azzal, hogy ezeknek gyakran nem az unióját, hanem a metszetét tudjuk csak kiaknázni: hiába lenne képes az alkalmazás rétegünk OO kódja csodálatos leszármazási gráfokat létrehozni, ezt nagyon nehéz relációs modellben ábrázolni. Létezik rá ugyan megoldás, de a való életben általában inkább eltekintünk az örökléstől, amúgy sem tartozik a kedvenc eszközeink közé ("Favor containment over inheritance"). Hasonlóan bánunk el az xml, a relációs és a objektum orientált modell minden "kilógó részével", amire nincs életbevágóan szükségünk. Ami a végére marad, az kicsit mindegyikre hasonlít, de igazából egyik sem. Kígyófejű oroszlán. Polipkarú kutya.

Ezzel kapcsolatos problémáinkat a felére tudjuk redukálni, ha nem próbálunk meg a különféle modellek között navigálni, hanem magunkhoz öleljük valamelyik modellt, és azt vezetjük végig az alkalmazáson. Vietnénk végig az xml-t, hiszen léteznek már xml adatbázisok, a Linq to xml pedig viszonylag fájdalommentes lehetőség a xml adatok kezelésére. Megtehetnénk, hogy az objektumainkat  próbáljuk adatbázisba menteni (db4o és társai), de azért ez sem valami jól kitaposott ösvény.

Amire viszont komoly támogatást kapunk a Visual Studio szinte mindegyik életképes verziójában, az a relációs modell objektum szinten terelése. Típusos DataSet-nek hívják a burkoló osztályt, és jó néhány éve velünk van már, csak néha hajlamosak vagyunk róla megfeledkezni, mert olyan sok érdekesség jelent meg mostanában: LinQ To SQL. Entity Framework. A jó öreg DataSet pedig feledésbe merül, pedig a .NET alkalmazások jelentős része remekül megülne a tetején.

Web deploy IIS-re

Aki nem unja az IIS témát, annak egy újabb agyzsibbasztó adag belőle: Ez most a többihez képest egyszerűbb lesz, de nagyon hasznos, főleg fejlesztői szerverek esetén: a segítségével a Visual Studio-ból közvetlenül tehetjük ki az új verziót az alkalmazásunkból.

Első körben ellenőrizzük, hogy fel van-e telepítve a Windows Security role:
Server manager/Roles/Web Server (IIS): Role Services. Itt a Security alatt a Windows Authhentication-nek kell telepítve lennie.

Következő lépésben a Web Deploy Tool telepítése szükséges: ezt a www.microsoft.com/web címen találhatjuk meg. Fontos, hogy a Web Deployment Agent Services felmenjen (full install), ez teszi lehetővé a távoli telepítést.

A fejlesztői oldalon a Visual Studio beállításához nyomjunk egy jobb gombot a webes projektünkön, válasszuk a Publiush... opciót, és következőképp állítsuk be a megjelenő párbeszéd-ablakot:
Publish Method: Web Deploy
Service URL: http://szerver-neve.domain-ha-van
Site/Application: az IIS könyvtár, ahová deployolni szeretnénk, pl. Default web Site/myWebApp
Mark as IIS application on destination: be
Leave Extra files...: igény szerint
Credentinals: ha a szerverre más bejelentkezési adatokkal kell belépnünk akkor ezt feltétlenül töltsük ki.
A Publish gombra kattintva már megy is fel az alkalmazásunk az IIS-re.

Az IIS 7.0 és a net.tcp protokoll esküvője

A lentieket (én még néhány másikat is) a facebook-ra kezdtem el felvinni, de inkább ide illik, ezért most ünnepélyesen átmásolom őket. A történet arról szól, hogyan telepítsünk fel egy IIS-t úgy, hogy futtasson net.tcp alapú WCF szolgáltatásokat is.

IIS telepítése

Start/Administrative Tools/Server manager: Roles/Add Roles/Web Server (IIS)

Roles/Web Server (IIS)/Add Role Services:

• Application development/ASP.NET
• Management Tools/IIS Management Console (Az IIS server manager, később még sokat fogunk benne ügyködni)
• Security/Windows authentication (csak ha szeretnénk távolról deploy-olni a szerverre)
• Common HTTP features/Static Content (enélkül semmiféle statikus tartalom nem jelenik meg)

Features/Add/

• .NET Framework Features/ alatta mindegyik, még a WCF Activation alatti két alpont is!!!
• Windows Process Activation Service/ alatta mindegyik

Ha a .net 4.0 hamarabb volt a gépen, mint az IIS (amit a fentiekben telepítettünk), akkor kell kicsit varázsolni, hogy a .NET 4.0-es webalkalmazások működjenek: admin command line-ből adjuk ki: %windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis -i
Ha még nincs fent a .NET 4.0 akkor most érdemes feltelepíteni.

A net.tcp engedélyezése az IIS alatt

A tesztek szerint a net.tcp alapú webszolgáltatások nagyjából kétszer gyorsabbak tudnak lenni a http alapú társaikhoz képest. Az életre keltésük viszont némi erőfeszítést igényel IIS alatt.
Mielőtt nekiesünk, győződjünk meg néhány dologról:

• Server manager-ben: Features/.NET framework features/WCF Activation/Non-http activation fel van telepítve
• Services-ben: net.tpc Listener Adapter fut-e?

Ezután próbálkozhatunk a beállításokkal.
Az IIS manager-ben nyomjunk egy jobb klikket a Default Web Site-on (vagy ahová a net.tcp-s alkalmazásunkat fel szeretnénk tenni), Edit Bindings..., válasszuk ki a net.tcp-t, és Edit.
Válasszuk ki a net.tcp-t, és adjunk meg neki egy portot. Ha silverlight 4.0 alkalmazást szeretnénk rákötni, akkor a 4502-4534 terület használható. ha ez nem akadály, akkor tegyünk hozzá portokat ízlés szerint, én a 4520-at fogom használni példaként. Ennek beállításához a binding information-nál adjuk meg: 4520:*, close
Újabb jobb klikk a Default Web Site-en, Manage Web Site/Advanced Settings. Itt az enabled protocols-hoz kell hozzávennünk a net.tcp-t. Ehhez adjuk meg a http után vesszővel elválasztva, kisbetűvel: net.tcp.
A net.tcp protokoll engedélyezését végezzük el a szolgáltatásokat nyújtó webalkalmazáon is, és készen is vagyunk az IIS oldalon.

web.config beállítások
A webalkalmazásunk oldalán is van néhány dolog amit nem árt észben tartani:

• Ha IIS-re deploy-olunk, nem kell a <BaseAddresses> felsorolásban felvennünk a címet, mert az IIS fikarcnyit sem törődik vele. Ami azt illeti, még akár félrevezető is lehet a kollégáknak. Én inkább kihagynám
• Ha Silverlight-ból fogjuk hívni a net.tcp szolgáltatásunkat, ki kell kapcsolnunk a biztonságot, mivel az nincs a Silverlight oldalán megoldva. Fontoljuk meg, komoly biztonsági kockázatot jelenthet! Valahogy így kell kivitelezni:

<system.serviceModel>

    <bindings>

      <netTcpBinding>

        <binding name="Unsecured">

          <security mode="None" />

        </binding>

      </netTcpBinding>

    </bindings>

    <services>

      <service name="myService">

        <endpoint address=""

                  binding="netTcpBinding"

                  bindingConfiguration="Unsecured"

                  name="myServiceEndPoint"

                  contract="IMyService" />

      </service>

    </services>

</system.serviceModel>

Az első...

A magyarázkodás

Reggel nekiestem volna a munkának, de a VMWare Player úgy dönött, hogy én ma reggel nem fogok dolgozni, mert ő most frissíteni fogja magát a zseniális 4.0 verzióra. Persze mondhattam volna nemet is, de ki tud ellenállni egy ilyen ajánlatnak?
Amíg a letöltés/telepítés/minden virtuális gép befrissítése tartott, kattintottam párat, és megtaláltam ezt az oldalt. Volt azért némi inspiráció, régóta gondolkodtam mér rajta, hogy a dolgokat, amivel küzdöttem munka közben érdemes lenne lejegyzetelni, hátha más is hasznát veszi. Ha a kutya se nézi, nekem még mindig jól jöhet később.

Miért ez a neve?

Egyszer (nagyon régen) egy állásinterjún kérték tőlem, hogy jellemezzem a munkához való hozzáállásomat egy szóban. Nem jutott eszembe semmi. Két héttel utána sem jutott eszembe semmi, pedig biz' isten sokat gondolkodtam rajta közben. Aztán egyszer csak beugrott. Coder Samurai.
Persze azóta sem kérdezte senki egyetlen interjún sem. Nem mintha olyan sok interjún vettem volna részt mostanában.


Miről fog szólni?

Sok sok olyan téma, ami csak programozókat érdekelhet. Jelenleg éppen C#, NHibernate, Oracle és az ezek kombinációiból kialakult komplikációk. Természetesen konkrét ügyfelek és projektek emlegetése nélkül.