A breaking címlap
Ez a post egy 2002-es jegyzet alapján készült.
A breaking címlapról teljes lelki nyugalommal állíthatom, hogy a web egyik olyan eleme, ami a maximális szakmai felkészültség mellett tökéletes csapatmunkát is kíván az újságíróktól, üzemeltetőktől és fejlesztőktől. Tervezhető és tervezni is kell rá, a hír műfaj csúcsa!
A breaking üzemmódról a főszerkesztő szokott dönteni, ez áltálában hosszú percekig tart, de ha a döntés megszületett azonnal kell. Az újságírók fejében egy nagy piros gomb van, amit ha megnyom, azonnal vált a site. Ha a realtime váltás nem is, de az egy-két perces szintidő megvalósítható.
A legfontosabb szabályok breaking címlap üzemmódra:
- tervezhetetlen forgalom,
- minden korábbi (tartalmi, üzemeltetési) szabály megszűnhet,
- bármikor életbe léphet,
- bármikor változhat a megjelenése,
- bármilyen tartalmi elemre érkezhet ezerszeres (tízezerszeres) forgalom,
- a tartalom másodpercenként változhat.
A breaking üzemmód legfontosabb és leglátványosabb eleme a minimál címlap. Mit érdemes figyelembe venni breaking címlap tervezésekor?
A lehető legkevesebb http request, minimalizált hálózati forgalom
Nem érdemes külső css és js fájlokat használni. Nagy általánosságban elmondható, hogy a html kód csak képek esetében tartalmazhat új http requestet. Minden mást egy requesttel kell lekérni a kliensnek. A css, html, js fájlok esetében a lehető legkisebb fájl méretet kell elérni. A kód csúnyasága nem szempont, gányolhatunk kedvünkre. A cssben optimális az egy betűs class név, minden egyes byte megspórolása több user kiszolgálását teszi lehetővé a sávszélesség használat optimalizálásával. Javascriptet ne, de ha igen, akkor tömörítve. A space az ellenségünk, nincs rá szükség kódszinten ha nem befolyásolja a működést (ne tegye).
A breaking üzemmódra külön web szerver, proxy szerver konfig ajánlott. Megfontolandó, hogy a breaking üzemmódú címlapra külön web szerver alkalmazást készítsünk fel. Pl. apache helyett lighttpd. Fontos kérdés, hogy a csökkentett címlapunk dinamikusan generáljuk, statikus fájlként, vagy reverse proxy-n keresztül szolgájuk ki. Mindhárom esetben tisztában kell lenni azzal a ténnyel, hogy hírverseny másodpercekben mérhető és mérik is. Egy-egy hírfrissítésnek azonnal láthatóvá kell válnia és az esetleges typok se lehetnek kint percekig. Ugyanez igaz az oldal sablonra. Bármikor készülhet egy új verzió, több hasábos, kevesebb hasábos, zöld helyett fekete, fehér helyett piros. A rugalmasság elsődleges, ezért a merev cachelési technológiákat máshogy kell használnunk.
Breaking címlap, how it works?
A breaking üzemmóddal a hírsiteok egymással, de legfőképpen a televízióval versenyznek.
Az új infók, híranyagok gyorsabban és bővebben jelennek meg a neten, de a helyszínen forgató breakinges tv csoport gazdagabb, részletesebb képi anyagot nyújt. Sok esetben, a helyszínen, gyorsabban ellenőrizheti az infók válóság tartalmát. A hírfogyasztás más tudományág, nem kontárkodnék bele, de a tapasztalatom az, hogy breaking eseménykor párhuzamos a tv és internet használat. A hírhez a leggyorsabban szeretnének hozzájutni az emberek.
Ezért az optimális szerkesztőségi üzemmód az, ha egy-egy információforrást egy-egy újságíró követ és a beérkező híreket a közös gyűjtőbe (news pool, news room) dobálja, amit más újságírók címlapoznak.
A címlapra kikerült híreket már más újságírók duzzasztanak fel, az így elkészült anyagoknak szintén azonnal meg kell jelenniük a site-on. (Ezek a cikkek jelentős forgalmat fognak kapni a címlapról, ha normál üzemmódban nem cachelne a CMS, breaking alatt mindenképp kapcsoljunk be minden rendelkezésre álló cache lehetőséget)
Ebből következik, hogy az újságíróknak olyan szerkesztőségi rendszert kell használnia breaking üzemmód alatt ami független a site infrastruktúrájától, azaz ha a site le is rohadt, a híreknek be kell kerülnie az adatbázisba (ez persze hasznos, ha nem csak breaking üzemmód alatt üzemel így a szerkesztőség).
Külön kérdés a régi hír elemek kikeresése és a hírfolyamba integrálása. Ez folyamat egy jól tagelt adatbázis esetén egy emberes munka és ideális esetben csak tiltó klikkre van szükség az admin felületen, azaz alapból "megjelenhet" állapotban kerül a GUI-ra. Ha irreleváns, nem megjeleníthető akkor egy klikk a tiltás.
Breaking üzemmód kellős közepén jöhetnek váratlan és érdekes kérdések, pl.
- éppen hol tartunk a user számban?
- mire kattintok a legtöbben?
- hogy áll a konkurencia?
- elérhetőek vagyunk mindenhonnan?
Nem elég tehát technikailag készülni… Vagy sablon szövegekkel vagy percre pontos adatokkal válaszoljunk.
Képek, videók, ajax, reklámok, auditscriptek, 404 error
A breaking üzemmód legfontosabb technológia kérdése a traffic kezelése. A másodpercek alatt ezerszeresére ugró megterheltség kellemetlen, de a csak szöveges címlap nem versenyképes. A képek, javascriptek, css fájlok nagyon jól proxyzható tartalmak.
Figyelni kell azonban arra, hogy a frissített fájlok más nevet kapjanak, még akkor is, ha minimális változtatás történt. Erre a tőlünk független cachek miatt van szükség.
Képek esetében érdemes észben tartani, hogy egy kép linkje már körbe ment a neten, linkelnek rá. Ha egy képet törlünk, gondoskodjunk arról, hogy az új verziót kapja a user, minimalizáljuk az elveszett usert, a hírversenyben nem csak az aktuális öt percért küzdünk, presztízs és a visszatérő userek az igazi nyereség.
Videók esetében saját video streaming szerver linkelésénél tartsuk észben, hogy felső vezetés lehúzott egy nullát a beszerzéskor... Nem biztos, hogy menni fog
Content network, site csoport, rovatok
A jól üzemelő breaking címlapról bárhova terelhetünk usert. Mindenre kattintani fog, minden információ érdekelni fogja, mindent megakar osztani az ismerőseivel. A főszerkesztő általában ezzel tisztában van és ki is használja. A skálázott rendszerek esetében ilyenkor borul a skálázhatóság, a címlapra, zászlóshajóra dedikált frontendek hiányozni fog más oldalak, rovatok, siteok alól. Megterheltség teszteknél, skálázási sémáknál tervezzünk egységes növekedéssel.
És a végre a breaking üzemmódra is jól alkalmazható aranyszabály: DON’T PANIC!
