NetAcademia

A legjobbakat tanítjuk!

Hogy kerülhetjük el a "szoftverpusztulást"? 12Factor app: 12. Adminisztratív folyamatok

2018. március 02. 05:00 - Plesz Gábor

Előző fejezet: 11. Naplók

Az adminisztrációs és felügyeleti feladatokat futtassuk egyszer futó folyamatokként

A folyamat formája pedig legyen olyan folyamatok együttese, amit az alkalmazás rendszeres üzleti folyamatai (például webes kérések kiszolgálására) is használnak. Ezen kívül a fejlesztők gyakran egyszeri adminisztrációs vagy karbantartási feladatokat is szeretnének végrehajtani, mint például:

  • Adatbázis migrációk végrehajtása (pl.: manage.py migrate a Django-nál, rake d:migrate a Rails használatakor vagy migrate.exe a .NET Entity Frameworkben)
  • Konzol használata (vagy másnéven REPL shell) tetszőleges kód futtatásához vagy akár az alkalmazás adatmodelljének használatához az éles adatbázis vizsgálata közben. A legtöbb nyelv biztosít REPL eszközt az értelmező alkalmazás parancssori paraméterek nélküli futtatásával (mint a python vagy a perl), egyes esetekben pedig erre külön parancs van (mint az irb a Ruby-hoz, rails console a Rails-hoz).
  • Az egyszer használatos scripteket az alkalmazás kódtárában kell tárolni (egy php példa: scripts/fix_bad_records.php).

Az egyszeri adminisztrációs folyamatokat ugyanolyan környezetben kell futtatni, mint az alkalmazás rendszeres, hosszan futó folyamatait. Ugyanazt a kódbázist és konfigurációt használó telepítés mellett futtatva, mint amit telepítés egyéb folyamatai használnak. Az adminisztrációs kódokat az alkalmazással együtt kell szállítani a szinkronizációs problémák elkerülése érdekében.

Ugyanazt az elkülönítési megoldást kell használni minden folyamattípusnál. Például, ha a Ruby webes folyamata a bundle exec thin start parancsot használja, akkor az adatbázis migrációnak bundle exec rake db:migrate-et kell használnia. Hasonlóan, a Virtualenv-et használó Python programnak a saját bin/python köyvtárát kall használnia a Tornado webkiszolgáló indításához ugyanúgy ahogy minden manage.py felügyeleti folyamathoz.

A tizenkét tényezős fejlesztés határozottan támogatja azokat a nyelveket, amik alapból kínálnak REPL környezetet és megkönnyítik az egyszeri adminisztrációs scriptek futtatását. A fejlesztők a saját gépükön az egyszeri admin scripteket egyből az alkalmazás munkakönyvtárából tudják parancssorban futtatni. Éles telepítés esetén a fejlesztők ilyen folyamatok futtatásához ssh-t vagy más, a telepítés futtatási környezete által biztosított távoli parancsvégrehajtási megoldást használhatnak.
The Twelve-Factor App: XII. Admin processes
Szólj hozzá!

A programozók jogairól - egy lehetséges alkotmánykiegészítés :)

2018. február 27. 06:00 - Plesz Gábor

Hű de régi ez a cikk, mégis milyen jó :)

A USA alkotmány kiegészítéseinek mintájára a szerző összeírta, hogy milyen jogokat védhetne akár törvény is egy programozók által elképzelt ideális világban (a cikk 2006-ban íródott).

Röviden:

  1. Minden programozónak biztosítani kell két monitort.
  2. Minden programozónak gyors számítógép jár.
  3. Minden programozó saját egeret és billentyűzetet választhat.
  4. Minden programozónak kényelmes szék jár .
  5. Minden programozónak biztosítani kell gyors Internet elérést.
  6. Minden programozónak elidegeníthetetlen joga a csendes munkakörnyezet.

Részletek a linken:

Jeff Atwood: The Programmer's Bill of Rights

1 komment
Címkék: JeffAtwood

Fejlesztőknek: Vajon érdemes Entity Framework mellett Repository mintában gondolkodni?

2018. február 23. 08:53 - Plesz Gábor

