L

A cache probléma végleges megoldása

Közel 3 hete foglalkoztam a blogon utoljára a kérdéssel, mi legyen a cache-sel. Akkor csak körvonalakban volt meg, hogy mit szeretnék, közben teljesen rendet raktam a káoszban. Első fő kérdés, hogyan tároljam az értékeket. Két lehetőségem volt, serialize vagy json_encode. Ezután végeztem egy mérést, hogy melyik a gyorsabb. A tesztnél fontos volt, hogy a letárolás és visszaolvasás együttes sebessége legyen gyorsabb. Így végül a serialize - unserialize páros nyerte a versenyt.

Ezután felvetettem a kérdést, hogy letároljam-e a teljes HTML kimenetet. Ökörség lett volna ezt is szerializálni, úgyhogy ez a lépés kimaradt, helyette kapott a cache egy bővítést, így képes letárolni a teljes HTMLt is. Ezen még majd módosítani kell kicsit, de jelenleg teljesen tökéletesen végzi a dolgát.

Mercurial: Auto Commit

Mivel legtöbb helyen kérik, hogy ismerj legalább egy verziókövető rendszert, így én is próbálkozom vele. Az egyetlen gondom az, hogy itthon nem sok értelme van a verziókezelésnek, kivéve az, hogy látom, milyen irányba halad a programom.

A verziókezelést főleg nagyobb projektekben, több programozó esetén érdemes kihasználni. Régen mindenki CVS-t, SVN-t használt, amit jelenleg felváltott a Git vagy a Mercurial. Nyílt forrású (open-source) projektekben kifejezetten a Git nyer. A Github megszületésével pedig mondhatjuk, hogy teljesen átvette a hatalmat. Tehát, kérik is, hogy tudd használni, főleg a projektek fejlesztésénél.

Kérések feldolgozása - avagy a Router Class

Egy dinamikus oldalnál elengedhetetlen, hogy valahogyan feldolgozzuk a kéréseket. Bevett szokás, hogy a .htaccess fileban a nem létező mappákra és file-okra csinálunk egy átirányítást az index.php-ra. Ezután millió és egy különböző megoldás van arra, hogyan dolgozzuk fel a kapott információt.

Jelenlegi módszer

Amit most használok, full egyszerű, amit már leírtam a Harc a cache-sel 1. részben. Ennek lényege, hogy adatbázisban a menüpontoknak 3 különböző értéke lehet: type, file és link. Tehát bejön a kérés a szerverhez, majd egy függvény mindenképpen kiveszi a linkből a nem oda illő karaktereket, ékezetmentesít, és minden nem megfelelő karaktert --re cserél. Ezután feldarabolja az URL-t a / jelek mentén. Az első mindig a feldolgozó egység neve. Ezt keresi meg az adatbázisban.

Harc a cache-sel - 1. rész

Egy új programot készítek szabadidőmben, ami már most - a tervezési fázisban - is nagyon bonyolultnak ígérkezik. Legalább van benne egy kis kihívás. Első körben megpróbáltam egy létező kód újraírását, bővítését, de rájöttem, hogy a saját logikám alapján gyorsabban fogok haladni. Sajnos, mire megszokok egy új logikát, addig rengeteg idő elmegy, ami nem frankó. Tehát marad a saját logika.

Alapként a jelenlegi motoromat akarom használni, csak kicsit tehermentesíteném az adatbázist. A jelenlegi motor működési elve tök egyszerű, van egy xy_menus tábla az adatbázisban, minden menüpontnak 3 vezérlőoszlopa:

  • file
  • type
  • link

A slug alapján lekérdezi az adatbázisból a megfelelő menüponthoz tartozó értékeket, majd megnézi, hogy van-e link érték. Ha talál a mezőben valamit, akkor automatikusan átirinyítja a felhasználót a linkre. A type mezőt hasonló tartalmak, pl szöveges tartalmak betöltésére használja, így ha ebben a mezőben mondjuk text-content értéket talál, akkor automatikusan betölti a szöveges tartalmat. Majd végül, ha a másik két mező üres, mepróbálja betölteni az adott filet.

Ez eddig szép is, de ami emögött van, arra nagyon nem vagyok büszke... Felesleges körökkel fut a program, rengeteg olyan feladatot végez el, amit nem kellene. Így most csak a logikát akarom megtartani, a sallangot kihajigálom és újratervezem a működést.

Harc a cache-sel - 2. rész

Az első részben már nagyjából kifejtettem a koncepciót. Tehát, van egy alap file alapú cache. Kiválasztottam a tárolás formátumát, már csak néhány kérdésem maradt. Ezeket próbálom most összerakni, hogy a végén a teljes rendszert ki tudjam szolgálni cache-ből.

