A korábbi Windows Phone Silverlight alkalmazásokat Windows 10-en futtatni?

Tips for porting apps from Windows Phone Silverlight to UWP

Riportalanyunk Heim Gábor, aki az IBM mainframe rendszerek IT biztonságáért felel főállásban. Ezenkívül etikus hekkerként az RFID rendszerek határait feszegeti, jelentsen ez beléptetőrendszert vagy bőr alá ültetett mikrocsipet.

Gáborral találkozhatsz az idei Ethical Hacking konferencián május 12-én, a Lurdy Moziban.

Riporter: "Mit jelent hacker-nek lenni?"
Heim Gábor: "Számomra ez egy életforma. Nem csak a munkahelyemen hekkelek, próbálom a mindennapi életben is kamatoztatni ezt a szemléletmódot. Arra gondolok, hogy megpróbálok kreatívan gondolkozni. Out of the box. Néhányan azt mondják, hogy ez bárki által megtanulható készség. Remélhetőleg a végeredmény pedig az hogy előrébb jutunk, és nem szokványos utakon megoldunk vagy enyhítünk egy problémát. Az életben, a munkahelyen, egy számítógépes rendszerben vagy egy kódban bárhol...

A Facebook fejlesztői konferenciáján jelentették be a hírt. A Microsoft az Universal Windows Platformon (ez tulajdonképpen minden Windows 10-et futtató eszközt jelent: mobil eszközök, PC-k, Xbox One, HoloLens) támogatja a React Native alkalmazások fejlesztését. 

És hogy mi is a React Native? Kezdjük a szintén nyílt forrásódú Facebook projekttel, a React-tal. Ennek segítségével JavaScript alkalmazásokhoz lehet felhasználói felületet készíteni. A React Native pedig azt ígéri, hogy JavaScript és React segítségével készített felületünk az egyes platformokon natív kódként fut. Az "írd meg egyszer futtasd mindenen" elvtől eltérően a React Native környezet számít rá hogy minden platform különböző, ezek a különbözőségek lekérdezhetőek, felismerhetők és kezelhetőek a segítségével. Jelmondata pedig a "tanuld meg egyszer, írd meg mindenen".

Ehhez még hozzájön, hogy 2015-ben a GitHubon a leggyorsabban növekvő nyílt forráskódú projekt a React Native volt.

React Native on the Universal Windows Platform

Egy érdekes könyvtár a GitHubról, aminek a segítségével linq kifejezéssel tudjuk lekérdezéseinket megírni: LINQ Provider for the Twitter API (Twitter Library)

Következő fejezet: 2. Függőségek kezelése

Korábban már volt szó róla, de annyira érdekes tárháza az információknak a 12 tényezős alkalmazás fejlesztése, hogy érdemes végigmenni a tényezőkön. A módszertant olyan közreműködők hozzák össze, akiknek nagy tapasztalatuk van összesen többszáz alkalmazás fejlesztésében és telepítésében, és mivel a Herokunál dolgoznak, több százezer alkalmazás üzemeltetésében.

