Elég sokat gondolkodtam rajta, hogy mikor mondjuk csinálok egy képgalériát, vagy csak simán egy webshop termék oldalát, meg tudom-e oldani valahogy, hogy a programnak ne kelljen 1000 különböző képet létrehoznia.

Volt egy oldal, ahol a grafikai tervek miatt 16 különböző méretarányú képet kellett használni. Tehát írtam egy php scriptet, ami mindig legenerálja - ha nem létezik - a megfelelő méretű képet. Ezzel eddig nincs is gond, mert a képek a méretezés miatt csak néhány KB helyet foglalnak, de azért sok kicsi sokra megy.

Most találtam rá nemrég a CSS egyik szolgáltatására az object-fitre.

Pont múltkor beszélgettem egyik ismerősömmel, aki olyan megrendelést kapott, hogy az oldal tetején és alján is maradjon egy sáv, de a teljes szélesség ki legyen töltve.

Már akkor ráztam a fejem, hogy ez egy nagy baromság. Az emberek ész nélkül nyomkodják a Windowsos telepítéskor a Next gombot, feltelepítve ezzel 2000 toolbart és 42000 vírust. Nem is ezzel van a baj.

A fő kérdés inkább az, hogy ezt szépen, hogyan lehet megoldani? Egy tapasztalatlan, Next-nyomkodó felhasználónál egy csík marad az oldalból? Hogy fog ez egyáltalán jól működni?

Ha belegondolunk abba, hogy a monitorok sem ugyanakkorák, sőt a régi CRT-ket lehetett orrba-szájba állítgatni. Ha nem zavart a 60Hz, akkor egy 14colosból ki lehetett hozni 1280×1024-es felbontást is, holott a normális működés, 85Hz-n 1024×768 volt.

Mivel sokszor van, hogy csak 1-2 mintakóddal vagy néhány sorral le lehet írni egy problémát, így most úgy döntöttem indítok egy "Egyperces" sorozatot is.

Rövid, tömör, gyorsan olvasható, kis problémákra megoldást nyújtó leírásokról. Nem fogok kilométereket írni, a legtöbb bejegyzés csak néhány soros lesz, maximum néhány sornyi, rövid mintakóddal.

Már írtam hosszabban néhány relatív mértékegységről, mint például a vh és vw használatáról vagy a rem-ről.

Sokan bele sem gondolunk szerintem, hogy hány különböző méretezési lehetőség van a CSS-ben. Én is a napokban futottam bele egy érdekes oldalba, ahol összeszedték és vizuálisan ábrázolták is mindegyiket.

A CSS Ruler névre keresztelt oldalon megtaláljuk ábrázolva az összes relatív, abszolút és látótérhez százalékos mértékben számolt értékeket és akár játszhatunk is vele:

Hivatalosan is bezárom a DicsakBuksit. Sajnos nem tudtam teljesíteni vele azt a szintet, amit régen kitűztem. Persze, tudom, hogy a semmiből nem lehet várat építeni. Emiatt is hoztam meg a döntést, hogy a Buksinak sajnos mennie kell.

Nulla háttérfinanszírozással indult az oldal. Egyedül a domain került pénzbe. Ezt az oldalt azért csináltam, hogy kipróbáljam magam ebben a műfajban is. Sajnos így is későn léptem a csatatérre. Már akkor, mikor el kezdtem gondolkodni azon, hogy megcsinálom, működött a NemKutya, akkor élte fénykorát a Napiszar.

Ezután mindenki nyitotta sorra a viccoldalait. Sajnos ez megváltoztatta a teljes "műfajt". Már az volt a lényeg, hogy minél több reklámot, megosztást generáljanak az oldalak. Jöttek a rejtett like-gombok, a kötelező megosztás, a kötelező like. A pofátlan oldalak 1-2 nap alatt több ezres követői tábort szereztek maguknak.

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.

A Bootstrap és a Foundation talán mondhatjuk, hogy a legelterjedtebb CSS-keretrendszerek a weben. Személy szerint eddig a Bootstrapet támogattam, mivel már a 2.3.2 idején, vagy még lehet előtte, megismerkedtünk. Aztán, mikor kijött a 3-as, első körben baromira nem jött be. Még a Google+ fiókoman is hangot adtam ennek, pedig ritkán szoktam bármit is posztolni.

Persze, csak a már megszokott 2.3.2 miatti kirohanás része volt. Egyszerűen nem láttam át az új gridet. De még utána max 1-2 oldal készült 2-ben. Szépen lassan megszoktam a 3-at, sőt...

Tehát, elkezdtem tanulmányozgatni a 3-as Bootstrapet, de valahogy mindig kevésnek bizonyult. Akárhogy designolod, mindig megvan az a tipikus, 1-2 kattintás után érezhető Bootstrap-feeling. Elkezdtem vadászni a neten és ekkor találtam rá a Foundation-re. A ZURB által készített keretrendszer első ránézésre kicsit többet adott, mint a konkurencia. Tehát akkor kicsit összefoglalom, hogy melyik rendszer pontosan mit ad hozzá az élményhez. Persze, mint mindennek ezeknek is megvan a saját előnye és hátránya. Egyik rendszerhez sem húzok igazán, így talán reálisabb képet tudok felállítani.

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.

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.

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.

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.

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.