Mikor legutóbb egy szoftverről készítettem tesztet, annak reményében tettem, hogy cserébe ingyen license lesz a jutalmam, ahogy a weblapjukon állították. A szoftver a WebcamMax volt, és bár ígéretesnek tűnt és sok szépet írtam róla, kiderült, hogy a gyakorlatban alkalmatlan arra, amire a játszadozáson túl használni szerettem volna. Most azonban a FotoJet online képszerkesztő csapata keresett fel engem azzal, hogy írnék-e egy cikket a termékükről. Ehhez pedig hajlandóak ingyen premium license-t adni, hogy minden funkciót kipróbálhassak. Ők megtették, amit ígértek, így most rajtam a sor, hogy teljesítsem az én feladatom. Lássuk tehát kíméletlenül, mit lehet tudni a FotoJet-ről.

Volt már olyan, hogy VPN-t kellett használnod egy távoli, privát hálózat gépeinek eléréséhez, de közben a helyi hálózati eszközökkel is szeretted volna megtartani a kapcsolatot? Én már jártam úgy, hogy azért szakadt meg a laptop és az asztali gépem közötti RDP kapcsolat, mert be kellett lépnem otthonról egy munkahelyi gépre. Szerencsére nem a VPN az egyetlen lehetőség ilyenkor. Ott van például az SSH tunnel. Ez inkább Linuxon népszerű és egyszerű. Windowson kicsit trükkösebb. Ilyenkor viszont gyakran nem úszod meg, hogy a rendszer hosts fájlját szerkeszd azért, hogy a távoli szerver virtuális hosztjait külön-külön elérhesd. Arról nem is beszélve, ha egy távoli fájlrendszert szeretnél felcsatolni például samba-n keresztül. Ekkor a samba portok átirányítása feladja a leckét. A VPN is problémás Linuxon, ha a távoli VPN szerver nem kompatibilis egyik kliens programmal sem. Én pontosan így jártam, és azóta kerestem a megoldást, amit most megtaláltam. Ehhez írtam egy kis programot, amit most bemutatok.

A napokban kérdezte tőlem egy ismerősöm, hogy hol talál youtube linket értelmező BB kódot. Nyilván, ma már mindenhez írtak ezerféle megoldást, de egy gyors Google kereséssel nem találtam megbízhatónak tűnőt, ezért kis gyakorlásként írtam egyet. Ezen azért nyilván lehetne még optimalizálni, de ha valakinek hiányzik egy függvény, amivel Youtube videók linkjét vagy csak azonosítóját alakíthatja lejátszható videóvá, akkor használja bátran.

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.