Harc a cache-sel - 2. rész

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.

Teljes bejegyzés
Harc a cache-sel - 1. rész

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.

Teljes bejegyzés
A változások ideje

A változások ideje

Szánalmas.

Ennyivel tudom jellemezni a mostani helyzetet. Tudom, hogy rengeteg rosszat él át az ember, mint ahogyan mostanában én is. Elkezdtem magamba fordulni. Ez meglátszik a blogbejegyzéseimen is. Olyan bejegyzéseket írtam, ami sokszor nem is a programozásról vagy a szakmáról szól, hanem arról, hogy sajnáltattam magam.

Tudom, hogy jelenleg nem vagyok ismert, a blogomat alig látogatják, de mi lesz, amikor felpörög és mindenki azt látja, hogy egy elkeseredett, nulla önbecsüléssel rendelkező ember bejegyzéseit olvassa. Egyből elveszem a kedvét a blogom olvasásától. Tehát itt a változtatás ideje. Ez az utolsó olyan bejegyzés, amiben bármilyen "panaszos" mondatot kiejtek.

Teljes bejegyzés
Mit takar a

Mit takar a "vh" és a "vw"?

Mint azt az előző bejegyzésemben is bemutattam van néhány újabb mértékegységünk, amit használhatunk a sitebuild során.

Az eddig ismert méretezési egységeink:

  • px
  • em
  • pt
  • rem
  • %

Amit pedig most fogunk kicsit körbejárni:

  • vh
  • vw

Jah és ne hagyjuk ki őket sem:

Font méretezés

Font méretezés "rem"-mel

Elég heves viták folynak napjainkban is a megfelelő fontméret egységek kiválasztásában. Sajnos rengeteg előnye és hátránya is van a különböző technikáknak és nem ez az egyetlen felmerülő kérdés velük kapcsolatban.

Két fő technikát használunk/használtunk a CSS3 megjelenéséig.

  • Font méretezés pixelben
  • Font méretezés em-mel

Mielőtt bármibe belekezdenénk vegyük sorra, mik a rég bevált módszerek.

Teljes bejegyzés
Visszajelzések

Visszajelzések

Nem utálatos dolog, mikor napokat, heteket, esetleg hónapokat dolgozol egy projekten, aztán a megrendelő egyetlen apróság miatt hord le?

Persze nagyban függ attól, hogyan mondja:

  • Tudom sokat dolgoztál a projekten, amit nagyon köszönök, jó munkát végeztél. De felfedeztünk egy apróságot...

  • A(z) _____ nem működik. Az egész szar.

Ugye elég eltérő módon hat rád a két különböző megközelítés? Míg az elsőben elismerik a munkádat, megköszönik és a megbántásod nélkül közlik veled, hogy egy "bogárka" került a projektbe, addig a másodikban egyetlen apróság miatt a teljes projekt szar.

Teljes bejegyzés
PHPMailer - Karakterkódolás

PHPMailer - Karakterkódolás

Ha PHPMailerben a feladó vagy a levél kódolása nem megfelelő, elég csúnya eredményeket kapunk. Még a nagyobb cégeknél is sokszor előfordul, hogy a kiküldött levél nagyon gáz. Ha nem megfelelően kódoljuk az emailt, akkor teljes lesz a káosz.

Fontos, hogy maga a generáló php fájl is ugyanolyan kódolásban legyen, mint amilyenben a kiküldött emailünk lesz. Ma már szerintem alap, hogy mindenhol UTF-8 kódolást használunk, nekem a program fel sem ajánlja, hogy más kódolásban hozzam létre a fileokat.

Másik fontos dolog, ha az emailben szereplő adatokat adatbázisból kérdezzük le, akkor az adatbázis kapcsolatot és az adatbázisokat is érdemes ugyanúgy UTF-8 kódolással létrehozni.

Teljes bejegyzés
Tanulj meg nemet mondani

Tanulj meg nemet mondani

Egy átlagos hét 40 munkaórából áll. Ezt a legtöbb esetben be is tudod tartani, de persze vannak olyan helyzetek, amikor 60, 70 vagy akár 80 órákat is le kell dolgoznod hetente, hogy a megadott határidőt tartani tudd. A főnök azt mondta, hogy az említett időpontra kész kell lenni. Ennyi. Vitának, ellenvetésnek helye nincs. Készen leszünk.

A főnök azt mondta, ha törik, ha szakad, a rendszert indítani kell az adott napon. Legtöbbször a főnök a saját vagyis a cég érdekeit nézi. Az ügyfél nagy, kell a bevétel, nem sülhetünk fel. Nem mersz ellenszegülni, nem mered kimondani a kulcsszót, hogy nem fog menni. Pedig a profivá válás egyik feltétele, hogy megtanulj nemet mondani.

A 80 órás munkahétnek a legnagyobb hátránya, hogy agyilag kétszeresen ki vagy használva. Ez 5×16 óra. Természetes, hogy nem tudsz jó kódot írni. Tele van hibákkal, átláthatatlan és a legfontosabb bővíthetetlen vagy nehezen bővíthető. Ha rövid a határidő, kapkodnod kell, átgondolatlanul írod a kódot, hogy meg tudd időre csinálni a programot.

Teljes bejegyzés
Spam! Spam! Mindenhol...

Spam! Spam! Mindenhol...

Alap sztori.

Ülök a gép mellett, épp egy PAYU rendszert rakok össze, mikor egy adat miatt meg akartam nyitni a mail fiókomat. 2 új email. Nincs is vele gond, fel vagyok iratkozva egy pár hírlevélre, gondoltam tőlük kaptam valamit. Szeretem rendben tartani a mail fiókom, így minden mappázva van. Az összes ritkán használt mail fiókom is egybe van irányítva. Így mindent egyből el tudok olvasni.

Tehát ez nem a megszokott hírlevél, hanem egy tök idegen.

Kedves Lacy!

Hogy mi a jó büdös anyád? Soha nem adom meg így, csak facen vagyok Lacy. Érdekes. Gyorsan keresgéljünk kapcsolatot, hogy ki a franc a "titkos" feladó. Azért "titkos", mert nevén nem nevezzük, de amúgy a levelében kb a levél fele csak a cég logója.

Teljes bejegyzés
Tervek a jövőben

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.

Teljes bejegyzés