Firefox addon: Webaudit, Gemius, GA kód checker
Összegányoltamdobtam egy Firefox addont, ami Webaudit, Gemius Google Analytics kód meglétét ellenőrzi az éppen aktuálisan megnyitott oldalban. Ha nincs kód, szép csúnya piros ikonnal jelzi a státuszbárban.
BBC global visual language 2.0
Korábban már körbement(?) az új BBC layout kapcsán postolt leírás a tervezésről, feladatokról. A postban volt egy link a Global Visual Langauge-ról és valahogy sikerült letöltenem egy Global Visual Language 2.0 elnevezésű pdf fájlt. A kötelező "olvasmány" 50 oldal, nagyon sok képpel, kb. 7.8MB, prezentáció jelleggel. (Picit cinkes, hogy nem ismertem / foglalkoztam vele, de talán ezzel vagyunk ezzel így páran, ami nem mentség, de megnyugató mantra lehet másoknak is.)
Webfejlesztőkön kívűl ajánlott még online újságíróknak, project managereknek, egyszerűen, átláthatóan, érthetően magyaráz el okokat, mi miért úgy van ahogy, miért pont ott és úgy van a design elem, ahova a designer, GUI tervező rakta.
Különösebben nem szorul kommentárra, a tartalma magáért beszél. A GVL elérhető itt. A pdf fájl felraktam magamhoz is, remélhetőleg nem törnek rám a bbc ninják. Szánj rá 20-30 percet, inspiráló.
A webet fejlesztő fejlesztők jövője
Freelancerekkel teljesített projectek után általában felmerül a kérdés, mi a következő? Hogyan tovább? Ez természetesen nem egy webfejlesztés specifikus kérdés. Amitől speciálissá válik a kérdés, az a webfejlesztői gondolkodásmód. Webet fejleszteni sok tekintetben jövőkutatás, technológiák, trendek folyamatos keresése, létrehozása, tesztelése, tökéletesítése.
Tapasztalatom szerint a webes szakemberek az átlagnál többet foglalkoznak a jövő tervezésével. Szakmai, pénzügyi, életút témakörben igyekeznek minden lehetőséget megragadni a korai nyugdíjért, de legfőképpen a tudásuk piacképességének megőrzése az, ami miatt a jövőre próbálunk meg a lehető legjobban felkészülni.
A napi teamkommunikáció során sokszor szóesik arról, hogy merrefelé érdemes fejlődni. Mivel elsősorban php fejlesztőkkel vagyok kapcsolatban, a technológia fejlődés lehetőségei a nosql, cache, mikro optimalízáció felé mutatnak. Ugyanez a kérdés-válasz a GUI tervezők / építők esetében a html5, CSS3, jquery (vagy más js frameworkok) felé tendál. A php mellett egyre gyakoribb a perl, ruby, python tanulása, a "pálya" elhagyás inkább reagálás a piaci igényekre, mint szakmai fejlődés.
Mégis azt kell mondjam, hogy ez a fajta "jövőtervezés" inkább nevezhető tökéletesedési folyamatnak, mint valódi jövőtervezésnek. A webfejlesztés igényeit utolérte -talán már le is hagyta- az információtechnológia. Elérhetővé vált a valódi sávszélesség, a html merev korlátjait szép lassan lebontjuk, az IE6 is megdöglik végre. A web végre valódi technológiává válhat. A web sötétközépkora lezárul, a gányolás idővel retro sörözések állandótémájává válhat.
A fejlődés leglátványosabb eleme a platformok közeledése, olvadása. Olyan platformok, mint a TV, internet, videojátékok, mobiltelefon pár éve még ég - föld távolságra voltak egymáshoz. Mára szinte minden kommunikációs és szórakoztató platform bekötésre került az webre, de minimum az internetre. Nem kell sok idő és a háztartási eszközök is beléphetnek a netre és azon keresztül a webre. A mosással végzett mosógép pop üzenetek dobhat majd a "tv"-re, és minden olyan kijelzőre, amire engedélyeztük, "telefon", mobil számítógép. A world of warcraft-ban futár figyelmeztethet a kifogyó red bull készletre és természetesen meg is rendelhetjűk a következő két napra a tálcás kiszerelést (húszat fizet harmincat kap). Az autóink szélvédői belátható időn belül transparent oled kijelzőkké válhathatnak, technikai adatokat szolgáltatva arról, hogy melyik karosszéria elemmé alakított napelem nem termel elegendő energiát. Kis szerencsével ki se kell majd szállni a kocsiból, hogy letakarítsuk a bogártetemeket az alul teljesítő celláról. Rosszabb esetben a család webes to-do listáját automatikusan frissíti autónk egy "apunak le kell mosnia a kocsit" bejegyzéssel.
A web tehát túllép(ett) az asztali monitoron, ennek már jól látható jelei vannak. A mobil internet bármennyire is elcsépelt, egyre jelentősebbé válik. A web fogalmat talán lassan át kell fogalmaznunk magunkban. A web, mint felület már nem a böngésző kompatibilitásról szól. A jövőben talán specializálódnunk kell megjelenítési felületekre, monitorok, mobilok, touchscreen, transparent, szem-és hangvezérelt eszközökre. Tudnunk felület függetlenűl tervezni, a felületek még hosszú ideig nem lesznek szabványosítva, a felhasználói felületek még jó ideig izgalmas játszóterek lesznek.
Bárhogyan is alakul (közel) jövő, a web jelentős szerepet játszik a világ fejlődésében. Ha a jövőre szeretnénk koncentrálni, gondolkodásmódunkat nem gátolhatjuk határokkal, se technológiai se földrajzi értelemben vett korlátokkal. Az eszközökön túl a platformokra kell koncentrálni a hosszútávú szakmai fejlődés tervezése során.
Eszközeink fejlődése a mindennapokat, a platformok fejlődése a jövőt töltik meg tananyaggal.
BTW: egy 3D hologram bolti eladó, hogyan fogja kezelni a touchscreenes pénztárgépet?
A lényeg: 2:55 - 3:05 között.
A szerkesztőségi rendszer – Bevezető – Első rész
Ez a post egy 2002-es munkajegyzet alapján készült. A post témája az internetes hír siteok, hírportálok szerkesztőségi rendszerének tervezése, üzemeltetése, fejlesztése. Reményeim szerint a kezdőktől a haladókig mindenki talál benne hasznosat.
A téma szerteágazó volta miatt több postot szánok a témának. Az első két részben áttekintést nyújtok a szerkesztőségi rendszer működéséről, elemeiről. A további részekben a felszínesebb bemutató után a legfontosabb elemekkel kapcsolatos ismereteim, tapasztalatom alapján próbálok gyakorlatias ötleteket, inspirációt adni. Reményeim szerint minden fontosabb témáról külön post lesz, így ami ebben a postban még homályos az idővel részletes leírást kap.
Pre és pro
A CMS alkalmazások kikerülhetetlenek, ha webes fejlesztésekkel foglalkozunk. A fejlesztők általában nagyon gyorsan eljutnak oda, hogy saját CMS-t akarnak írni. A project managerek nagyon gyorsan szembesülnek azzal, hogy a legtöbb problémát a CMS jelenti cégen belül. Az újságírók nagyon hamar megutalják a nehézkes, logikátlan alkalmazást.
Sokszor hallom (általában sárgaöves) fejlesztőktől, hogy miért kell CMS-t írni, ott vannak a jól bevált opensource CMS rendszerek, azokkal bármilyen siteot meglehet csinálni, és még ingyenes is. Barnaövtől felfelé már jól ismertek az okok:
- megterheltség,
- biztonság,
- fejleszthetőség.
Az ingyenes rendszerek mellé általában legalább olyan képzettségű fejlesztő kell, mintha nulláról fejlesztenénk saját CMS-t. Természetesen lehetséges jól üzemelő, nagy forgalmú siteot készíteni opensource rendszerekkel, de fejlesztés során szem előtt kell tartani, miért is választottuk azt a CMS-t amit.
Ugyanakkor tény, a php frameworkök egyre jelentősebb szerepet kapnak a fejlesztések során, egyre inkább közeledik az időszak, mikor már megéri a framework alapú fejlesztés nagy megterheltségű rendszerek esetében is.
A legfontosabb indok azonban az online újságírói igények. A siker kulcsa az újságírói munka maximális kiszolgálása. A project sikere azon fog, múlni, mennyire tudjuk felmérni az igényeket és mennyire vagyunk képesek fejleszteni újságírói gondolkodásmóddal. Sok esetben az online újságírók közel digitális analfabéták, a szerveri oldali technológiákhoz (a szakírót nem beleszámítva) alig pár újságíróért. El kell fogadni, meg kell érteni, hogy nem dolguk ismerni a lehetőségeket.
<sarcasm>CMS-t fejleszteni igazán kreatív és kihívásokkal teli feladat. </sarcasm> A legfontosabb: take it easy. Ha megvan a zen, ne engedjük el.
CMS vs. szerkesztőségi rendszer
Az online szerkesztőségek életében a CMS sokszor csak egy szoftver „elnevezése”, amivel weben keresztül viszik fel a cikkeket, híreket a site-ra. Fejlesztőként, project managerként azonban tovább kell gondolkodni. A CMS fejlesztésénél a következő területeken is tervezni kell:
- Üzemelési környezet
- Hardware
- Szerkesztőségi work flow
- Online sales
- SEO
- GUI-k
- Kimenetek, formátumok
- Hírügynökségi területek
- Újságírási munkafolyamatok, szokások, szerkesztőség működés
Még egyértelműben, a szerkesztőségi rendszer az alábbi modulokból áll (a teljesség igénye nélkül):
- CMS ADMINGUI ::content admin,
- CMS ADMINGUI ::content pool (news room),
- CMS ADMINGUI ::statisztika report,
- CMS ADMINGUI ::webmester, moderátor, traffic/admester,
- CMS PUBLICGUI ::user felületek
- CMS SERVER::LOGGER
- CMS SERVER::CACHE BUILDER
- CMS SERVER::OUTPUT API
- CMS SERVER::SEARCH INDEXER / CACHE
- CMS SERVER::NEWSLETTER / CONTENT PUSHERS
- SERVER::SQL
- SERVER::LOAD BALANCER
- SERVER::BACKUP
- SERVER::MAIL
CMS. De hogyan? Az Elmélet
Az alábbiakban egy multi domain CMS-t veszek példának. Ahogy előbb utóbb mindenből kalapács (vagy szög) lesz, a CMS-ből is multi domain szoftver lesz.
A multi domain CMS lényege, hogy egy engine több, egymástól teljesen függetlenül működö hír siteot szolgál ki, úgy hogy az adatbázis egységes, és a különböző domaineken futó hír siteok újságíróit segíti a közös munkában. Figyelem, ez a koncepció nem azonos a fejlesztőcégek által használt weblap "gyár" CMS-ekkel. A hangsúly a közös munkán, az egységes hírgyártás és a content átjárhatóságán van, nem a gyors fejleszthetőségen.
Röviden
A hírsiteok esetén multi domain CMS-k kialakulásáért a hírverseny a felelős. Magyarországon különösen, khm finoman fogalmazva is, necces a hírfogyasztási szokás, a nagyon széles horizontális portálok idővel igyekeznek a jól menő rovatokat vertikális oldalakká alakítani
Ideális esetben a CMS-t ilyenkor a domain vezérli, de gyakori, hogy a CMS engine-t "klónozzák" szerverekre. (Utóbbi egyébként hibás elgondolás abban az esetben, ha az adatbázisok között nincs strukturális kapcsolat, pl. eltérő tag adatbázis, más hiearchiában épített tag csoportok, összerendelhetetlenség.)
A portálosodás hatása, hogy a rovatoldalak általában elhalnak, nagyon minimális user számmal rendelkeznek. A forgalmat siteon belül nehézkes terelni, az aggregátor siteokról érkező traffic nagy átlagban zárja a böngészőt, további cikkeket ritkán olvasnak. A korábban már említett hírverseny miatt nagyon sok hír eltűnik egy nagyon széles, vertikális (hír)portálon. Ezért sok esetben a rovatokból önálló brand válik, önálló szerkesztőséggel, önálló tartalmi koncepcióval, a széles vertikális site helyett több, vertikális site jön létre, melyre optimális esetben a horizontális gyűjtő siteról érkező userek mellett direkt traffic is létre jön idővel.
A web CMS fejlesztés során meg kell ismerkednünk a tartalom biznisz alapjaival, mindennapi működésével. Nagy általánosságban elmondható, hogy a tartalom biznisz a sok látogató = sok tartalom képlet alapján működik. Ez számszerűsítve azt jelenti, hogy egy nagy forgalmú hír site képes százas nagyságrendben cikkeket előállítani naponta.
A multi domain CMS lényege az azonos adatbázis (struktúra), mely átjárhatóságot biztosít a tartalmak között. A tartalmak cross linkelése mellett olyan "láthatatlan" funkcióval is felruházható, mint a közös news room, ki, milyen témával dolgozik, hol melyik téma forog. A news room kollaborációs funkció, melynek segítségével a tartalmi piramisok, időzített körbe linkelések alakíthatóak ki, külön megbeszélések nélkül. A vertikális szerkesztőség önálló munkája így egy - egy téma esetén napokig, hetekig a felszínen tud tartani jól pörgő anyagokat.
Példa: Egy cikk megjelenhet a hírportálon. Megjelenhet a tematikus site-on. Mindkét megjelenési helyen más címkéket kaphat. Licenszelési okok miatt a kisebb forgalmú oldalon több képet, galériát kaphat. Megjelenhet más nyelven. Más szöveget kaphat. Megjelenhet más platformon pl. print. Eladható hírügynökségi tartalomként. A későbbiek során, a szerkesztőségi felületen listázható a cikk összes verziója, megjelenési formái, helyei.
Hosszabban
Az újságírók ideje drága. De nem annyira drága, mint az információ. Nem meglepő módon a világban keletkező hírek száma véges. A mai magyar média piacon talán a legnagyobb pénz a hírcsinálásban van. Az álhír piac dübörög, ha nincs hír, akkor csinálni kell, különben nincs mit eladni.
Egy jól szervezett szerkesztőségi rendszerben nincs elveszett információ, a jól megírt cikkek körbe mennek a networkön, a lehető legtöbb olvasót kell elérnie, az a bizonyos bőr sokszor lesz lehúzva. A digitális média, bár nem beszélünk róla, még mindig erős versenyben van a print és elektronikus médiával. A print médiát az online már megverte nagyon sok területen, de a legfontosabban, a bevételekben még csúnyán alulmarad. (A printet egyébként a saját területén tudná megverni egy online cég, a délutáni "sávban" szabadon van az ingyenes, metropol jellegű újságok piaca.) Az elektronikus média pedig nagyon mélyen van beégve a hírfogyasztási szokásokba, jó pár év kellene mire megverhetnénk, de ez idő alatt valószínűleg a két platform nagyon közel fog egymáshoz járni, más jellegű verseny fog kialakulni.
A magyar piacon is létező üzleti modell, hogy külföldi (társ)oldalakon keletkezett cikkeket fordítanak magyarra. Ez a tartalom refactoring jelenleg az egyik legjobb megoldás a "költséghatékony" tartalom előállításra. A refactoring (becézve hírgyár) a gyakorlatban egy információ feldolgozása, több stílusban, több platformra. Az MTI ebben profi, az áltála gyártott hírek (bocs) gyakorlatilag platform függetlenek.
A célunk tehát a hír refactoring maximalizálása. Az újra "megírt" cikkeket a lehető legtöbb felületen meg kell jelenítenünk és a CMS rendszerünknek tudnia kell, mi, hogyan, mikor jelent meg és ezekkel az adatokkal, információkkal támogatni kell a főszerk, szerkesztők, újságírók munkáját.
News room, info queue
Az újságírás meglehetősen időigényes dolog. Az újságíró kollegák munkáját egy jól megírt news room modul nagymértékben segítheti. A news room modul feladat a témamutatás, a felhasználható infók és cikkek áttekintése.
Ideális esetben a news room nem csak a belső anyagokat mutatja, de trendeket, ügynökségi anyagokat, RSS forrásokat is beránt. Egyre fontosabbá válik a real-time események figyelése, nyomkövetése, a hype hullámok elsőkénti meglovagolása.
A news room tehát minden keletkező hírt, tartalmat megjelenít. Közös munka felületet ad az újságíróknak, figyeli a konkurencia híreit, integrálja a külső információforrásokat, trendeket figyel.
A szerkesztőségi rendszer. A gyakorlat
Az igények 90%-a fejlesztés közben fog érkezni. Akkor, mikor már látható, hogyan is működik a szoftver. A project ilyenkor nagyon közel állt a végtelen loophoz, tapasztalatom szerint érdemes hetes ciklusokkal "kifárasztani" az ötletbörzét és ez idő alatt a lehető legtöbb kívánságot megvalósítani, még akkor is, ha életképtelen az ötlet. Az idő előre haladtával szépen letisztul minden funkció. Csak(!) idővel és idegekkel kell bírni.
A megterheltségi mutatók és hardware tervezésekor a skálázhatóság, hirtelen peakek jelentik a legnagyobb problémát. A CMS fejlesztésekor a kódnak, a cache rendszernek és az sql enginenek minimum rendundásnak kell lennie és lehetőség szerint maximalizáni kell a cache használatot. De. A hírnek realtime meg kell jelennie minden frontenden egy időben. Ez általában fájl cachet jelent, kisebb nagyobb dinamikus elemekkel tűzdelt statikus html fájl.
Template rendszereket, opcode-t, sql cache megoldásokat kell alkalmazni a tartalom megjelenítéshez. Logikailag érdemes különválasztani a tartalom megjelenítést a user funkcióktól, azaz a tartalom megjelenítés prioros, ha választani kell, akkor a user belépés, testre szabási funkciók kikapcsolása kisebb veszteség, mint az üres vagy timeoutolo oldal.
Fizikálisan mindenképp külön működik a szerkesztőség, a frontendek, meghalhatnak, az admin felület nem. A stabilitás kulcskérdés, az egy-két frontendes, fél rack szekrényt elfoglaló megoldások mellett ismert és széles körben használt a sok, kicsi noname pc alapú szerverfarmok és valamilyen load balancer (dns, cél hardware, szoftveres) megoldással vitt rendszer. Ízlések, pofonok, pénztárca.
A lényeg: az adatbázis
A db fizikai megvalósítására mindenki rendelkezik saját, jól bevált módszerrel, technológiával.
Az alábbiakban az adatstruktúra darabolását mutatom be, ami ugyan sok programozói irányelvnek mond ellent, de a gyakorlatban több, tőlem független projectben bevált.
Az adatstruktúra darabolás nem keverendő össze a db sharding-gal. Előbbi esetében a priorizált adatoknak adunk dedikált vasat, utóbbiban az adatokat daraboljuk ideális méretűre.
Funkció szintű SQL adatbázis bontásra példa, adat priorizálva:
- content,
- design,
- ad, banner, reklámok,
- archívum (keresés),
- userek,
- log (user, ad),
- stat (user, ad).
A túlságosan darabolt adat struktúra ugyanakkor más jellegű problémákat hozhat, melyeket az egyre több eleme folyamatba vonása generál. A darabolás előnye a skálázhatóság, a funkció szintű adatbázis "sharding". Hátránya a több hiba lehetőség, további hátrány lehet a kód fejleszthetőség és kód rugalmasság csökkenése, kódlassulás.
A darabolás meglehetősen egyszerű okokra vezethető vissza. Az olvasást igénylő táblákról leválasztott írást igénylő táblák fizikálisan más RDBM kapnak, eltérően optimalizált konfiggal. Ha jó arcok a rendszergazdák, a hardware is tükrözi az RDBM funkcióját.
Az adatbázisok esetén rengeteg eszköz áll a rendelkezésünkre. Amiket nyugodt szívvel ajánlok:
- connection pool managerek, load balancerek
- tárolt eljárások, triggerek alkalmazása,
- adatbázis klónozás, master, slave megoldások,
- tablespace alapú optimalizálás (gyors tábláknak kisebb, de gyorsabb disk / ssd terület megadása).
Amit nem ajánlok, és nem is próbáltam:
- egy darab index.php fájl
- egy nagy adatbázis a contentnek, design elemeknek stb stb.
Összegezve: a CMS lelke az adatbázis. A fizikális adatstruktúra elválasztható a logikai struktúrától. Az adatbázis és az RDBM optimalizálható írásra, olvasásra. Spice must flow. Az admin felületnek minden körülmények között élnie kell, inkább legyen duplázódás az adatokban, mint üresjárat a szerkesztőségbe. Adatot nem veszíthetünk. A RDBM megterheltség skálázható
Ninjaken::Cache
Cache alatt sok mindent értünk, a lehető legtöbb adatot, fájlt szeretnénk a klienssel cacheltetni, a lehető legtöbb tartalmi és design adatot szeretnénk memória és fájl cacheban tartani.
A cache tervezésekor a rugalmasságot érdemes szem előtt tartanunk. A cache építés időigényes folyamat, lehetőség szerint saját vezérlésű eljárással építendő, a felhasználói requesttel indított cachelést csak biztonsági folyamatként érdemes a kódban tartani.
A legjobb megoldás folyamatos cache ellenőrzés és cache replace, az adat bemeneti pontoknál, tipikusan admin felület, triggereljünk cache modósítást, lehetőség szerint a cacheből nyert adatok bővítsük és ne a teljes cachet építsük újra.
A cache folyamatokat érdemes logolni és a missed cahce hit-ekről értesítést küldetni a fejlesztőknek, üzemeltetőknek.
Végül: sose bízz a cacheban. Vagy ott van, vagy nincs amit keresel. Ha ott van, örülünk, ha nincs irány az adatforrás.
Admin GUI
Bár szakmailag nem a legnagyobb kihívás, mégis a CMS admin felületével fogjuk aratni a leghangosabb sikereket. Ismételten le kell szögezni. Ebben a projectben az újságíró a király. Az admin felület ennek megfelelően a legidétlenebb funkciókat kaphatja. Ugyanakkor a "statikus" funkciókat érdemes "dinamikussá" tenni. Ilyen magic funkció az automatamentés, a kapcsolódó írások mutatása, a tag ajánlás, a word "kompatibilitás", az előre-hátra lépegetés hibaüzenet nélkül, az on-the-fly preview, a drag and drop cikk elem (kép, videó, keretes) mozgatás, a session független user auth (egy-két évig aktív session), és ami a legfontosabb: böngésző függetlenség. Talán az IE5 nem fog szerepelni, de azon kívül szinte bármi felbukkanhat. Ez persze nem azt jelenti, hogy minden böngésző alatt ugyan annak kell megjelennie, de minden böngészővel működnie kell a cikk felvitelnek. Technikai okok miatt nem állhat újságírói munka.
Gyakori, hogy az admin gumi valamilyen erőszak eredményeképpen megkapja a site designt. Az admin felületeket nyugodtan kezeljük webappként. Ennek megfelelően gazdagon alkalmazhatunk website idegen megoldásokat. Lehetőség szerint gondoljunk a "modemes" újságírókra, akik terepről, mobilneten keresztül próbálkoznak. Jó irány, ha egy heavy light, minimál design fogadja őket és ha akarnak váltanak a javascripttel tuningolt csilivili felületre. Ha pedig mindez meg eszköz (felbontás) függő designnal is megcsináljuk, jogosan érezhetjük magunkat fekete övesnek. Hint: az interneten a gyorsaság az elsődleges.
Összegezve: az admin legyen egyszerű, de az egyszerűség ne korlátozza a funkcionalitást. A sok funkció közül keveset fog használni az újságíró, ha nem vezetjük a felülettel. Az újságírók általában a MS Wordön edukálódtak. Az office shortcutok közül a ctrl+s beépítése a felületbe sokat segíthet az újságíró lelki állapotán, még akkor is, folyamatosan mentjük a munkáját. Az újságíró bárhonnan, bármivel belogolhat az adminra cikkírás okán.
A quest akkor sikeres, ha ninjaként minden technikai nehézségtől megóvjuk újságíróinkat és képesek vagyunk több tízezernyi cikket összelinkelni különböző sitekon. Akár utólag is, az új cikket linkelni a régebbi cikkben.
A következő részek tartalmából: folyamatos fejlesztés, content delivery network, ajax, user gui, site kereső optimalizálás, mail server optimalizálás, biztonságtechnikai kontrollok, üzemelési környezet optimalizáció és még sok minden más.
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!
#mullered – A dínó meteort* smo-nak hívják?
Sokan, sok helyen, sokféleképpen megírták a „Csörögjetek ránk” sztorit. Számomra a legérdekesebb, függetlenül attól, hogy ki és mekkorát hibázott, a hype folyamata. A teljeség igénye nélkül, a twitteren történtekre fókuszálva, összeszedtem, mi is történt, hogyan alakult ki a Vodafone ellenesség, mikor milyen történés befolyásolta az eseményeket.
Kollaboráció – fleck
A mai napig egy ősrégi Firefox extensiont használok "jegyzetelsére". Kis bűvészkedéssel (about:config extensions.checkCompatibility) életrekelthető. Download link: https://addons.mozilla.org/en-US/firefox/addon/3908
Példaként a yamm.hu-ra fleckeltem és screenshotoltam le (ez volt nyitva, csak yamm.hu fan vagyok, nincs köztünk fejlesztői kapcsolat). Egy flash applet segítségével kerülnek fel a note-ok, amit a save button nyomogatásával menthetünk fel a fleck.com ra. Egyszerű és nagyszerű.
Könnyen készíthető a fejlesztők számára iránymutatós-ötletelős-idegesítős, vagy vicces note. Kattra nagy lesz...
És igen, a noteok megoszthatóak, így kialakulhat az igazi csapatmunka.
2009 legnagyobb kihívása: 2010
Szeretek túlzásokba esni, de talán nem túlzok, ha sokak számára 2009 legnagyobb kihívása: 2010-ben is a piacon lenni.
A piac nem állt meg 2009-ben, egy picit lelassult, de csak azért, hogy eldöntse merre tovább. 2009-nek még koránt sincs vége, de sok cégvezető, freelancer, startup tulajdonos már 2010-et tervezi. A pénz ugyanis ott van.
A 2009-es lassulást 2010-ben extraprofittal, a 2009-ben elbukott bevételek összegével szeretnénk pótolni. Gyakorlatban 2010 másfélévnyi bevételterv lesz a fejekben. A 2010-es terveket rögzítő papír darabkák egy óvatos 10% - 15% növekedést fognak tartalmazni, sok esetben 2008 lesz a viszonyítási alap, just in case. Az offline - online "vegyes vállalatok" ugyanakkor ha nem erősítik az online bevételeiket (nem a felületeket), egyre nagyobb bajban lesznek. Akik nem képesek az offline brandjüket minden platformon megjeleníteni, további leépítésekkel vagy veszteségekkel keresgélik a továbbiakban a kiutat az összeolvadó, összekapcsolodó platformok között.
A facebookos, googlos üzengetések megmutatták, hogy a magyar piacon nagyon kevesen vannak felkészülve a hirtelen váltásokra, a merev vállalati üzlettervezési módszerek életképtelenek az egyre gyorsabban fejlődő intetnet szemponntú tervezéssel szemben . Az óvatosság és megfelelési kényszer görcsösséget okoz, ami gátolja a multikat és wannabe multikat a rugalmasságban. Míg a konzervatív cégek befagyasztanak minden büdzsét, a modernizált üzletimodellel rendelkező rugalmas cégek előremenekülnek, fejlesztenek.
2009 leginkább a cashflowról és az életben maradásról szólt. 2010 az innovációról fog szólni. Aki képes lesz minden platformon egyszerre megtartani a usereit, nyertes lesz. Ehhez persze minden esetben a platformokhoz kell igazodni, érteni kell a platformok használatának okát, mikéntjét, és legfőképpen kristálytiszta fókuszban kell tartani a bevételi forrásokat.
Már csak az a kérdés maradt, hogy maradnak-e a siker képletek?-->
Szeretek túlzásokba esni, de talán nem túlzok, ha sokak számára 2009
legnagyobb kihívása: 2010-ben is a piacon lenni.
A piac nem állt meg 2009-ben, egy picit lelassult, de csak azért, hogy
eldöntse merre tovább. 2009-nek még koránt sincs vége, de sok
cégvezető, freelancer, startup tulajdonos már 2010-et tervezi. A pénz
ugyanis ott van.
A 2009-es lassulást 2010-ben extraprofittal, a 2009-ben elbukott
bevételek összegével szeretnénk pótolni. Gyakorlatban 2010 másfél
évnyi bevételterv lesz a fejekben. A 2010-es terveket rögzítő papír
darabkák egy óvatos 10% - 15% növekedést fognak tartalmazni, sok
esetben 2008 lesz a viszonyítási alap, just in case. Az offline -
online "vegyes vállalatok" ugyanakkor ha nem erősítik az online
bevételeiket (nem a felületeket), egyre nagyobb bajban lesznek. Akik
nem képesek az offline brandjüket minden platformon megjeleníteni,
további leépítésekkel vagy veszteségekkel keresgélik a továbbiakban a
kiutat az összeolvadó, összekapcsolodó platformok között.
A facebookos, google-ös üzengetések megmutatták, hogy a magyar piacon
nagyon kevesen vannak felkészülve a hirtelen váltásokra, a merev
vállalati üzlettervezési módszerek életképtelenek az egyre gyorsabban
fejlődő internet szempontú tervezéssel szemben . Az óvatosság és
megfelelési kényszer görcsösséget okoz, ami gátolja a multikat és
wannabe multikat a rugalmasságban. Míg a konzervatív cégek
befagyasztanak minden büdzsét, a modernizált üzleti modellel
rendelkező rugalmas cégek előremenekülnek, fejlesztenek.
2009 leginkább a cashflowról és az életben maradásról szólt. 2010 az
innovációról fog szólni. Aki képes lesz minden platformon egyszerre
megtartani a usereit, nyertes lesz. Ehhez persze minden esetben a
platformokhoz kell igazodni, érteni kell a platformok használatának
okát, mikéntjét, és legfőképpen kristálytiszta fókuszban kell tartani
a bevételi forrásokat.
Már csak az a kérdés maradt, hogy maradnak-e a siker képletek?
$$$$ = web + mashup
$$$$ = mobil platform + kreatív ötlet
$$$$ = content + multiplatform
$$$$ = social media + hype generálás
Nokia 3G booklet – október 22-től a német O2-nél
Október 22.-től megvásárolható a Nokia 3G booklet a német O2-től. €249 befizetésével és a havi €20 fizetésének vállalásával máris elhozható a Nokia booklete. Opcionálisan választható hozzá adatcsomag, €25-ért.
€249 kb. 67,230 HUF
€45 kb. 12,150 HUF
Biztató.
turulcsirip.hu a twitter streaming API-n(?)
@tothbenedek pár perce "jelentette be", hogy éles a turulcsirip.hu tesztváltozata, ami a twitter streaming API-ját is használja.
Meglepő a bejelentés (és könnyen lehet félreértelmeztem), mert a twitter streaming API-ja jelenleg alpha állapotban van. Ha az alpha streaming API már alkalmas olyan méretű twitter mashup kiszolgálására mint a turulcsirip.hu, akkor hamarosan következhet a béta verzió, ami egy nagy lépéssel közelebb viszi a twittert a real-time-web platform eléréséhez.
@tothbenedek jelenleg úton van a #csiripest -re, így a konfirmjára még várni kell.
turulcsirip.hu streaming api
