Szemléletformálás gyakorlati formában fejlesztőknek, tesztelőknek, üzemeltetőknek.
Nem fogok hazudni, nehéz lesz, de megéri.
Sokat fogsz kódolni, és nem csak a foglalkozáson.
Sőt: elsősorban nem a foglalkozáson, hanem a foglalkozások között önállóan vagy valamelyik csapattársaddal közösen. Ahhoz, hogy tapasztalatot szerezz, kódolni kell, próbálkozni, utánaolvasni, megírni, kitörölni, újra megírni...
A modern szoftverfejlesztési világ rendkívül szerteágazó. A kód megírása csak az első lépés, amit olyan kihívások követnek, mint a stabilitás, skálázódás, biztonság. Ezeket egy tanfolyamon belül nem lehet megtanulni, de az alapokat le tudjuk fektetni, és a szemléletet el tudjuk kezdeni kialakítani.
Egy felhőkarcolót nem épít fel egyetlen építész. Ahogy egy komplex rendszert se fog megírni egyetlen fejlesztő. A modern szoftverfejlesztés 98%-ban csapatmunka, amit csak csapatban lehet megtanulni.
Az sv.simulator 10 héten át 20 darab két és fél órás közös alkalomból áll és ezen felül annyi időt vesz igénybe, amennyit rá akarsz szánni önállóan. A közös alkalmakon személyesen találkozunk.
A program során úgy fogunk működni, mint egy termékfejlesztő startup csapat. Átfogó, működő webes alkalmazást fogunk összerakni, azokkal az eszközökkel, amit együtt választ ki a csapat. Ettől lesz az egész egy szimuláció.
A cél, hogy tanuljunk, de ne feledd, a tanulás akkor hatékony, ha közben jól érzed magad!
Megbeszéljük a szimuláció szabályait, a lebonyolítás menetét. Beszélünk a szoftverfejlesztés állapotáról. Átvesszük, hogy mit fogunk tanulni, és belevágunk azzal, aki nem hátrál meg.
Ez az alkalom ingyenes. Ha továbbra is úgy látod majd, hogy belevágnál, akkor a helyszínen megbeszéljük a továbbiakat.
Kiválasztunk egy projektet, amin a csapat közösen fog majd dolgozni. Rengeteg döntést meg kell hozni közösen: mi legyen a termék, amit fejleszteni fogunk, milyen technológiában, ki miért feleljen a csapaton belül.
POC-okat már ekkor elkezdünk gyártani. Hogy mi az a POC? Erről is lesz szó.
Agile? Waterfall? ScaledScrumbanBullshit? A szoftverfejlesztés különböző módszertanok mentén történik. Ha nem vagy szerencsés, akkor olyan csapatba kerülsz, ahol azt hiszik, hogy ismerik a Szent Grált, ha még ennyire se vagy szerencsés, akkor olyanba, ahol semmit se használnak. Milyen eszközök vannak? Mikor mit érdemes használni? A szoftverfejelsztés ott kezdődik, hogy megtervezzük a keretet, amin belül dolgozni fogunk.
Közben természetesen kódolunk. Prototípusokat fejlesztünk, eszközöket nézünk meg, nyelvekkel, technológiákkal kísérletezünk. Iránymutatás segítségével, de javarészt önállóan, csapatban.
Mindegy, hogy milyen eszközzel menedzseljük a projektünket, nincs végtelen erőforrásunk. Fel kell mérnünk, hogy mekkora a büdzsé, és mire tudunk lőni a rendelkezésre álló kereten belül. Ezen az alkalmon a becslés és felmérés sötét művészetéről lesz szó.
Ezen felül meg fogjuk nézni, hogy mi az az MVP, mire jó a LEAN szemlélet, és közösen eldöntjük, hogy ezek közül mit és hogyan akarunk használni a projektünkön belül.
Lehet úgy is projektet vinni, hogy az üzemeltetési feladatokra csak a fejlesztés késői szakaszában kerül sor. A tudomány jelen állása szerint azonban (DORA devops research) jobban járunk, ha minél hamarabb és minél gyorsabban használható szoftvert szállítunk a végfelhasználóknak. Ezen az alkalmon a miértekről és a hogyanokról lesz szó.
Mindeközben az épülő terméket felkészítjük a folyamatos szállításra (countinous delivery), meghatározzuk a dokumentálási stratégiánkat és tovább optimalizálunk a folyamatainkon.
A DevOps egyes részeit tovább vizsgáljuk, és madártávból bejárjuk az egész folyamatot: code, build, test, release, deploy, operate, monitor, repeat.
A tanultakat felhasználva javítunk a CI/CD pipeline-on, miközben haladunk a feature fejlesztéssel is. Ezt a kettő feladatot nehéz párhuzamosítani, ettől függetlenül szükséges, ha fenntartható fejlesztési sebességet akarunk elérni hosszútávon.
A tesztelés fejlesztői oldalról nem mindig kap elegendő figyelmet. Miközben egy bugos program a legtöbb esetben rendkívül negatív felhasználói visszajelzésekhez vezet (lásd: Cyberpunk 2077). Milyen tesztelési megközelítések vannak? Mit érdemes manuálisan és mit érdemes automatikusan tesztelni? Itt sincsennek egyértelmű válaszok, át kell gondolni, meg kell tervezni.
Átültetjük a gyakorlatba is az elméletet: kitaláljuk, hogy mit, hogyan és milyen mélységben akarunk majd tesztelni.
Az automata tesztelés a modern szoftverfejlesztés egyik tartó oszlopa. A magas rendelkezésre állású oldalak stabilitásának megőrzése elképzelhetetlen lenne nélkülük. De mi a helyzet egy kisebb projektnél? Szükségünk van automata tesztekre már a 0-dik perctől kezdve? Érvek - ellenérvek.
Valamennyi automatatesztet használni fogunk a projekten, de, hogy mennyit, milyen típusút és milyen mélységben, az a csapattól fog függni.
A teszt vezérelt fejlesztés (TDD) valamint az extrém programozás (XP) régóta kitalált és kipróbált szoftverfejlesztési módszerek. Sokan esküsznek rájuk, sokan pedig feleslegesnek tartják ezeket. Bárhogy is, mielőtt egy fejlesztő eldönti, hogy használja-e őket, érdemes alaposabban megismerni a működésüket, és azt, hogy pontosan milyen problémákat is oldanak meg. Meg fogsz lepődni, nem azt, amire gondoltál.
Azt, hogy a projekten belül fogunk-e használni TDD vagy XP módszereket, majd a csapat eldönti.
Milliszekundumokon több ezer potenciális látogatót veszíthetünk. Ha pedig sok a látogató, de a terhelésre nem készültünk fel, garantált az összeomlás. Egy termék esetében a stabilitás létkérdés, és a performancia tesztelése állandó mentőhálónk tud lenni.
A projekten bevezetünk performanciateszteket, és megnézzük, hogy hogyan támogatják a mérések a technikai döntéseket.
A fejlesztés szinte mindig lokálisan történik, az üzemeltetés pedig egy teljesen más környezetben. Ez a különbség sok hibának a forrása, amiket se a fejlesztő, se az üzemeltető nem tud egyszerűen kiszűrni. A konténervirtualizációnak sok előnye van, és ipari standard-nak számít. Ettől függetlenül itt is fel kell tenni a kérdéseket: kell-e? Ha kell, akkor miért és hogyan? Egyáltalán: milyen hosting lehetőségeink vannak?
Docker? VPS? Bare-metal garázs szerver? Ahogy mindent, ezt is eldönti majd a csapat.
Egy startup legnagyobb kihívása a skálázódás. Ezt mind üzletileg, mind technológiailag meg kell tanulni kezelni. Üzemeltetési szempontból az a kérdés, hogy fel vagyunk-e készülve arra, hogy az alkalmazásunk nagymértékű terhelésnek lesz kitéve. Milyen megoldások léteznek? Hogyan álljunk neki a problémának?
Mindeközben kitesszük a rendszerünket egy DDoS támadásnak és megpróbálunk néhány SLA-t meghatározni.
Üzemeltetés közben minél több információnk van a rendszerünkről, annál jobb. Bármi elromolhat, bármikor. Egyedül a monitoring rendszerünkben bízhatunk, ami viszont csak akkor lesz teljeskörű, ha beleépítjük az alkalmazásunkba.
Megint csak a csapat döntése lesz, hogy mire készíti fel az épülő rendszerét: logolás, metrikák, trace? Mindhárom? És milyen mélységben?
A folyamatos monitorozás nem csak a stabilitás megőrzése miatt fontos. Az adat, amit begyűjtünk a felhasználók szokásairól, fontos tényező lesz, amikor a termék jövőjét tervezzük. A valódi UX adat alapú, aminek a feltételeit technológiailag kell megvalósítani.
A / B tesztelés, esetleg canary release? A csapaton múlik, hogy milyen mélyen merül bele az adatgyűjtés világába.
A cyber biztonság is egy végtelen kút, de általában nem kell túlmagyarázni, hogy miért is fontos téma. Mi ott fogjuk kezdeni, hogy belenézünk az OWASP Top 10 webes alkalmazásokra vonatkozó biztonsági ajánlásokba.
A gyakorlást ott fogjuk kezdeni, hogy megpróbáljuk feltörni a saját alkalmazásunkat.
A szoftverfejlesztés során a biztonság nem lehet utólagos gondolat. A DevSecOps célja, hogy a biztonságot már a fejlesztési folyamat legelején beépítse a gyakorlatba. Beszélünk a shift-left szemléletről és arról, hogyan érhetjük el, hogy a fejlesztők, tesztelők és üzemeltetők közösen dolgozzanak a biztonságos kód létrehozásán.
A CICD pipeline-ba berakunk security lépéseket is, de hogy mit, az a csapaton fog múlni.
A felhőszolgáltatások végtelen erdejébe fogunk betekinteni. Miért van ennyi szolgáltatás? Mit használjunk közülük? És úgy egyébként is: mi az a felhő?
A csapatnak azt kell eldöntenie, hogy a projekt igényel-e valamilyen felhőszolgáltatást, és van-e közülük olyan, amiért érdemes fizetni.
A felhőszolgáltatások vonzó alternatívát nyújtanak a legtöbb esetben, hiszen nagyon sok terhet átvállalnak a fejlesztési és üzemeltetetési költségekből. Azonban nem biztos, hogy minden esetben jól járunk, mert a költségek így is nagyra nőhetnek ha nem vigyázunk. A Cloud FinOps a költségoptimalizációról szól, és mindenkinek érdemes rá figyelni, aki a felhővel akar kezdeni.
Nem meglepetés: a mesterséges intelligencia megkerülhetetlen eszköz a modern szoftverfejlesztésben. Valaki szerint 3 év múlva le fogja váltani a programozókat, valaki szerint soha. Ezt majd az idő eldönti, egy biztos: jelenleg nem vette el a programozók munkáját. Helyette az a feladat, hogy megtaláljuk a fejlesztés folyamatában a különböző eszközök helyét.
Összegzünk, lezárunk, és ami fontosabb, átbeszéljük, hogy hogyan tovább. A csapat dönthet úgy, hogy tovább építi a projektet, de az is lehet, hogy megmarad egy felmutatható portfolió alkalmazásnak. Ez már a csapaton fog múlni. A tanultakat ettől függetlenül átbeszéljük, a tapasztalatokat tudatosítjuk.
50 órányi képzés, plusz önálló munka.
Tanulnál magadtól ennyit a nyáron?
Rólam
14 éve tevékenykedem a szoftverfejlesztés területén. Pályafutásomat full-stack fejlesztőként kezdtem, majd üzleti elemzőként és menedzseri pozíciókban folytattam. A kódolás azonban mindvégig az életem része maradt, csakúgy, mint a mentorálás és az oktatás. Vettem részt sikeres projektekben, és közreműködtem veszteséges, elhúzódó fejlesztésekben is.
A covid időszak alatt volt időm elmélyíteni a szoftverfejlesztési ismereteimet, és átgondolni, hogy mitől is függ, hogy egy projekt sikeres lesz vagy sem. Sokféle irányból közelítettem meg a kérdést, de nem talátam válaszokat azzal kapcsolatban, hogy hogyan lehet jól csinálni ezt a szakmát. Remek szakirodalmat találtam technológiai szinten, de ezek nem a projekt egészét vizsgálták, sokkal inkább csak a programozó részét vagy az üzemeltetés részét. Lehetséges egyáltalán jó becslést adni egy projektre? Hasznos az agilis fejlesztés vagy csak egy buzzword? De ha nem jó, akkor mit használjunk helyette? És egyébként is, miért jelenik meg hetente egy új JavaScript framework? Ebben a kaotikus világban adott számomra egyértelmű, tudományos alapokon nyugvó válaszokat az Accelerate című könyv, ami Nicole Forsgren és csapata kutatási eredményeit foglalja magába. Egész addig a DevOps számomra egy technológiai fogalom volt. Onnantól viszont láttam, hogy a DevOps egy szemlélet, amit egyébként hívhatunk Continous Delivery-nek, vagy akár modern szoftverfejlesztésnek is. A lényege, hogy a fejlesztés alapegysége a csapat, a szoftverfejlesztés pedig sokkal inkább tanulási, semmint termelői folyamat.
Török-Szabó Balázs filozófus meghatározásában a fejlődés tudatos változtatás. Erre a tudatos változtatásra van szükség ahhoz is, hogy egy olyan komplex problémát meg tudjon oldani a csapat, ami számára kihívást jelent. Márpedig egy szoftverfejlesztési probléma vagy teljesen automatizálható, és akkor hosszútávon nincs szükség csapatra, vagy kihívást fog jelenteni. Onnan indulva, hogy nem látjuk a megoldást, azokká kell válnunk, akik ismerik a megoldást. Ez pedig apró lépésekben, folyamatos információszerzés mellett tud a leghatékonyabban megvalósulni.
Az utóbbi 4 évben arra törekszem a szakmámon belül, hogy a folyamatos fejlődés szemszögét a szoftverfejlesztés területén képviseljem és megismertessem másokkal is.
Rólam mondták
Július 2-án lesz a start, egy ingyenes bemutató alkalommal, ahol megtudhatod, hogy mi vár rád, ha jelentkezel a programra.
Foglald le a helyed most! Dönteni ráérsz utána is.
Az első, bemutató alkalom díjmentes.
A képzés díjának kifizetése átutalással történik. Részletfizetés lehetéges. A fizetéssel kapcsolatban minden szükséges tudnivalót át fogunk beszélni a bemutató alkalmon.
Képzés helyszíne
Budapest, XX. Vizisport utca 21 / B
Egy barátságos teremben leszünk a csodálatos hangulatú Mediterrán lakópark közepén. 100 méteres körzetben található kávézó és élelmiszerbolt is.
Jelentkezéssel kapcsolatos kérdések
Kapni fogsz egy oklevelet és egy LinkedIn badge-t, de nem ez a valódi érték, hanem a tudás, amit elsajátítassz. Átfogó rálátásod lesz a mai szoftverfejlesztésre, és olyan technológiákkal fogsz megismerkedni, amit sok senior fejlesztő sem ismer. Ettől függetlenül hidd el, sokat számít ha olyan kulcsszavakat, mint pl. Docker, Prometheus, GtiHub Actions, Playwright... fel tudsz sorolni a CV-dben úgy, hogy valós tapasztalattal is rendelkezel belőlük.
Egy képzésen valójában semmit se lehet megtanulni. Tanulni, gyakorolni, utánajárni neked kell. Amit itt kapsz az a big picture, valamint alapok és iránymutatás, hogy merre indulj. A képzés lényege, hogy csapatban és projekten fogsz dolgozni 10 héten át! Ha komolyan veszed, akkor rengeteget fogsz tanulni. Ha csak bejársz a képzési alkalmakra, de azon felül nem tudsz rá időt szánni, akkor ez a képzés nem neked való. Abban az esetben nagyon jó online képzések és Youtube videók vannak. De ha nem félsz belevágni egy projektbe, együtt dolgozni másokkal, kipróbálni a hallottakat, akkor garantálom, hogy szintet fogsz lépni a tudásodban. Tanulni és tapasztalni fogsz. Ez tuti.
Azért tudok garanciát vállalni, hogy rengeteg hasznos ismeretet fogok átadni, és motiválni foglak, hogy minél többet kihozzz magadból. Az elmúlt években közel 800 órányi tréninget tartottam a témában és úgy hiszem, sikerült feltérképeznem, hogy mi az a tudás, amit a legtöbb junior-medior fejlesztő nem sajátít el, és ami miatt a piaci értékük nem éri el azt a szintet, hogy a számukra ideális pozíciókat meg tudják szerezni. De ha az első hét után úgy érzed, hogy nem tudsz tőlem tanulni, és a csapattal sem akarsz együtt dolgozni, akkor kérdés nélkül visszatérítem számodra a költségeket.
Jelenleg nagyon nehéz a piaci környezet, főleg a belépő szinteken. Ez nem azért van, mert a cégek direkt ki akarnak szúrni a junior fejlesztőkkel, és nem is amiatt, mert az AI elveszi a munkát. Egyszerűen arról van szó, hogy különböző gazdasági tényezők miatt jelenleg nem éri meg kockáztatni. Márpedig egy tapasztalatlan informatikai munkavállaló kockázatot jelent. Hiszen a legtöbb esetben tanítani szükséges, mielőtt termelővé vállna. Ha pedig termelővé válik, nagy a kockázat, hogy átmegy egy másik céghez dolgozni. Ha egy informatikus jelenleg nem kap állást, akkor nagy valószínűsséggel tanulnia kell és tapasztalatot kell szereznie. Olyan tudásra van szüksége, ami miatt értékes lesz. Ha úgy érzed, hogy neked megvan ez a tudásod, és szeretnél már dolgozni, akkor nincs más hátra, mint jelentkezni ahova csak tudsz. Ha viszont megakadsz a keresésben, akkor nagy valószínűséggel tanulnod kell és felmutatható tapasztalatot kell szerezned.
Ezt nem garantálhatom. Bármennyire is vonzó marketinges szlogen lenne számomra azt mondani, hogy ez a képzés elegendő tapasztalatot fog neked jelenteni, hogy felvegyenek álmaid munkahelyére, vagy sikerre tudd vinni életed startup-ját, nem fogok illúziót árulni. Ahogy az elején leírtam: ez a nehezebbik út. Ez azt jelenti, hogy tanulsz, fejlesztesz, és közben fejlődsz. De nem garantált a rövidtávú megtérülés. Az viszont garantált, hogy ha végigviszed a képzést, együtt dolgozol a többiekkel a projekten, önállóan is beleásod magad, akkor szinte kicserélődsz fejben. Úgy fogsz a képzés előtti önmagadra tekinteni, mint egy lelkes, de tudatlan informatikusra, aki még nem látja, hogy mennyi mindent nem lát. A képzés után már sokkal jobban fogod tudni, hogy mennyi mindent nem tudsz, és a piaci értéked is szintet fog lépni, ami könnyen lehet, hogy elég lesz. Ha pedig nem lesz elég, akkor legalább már tudni fogod, hogy merre kell tovább menned.
Nem, tesztelők és üzemeltetők is jelentkezhetnek. Alapszintű programozási ismeret viszont feltétel.
Képzéssel kapcsolatos kérdések
Abban, amit a csapat megszavaz. Ez nem egy kódolási képzés, hanem egy mentorált projekt fejlesztési workshop. A program része a csapathoz és a feladathoz illő technológia kiválasztása is. Ha akarjátok Smalltalkban vagy Elixir-ben is programozhattok. Ettől függetlenül vannak nyelvek, amikben több támogatást tudok adni: JavaScript, Java, Python, Go
A projekt a képzésen résztvevők szellemi tulajdona lesz. Nyílt forráskódú szoftverként azonban olyan utóélete lesz, amilyet szántok neki. Az is lehet, hogy valamelyikőtök fork-olja és felépíti rá a következő Facebook-ot.
Sajnos nem. A DevOps eszköztár hatalmas, és mint szakma nem is körülhatárolható ezzel az egy szóval. Még ha lenne is annyi időnk (évek), amennyire szükég lenne egy szakmai DevOps képzés megtartására, akkor se lennék kvalifikált a megtartására. Ennek a képzésnek nem az a célja, hogy mélységében átadja a modern szoftverfejlesztés minden fázisát, hanem az, hogy megmutassa a nagy képet, és segítsen eligazodni ebben a labirintusban. Nem specializált tudást ad, hanem átfogó alapot, és jó sok tapasztalatot.
Ha személyesen nem tudsz eljönni, akkor is legfeljebb 3 alkalommal online bejelentkezhetsz. Ezen felül 3 hiányzása lehet mindenkinek. Ennél több hiányzás esetén a képzés végi oklevél átadása egyéni elbírálás függvénye.
A képzésen kívüli rész a program legfontosabb eleme. Csapatban fogtok dolgozni, és együtt akartok majd egy rendszert összerakni. Ha úgy érzed, hogy a képzéseken felül heti 8 óránál kevesebbet tudsz vele foglalkozni, akkor számodra nem ajánlom a programot.
A személyes oktatáson minden eszköz biztosítva lesz, azonban az önálló munkavégzéshez szükséged lesz valamilyen eszközre. A képzésnek semmilyen különleges igénye nincs. Egy átlagos irodai felhasználásra alkalmas laptop vagy asztali számítógép tökéletesen megfelel.
Most már mindent tudsz...
Legalábbis arról, hogy miért éri meg eljönnöd.
Kérdés esetén írj itt, vagy írj rám LinkedIn-en!
Köszönöm az érdeklődést!
Hamarosan válaszolni fogok.
BrainLib Kft.
1203, Budapest, Vízisport utca 29, 4.em. 1.a.
Blaskovics Viktor