A kolléga .NET Core ügyekben kotangens, érdemes átnézni a blogját, igényes cikkeket ír.

Repository minta kiváló eszköz arra, hogy az adatok perzisztenciájáért felelős komponens, és az adatokat felhasználó komponensek erős csatolását megszüntessük (indirekció segítségével). Rengeteg példa megtalálható a neten arról, hogyan érdemes kódolni repository (és Unit of Work) mintát mindenféle nyelven, Entity Framework-öt használva vagy anélkül. Ez a cikk egy racionális áttekintés arról, hogy vajon érdemes-e repository mintát használni Entity Framework környezetben?

Ki mit gondol erről?

Jon P Smith: Is the repository pattern useful with Entity Framework Core?

Szólj hozzá!

Fejlesztőknek: hogyan tegyük érthetőbbé a feltételvizsgálatot a forráskódban? (C++)

2018. február 21. 09:26 - Plesz Gábor

Most találkoztam ezzel a kollégával először, de egyből megtetszett a blogja. Egyszerű, érthető, azonnal felhasználható kódolási tanácsokat ad C++ példákkal, de minden fejlesztő számára érthető módon.

Érdemes végigböngészni a blogot, szerintem aranybánya.

Jonathan Boccara: How to Make If Statements More Understandable

 

Szólj hozzá!

Hogy kerülhetjük el a "szoftverpusztulást"? 12Factor app: 11. Naplók

2018. február 19. 17:48 - Plesz Gábor

Előző fejezet: 10. Egyensúly a fejlesztés és az üzemeltetés között

Kezeljük a naplókat esemény-folyamatként

A naplók a futó alkalmazás működésébe nyújtanak betekintést. Szerver alapú környezetben gyakran a lemezen egy állományba írják őket ("naplóállomány"); de ez csak egy kimeneti formátum.

A naplók valamennyi futó folyamat és háttérszolgáltatás kimeneti adataiból összegyűjtött és idő szerint rendezett adatfolyama. A naplók nyers állapota tipikusan szöveges formátum ahol minden esemény külön sorban szerepel (akkor is, ha a kivételekből származó veremtartalom több sorba is kerülhet). A naplóknak nincs meghatározott elejük vagy végük hanem folyamatosan keletkeznek egészen addig, amíg az alkalmazás üzemel.
A tizenkét tényezős alkalmazás saját maga sosem foglalkozik a saját kimeneti adatfolyamának irányításával vagy tárolásával. Nem szabad naplófájlokat írnia vagy kezelnie. Helyette minden futó folyamat a saját eseményeit gyorsítótár nélkül kiírja a sztenderd kimenetre (stdout). A fejlesztés alatt a fejlesztő a saját képernyője előtt ülve fogja nézni, hogy megfigyelje az alkalmazás viselkedését.

A tesztelési vagy az üzemeltetési telepítéseknél minden folyamat adatfolyamát a végrehajtási környezet rögzít, összevonva az alkalmazás összes többi adatfolyamával, megtekintésre és hosszútávú archiválásra egy vagy több végcél felé irányítva. Ezek az archívumok nem láthatók és konfigurálhatók az alkalmazásból, helyette teljes egészében a futtatókörnyezet kezeli őket. Ehhez nyílt forráskódú napló forgalom írányító eszközök állnak rendelkezésre (mint a Logplex és a Fluentd).

Az alkalmazás eseményeinek adatfolyamát irányíthatjuk állományba, vagy valós időben figyelhetjük terminálablakban. A legfontosabb, hogy az adatfolyamot elküldhetjük egy naplóindexelő és elemző rendszerbe, mint a Splunk, vagy egy általános célú adattárház eszközbe, mint a Hadoop/Hive. Ezek a rendszerek elegendő teljesítményt és rugalmasságot biztosítanak az alkalmazások időbeli viselkedésének megismeréséhez, ideértve:

  • Meghatározott múltbeli események keresése.
  • A trendek tágabb nézőpontból történő ábrázolása (mint a percenkénti kérések száma).
  • Aktív riasztás a felhasználó által létrehozott figyelésnek megfelelően (például egy riasztás jön létre, ha a percenkénti hibák száma meghalad egy bizonyos küszöbértéket).

