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!
convert this post to pdf.
#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.
convert this post to pdf.
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.
convert this post to pdf.
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
convert this post to pdf.
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ó.
convert this post to pdf.
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
convert this post to pdf.
Három képzeletbeli baki a Google Wave meghívókkal
Már csak órák vannak hátra a 100,000 db Google Wave meghívó kiküldéséig. A fokozott izgalomban ne felejtsünk el humorizálni, "elvégre magyarok vagyunk, vagy nem"?
Bár a Google szerint ne legyünk gonoszak, a humor talán nem számít gonoszságnak. Bevezetőnek írhattam volna valami igazán gonoszat, pl. mi történne, ha a x cég küldené ki a Wave meghívóját, vagy épp álhírként is megjelenhetett volna. Lényeg, három képzeletbeli baki, a google wave meghívókkal.
google wave spam (fake)
- A Gmail spamként azonosítja a Google Wave meghívót.
- A meghívók kiküldésével azonos időben, egy botnetről fake Google Wave meghívókat küldenek albán hackerek. Egy egész bolygó kattint egy időben.
- A meghívókban közlik, hogy elhalasztva két nappal. Addig is olvass híreket a Google News-on.
convert this post to pdf.
Digitális tatárjárás
Pár napja a Facebook, ma pedig a Google dúlta fel az álmos internet falu, Magyarország mindennapjait.
A mai napon a Google bejelentette a Google Maps lokalizálást. A fogadtatás, a twitteres streaminget figyelve, felemás. A szolgáltatás jó. Minden bizonnyal rengetegen fogják használni. És talán pont ez a baj. A Google eddig is a spájzban volt, de a Facebookhoz hasonlóan picit láthatatlanul növelte azt a bizonyos tortaszeletet. Lassan de biztos a tengerentúli multiból kézzelfogható helyi szereplővé válik.
A Google Map lokál biztosan nagyon sok piaci szereplőnél okoz gyomorgörcsöt, Longhand pontosan definiálta, kiket is érinthet a "GomorGorcs".
Remélhetőleg a nagyok megjelenése a piac fejlődéset és a tartalmak és szolgáltatások minőségének javulását fogják előidézni.
Pár kép az érdekesebb keresési eredményekről, jól megfigyelhető, hogy az adatbázis pár helyen még kezdetleges.
Kattintásra slideshowos galléria.
-
- apple budapest
-
- bank budapest
-
- seo budapest
-
- kerékpárút budapest
-
- webshop budapest
-
- microsoft budapest
-
- mobiltelefon budapest
-
- narancs budapest
-
- seo new york
-
- vasutállomás budapest
convert this post to pdf.
Facebook vs. iwiw?
update: webisztán is foglalkozik a témával.
Konrádnál olvasom, hogy a Facebook 2012-ben lenyomja az iwiwet. Marketinges oldalakról helyes lehet a megállapítás. Másrészt a Facebook egy másik pályán focizik. A bevételi összegek és a user számok villogtatása nem olyan érdekes mint a real-time web uralásáért zajló folyamatok.
Nem lenyomja, hanem tovább lép
Techie szempontból a Facebook és az iwiw összehasonlítás a körte vs. alma klasszikusa. Emberek használják mindkettőt többnyire azért, hogy más emberekkel kommunikáljanak. De amíg a Facebook szinte bármit hajlandó beengedi az apps platformmal felvértezve egyre inkább valódi platformmá válik, addig az iwiw megpróbálja zártan tartani a rendszerét, felhasználóit igyekszik megóvni még a széltől is.
Az iwiw opensocial move-ja egy jó döntés és lépés volt, ami még rengeteg lehetőséget rejt magában, de hatalmas meglepetés lenne, ha az iwiw tulajdonos, t-udjukki, engedélyezne az opensocial teljes arzenáljának bevetését. Vélhetően t-udjukki számára az már látszódik az excel táblákból, hogy a display szegmens pénzprintere akadozik. Közel se annyira mint a print média pénznyomdája, de lassan tonert kell majd cserélni. Az alkalmazások talán termelnek valamikor nagyobb összeget. 2012-ig biztosan elkettyeg a mostani banner toner, néha fel kell rázni, de megbírja még.
A Facebook rápörög a magyar hirdetőkre. Tény. Szép lassan a geekek mellé megérkeznek az átlag userek. Tény. De a Facebook számára a magyar piacért vívott harc csak egy pici csatácska, ami inkább presztízs kérdés mint a világhódító hadjárát egyik fontos ütközete. Az iwiw ugyanakkor könnyen megroppanhat a Facebook nyomulása alatt. Ez nem a klasszikus nyílt sisakos küzdelem lesz.
i mint matáw
A nagyok csatájában az iwiw maximum az opensocial elnevezésű pajzsot hordozhatja a G és Y! lovagok mögött. Már ha egyáltalán érinteni fogja a távoli háború. A nagyok olyan fegyvereket vetnek be, mint a google wave, friendfeed, bing, chromOS, windows 7, pubhubsubbub, facebook apps, windows live. Az iwiw maximum pénzt tud kérni újabb szerverekre.
G mint hullám
A Google Wave majd minden G alkalmazásba beépül valamilyen szinten. Még az olyan elfeledett G tulajdon is "hullámozni" fog, mint az Orkut. Google nem ismeri a kispályát, a
Google Wave teljes pályás letámádasa talán csak jövőre indul meg, de a csatársor már keményen edz a Google real-time stratégiájának megvalósításán. PubSubHubbub publikálásával és a search engine átalakításával a Google megindult a real-time web irányába.
F mint Microsoft
A Facebook és a Microsoft már korábban is egymásra talált. Ha Microsoft nem is fogja a Facebookban szerzett befolyását arra használni, hogy a Facebook csak és kizárólag MS reklámokat toljon, de azért szépen lassan megjelent a "Results by Bing" szürkés felirat a Facebook serp-n. A windows 7 kapcsán hozzápiszkálnak a windows live-hoz, a messenger twitter és Facebook támogatást kapott.
tw mint ?
A twitter nagy kérdőjel. A Microsoftnak a twitter úgy kell, mint egy falat kenyér. Pontosabban a Microsoft - Facebook páros közösen éhezik a twitterre. A Microsoft mint twitter tulajdonos közeláll a fail taghez, a Facebook viszont cool twitter tulajdonos lenne. A márciusi sikertelen Facebook - twitter deal után elmaradt a látványos Google erődemonstráció. A twittert csak azért megvenni, hogy riválisok ne tudják, drága mulatság. Biz Stone egészen biztos nem egy könnyű tárgyaló partner ha ennyi pénzről van szó. A twitter szép csendben fejleszti a twitter streaming API-t ami a jelenlegi "real-time" API-nál is gyorsabb lesz, támogatni fogja a retweet-et. Ha a twitter sikeressé tudja tenni a streaming API-t, tovább növelheti a twitter jelentőségét és értéket a real-time webre utazóknál.
2010-ben talán az iwiwnek is sikerül a szürke hétköznapok banner kattingatásain túl felmutatni valamilyen komolyabb fejlődést, de a Facebook vs. iwiw boxmeccs helyett izgalmasabb eseményekre fogunk figyelni.
convert this post to pdf.
Hamarosan: retweet a twitter API-ban
Korábbi twitter api-val kapcsolatos postokban már írtam arról, hogy a twitter (egyik) lelke, a retweet. A twitter API hamarosan támogatni fogja a retweetet, azaz natív támogatást ad a tweetek életútjának követéséhez. Természetesen a twitter API-val párhuzamosan a twitter.com felülete is megkapja a retweet funkciók kezelhetőségét GUI-ról.
Sajnos a twitternél még mindig performance jellegű problémákkal küzdhetnek, számos korlátozással fogják élesíteni a retweetek lekérdézését. Így például egy tweethez kapcsolódó retweetekből maximum az utolsó százat tudjuk lekérdezni.
A funkció bevezetése szakaszosan történik majd, először teszt jellegel pár felhasználó számára lesz elérhető. Konkrét release date még nincs.
A retweet funkciók igazi nyertesei a mashup és kliens készítők lehetnek, látványos retweet tree és wave megjelenítéseket jósolok a közeljövőre.
A twitter API a következő funkciókkal bővül:
Timeline Methods
statuses/retweeted_by_me
Returns the 20 most recent retweets posted by the authenticating user.
statuses/retweeted_to_me
Returns the 20 most recent retweets posted by the authenticating user's friends.
statuses/retweets_of_me
Returns the 20 most recent tweets of the authenticated user that have been retweeted by others.
Status Methods
statuses/retweet
Retweets a tweet. Requires the id parameter of the tweet you are retweeting.
statuses/retweets
Returns up to 100 of the first retweets of a given tweet.
convert this post to pdf.