Már milliónyi hobbi projekt van a hátam mögött. Ezért merem ajánlani, hogy kezdj bele te is. Nem kell félni attól, hogy hülyeség az ötleted, nem éri meg a bele szánt idő Indítok majd egy sorozatot azokról a hobbi projektjeimről, amiket nem fejeztem be, de másoknak lehet, hogy jó ihlet forrás.

Sosem hülyeség elkezdeni

Ha van egy ötleted, kezd el össze írni! Például hogy hogyan működjön, miket szeretnél bele pakolni, milyen módszerekkel szeretnél rajta dolgozni.

Van egy érdekes keretrendszer, amit szívesen kipróbálnál? Tedd bele. Ne habozz, ha később nem is tetszik majd kipróbálsz egy másikat. Fontos, hogy kihívásokat is tegyél bele a projektbe, hogy tudd magad fejleszteni. Oda kell figyelni viszont, hogy ne vállald túl magad. Azt javaslom, hogy maximum 2-3 új dolgot tegyél bele, mert a végén belegabalyodsz és feladod. Vannak azért súlyozások is, pl.: Ha új nyelvben akarsz dolgozni, az egy elég combos tanulási folyamatot igényel. Nem feltétlen dolgoznék mellette még egy másik új technológiával is.

Az aktuális ismereteiden túl próbálj többet belerakni.

Mindig megéri a beletett idő

Felmerülhet benned a kérdés, hogy tök jó új technológiákat tanulhatok meg, de ha nem lesz belőle semmi, akkor az időmet másra is fordíthattam volna.

Egyrészt, a tanulásra szánt idő sosem megy pocsékba. Másrészt,véleményem szerint nem szabadna elsődleges célnak lennie, hogy tudd publikálni. Magadnak készíted. Ha elég jó és használható, csak akkor, a későbbiekben fájjon a fejed amiatt, hogy hogyan is publikáld.

Mi legyen az ötlet?

Közhely, de igazából lehet bármi. Van egy szoftveres akadály az életedben, ami mindig is bosszantott? Próbálj írni egy scriptett/alkalmazást, ami ezt megkönnyíti.

Lehet nagyszabású az ötlet, így van rengeteg területe,amivel tudsz foglalkozni. Érdekel a felhasználókezelés? Regisztráció, bejelentkezés, security? Tökéletes, kezdj el egy alap tűzfalat építeni a projekted köré. Többjátékos kártyajátékot akarsz írni? Tanulmányozd, hogy hogyan lehet realtime meccseket csinálni.

Rengeteg lehetőség van. Csak el kell kezdened.

Nincs abban semmi rossz, ha nem fejezed be

Rengeteg projekt van a hátam mögött és egyiket sem fejeztem be. Néhány még mindig a fejemben van, hogy van benne potenciál, de a maradékra sem gondolok úgy, hogy feleslegesen kezdtem bele.

Sok oka lehet annak, hogy félbe hagysz / abba hagysz egy hobbi projektet. Időhiány, elfogy a lendület vagy félúton rájössz, hogy nincs szükséged rá. Ezekben nincs semmi rossz. Ne tekints ezekre, kudarcként. Fontos, hogy belekezdtél, mert elsődlegesen a tanulás volt cél. A későbbiekben képes leszel majd befejezni őket. De ehhez még tapasztalatot kell gyűjtened, - ahogy nekem is.

Gondolj arra, hogy lehet később újra előveszed és folytatod, esetleg újra írod. Akár újabb kihívásokkal megtűzdelve.

Végszóként, csak javasolni tudom, hogy bátran kezdj bele egy hobbi projektbe, legyen az világmegváltó ötlet vagy, akár egy kisebb kis alkalmazás.

Mindig zavart, az hogy különböző projektek miatt váltani kell php, adatbázis valamint nodejs verziókat. Rengeteg idő ment el arra, mert valamit kifelejtettem és már nem úgy működött a rendszer ahogy kellene.

Úgy 1-2 évvel ezelőtt csináltam is magamnak docker segítségével egy jó kis fejlesztői szervert, minden projekthez külön-külön szerver, csak azokkal a beállításokkal ami a projekthez szükséges. Ezzel voltak kis problémák. Nehézkes volt egy új projekt felépítése. Nehéz volt egy kis szerver módosítást végezni rajta, mert minden egyes módositásnal újra le kell buildelni a docker image-et. Éltem ezzel egy ideig, de aztán meg találtam a szent grált miközben kutakodtam a zsh pluginjai közt (zsh-ról tervezek máskor írni)

Lando

Nem, nem a Star Wars Lando-ról van szó, habár én is pont emiatt figyeltem fel annó rá.