The Twelve-Factor App: XI. Logs

Szólj hozzá!

Hogy kerülhetjük el a "szoftverpusztulást"? 12Factor app: 10. Egyensúly a fejlesztés és az üzemeltetés között

2018. február 12. 09:44 - Plesz Gábor

Előző fejezet: 9. Eldobhatóság

A fejlesztési és az üzemeltetési folyamatok legyenek annyira hasonlóak amennyire csak ez lehetséges.

Történeti okokból jelentős különbségek vannak a fejlesztés (a fejlesztő az alkalmazás helyi telepítését élőben módosítja) és az üzemeltetés (az alkalmazás végfelhasználók által elérhető, éppen futó telepítése) között. Ezek a különbségek és az ezekből adódó problémák három területen jelentkeznek:
  • Az idő különbség: a fejlesztő a kódon dolgozhat napokig, hetekig vagy akár hónapokig, mire a munkája az üzemeltetett alkalmazásba kerülne.
  • A személyi különbség: A fejlesztő írja a kódot, az üzemeltető mérnök telepíti azt.
  • Az eszköz különbség: a fejlesztő dolgozhat olyan csomaggal, amiben Nginx, SQLite és OS X van, az üzemeltetés viszont Apache, MySQL és Linux környezetre telepíti az alkalmazást.
A tizenkét tényezős alkalmazást eleve folyamatos telepítéshez tervezzük, hogy ez a különbség a fejlesztés és az üzemeltetés között kicsi legyen. Nézzük a három különbséget egyenként:
  • Az időbeli különséget tegyük kicsivé: a fejlesztő írhatja a kódot, és az órák vagy akár percek múlva az üzemeltetésbe kerülhet.
  • A személyi különbséget tegyük kicsivé: a kódot író fejlesztőt szorosan bevonjuk a a telepítésbe így közelről figyeli az üzemeltetésben az alkalmazás viselkedését.
  • Az eszközökben megjelenő különbséget tegyük kicsivé: legyen a fejlesztési és az üzemeltetési környezet olyan hasonló, amennyire csak lehet.
Összegezve ebben a táblázatban:
Hagyományos alkalmazás Tizenkét tényezős alkalmazás
Telepítések közötti idő Hetek Órák
Kód létrehozó kontra telepítő Különböző emberek Ugyanazok az emberek
Fejlesztési kontra üzemeltetés Szétágazó, különböző Amennyire lehetséges hasonló
 
A háttérszolgáltatások, mint az alkalmazás adatbázisa, az üzenetsor vagy a gyorsítótár olyan terület, ahol a fejlesztés és az üzemeltetés egyensúlya fontos. Sok nyelv kínál könyvtárakat, amik egyszerűsítik a hozzáférést a háttérszolgáltatáshoz, ideértve adaptereket a különböző típusú szolgáltatásokhoz. Néhány példa táblázatban:
Típus Nyelv Könyvtár Adapter
Adatbázis Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
Üzenetsor Python/Django Celery RabbitMQ, Beanstalkd, Redis
Gyorsítótár Ruby/Rails ActiveSupport::Cache Memory, filesystem, Memcached

A fejlesztők néha nagyon vonzónak találják, ha fejlesztés közben pehelysúlyú háttérszolgáltatást használhatnak a saját fejlesztési környezetükben, míg erős háttérszolgáltatások kerülnek az üzemeltetési környezetbe. 
Például fejlesztéshez SQLite-ot üzemeltetéshez viszont PostgreSQL-t használni; vagy helyben a folyamat memóriáját, üzemeltetéskor pedig Memcached-et használni gyorsítótárazáshoz.