A módszertant szerintük bármilyen programozási nyelven (C, Ruby, Java, C#, stb.) és bármilyen futtató-környezetben (Windows, Linux, stb.) lehet használni.

Segítségével hármas egyensúlyt lehet kialakítani egy alkalmazás fejlesztésének és üzemeltetésének teljes életciklusa alatt. Különös figyelmet tudunk fordítani az alkalmazás időben történő természetes növekedésére és fejlődésére, a kódbázison dolgozó fejlesztők együttműködésének a dinamikájára, és el tudjuk kerülni a költséges szoftverpusztulást.

Az első pont a listán a kódbázis.

Tanácsuk röviden: egy alkalmazáshoz egy kódbázis tartozik, amit mindig verziókövető adatbázisban (kódtárban) kell tárolni (például subversion, git, mercurial vagy tfs, stb.), és minden változat telepítése (teszt, fejlesztő, éles, stb.) innen történik. Tehát:

A kódbázishoz (kódtárhoz) egyértelműen megfeleltethető pontosan egy alkalmazás, és ugyanez igaz visszafelé is.

• Ha több kódbázis van, akkor az nem lehet egy alkalmazás. Ebben az esetben elosztott rendszerről beszélünk több összetevővel. Ilyenkor tekintsünk minden összetevőt egy-egy alkalmazásnak, és ezek az alkalmazások külön-külön már alkalmasak arra, hogy a 12 tényezős alkalmazásfejlesztés követelményeinek megfeleljenek.
• Ha több alkalmazás ugyanazt a kódot megosztja (például ugyanazt a függvényt használják, ugyanazt a konstans/modell kódot tartalmazzák stb.), akkor ezek az alkalmazások megsértik a 12 tényezős alkalmazásfejlesztés előírásait. Ebben az esetben a megoldás az, hogy a megosztott kódot például egy könyvtárba ki kell szervezni, és az egyes alkalmazások közötti függőségek feloldásának mechanizmusával (ld. később, egy következő blog bejegyzésben) felhasználni ahol szükség van rá.

Minden kódbázishoz tehát pontosan egy alkalmazás tartozik, azonban ezt az alkalmazást több környezetben és változatban is lehet telepíteni. A telepítés az alkalmazásnak egy futó példánya. Ilyen például az éles (produkciós) környezet, különböző tesztelési környezetek, illetve, minden fejlesztő gépére kerül egy-egy fejlesztői másolat is az alkalmazásból.

A kódbázis azonos minden példánynál akkor is, ha nem minden telepítés azonos kód verzióból készült. A fejlesztőknél lehetnek olyan módosítások, amiket a tesztkörnyezet(ek)re még nem telepítettünk, és a tesztkörnyezeteken is olyan változatot tesztelünk, aminek nem minden változása van az éles telepítésben. De minden telepítés ugyanazt a kódbázist (kódtárat) használja, innen ismerjük fel, hogy ezek ugyanannak az alkalmazásnak a különböző telepítései.

The Twelve-Factor App: I. Codebase

A Kestrel az ASP.NET Core beépített http szervere. Ennek segítségével nincs többé szükség IIS szerverre, ha ASP.NET Core alkalmazást szeretnénk futtatni. Az alkalmazásunk képes lesz különböző webkiszolgálókra (IIS-re is) települni , de saját magát is képes szolgáltatni a Kestrel segítségével. Ez egy nagy teljesítményre tervezett és fejlesztett kiszolgáló, ami, ha már van, jól kihasználható.

Kestrel as a Static Server for Angular

Jó pár éve készítünk már image-eket, többek között a tantermeink gépeire is. A Windows 10 1511-es verziójánál azonban az OOBE/Generalize opcióival elhasalt a SysPrep. A hibaüzenetre rákeresve ezernyi bejegyzés található különböző fórumokról. Az egyikben a Registryben kellene keresni olyan kulcsokat, amik a mi példányunkban nincsenek is benne, a másik fórum szerint ne egy Windows 8-ból upgradelt példányt használjunk (nálunk Clean Install volt). A lényeg, hogy egyik ötlet sem jött be, maradt a teljes újratelepítés.

Ekkor azonban megtaláltam ezt a cikket: http://www.tenforums.com/tutorials/2110-default-user-profile-customize-windows-10-a.html

A lényeg az első képen van, azaz nyomj egy CTRL+SHIFT+F3-at a telepítés azon szakaszában (hívjuk mondjuk Welcome Screen-nek), és lám ott az Audit mód, ami egyébként eddig is előjött a korábbi telepítéseinknél, csak kicsit később.

Woow! Nincs elhasalás, tökéletes image készül(t), a SysPrep is lefutott rendesen.

(Azért megjegyzem, hogy ez már Windows 7 óta működik a Technet szerint. https://technet.microsoft.com/en-us/library/dd799305%28v=ws.10%29.aspx De érdekes módon eddig sosem került előtérbe, csak most, 4 generációval később. Maradi lennék? Vagy Nálad is éppen most jött ez elő?)

Ez a teljesítmény 23x (tehát: huszonháromszor) jobb, mint a jelenlegi produkciós (ASP.NET 4.6) teljesítménye.

Performance competition is a good thing

Ez a cikkben szereplő hivatkozás, de azért kiemelem, mert érdemes belenézni:

ASP.NET Core – 2300% More Requests Served Per Second

Az ASP.NET Core a korábbi változatokhoz képest rengeteg változást hoz magával. Ebben a cikkben a sok változás közül az egyikről, a konfigurációk megváltozott kezeléséről lehet olvasni.

A korábbi változatokban a konfiguráció központja és kiindulópontja a Web.config állomány és a benne szereplő beállítások voltak. Az ASP.NET Core-ban már nincs többé ilyen állomány. Viszont van helyette más: The New Configuration Model in ASP.NET Core