A Lando saját docker image-eket használ, de lehet egyedi saját image-t használni benne. Ez adja a báját, hogy végtelenségig lehet testreszabni. Alapja az, hogy van egy szerver ami futtatja a kódunkat. Lehet az apache, nginx vagy bármi amire szükséged van. Nem kell feltétlenül php specifikusnak lennie szervernek (Erről lesz később példa is).

Kezdjük az elejéről. Feltelepíted a dokumentáció alapján. Innentől kezdve végig mehetsz egy egész egyszerű tutorialon ahol bemutatják az alap működését ennek az eszköznek. Részletesen nem fogok kitérni, hogy hogyan is működik mélységeibe. Nekem most egy ismertető a célom.

Ha a Lando segítségével akarom futtatni a projektemet mindig első körben megadom az feltételeket. A Landonak vannak receptjei az olyan alkalmazások futtatására ami elterjedtek, hogy még kényelmesebb legyen egy projekt futtatása. A példánkban nem fogok recepteket használni, mert azok használatával nem lehet belelátni, hogy mégis hogyan is működik ez az eszköz.

Vegyünk egy symfony projektet. Mi kell alap esetben hozzá? Kell egy valamilyen szerver, mint például apache. Ezt felvesszük a ._lando.yml fájlunkba a következő képpen:

name: demo

proxy:
  appserver:
    - demo.lndo.site

services:
  appserver:
    type: php:7.4
    webroot: ./public
    ssl: true

Ez után csak lekell futtatnunk a lando start parancsot és a folyamat végén el is érhető a projektünk. A Lando csinál local domaint, ssl-t mindent is. A projektünket a https://demo.lndo.site linken fogjuk tudni elérni.

Tooling

Ami még nagyon hasznos a Landoban, hogy a projekthez szükséges parancsokat nem kell a host gépeden futtatni, hanem egy egyszerű lépéssel már a docker containerbe futtathatod. Ezzel nem kell feltelepítve lennie semmilyen alkalmazásnak a gazdagépen. Elég ha a container-ben telepítjük fel őket egy direkt specifikus verzión. Tegyük fel én a projektemhez szeretnék yarn package managert használni, de a gépemre nincs feltelepítve a NodeJS. Csupán ennyit kell módosítanom a konfiguráción:

name: demo

proxy:
  appserver:
    - demo.lndo.site

services:
  appserver:
    type: php:7.4
    webroot: ./public
    ssl: true
    build_as_root:
      - curl -fsSL https://deb.nodesource.com/setup_18.x | bash -
      - apt-get install -y nodejs
      - npm install --global yarn

tooling:
  yarn:
    service: appserver
    cmd: yarn

Egy gyors lando rebuild -y parancs után már rendelkezésre is áll a projektünkben a yarn. Csupán a szokványos yarn parancsaink elé be kell szurnunk a lando parancsot, és onnantól kezdve a projektünk container-ében futtatja a scriptet amit akartunk, pl.: lando yarn add vue.

A tooling parancsokat nagyon mélyre menőleg lehet testreszabni, mint ahogy a dokumentáció is írja.

Végszó

Szerintem alapjába véve ezek miatt nagyon erős tool a Lando. Csapatban még inkább ajánlatos használni, mert mindenkinek ugyan az a fejlesztői környezete lesz és az sokat számíthat. Én ma már ha új projektett kezdek el akkor csak Lando segítségével. Mint ahogy ezt a blogot is Landoval futtatom, mert nem akartam külön rengeteg mindent feltelepíteni, ahhoz hogy használni tudjam a Jekyll-t. Csak lehúztam a docker image-et és elindítottam. Alább meg is osztottam a jelenlegi változatát a blog Lando configjáról.

Nagyon szépen köszönöm, hogy idáig elolvastad. Remélem meghoztam a kedved ennek a remek fejlesztői eszköznek a használatára.

Tscháó! ;)

name: keszeiblog

proxy:
  appserver:
    - keszeiblog.lndo.site:4000

services:

  appserver:
    type: compose
    app_mount: false
    scanner: false
    ssl: true
    moreHttpPorts:
      - '4000'
    build_as_root:
      - apk add nodejs npm
      - npm install --global yarn
    services:
      image: jekyll/jekyll:4
      command: jekyll serve
      ports:
        - '4000'
      working_dir: /app
      environment:
        JEKYLL_ENV: development
      volumes:
        - $PWD:/app

tooling:

  jekyll:
    service: appserver
    command: jekyll
    user: jekyll

  yarn:
    service: appserver
    cmd: yarn
    user: jekyll

Most egy újjabb próbálkozást láttok, ami lehet, hogy dugába dől mint az előzőek is. Próbálkoztam twitterrel, blog.hu-val, saját bloggal stb.