A tizenkét tényezős fejlesztő ellenál annak a kísértésnek, hogy más háttérszolgáltatást használjon a fejlesztési és az üzemeltetési környezetben még akkor is, ha az adapterek elméletileg bármilyen háttérszolgáltatások közötti különbséget eltüntetnek. A háttérszolgáltatások közötti különbségek azt jelenti, hogy apró inkompatibilitási problémák merülhetnek fel azt eredményezve, hogy a kód, ami működött és a teszteken megfelelően teljesített fejlesztési és tesztkörnyezetben, üzemeltetés közben hibára fut. A hibáknak ez a típusa súrlódást hoz létre ami a folyamatos telepítést akadályozza. Ennek a surlódásnak a negatív hatása a folyamatos telepítésre és az alkalmazás életciklusára összegzett kültsége rendkívül magas.

A pehelysúlyú háttérszolgáltatások ma már kevésbé vonzóak, mint korábban voltak. A modern háttérszolgáltatásokat, mint a Memcached, a PostgreSQL és a RabbitMQ a modern csomagkezelési rendszereknek köszönhetően -mint a Homebrew és az apt-get, (vagy a Windows világban a nuget és chocolatey) egyáltalán nem körülményes telepíteni és futtatni. Alternatív megoldásként a deklaratív telepítő eszközök, mint a Chef és a Puppet, kombinálva a vékony virtuális rendszerekkel, mint a Docker és a Vagrant lehetővé teszi a fejlesztők számára, hogy az üzemeltetési környezethez nagyon hasonló fejlesztési környezetben dolgozhassanak. Ezen rendszerek telepítésének és használatának a költsége alacsony - összehasonlítva a fejlesztési és üzemeltetési egyensúllyal valamint a folyamatos telepítés előnyeivel.

A háttérszolgáltatások eléréséhez adaptereket használni továbbra is hasznos, mivel az újabb háttérszolgáltatásokra való áttéréet relatív fájdalommentessé teszik. De az alkalmazás valamennyi telepítésének (fejlesztési környezet, tesztelés és üzemeltetés) azonos típusú és verziójú háttérszolgáltatásokat kell használnia.

The Twelve-Factor App: X. Dev/prod parity

Szólj hozzá!

Junior-e a senior? Avagy mit tudhat a junoir, amiről fogalma sincs a seniornak?

2018. február 05. 10:47 - Fóti Marcell NetAcademia

aamaagdgaaoaaqaaaaaaaa80aaaajde4mmixztbhlwzkodqtndlkmi1hmjg3lwiyyzflywnkn2i1za.jpg

Junior-e a senior? Botrányosan fiatal Nagy Gergő kollégám tette fel ezt a kérdést, miután kiment egy céghez, hogy front-end fejlesztésről konzultáljon az ottani senior fejlesztőkkel.

Lenyűgözve tért vissza: ezek nem értenek semmihez!

Lefordítom: az adott cég senior fejlesztőinek halvány lila elképzelésük sem volt, hogy hogyan kellene manapság többplatformos, skálázható alkalmazást fejleszteniük. Mert amit tudtak, az talán ugyan még létezik, de összezsugorodott. Kell belőle valamennyi - de már csak egy csipetnyi. Helyét átvette az XY technológia - amiről ők szinte semmit sem tudnak.

Ez a cikk nem a frontend-fejlesztésről szól. Hanem például azokról a cégekről, akik lépten-nyomon senior fejlesztőket keresnek, nem tudván, hogy a seniort sok esetben egy a világra nyitott, haladó szellemű junior kenterbe veri, lealázza.

Hogy ne más telkére borítsuk a fertilizert, vegyük például az én esetemet. Én egy senior SQL-fejlesztő vagyok. Már akkor sarokba lettem szorítva, amikor jött a Code First-megközelítés a dotnetben, de ez még hagyján, mert ha nagyon akartam, még mindig piszkálgathattam az adatbázist kézzel. Akartam is! Az az enyém! Az adatbázistervezést azonban ezzel réges-régen kicsavarták a kezemből, és én tudom is ezt, hisz ennek már vagy 5-6 éve.

De jöttek az appok, a világméretű elérés, a freemium modellből származó irdatlan alapterhelés, majd erre rá a csúcsok, a rengeteg platform, és lassan kiderült, hogy az SQL Server nemhogy nem központi eleme egy ilyen rendszernek, hanem egyenesen egy porszem a gépezetben. HTML-generátorok, Angular, CDN-ek és cache-farmok, konténerek, bejelentkeztetési szolgáltatások és ezer egyéb réteg veszi le a terhelést a - már lassan tíz éve amúgy felhőben lévő, és akkor skálázhatónak kikiáltott - szerveroldali infrastruktúráról. Mert másképp nem megy. Mert másképp behal.

