L

Gyorsítsunk az oldal betöltésen

A közösségi portálok gyors és egyszerű kódokkal segítik a szolgáltatásaik beágyazását weboldalunkba. Egyszerű copy-paste (másolás-beillesztés) az egész. De ezzel van egy aprócska probléma. Minden ilyen közösségi oldal JavaScript kódot használ, ennek a "gördülékeny" megoldásához. Persze van lehetőség iframeben beilleszteni vagy egyéb finomságokkal játszani, de vegyük az átlagos esetet, mikor egyszerűen a Facebook HTML5 kódját használjuk. Tehát ehhez mindenképp kelleni fog egy JS kód is.

A JavaScript használata egyetlen gondot fog nekünk okozni, mégpedig, újabb lekéréseket fog indítani a céloldal felé. Ezzel növeli a betöltési időt, még több HTTP lekérést indít. Tehát egyetlen szóval: rossz.

Mi a jó megoldás? Használjuk helyette a megosztás linkeket.

Miért jó ez nekem? Most persze szintén a Facebookból indulok ki, és a saját megfigyeléseimből. Tehát, ha megosztasz valamit a Facere, akkor az a hírfolyamodban egyből megjelenik, hogy "XY shared a link". Végig görgetem a hírfolyamot és sehol sem látok olyat, hogy "XY liked a link", ez persze a chat felett jelenik meg a Tickerben. Arra nagyjából hetente 1x nézek rá, amikor az online ismerőseim között keresem azt, akire rá szeretnék írni.

Bezár a DicsakBuksi

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.

Miért döntöttem így?

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.

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.

Visszajelzések

LeoamrosLeoamros 2015.02.26.

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.

Tanulj meg nemet mondani

LeoamrosLeoamros 2015.02.25.

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.

A jó és a profi programozó közötti különbség

Szóval profi programozó szeretnél lenni? Büszkén akarod a világnak hirdetni, hogy "Profi vagyok!"? Azt szeretnéd, hogy az emberek tisztelettel tekintsenek rád, vagy hogy a szülők példaképként emlegessenek a gyerekeik előtt? Ráadásul minezt egyszerre?

A profizmus kétélű fegyver

Már az előző bejegyzésben taglaltam, hogy mitől jó egy jó programozó. Tehát, ahogy kifejtettem előzőleg, a jó programozó minden erejével a fejlődésre és a tudásszintjének növelésére koncentrál. Minden helyzetben feltalálja magát, minden aktuális újdonságot ismer, és nem lepődik meg, ha ritkán látott technikákat kérnek tőle. Tehát fejlődik, tanul, gyakorol.

Milyen hibákat követhetsz el a munkában?

Ez egy teljesen szubjektív vélemény. Az évek során volt szerencsém több cégnél is dolgozni, így csak a saját tapasztalataim és elképzeléseim alapján tudom meghatározni a választ.

Ettől függetlenül persze mindenkinek megvan a saját véleménye, nem kell osztoznod az enyémen.

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