Mivel web alkalmazás fejlesztő vagyok adott, hogy saját magamnak írjam meg a blogomat. A wordpress túl egyszerű választás lett volna. A wordperss-be az sem tetszik, hogy rá vagyok kényszerítve a saját működésére. Nehéz a motorház tető alatt dolgozni. Az is lehet, hogy nem igazán értek hozzá, de nem akartam akkora energiát bele tolni.

Végül amit találtam az a jekyll. Nagyon egyszerű a használata, ismerős template kezelő mechanizmusa van. A végső eredmény pedig egy sima html struktúra ami a legygyorsabb kiszolgálást eredményezi.

Találtam is egy szép témát is hozzá. Kicsit módosítottam rajta, hogy végül csak egy javascript és egy css fájl betöltés legyen, hogy a végén kimaradjanak a cdn betöltések.

Vannak még gondolataim arra, hogy mit szeretnék még írni, deegyenlőre ez a legelső posztom ezen az oldalon.

A jelenlegi munkahelyemen, ez egy fontos fejlesztési eszköz. Nagyon egyszerűen fogalmazva az alapelve, hogy először tesztet írunk és utána csak production kódot.

A TDD fejlesztésnek 3 fő lépése van, ami folyamatosan körbe-körbe “hajtódik” végbe.

• Red
• Green
• Refactor

Red lépés

Először is mikor neki állunk egy algoritmus megírásához írnunk kell egy fail-elő tesztet. A teszt megírása elött meg kell fogalmaznunk magunkban, mit is szeretnénk, hogy csináljon az adott függvény amit megszeretnénk írni. Vegyük egy egyszerű példát.

Azt szeretnénk megírni, hogy a végső eredmény egy adott matematikai műveletett végezzen el. PHP-ban írom a példát, mert azt jobban ismerem. Az első tesztünk az lesz, hogy a függvényünk adjon össze 2 számot.

public function testSum() {
	$this->assertSame(7, $this->calc(3, 4));
}

Ha lefuttatjuk az általunk kedvelt kód szerkesztőben a teszt futtató környezetünket. PHP-ban például ez a PHPUnit-ot jelenti. A végeredmény az lesz, hogy pirosan fog vírítani a konzolban.

Ez a Red lépés. Hibára futtatuk a tesztünket és csak ekkor javíthatjuk ki a tesztet, úgy, hogy a production kódban a megfelelő eredményt adjuk vissza.

Green lépés

Ebben a részben javítjuk ki a tesztünket, hogy zöld legyen. Az a fontos ebben a lépésben, hogy nem szabad annál többet írni, mint ami a teszt megkíván. A példa kedvéért a kódunkban nem fogjuk ténylegesen össze adni a két értéket, hanem csak egyszerűen vissza adjuk a 7-et.

public function calc($x, $y) {
	return 7;
}

Ezek után ha újra lefuttatjuk a tesztünket, már zölden is virít. NIncs más teendőnk ezután csak tovább lépni a következő lépésre.

Refactor lépés

A példánkban ennél a lépésnél nagyon nem lehet mit refactorálni, de ennél a lépésnél lehet megtenni azt, hogy amit a production kódban megírtunk azt szépítsük, gyorsabbá vagy újra felhasználhatóvá tegyük. Ennél a lépésnél is nagyon fontos, hogy bármi amit módosítunk a kódunkon, az ne “törje” el a tesztünket. Vagyis mindig zöldben kell maradnunk. Ennek a lépésnek a vége, akkor van mikor magunk úgy gondoljuk.

Miután végeztünk folytathatjuk a lépéseket újra az elejétől.

Repeat lépés

A folyamat kezdődik előlről újra a red lépésben vagyunk, vagyis hibás tesztet kell írnunk. A példánkban látszik, hogy nem a megfelelő a számíásunk, mert hát csak egyszerűen 7-est adunk vissza ahelyett, hogy ténylegesen kiszámítanánk. Ezt nagyon egyszerűen tudjuk orvosolni. Írnunk kell egy másik tesztet ami más eredményt vár a függvényünktől.

public function testSum() {
	$this->assertSame(7, $this->calc(3, 4));
}

public function testAnotherSum() {
	$this->assertSame(9, $this->calc(2, 7));
}

Lefuttatjuk a tesztünket és hibára is fut, nyílván. A production kódunkat már javíthatjuk azzal a lendülettel, hogy ténylegesen számítjuk az értékeket.

public function calc($x, $y) {
	return $x + $y;
}

Fontos, hogy úgy módosítsuk a kódunkat, hogy minden tesztünknek zöldnek kell lennie. Innen mindent újra meg újra meg újra meg újra.

Majd az egésznek vége is van, hogy ha a végeredmény azt adja vissza amit szeretnénk akkor végeztünk is.

Gratulálok, meg tanultad a TDD alapjait.