Aki a “régi” úton jár, az időről időre sorscsapásszerűen megbotlik. Ilyen például a NetAcademia rendszere. Én terveztem! :)

És én, mint senior SQL-guru, egy tejfölösszájútól tudom meg, hogy ha azt szeretném, hogy végre ne legyenek teljesítményproblémáink, akkor legalább a nagytömegű read-only adatelérést tegyük mán át FireBase-re (Google).

Ja, meg hagyjuk már, hogy az autentikáció mögött ugyanaz az SQL Server áll, mint a “rendes” adataink mögött, sőt, hagyjuk már a saját autentikációt békében pihenni, vannak erre kihegyezett rendszerek.

Ja, meg micsoda dolog, hogy szerveroldalon próbáljuk előállítani MVC-vel a weblapokat egy bármekkora szeverfarmmal, mert az be fog dőlni így is, meg úgy is. Donut cache? Ide nekünk egy frankó kis HTML-generáltort, meg egy CDN-t!

Felfogtam, megértettem. Hiába vagyok senior SQL-guru, az élet túllépett ezen, a hajdani “mindent főzzünk SQL-ből” helyét méretezési és teljesítményokokból átvette “Az SQL Servert maga Zeon, a föld alatt. The last human city” filozófia.

Lett tehát egy csomó olyan feladat, amihez ha kalapácsom van, és mindent szögnek nézek, akkor - ne engedjetek a közelébe!

Lassan esett le, de én már tudom. És pont azért tartott hosszú ideig, mert senior vagyok. Mert amihez értek, ahhoz én értek a legjobban, te meg itt HTML-ről süketelsz nekem, kispofám? 

És ez az a pont, ahol a junior előnyt élvez a seniorral szemben. Eleinte nem tud ugyan semmit, de nem is köti semmi. Kész befogadni az újat, és nem rágódik azon, hogy a régivel mi lesz. A gondolkodását nem köti semmiféle olyan régi “igazság”, ami már egyáltalán nem igaz. Mi sokkal inkább nyitott szellemű juniorokat keresünk, mint guruvá aszott seniorokat, akikkel minden egyes régi, megdőlt igazság belátásáért harcolni kell.

Van egy csomó “palackba zárt” senior, aki nem tud semmit, de azt sem tudja, hogy nem tudja. Én is onnan jövök, tudom, miről beszélek. Aki el sem tudja képzelni, hogy a “világ vasfoga elrepült felette”, hogy egy igen költői képzavarral éljek. Ők azok a seniorok, akiknek az alapos tudása a mai világban rémisztően kevés. És - csakúgy, mint én még egy éve is! - tárgyi tudástól el nem vakított éleslátással hoznak meg a cégek működését hosszútávon súlyosan korlátozó döntéseket.

Igen, rengeteg senior sajnos junior. Én bevallottam magamról. Te mit gondolsz?

7 komment

Hogy kerülhetjük el a "szoftverpusztulást"? 12Factor app: 9. Eldobhatóság

2018. február 05. 08:37 - Plesz Gábor

Előző fejezet: 8. Párhuzamos folyamatok

Következő fejezet: 10. Egyensúly a fejlesztés és az üzemeltetés között

Maximális hibatűrés gyors üzembehelyezéssel és egyszerű, gördülékeny leállítással.

A tizenkét tényezős alkalmazás folyamatai eldobhatóak (disposable), ami azt jelenti, hogy nagyjából a parancs észlelésének pillanatában elindul vagy leáll. Ez megkönnyíti a rugalmas méretezést (elastic scaling), a kód vagy a konfiguráció gyors telepítését és a produkciós telepítések hibatűrését.

