Egy belsős ember a Microsoft-tól rövid videókban szórja az információt, ezúttal a Dependency Injection használatáról az ASP.NET Core-ban: Fritz’s 10 Minute Tips: Today’s video is about how to use Dependency Injection in ASP.NET Core.

Néhány kép , ami több, mint ezer szó :) Live-Charts

Guide for building C# apps on Ubuntu: MonoProject Introduction

Egy nagyon tartalmas cikk a "Funkcióválasztás" (Feature Toggling) elméletéről és gyakorlatáról. Ez néhány tervezési minta, ami egy fejlesztőcsapat számára az új funkciók gyors de biztonságos szállításában hasznos. Ebben a cikkben egy rövid történet segítségével először is kiderül, hol segíthet a Funkcióválasztás néhány tipikus forgatókönyv esetén, Aztán alámerülünk a részletekbe, áttekintünk speciális mintákat és gyakorlati megoldásokat, amik megkönnyítik a Funkcióválasztás sikeres alkalmazását.

Feature Toggles

Contents

• A Toggling Tale
  • The birth of a Feature Toggle
  • Making a toggle dynamic
  • Getting ready to release
  • Canary releasing
  • A/B testing
• Categories of toggles
  • Release Toggles
  • Experiment Toggles
  • Ops Toggles
  • Permissioning Toggles
  • Managing different categories of toggles
    • static vs dynamic toggles
    • Long-lived toggles vs transient toggles
• Implementation Techniques
  • De-coupling decision points from decision logic
  • Inversion of Decision
  • Avoiding conditionals
• Toggle Configuration
  • Dynamic routing vs dynamic configuration
  • Prefer static configuration
  • Approaches for managing toggle configuration
  • Hardcoded Toggle Configuration
  • Parameterized Toggle Configuration
  • Toggle Configuration File
  • Toggle Configuration in App DB
  • Distributed Toggle Configuration
  • Overriding configuration
    • Per-request overrides
• Working with feature-toggled systems
  • Expose current feature toggle configuration
  • Take advantage of structured Toggle Configuration files
  • Manage different toggles differently
  • Feature Toggles introduce validation complexity
  • Where to place your toggle
    • Toggles at the edge
    • Toggles in the core
  • Managing the carrying cost of Feature Toggles

A reszponzív webfelület fejlesztés zászlóshajója a (twitter) Bootstrap. 2010-ben a Twitternél egy fejlesztő (@mdo) és egy (web)designer (@fat) hozta létre, ingyenes, nyílt forráskódú projekt, a githubon nyilvános. Egy egy oldalas összefoglaló a következő nagy (immáron mobile first) változatról:

Bootstrap 4 Cheat seet

Nem új, de nagy és részletes, így talán hasznos csomag nem csak C#, és nem csak robotikában fejlesztők számára. A környezet a következőkből áll:

• Robotics Developer Studio (RDS):
  • Integrált .NET fejlesztőkörnyezet robotikai alkalmazások tervezéséhez, fejlesztéséhez és hibakereséséhez. Welcome to Robotics Developer Studio
• Concurrency and Coordination Runtime  (CCR)
  • Üzenetalapú programozási modell thread-ek, lockok, szemaforok (stb.) használata nélküli, jól skálázható, robosztus, aszinkron, párhuzamosan több hardveren futtatható és erősen konkurrens kód írásához.
  • Az egyik (Robotics team) fejlesztő tanácsai itt és itt.
• Decentralized Software Services (DSS)
  • REST alapú elosztott, egymással együttműködő, robosztus, nagy teljesítményű és jól skálázható alkalmazás modell.
• DSS Manifest Editor (DSSME)
  • Grafikus felhasználói környezet alkalmazások konfigurációjához, telepítéséhez, futtatásához és ezen alkalmazások együttműködésének kialakításához, egy szerveren vagy a hálózaton elosztva több helyen.
