Nem terveztem ezt a bejegyzést, de egy spontán véleménynyilvánításom annyira kerekre sikerült, hogy úgy gondoltam, megosztom a gondolataimat. Hasonlót 2010-ben írtam, de ez kicsit másról szól. Előfordult már, hogy elhatároztad, hogy valamit megtanulsz és megijedtél az oda vezető úttól, mert azon az úton nagyjából semmi sem érdekel? Ilyenkor eszedbe jutott, hogy talán rossz úton közelíted meg? Én úgy látom, vannak emberek, az informatika iránt érdeklődő kezdők, akiknél alapvető problémák vannak annak megítélésében, hogy hogyan is kéne egyről a kettőre jutni vagy azt sem tudják, hova akarnak eljutni. Az alábbi véleményem ebben próbált utat mutatni.

Tegye fel a kezét, aki még nem bizonytalanodott el abban, hogy mikor nyúljon absztrakt osztályhoz és mikor interfészhez! Annak ellenére, hogy a különbséget általában mindenki érti vagy érteni véli, mégis néha felcserélhetőnek tűnik a kettő. És ez pedig csak bonyolódott PHP-ben, mióta megjelentek a trait-ek, amik sok esetben nagyon vonzónak tűnnek. Ezekről mind írtam 2011-ben egy összefoglaló cikkben, amit szintén érdemes elolvasni, de vajon mikor, melyiket kell alkalmazni a gyakorlatban? Ezt igyekszem tisztázni ebben a cikkben.

Van egyfajta háború az programozói világban az osztályok, interfészek és most már a PHP esetén a trait-ek elnevezését illetően. Igen szélsőséges vélemények tudnak megjelenni, amik nagyon el tudják bizonytalanítani az amúgy is bizonytalan fejlesztőpalántát, de talán még a régebb óta programozókat is. Ahogy az sajnos általában lenni szokott, sokan annyira ragaszkodnak a véleményükhöz, hogy a másik oldal képviselőin már-már szánakoznak, mily balgaságot követnek el. Azt hiszem, itt az ideje egy kissé rugalmasabb megközelítésnek és összehasonlításnak arról, hogy a fenti definíciókat miként érdemes elnevezni, illetve miért nem eredendő bűn egyik vagy másik megoldástól eltérni. A cikkben az egyes csoportok nevei a saját fantáziám szüleményei, hogy megfoghatóbbá tegyem a különbséget.

Webszerverek beállításánál az MPM konfigurálása egy nem elhanyagolható kérdés. Nem az üzemeltetett weblapokhoz optimalizált értékekkel ugyanis előfordulhat, hogy az oldal belassul vagy a látogatók hibaüzenetekkel találkoznak, mert a szerver nem képes több kérést kiszolgálni egyszerre, vagy éppen erőforrást pazarolsz a webszerverre, miközben máshol nagyobb szükség lenne rá. Az Apache HTTPD-nél ismert MPM-hez hasonló a PHP-nél az FPM, ami szintén a processzek kezelését végzi a PHP értelmező esetén, amikor az nem a HTTPD moduljaként működik, hanem külső szolgáltatásként. Mivel a "rimelek.hu" egy időben rendszeresen megállt, akkor megelégeltem tudatlanságom és benéztem a színfalak mögé. Ebben a cikkben összegzem a tanultakat.

Idén 26. alkalommal került megrendezésre a Networkshop nevű számítógép-hálózati konferencia, aminek ezúttal a Szegedi Tudományegyetem adta a helyszínt az SZTE József Attila Tanulmányi és Információs Központ épületében. Az eseményt a Kormányzati Informatikai Fejlesztési Ügynökség (KIFÜ) és a HUNGARNET egyesület szervezte és 2017. április 19-től április 21-ig tartott. A rendezvényen könyvtárosok és az informatika különböző területein dolgozó előadók és érdeklődők jelentek meg, hogy tapasztalatot cseréljenek. Idén én is az előadók számát növeltem, ahol a Dockerrel kapcsolatban szerzett ismereteimet foglaltam össze 20 percben. Az alábbiakban az esemény részleteiről számolok be.

Eddig már két alkalommal is a Docker előnyeiről írtam, de ebben a cikkben a gyakorlatibb oldaláról közelítem meg a témát. Dockerrel elindítani egy már eleve arra készített programot gyerekjáték és így öröm dolgozni. Ezt lehet bonyolítani, de egyelőre bőven elég lesz a vidámabb része. Ehhez azért pár fogalmat tisztázni kell, mert bár a gyerek kreatívan eljátszik bármivel, a Docker esetén jobb, ha tudod, mi, mire való. Mindeközben használhatod a teszteléshez a Play with Docker szolgáltatást, hogy telepíteni se kelljen semmit. És ami a legszebb, legegyszerűbb esetben ennyi egy program indítása: docker run hello-world