A folyamatoknak törekedniük kell az üzembehelyezésükhöz szükséges idő minimalizálására. Ideális esetben egy folyamatnak néhány másodpercig tart az indulási parancstól eljutni egészen addig, hogy a folyamat fut és kész a kérések vagy a feladatok fogadására. A gyors üzembehelyezési idő több teret biztosít a folyamat üzembehelyezéséhez és a felskálázódáshoz (scaling up); segíti a hibatűrést, ugyanis ha indokolt, a folyamatkezelő (process manager) könnyebben át tudja mozgatni a folyamatot egy új fizikai eszközre.

A folyamat álljon le egyszerűen és gördülékenyen, ha megkapja a leállító parancsot (SIGTERM) a folyamatkezelőtől. Webes folyamatoknál ez elérhető, ha megszüntetjük a szolgáltatás portján a rendelkezésre állást (listening - ezzel minden további kérést visszautasítva), engedélyezzük viszont a folyamatban lévő kérések teljesítését és csak ezután állítjuk le a folyamatot. Ebből következik, hogy ebben a modellben a HTTP kérések kiszolgálása rövid (nem több néhány másodpercnél), a hosszú ideig tartó hívásokkal történő folyamatos lekérdezés (long polling) esetén pedig a kliens zökkenőmentesen újrakapcsolódik, ha a kapcsolat megszakad.

Munkavégző folyamatok esetén az egyszerű és gördülékeny leállás elérhető az aktuális végrehajtás alatt lévő feladat visszahelyezésével a várakozósorba (work queue). Például a RabbitMQ üzenetsor esetén a munkavégző folyamat küldhet egy NACK jelet; míg Beanstalkd esetén a feladat automatikusan visszakerül a várakozósorba, ha a munkavégző felé megszakad a kapcsolat. A Delayed Job-hoz hasonló zárolás alapú rendszereknél fontos, hogy a zárolást ilyenkor a feladat adatrekordján feloldjuk. A modellünknek a következménye, hogy minden feladat ismételhető kell, hogy legyen, ami tipikusan a feladatok tranzakcióba burkolásával, vagy a műveletek idempotenssé tételével (az első feladatvégzés után a további ismétlések nem változtatják az eredményt) érhető el.

A folyamatoknak ezen kívül jól kell tűrniük a hirtelen halált is, a futtató hardver eszköz meghibásodásának az esetét is. Bár ez a leállási parancs (SIGTERM) hatására történő egyszerű és gördülékeny leállásnál sokkal ritkábban előforduló lehetőség, azért meg szokott történni. Az javasolt megközelítés egy hibatűrő üzenetsor használata, mint például a Beanstalkd, ami egyszerűen visszahelyezi a feladatot a várakozósorba, ha kapcsolat megszakad az ügyfélprogram felé vagy a kliens időtúllépésbe kerül. Akárhogy is, a tizenkét tényezős alkalmazás a nem várt és/vagy nem gördülékeny leállások kezelésére megfelelő felépítést alkalmaz. A kizárólag-összeomlás (crash-only) elleni tervezési mód ezt a koncepciót vonja le logikus végkövetkeztetésként.

The Twelve-Factor App: IX. Disposability

Szólj hozzá!

NetAcademia főnixperiódusban

2018. január 30. 12:26 - Fóti Marcell NetAcademia

Írta: Nagy Gergő (NetAcademia) (Bárcsak itt is működne a kukac karakter...)

pic_pulse_stock_article_11.jpg

Volt egy beszélgetésem, amiben az alábbi kérdés merült fel: 

“Nekem a főnix csak nagyon halvány emlékeket hoz elő, kifejted pls kicsit, hogy mit értesz főnixperiódus alatt?”

Ez az iromány erre a kérdésre született válaszként, csak kicsit kinőtte magát, úgyhogy inkább cikk lett belőle.

A Főnix az az elpusztíthatatlan, örökéletű madár, ami mikor az életciklusa végére ér, porrá ég, majd hamvaiból újjáéled. Mint a Doctor Who, csak ő madár :)

De mit is jelent ez a NetAcademia szempontjából ? 