Második mérkőzés - mit és hogyan tároljak?

Elsőre a kérdés lehet kicsit hülyén hangzik, de megpróbálom kifejteni, min töröm a fejem. Tehát azt már tudom, hogy az adatbázis lekérdezéseket egyszerűen le tudom tárolni fileba, így az időigényesebb lekérdezések eredményét is egyszerűen adatbázis nélkül vissza tudom kérdezni.

Tervek a jövőben

Tovább fejlődni

Az első és legfontosabb haladni tovább a profi programozó címért ezzel együtt a jó programozó követelményeit is folyamatosan teljesítenem kell. A gyakorlás egyik előnye, hogy folyamatosan bővülnek a tapasztalataim. Minden reggel, mielőtt elkezdek a tényleges munkával foglalkozni, leülök a gép elé, és egy kisebb feladatot megoldok. Ennek előnye, hogy ezek a feladatok rögzülnek, így gyorsabban meg tudom oldani a feladatot. Első reggel, mikor elkezdtem ugyanez a feladat fél órát vett igénybe, mára 5 perc, eközben a kódom mérete csökkent, a sebessége pedig nőtt. Ehhez persze kellett az, hogy minden alkalommal újratervezzem a kódrészletet, és mindig egyszerűsítsek rajta.

Saját project

Aztán kicsit fel szeretném pörgetni a függőben lévő fejlesztésemet. Sajnos az elmúlt időszakban a saját projectemel nem volt időm foglalkozni, így a fejlesztése is leállt. Most újra elővakartam a backup mappa mélyéről, és elkezdtem átformálni, hogy a régi kódom kicsit átláthatóbb legyen, könnyebben bővíthető és természetesen gyorsabb. Most épp az egyik lekérdezésnél szenvedek, mert nagyon megdobja a memóriát. Alap esetben mindig alacsony a memóriafogyasztás, majd a lekérdezés után 150%-kal megnő. Persze, rengeteg adattal dolgozok, így nem csoda, de a lekérdezést át kellene alakítanom, hogy ténylegesen csak annyi adatot kérdezzen le, amennyivel az adott helyzetben dolgozni fogok. Ezáltal nem lesznek felesleges tömb elemek, melyek plusz memóriát foglalnak. Így számításaim szerint csak duplázódni fog maximum a memória használat. Ami már elfogadhatóbb. Persze, minden alkalommal, mikor ránézek a kódra, jön egy újabb ötlet, még egy kis fejlesztés, egy kis egyszerűsítés, így folyamatosan lefelé tornázom a terhelést.

Ki a jó programozó?

A kérdés jogos, ki a jó programozó, kit tart a környezete, a munkaadók, a programozó társak jónak?

Szerintem a jó programozó:

  • Könnyen tudjon tanulni
  • Hatékonyan ír kódot
  • Ismeri a modern technikákat
  • Folyamatosan fejlődik
  • Rendszeresen gyakorol

Vegyük sorra a fenti pontokat. Vannak átfedések a pontok között, így megpróbálom mégis a fenti struktúrát követni.

Miért éjszaka dolgozik a programozó?

Ha programoztál már valaha, elég ismerős lehet a kérdés, miért éjszaka vagy ébren, miért nem vagy elérhető értelmes emberi időben?

A programozó a kávét kóddá alakítja

Ez egy általános mondás a programozók körében, ami csak részben igaz. Az éjszakai munkának rengeteg előnye van, amit mi szeretünk kihasználni.

Kérdezz meg egy szabadúszót, hogy mikor aktív. Az esetek nagy százalékában fogod azt a választ kapni, hogy éjjel, főleg este 10 és hajnal 2 között kelnek. Ezután kezdődik a napi rutin. Ha koffein függő vagy, akkor lefőzöd a kávét, ülsz pár percet a wc-n, megnézed a híreket. Majd beizzítod a géped munkára.

Sokan tartják úgy, hogy éjjel sokkal aktívabbak, mi ennek az oka?

Leoamros

X

Üdv! Ha még személyesen nem ismerjük egymást, Smajda László vagyok, de szólíts csak egyszerűen Laccának vagy Leoamrosnak. Olyan netbúvároknak osztom az észt, akik szárnyaikat próbálgatják a PHP, MySQL, JavaScript világában, és elakadnak valamelyik folyamat során. Főleg a saját tapasztalatokat írom le, ettől függetlenül kérdezhetsz bátran, lehetőségeimhez mérten válaszolok.

Kategóriák
Címkék
Social Media
Eszközök