Amikor az ember megpróbál egy teljesen új témát bevezetni, problémát jelenthet, hogyan is kezdjen neki, mennyire induljon az alapoktól. Én is így jártam az előző, és egyben első, Dockerről szóló bejegyzésemnél. A visszajelzések felhívták rá a figyelmem, hogy valószínűleg nem volt teljesen érthető és világos, hogy mi is az a Docker és miért jó ez neked. Április 21-én előadást tartok a témában Szegeden a Networkshop konferencián, aminek főpróbájaként a könyvtáros kollégáknak is volt lehetőségem bemutatni a témát. Erre az alkalomra egy olyan, érthetőbb bevezetővel kezdődő prezentációt készítettem, ami ábrákkal teszi felfoghatóbbá a Dockert és annak világát. Ezt a bevezetőt hoztam el cikk formájában.

Korábban már írtam virtuális gépekről és azt is megmutattam, hogyan alakítható ki vele egy komplett fejlesztői tesztkörnyezet. Már ez a fajta virtualizáció is sokat segített bizonyos problémák megoldásában. Van azonban egy másik lehetőség, amikor nem egy virtuális gépet indítasz egy teljes értékű operációs rendszerrel, hanem csak az alkalmazásod számára biztosítod azokat a programkönyvtárakat, binárisokat, amit valójában el szeretnél indítani. Valószínűleg legtöbbetek számára ez alapján egy egyszerű "jail" ugrik be, ahol egy programot be lehet zárni a fájlrendszernek egy adott területére és csak az azon belüli fájlokat látja. Gyakorlatilag valóban valahol itt kezdődött minden.

Elérkezett napja, hogy kijelenthetem az I.T sziget születését. 2009 óta minden saját szerzeményt - legyen az vers vagy szakmai cikk - egy felületen osztottam meg a rimelek.hu oldalon. Mától kezdve az it-sziget.hu veszi át az informatikai cikkeket és a korábbiak is átkerültek ide.

Az utóbbi egy évben egy kicsit új területre eveztem, ami pedig a konténerizáció. A tervek szerint erre a témára nagy hangsúlyt fogok fektetni és megosztom a már elkészült megoldásaimat, illetve újakra is lehet számítani. Így várható a korábbi Tesztkörnyezet kialakítása webfejlesztéshez sorozat Docker-es változata is.

Kisebb változások még előfordulhatnak a weboldalon, ugyanis még nem működik minden tökéletesen, de törekszem rá. Ha bárki bármilyen hibát, kényelmetlenséget tapasztal az oldalon, kérem, jelezze, hogy minél barátságosabb szigetet alakíthassak ki, ami lehetőleg nem lakatlan.

Ezennel megnyitom az I.T. szigetet az informatika végtelen óceánján és bízom benne, hogy hamarosan benépesítjük.

A Phar egy mozaik szó, ami a PHP Archive, azaz a PHP Archívum szavakból jött létre és egyben az archívum fájlok kiterjesztése is. Java programozók a JAR-hoz, illetve WAR-hoz hasonlíthatják. Bár bizonyos tekintetben a Windows DLL fájljaival is párhuzamot vonhatnánk, hiszen egy fájlba csomagolt programkönyvtárról beszélünk. A DLL-ekkel ellentétben viszont a PHAR fájlok futtathatók is, mint egy exe. Természetesen attól távol áll, mivel továbbra is a PHP értelmező lesz az, ami az értelmezést, futtatást végzi.

A PHAR kicsit mostoha gyerek, mert el is terjedt és nem is. Míg a JAR gyakorlatilag kéz a kézben jár a Java-val, a PHP archívumok nem ennyire általánosak és bizony gondolkodni kell rajta, hogy mikor, mire is érdemes használni, ha egyáltalán érdemes.

A PHP, fájlkiterjesztések és kódszervezés című cikkben kihagytam ezt a formátumot, ami lehetett volna szándékos, de szimplán elfelejtettem. Most viszont alaposabban körbejárom a témát. Igyekszem választ adni néhány potenciális kérdésre, illetve mutatok példákat és felhívom a figyelmet a buktatókra.

Abból, amit ez a formátum ígér, nem sikerült mindent kipróbálnom. A dokumentáció gyakran hiányos, és nem is beszélnek róla mások sem. Ettől függetlenül összeállítottam egy példasorozatot a főbb funkciók bemutatására a teljesség igénye nélkül. A példák elérhetők github-on vagy letölthetők Docker image-ként is "1.0" tag-et megadva.