Ahhoz, hogy ezt értelmesen el tudjam mondani, kicsit hátrébb kell lépnünk először, mivel ez is egy emberi történettel indul. Minden ember élete periódikus valamilyen szinten. Nem kivétel ez alól Marcell sem, aki alapította a céget. De hogy is néz ez ki? 

  1. Idealista vagyok, ötletem van, csináljunk valamit. 
  2. Elkezdem csinálni. 
  3. “Né’ má' ez király és még jó pénzt is termel.” 
  4. Akkor csináljuk tovább. 
  5. Mindennap ugyanazt csinálom, és hiába tudom, hogy ez király, de azért érdekes lenne valami új dolgot is kipróbálni. Mondjuk csináljuk bort. Miért ? Mert olyat még nem csináltam. - Ez eléggé olyan mint az 1-es pont nem ? :) Akkor ugorjunk a 2-es pontra.

Viszont mi történik, amikor ennek a ciklusnak a mentén létrejön cég, szervezet, akármi, aminek azért igen hasznos lenne tovább csinálni amit csinál, mert azért csak értéket teremt ? (Meg nyilván bevételt is, hogy ne legyünk álszentek :)) Hát van a triviális válasz (zárjuk be, adjuk el), és az általános megoldás (elkezd a rendszer “valahogy” működni). Meg van a nehéz, de jó - jöjjön a következő generáció.

Esetünkben a következő generáció a megoldás, ami mentén elindultunk, viszont ez azért nem ennyire lineáris, vagy egyszerű. Először van egy “valahogy” működünk rész, utána peidg, mikor összeáll a következő generáció, akkor egy “elengedési - átvételi” ciklus. Ebben a részben általában csökken a produktum a világ felé, mert a belső dolgok viszik el az energiát. Viszont amikor ezek a belső dolgok helyre kerülnek, akkor jöhet a megújulási - “hamvaiból feltámad” szakasz.

Na mi most pont ezen a ponton vagyunk. Ez sokszor nehéz, sokszor felemelő de leginkább nagyon inspiráló. Én személyesen legalábbis ezeket az időszakokat imádom a legjobban. Amikor a lehetőségek végtelenek, de ezzel arányos a stressz és a feladtok mennyisége is. Viszont szerintem az “igazi csodák” bizony ebben a szakaszban történnek! 

Oké, értem. Újulunk. Király. De hogy ?

Ennek része esetünkben például az, hogy az infrastruktúránk nagy részét kicseréljük vagy átalakítjuk, változtatunk az oktatási módszereinken, illetve az egész működésünket átformáljuk teória - mérés - döntés körforgásra, ami azért egy elég erős dolog szerintem. 

És a "csontvázakkal" mi van ? 

Személyesen nagyon élvezem, hogy bárkit megkérdőjelezhetek, és engem is akárki megkérdőjelezhet. NINCS TABU! Erre pedig az a reakció, hogy oké próbáljuk ki, nézzük meg melyik a hasznosabb, és menjünk a jobb irányba.

Építsünk brain tank-ot

Ez azt jelenti, hogy alapvetően motivált, tehetséges embereket keresünk kiemelt témák oktatásárára, tanárainknak pedig igyekszünk szabadkezet biztosítani tudásátadási módszerük kialakításában. Úgy tanítsanak, ahogy azt ők maguk a leghatékonyabbnak gondolják! 

Legyünk interaktívabbak!

Jelenleg futó kurzusainkat a gamerekhez hasonlóan streameljük. Interakcióra chaten van lehetőség a diákok oldaláról, viszont oktatóként többször ütköztem ennek limitáltságába. 

Amikor tanítok, nagyon szeretem látni a megértést a másik oldalról - elvégre ezért csinálom. Fontosnak találom tudni, hogy mennyire voltam érthető, gyors, lassú, részletes, vagy éppen felületes, majd a visszajelzések alapján fejlődni. 

Sokszor az is probléma, hogy diákjaink az én rutinomhoz hasonlítják magukat, nem pedig egy hasonszőrű kezdőhöz, így gyakran kudarcként élik meg a fejlődésüket.