• Microsoft Visual Programming Language  (VPL)
  • Adatáramlás alapú grafikus (drag'n drop) fejlesztőkörnyezet CCR/DSS alkalmazások készítéséhez. Az általános programozási modellben található vezérlés alapú megközelítéssel ellentétben az adatáramlás alapú program azt szabályozza, hogy az egyik komponenstől beérkező adatok melyik komponenst "hajtsák meg". Ehhez 7 leckéből álló minitanfolyam is van.
• Microsoft Visual Simulation Environment  (VSE)
  • integrált környezet robotok, környezet és egyéb fizikai objektumok szimulációjának a létrehozásához és futtatásához jó minőségű 3D szimulációban. Azon túlmenően, hogy a környezet generálását a Microsoft XNA Framework végzi, az NVIDIA™ PhysX™ segítségével valódi fizikai gravitációs környezetet generál.

Bevezetés 4 leckével.

Néhány kiragadott példa az összetevőkből:

Beépített általános robotikai eszközök, ezek példakódja C# nyelven rendelkezésre áll.

• Analóg szenzor
• Analóg szenzor tömb
• Csuklós kar
• Akkumulátor
• Érintésérzékelők
• Távolságérzékelő kamera
• Differenciál meghajtás - A kerekes robotok alapja
• Kódoló
• Motor
• Hanglokátor
• Adatfolyam
• Általános webkamera
• Kinect webkamera szenzor

Néhány példa szenzor kódja:

• Kinect
• IP Kamera
• SICK Lézeres távolságmérő
• Webkamera

 Támogatott robotok:

• iRobot Create és Roomba
• LEGO MINDSTORMS NXT
• MobileRobots Pioneer P3DX
• Reference Platform

 A szimulációs könyezetben a következő robotokat szimulálja:

• Kuka LBR3 Articulated Arm
• LEGO NXT
• Pioneer 3DX
• iRobot Create

illetve ezen szenzorok szimulációja áll rendelkezésre:

• Lökhárító
• Differenciál hajtómű
• Webkamera

Olyan példákon keresztül mutatja be a lehetőségeket, mint a követőkamera, vagy pedig a beágyazott szimuláció. 

Az új csapatok csatlakoztak a Microsofthoz az alapítvány technikai irányító csoportjában is, ezzel biztosítva, hogy a jövendő fejlesztések mindenki számára megfelelőek legyenek.

A Red Hat a Linux világ meghatározó alakja a vállati szegmensben a Red Hat Enterprise Linux kiadójaként. A Unity a játékmotorjáról méltán híres, a JetBrains pedig egyebek mellett a ReSharper gyártója.

Technical Steering Group

Az új kiadás kereteit a MIT licensz szabályozza, gyakorlatilag korlátozás nélkül használható, .NET Foundation részeként. 

http://www.mono-project.com/news/2016/03/31/mono-relicensed-mit/

Előző fejezet: 1. A kódbázis

Következő fejezet: 3. Beállítások, konfigurációkezelés

Egy korábbi bejegyzésben elkezdtük feldolgozni a szoftverpusztulás elkerüléséhez tanácsolt lépéseket. Most lépjünk a következő pontra:

2. Függőségek kezelése

A tanács: mindig explicit módon deklaráljuk és különítsünk el a függőségeket.

A legtöbb programozási nyelvben rendelkezésre áll már csomagkezelési megoldás, ami támogatja könyvtár modulok becsomagolását és csomagban terjesztését. A .NET világban a NuGet (egy régebbi, de részletes cikk erről) megoldását használjuk, Ruby nyelven fejlesztőknek ott a  Rubygems. És a teljesség igénye nélkül néhány példa még: A Phyton-nál a Pip és a Virtualenv, a nodejs-nél az npm, a PHP-t nem ismerem túl jól, de a Composer és a Packagist lennének az első jelöltjeim. A JavaScriptnél pedig ezekből választhatunk: npm, bower, Ender, volo, component és jam.

A csomagkezelő megoldásunk segítségével egyrészt telepíthetjük a könyvtárainkat rendszer szinten, ekkor minden telepített alkalmazás használhatja őket (ilyesmi például a .NET global assembly cache, vagy többféle nyelven a "site package"). Vagy telepíthetjük a könyvtárainkat az alkalmazásunkkal együtt, egy csomagban, kizárólagos használatára (ilyenek az alkalmazásunkhoz telepített nuget csomagok például).

A 12 tényezős alkalmazásfejlesztés soha nem feltételez rendszerszinten rendelkezésre álló könyvtárakat.

(Erre jó példa a .NET Core/ASP.NET Core újdonságai közül például, hogy a .NET futtató környezetet az új .NET alkalmazásokhoz NuGet csomagokkal telepíthetjük. Erről némi információ: NuGet is a .NET framework release vehicle és ASP.NET vNext will let you deploy your own version of the .NET Framework on an app-by-app-basis,)

Az alkalmazás, (ami követi a 12 tényezős alkalmazásfejlesztés tanácsait) az összes függőségét pontosan deklarálja a függőségi deklarációs jegyzékében (pl.: NuGet csomagkezelő esetén a package.config állományban). Ezen túlmenően az alkalmazás a függőségeket elkülönítő megoldást használ a futtatás során, ami biztosítja, hogy hogy nincs implicit (nem pontosan definiált, csak valamilyen egyéb körülményből következő) függőség, ami a környezetből "beszivárog". (mondjuk Microsoft Office alkalmazás osztályok használata, mivel a fejlesztő gépén telepítve van az Office).

Például a Ruby a Gem Bundlert adja a Gemfile-ok (függőségi deklarációs jegyzék) létrehozásához, és a bundle exec-et használja a környezet leválasztásához. A Phyton fejlesztők a Pip-et használják a deklarációs jegyzék létrehozásához, és a Virtualenv-et a leválasztáshoz. Még C nyelven is megoldható az Autoconf segítségével a jegyzék gyártása, és statikus linkeléssel pedig a környezet leválasztása. Nem számít, hogy milyen kombinációt alkalmazunk, a függőségek jegyzékbe vétele és a környezet leválasztása mindig együtt kell, hogy jelen legyen az alkalmazásfejlesztés során. Ha csak az egyiket használjuk, nem teljesítjük a 12 tényezős alkalmazásfejlesztés követelményeit.

Az egyik nagy előnye a függőségek megfelelő kezelésének az, hogy ha új fejlesztő csatlakozik, akkor a környezet telepítése egyszerűen a kódbázis letöltését jelenti a gépére, ezen túlmenően csak a programozási nyelvre és a csomagkezelőre van még szükség semmi egyébre. Ezzel a fejlesztő egy egyértelmű build paranccsal tudja az alkalmazást futtatni. Például Visual Stúdióból az első BUILD előtt minden szükséges NuGet csomag automatikusan letöltődik (a nuget.exe restore parancs segítségével). A Ruby fejlesztők a bundle install parancsot, a Clojure fejlesztők pedig a lein deps parancsot használják.

Egyéb, a futtatókörnyezetben létező rendszereszközök használata sem megengedett. Így curl, cmd.exe vagy bash parancsok hívása sem. Bár a legtöbb rendszeren ezek az eszközök léteznek, nincs rá garancia, hogy minden rendszeren léteznek illetve a jövőben mindig létezni fognak, valamint ha léteznek, a verziójuk mindig alkalmas lesz az együttműködésre alkalmazásunkkal. Ha ilyesmit használni szeretnénk, akkor az alkalmazás mellé kell csomagolnunk és alkalmazásunkkal együtt telepítenünk.

The Twelve-Factor App: II. Dependencies

Egy részletes elemzés a választási weboldal feltöréséről: When a nation is hacked: Understanding the ginormous Philippines data breach