Ezeknek a megoldására találtuk ki, és teszteljük a “referenciadiák” rendszert. Azaz amikor lehetőségünk adódik rá, az órákra “beültetünk” - nyilván online - egy olyasvalakit, akinek lehet magyarázni, és adott esetben kérdez is. Úgy képzeld el, mintha online csinálnál pair programmingot egy juniorral. Építed a projektet, miközben minden lépést elmagyarázol a másiknak.

Természetesen vannak aggályok az ötlettel kapcsolatban - mennyire lesz bonyolult partnert találni, rontja-e az oktatás hatékonyságát stb. De hát itt jön majd a mérés. Megnézzük, hogyan működik a dolog, és ezt kiértékelve döntünk arról, hogy megtartjuk-e. Eddig egy ingyenes html kurzusban teszteltük, és elég jól jött ki. 

Csináljunk tanulócsoportokat!

Emellett szeretnénk bevezetni a kiscsoportos közös foglalkozásokat is. Valami olyasmit kell elképzelni mint a közös zh-ra, vizsgára felkészülést. Azaz összeültök páran, akik ugyanazt tanulják, vannak feladatok, amiket meg kell oldani, és ezt mindenki csinálja magának. Lehet egymástól kérdezni, illetve mindig van valaki aki tud segíteni is, ha elakadás van.

Definiáljuk az értékeinket!

  • Szabadság - Miért kéne, hogy a tanulás földrajzhoz vagy napszakhoz kötődjön ? 
  • Elérhetőség - Azaz ne kelljen milliós tandíjakat elkérnünk, hanem elérhetők legyünk bárkinek. Én személyesen nagyon hiszek abban hogy a tudás alapjog, és __nem__ privilégium. 
  • Hatékonyság - Alakítsuk ki az oktatásainkat úgy, hogy az a legjobban támogassa a tanulási folyamatot. Mert mint bizonyára tudjátok, oktatás nincs! Csak a tanulást lehet segíteni és a személyes motivációt támogatni. 
  • Hitelesség - Csak olyan témaköröket tanítunk és csak olyan tanárok tanítanak, akik gyakorlatban is alkalmazzák azt, amiről beszélnek. 
  • Naprakész tudás - Ez leginkább a front-end és webes dolgokra igaz, ahol minden fénysebességgel változik. Nézzük meg, hogy mik az aktuális trendek a világban és aszerint tanítsunk. Miért kellene lemaradásban lenni, ha az élmezőnyben is lehetünk? Gyorsan fejlődik a Vue ? Használjuk és oktassuk azt! https://risingstars.js.org/

Zárás gyanánt 

Talán azt tudnám megfogalmazni, hogy eléggé szerencsésnek érzem magam, hogy ide keveredtem. Olyan közeg ez számomra, ahol a kultúra és az értékrend egybevág azzal, amit mindig is kerestem. Az anyagi háttér is stabil - teszem hozzá transzparens, ami igen nagy szó - és a munkánk során olyan dolgot építünk, ami jobbá teszi a világot és segít az embereknek. 

Ráadásul ahhoz, hogy ezt az egészet a lehető legjobban képviseljem, “csupán” azt kell csinálnom, amit imádok. Tanulni 0-24, fejleszteni és ezt átadni másoknak. Meg néha ezeket kiírni magamból, hogy lehetőleg minél több emberhez jusson el az üzenet :)

Let's talk!

Persze a végére a hatékonyságot dobjuk meg még kicsit :) Ha a fentiekben olyasmit olvastál ami tetszik, akkor bátran írj rám és beszélgessünk! Van háttér és építkezünk gőzerővel, úgyhogy ha szeretnél ebben részt venni, akkor legalább 6*10^23-féleképpen tudsz nálunk értéket teremteni! :)

Akko’ csá!

Szólj hozzá!

C# programozó vagy és érdekel a Blockchain (Bitcoin)?

2018. január 29. 17:07 - Plesz Gábor

A kriptovaluták technológiája általában is érdekes téma, C# programozóként viszont eddig nem nagyon volt átfogó segédeszköz a kezünkben, egészen mostanáig. Egy ingyenes könyv segítségével már ebből sem kell kimaradni.

A tartalomjegyzék

Programming The Blockchain in C#

Szólj hozzá!
süti beállítások módosítása