Тези дни хората от Mozilla Labs стартираха конкурс за разработка на изцяло уеб базирана игра. Състезанието се казва Game On 2010 и дава възможност на всички гейм или уеб разработчици да покажат на какво са способни, но… само с HTML(5)/Javascript/CSS.
Да – правилно прочетохте! Flash, Applet-и и други плъгини не са позволени, защото основната идея на конкурса е да покаже на какво са способни модерните браузъри. А те наистина са способни! HТML5 & Friends докараха на белия свят доста новости и купища ексцентрични API-та – Canvas елементът, SVG (директно в html кода), WebGL, Web Sockets (двупосочна свързаност), няколко API-та за data storing, Video елементът и още много интересни благинки.
В конкурса могат да участват както индивидуални разработчици, така и екипи. Естествено и за награди е помислено, като за сега от Лаба са обявили само наградата за първо място – два билета за Game Development Conference 2011 в Сан Франциско, с включен път, хотел и храна. Награди ще има и за още дузина категории, така че запретвайте ръкави 😉
Крайният срок за участие е 11.01.2011г.
Успех на всички 🙂
П.П. Аз лично смятам да се включа и съм навит за обединяване на усилията с други ентусиасти.
Ако до преди години се гледаше на Javascript като на нещо, което само някои браузъри поддържат и заклеймено като “по-добре да не се използва”, то сега нещата вече не са такива. Всъщност едва ли някой си спомня тези отминали времена и едва ли има сайт, разработван последните (може би 10) години, който да няма поне един ред JS.
Сега Отдавна на дневен ред стои един друг проблем – липсата на сносна документация и туториали за езика… и по-точно трудното им откриване в нета. Доста пъти, когато съм се опитвал да издиря някое примерно парче код или документация за Javascript е трябвало да прегледам по няколко линка преди да открия нещо, което да върши работа. А даже и да открия нещо, което върши работа за един браузър, впоследствие се оказва, че не върши работа за Internet Explorer. Е, разбира се за това има благинки като jQuery и Prototype, които btw са докуметнирани перфектно, но е срамота “чистият” Javascript да тъне в такова забвение.
Спасението (евентуално) ще дойде от Pirates of JSConf и хората от Mozilla, които искат да популяризират JS документацията в MDC, чрез масирано разпространение на банер. За целта трябва колкото се може повече хора да сложат в блоговете/сайтовете си кода от този адрес – http://www.promotejs.com/ . Така Google ще рейтне по-високо документацията (понеже е линктната от повече хора) и съответно когато напишете “Javascript” в търсачката линкът към документацията ще се появява в първите резултати. Не съм вещ в SEO и не знам дали Google няма да се усети за този “линк-фарминг” (SEO гурутата да ме прощават, ако бъркам термини :D), но ако има и съвсем малко шанс нещата да се подобрят и живота на изтерзаните Уеб-дивелопъри да се облекчи – значи си е заслужавало.
Преди около година сътворих едно малко уеб-туулче, което да позволява бързо качване на скрийншот в мрежата – ScreenShootMe. Очакванията ми да стана свръх богат и да задмина Facebook по потребители не се сбъднаха, но и първоначалната ми идея никога не е била тази, де. Подбудите да го създам тогава бяха, че такъв инструмент ми е нужен и има смисъл от него. Виждам смисъл в него и сега – 1 година по-късно. Първата му версия беше функционална – имаше това което исках, но нямаше това, което искаха останалите хора – хубав вид. За това докато пътувах в автобуса от Созопол към София с изтощена батерия на телефона и празен поглед забит в хоризонта, реших да подобря творението си – да го направя “красиво”. И не просто реших, ами помислих сериозно какво искам, помислих за всеки детайл, за цветове, разположение – за всичко. Когато се прибрах веднага започнах работа по него и след 4-5 дни бях завършил всичко, което ми се въртеше в главата докато пътувах в автобуса. Всички промени касаят клиентската част – нищо по сървърната част или в Applet-а не е пипано, което беше и първоначалната идея – все пак е само фейслифтинг.
Ето и списък с промените:
Разположението – меню с всички бутони и контроли в ляво, до менюто е платното, а под тях е информативен текст.
Менюто се дели на 4 части – бутони с основни функции, бутон и контроли за crop, бутон и контроли за рисуване върху платното (избор на дебелина и цвят на четката), поле за въвеждане на специфичен ключ (ключа се ползва в URL-a с изображението).
Информативния текст се дели да две паралелни колони, като в лявата има информация за функциите на уеб-туулчето, а в дясната има текст с общо предназначение.
Състоянието на кенвъса по подразбиране трябва да има рекламен вид – да казва колко е лесно и полезно туулчето.
Цветовете: Тъмно синьо, жълто, оранжево и бяло (за текста). Топлите и студени цветове, някак си противно на логиката, си паснаха. Тъмно синьото и бялото бяха първите два избрани цвят, които да си призная, разбрах че си пасват благодарение на това лого – http://screenshoot.me/7r04fQ . За оранжавото знаех, че е енергичен цвят, а за жълтото че прави много добър контраст с черно и тъмни цветове (освен това ми е любим). И така от цялата каша се роди една палитра, която е ЕДИНСТВЕНАТА свястна палитра, която някога съм подбирал.
Бутоните и контролите представляват Canvas елементи и са изцяло генерирани от Javascript. Един ден ще бъдат заменени от HTML5 Web Forms.
Наех домейн за уеб-туулчето – screenshoot.me
Donation бутонче – домейнът струва пари 😛
Футър
Undo – в случай, че нещо се обърка тотално.
Това “разкрасяване” за пореден път подтвърди мнението ми, че хубавията дизайн се постига много по-трудно отколкото самата функционалност. Дано поне да си е заслужавало труда и парите за домейн и да привлече повече потребители 😉
Тази публикация е първата от поредица статии за HTML5. Пиша ги основно по две причини – обичам HTML5 стандарта и искам да помогна за популяризирането му. Дано ви харесат и приятни занимания с HTML5 😉
Веднага след като W3C завършиха стандарта HTML 4, се заеха с разработката на напълно нов уеб език – XHTML 2, който макар и да е “XHTML” няма нищо общо с XHTML 1.0 или 1.1, а на всичкото отгоре не е съвместим и с тези предни версии. По този начин браузър-вендорите трябваше рано или късно да започнат да поддържат два езика за структуриране и представяне на уеб страници, които нямат много общо по между си. Естествено никой не се съгласи на това безумие и след като до 2004 година, никой от водещите браузъри не беше имплементирал абсолютно нищо от XHTML 2, a W3C не желаеше да отстъпи и да прекрати разработката на стандарта, производителите на браузъри (Microsoft, Apple, Mozilla и Opera) просто се оттеглиха и създадоха собствен работна група – WHATWG, чиято цел бе да разработи нов HTML стандарт, който да е съвместим с предни версии и да предлага нови функционалности, достъп до периферни устройства и по-лесно и уеднаквено разработване на уеб приложения. Няколко години след това W3C най-накрая забелязват, че никой не се вълнува от съдбата на XHTML 2, но пък WHATWG доста напредват с новия неофициален стандарт, и след като самият Тим Бърнърс-Лий пише в блога си, че нещата около XHTML 2 не вървят, W3C най-накрая се вразумяват. През 2007 година W3C официално решават да прекратят работа по XHTML 2 и да се обединят с WHATWG, за да разработят заедно новия стандарт – HTML5.
С течение на времето стандарта става все по-голям и по-разнообразен като до 2010 година в него вече влизат функционалности за запис и възпроизвеждане на видео и звук, няколко варианта за двупосочна връзка между потребителския клиент и уеб сървъра, няколко вида офлайн съхранение на данни в браузъра (вкл. и с база данни), възможност за чертаене на екрана, възможност за директно внасяне на MathML и SVG код в HTML документа, полета за въвеждане на специфични данни (например телефон или e-mail), един куп нови елементи, подобрена семантика в структурата на уеб страниците, нов стандартизиран начин за токенезиране и построяване на дървото от елементи в браузъра. Последното ще накара производителите на браузъри да не си измислят сами как да се интерпретира невалидния HTML5 код, а да следват ясно зададен алгоритъм, така че страниците да изглеждат еднакви на всички браузъри.
До тук всичко е повече от красиво, но следва една обезпокоителна новина – HTML5 ще бъде записан като задължителен стандарт през 2022 година, а като препоръчителен стандарт едва през 2012. Това значи, че на теория производителите на браузъри могат да си седят кротко и да се ослушват до 2022 година, с което да пречат на цялата работа по внедряването на стандарта в уеб пространството. Реално обаче това не е така, тъй като всяка нова версия на популярните браузъри поддържа все повече и повече от новия стандарт. Очакванията са, че паралелно с официалното завършване на HTML5 (2012г.) повечето браузъри ще са го имплементирали. Това е напълно разбираемо, защото в крайна сметка хората, които пишат стандарта са хората, които правят и уеб браузърите.
Аз се запалих по HTML5 лятото на 2009 година, когато за първи път видях частична поддръжка на стандарта (Canvas елемента) в Firefox 3.5. Бях меко казано изненадан от това, което предлагаше и реших да експериментирам с едно малко уеб приложение – ScreenShotMe, което да предлага минимална редакция и ъплоуд на изображение от клипборда. Написването на кода (макар и без много примери в нета) беше лесно, като в резултат с малко код се постигна прилична функционалност. Следващото нещо, което ми направи силно впечатление бе появата на WebSocket-ите в Google Chrome през декември 2009, като те предлагаха дуплексна връзка между клиента и сървъра. Opera пък поддържат HTML5 Forms – нови потребителски контроли като слайдер, color picker и др. Само тези няколко нови функционалности загатват за десетките нови онлайн приложения, които може да видим скоро на белия свят. Например директна редакция на снимките във Facebook, Skype в браузъра, офлайн достъп до електронната поща и др.
Макар че HTML5 e още чернова и e далеч от поява на белия свят, горещо препоръчвам уеб дивелопърите да не чакат 2012 или 2022 година, за да се запознаят по-детайлно с HTML5, защото този нов стандарт ще отвори вратите за един куп нови и интерактивни уеб приложения!
Най-голямата спънка при разработката на богати уеб приложения до сега е липсата на двупосочна връзка – от клиента към сървъра и от сървъра към клиента. Решението на този проблем винаги е било голяма болка и страдания, като най-общо се ползват чести запитвания към сървъра, на които той в 90% от времето връща празен response или Comet (познато още като long polling най-общо). И двата начина са тромави и ресурсоемки… даже бих ги определил като законни DoS атаки. И всичко това за да се симулира нещо подобно на двупосочна връзка.
Е, дните на безсмислени request-и и празни response-и отминаха, защото HTML5 предлага няколко варианта за решение на този казус. Ще се спра само на един от тях, на тъй наречените Web Socket-и. Както сигурно се досещате става въпрос за сокет съединения, макар и леко модифицирани и орязани, които могат да се създават и управляват чрез Javascirpt. Освен че тези web socket-и могат само да започват връзка, но не и да стоят и да слушат за постъпване на такава, те имат и собствен допълнителен протокол, с който си комуникират със сървърното приложение. Важното в случая е че дуплексна връзка има и то на много ниска цена (от към писане на код). При създаване на сокет се оказват callback функции за четене, възникване на грешка и отваряне/затваряне на връзката, така че когато някое от изборените събития се случи, тези callback функции се извикват и обработката на данни пада във вашите ръце. Това намалява драстично главоболията породени от блокиращи/неблокиращи сокети, безкрайни цикли, exception-и и какво ли още не.
От сървърна гледна точка нещата също са прости, кодът който е нужен за успешна комуникация с клиента е съвсем стандартен за сървърно сокет приложение, с изключение на едни служебни съобщения, които Web Socket-ите очакват и от които не може да се бяга.
Понеже всичко до сега звучи прекалено хубаво, ще се наложи да ви приземя малко, защото Web Socket-и за сега се поддържат само от Google Chrome, но рано или късно и другите browser vendor-и ще се усетят откъде духа вятъра. И понеже вече се приземихте ето и едно примерно приложение, което сглобих – MultiDraw. Идеята е чрез HTML5 Canvas елемента и Web Socket-и да се постигне паралелно рисуване от множество клиенти върху платно. Сървърната част е на Python 2.6 и ползва модула asyncore от стандартната библиотека, който симулира асинхронно четене и писане от сокети.
Ето кодът, който се отнася до web socket-ите при клиента:
var s = new WebSocket("ws://" + document.location.host + ":6789/");
// създаване на сокет съединение на порт 6789
s.onopen = function(e) { document.title = 'MultiDraw - Online'; }
// функция, която да се изпълни при установена връзка
s.onclose = function(e) { document.title = 'MultiDraw - Offline'; }
// функция, която да се изпълни при прекратяване на връзка
s.onmessage = function(e) {
// функция, която да се изпълни при пристигане на съобщение (съобщението е в e.data)
var data = e.data.split(" "); // обработваме съобщението...
draw(data[0], data[1], data[2], data[3], data[4], data[5], data[6], data[7]); // ... и чертаем върху Canvas-а
}
...
s.send([x, y, e.pageX, e.pageY, color, brushSize, lineCap, lineJoin].join(' ')); // изпращане на съобщение
При сървъра, единственото по-екзотично е хендшейк съобщението и това, че всяко съобщение започва с нулев байт и завършва с 0xFF (може да го видите в кода на сървъра).
P.S. Незнам дали забелязахте, ама редакторът на спецификацията за Web Socket-ите е “Ian Hickson, Google, Inc.”, така че няма нищо странно, че тези чудесии се появяват именно в Chrome за първи път 😛
В последно време не съм писал нищо (става въпрос за писане на код) и взе да ми липсва… което май е нормално имайки предвид, че съм Софтуерен Инженер :-). Та, много умувах какво да направя, първо бях решил да разширя ScreenShootMe с четка и възможност за писане, обаче това в някаква степен измества фокуса от основната идея на приложението и е трудоемко, а и искам FF да почне да поддържа colorpicker и slider функционалностите от HTML5, за да си спестя ненужни мъки. Впоследствие разбрах, че една колежка е 40 левъл в FarmVille… не че тя е единствената колежка, която играе FarmVille, но определено е висок левъл :-D. Понеже и аз имам фермичка се сетих, че всъщност в timeline-a на ФБ постоянно излизат съобщения за бонуси в FarmVille и част от тях си заслужават, но е досадно да си проверяваш нон-стоп ФБ за FV бонуси и да цъкаш по тях като ненормален. За това естествено тръгнах да мисля начин за автоматизация на процеса… за БОТ.
След нетолкова кратък рисърч, стигнах до извода че ФБ API-то може и да е удобно и лесно за ползване, но определено би отнело известно време, за да се свикне с него и за да се напише нещо такова, а и писането на PHP или друг скриптов език означава допълнителни constraints за обикновения юзър, който не е виждал програмен език в живота си или пък няма инсталиран нужния софтуер, за да подкара бота. От тук вече избора съвсем се стесни до… хм… Javascript и браузър.
v.0.1: Тръгнах да пиша един html файл, който да отваря ФБ в един фрейм и да парсва линковете за FarmVille… е не стана, незнам дали заради фроуд детекшън или заради нещо друго, но браузърите вече не дават да се бърника/чете html кода на страници в различни от настоящия домейн.
v.0.2: Същото важи и за отваряне на child прозорци и бърникане по техния код… god damn it… X_X
v.0.3: Докато търсех инфо за ФБ API-то попаднах на sandbox, в който може да се тестват разни функционалности – http://developers.facebook.com/tools.php и едно от нещата, които ми направиха впечатление, е че за изпълнение на request се ползва AJAX, a не просто постбек. Това естествено значи, че мога да напиша js код, който да се слага в addressbar-а или като bookmarklet и да обновява информацията през определено време, да я парсва и да отваря част от линковете в нови iframe-ове, което изпълнява целта напълно!
Моля, запишете си нужните продукти за да сготвиме бота 🙂
3. Copy/Paste кода по-долу в addressbar-a (за всички, които виждат браузър за първи път – после натиснете Enter)
javascript:
visited = {};
function process() {
var code = document.getElementById('trace').innerHTML;
var m = null;
while (m = /\<href\>(http:\/\/apps\.facebook\.com\/onthefarm\/.+?)\<\/href\>/gi.exec(code)) {
if (!visited[m[1]]) {
var ifr = document.createElement('iframe');
ifr.src = (m[1].replace(/&/g, '&')).replace(/&/g, '&');
container.appendChild(ifr);
visited[m[1]] = true;
}
}
setTimeout('container.innerHTML = \'\'', 60*1000);
}
function refresh() {
callMethod();
setTimeout(process, 5*1000);
}
container = document.createElement('div');
document.getElementsByTagName('body')[0].appendChild(container);
setInterval(refresh, 120*1000);
void(0);
И така вашия бот би трябвало вече да е напълно оперативен (на български не звучи добре)!!!
Накратко какво прави кода – на всеки 2 минути обновява timeline-а и проверява дали има нови url-и, които да са за FarmVille. Ако има такива ги отваря в iframe-ове (все едно вие сте цъкнали на “Get bonus” линковете в ФБ). Може да го задействате навсякъде напрактика (освен ако не ползвате Mosaic) и да си събирате колектабълс или нафта или там каквото още имаше.
В заключение ще кажа, че докато четох повторно поста си осъзнах, че явно обичам да пиша глупави, безсмислени и непотребни приложения… или по-скоро ако трябва да избирам между направата на нещо смислено и нещо глупаво, май-май ще се спра на второто :-D… но пък това е в духа на блога ми все пак 😛
Такааа, след близо 4 месеца без да напиша нищо ново най-накрая се реших. Провокира ме новата услуга на Google – Buzz. Може би ако Google не ми натрапваха един глупав сплашскрийн с глупави въпроси по него, докато се мъча да си видя мейла в Gmail, нямаше да се налага да пиша лоши неща за новата им услуга… но сега се налага.
За тези от вас, които все още живеят в пещерите, ще ви кажа че Buzz е просто поредната микроблогинг услуга, която копира идеята на Twitter, но е добавила няколко фенси неща, като например тъмбнейлове на клипчетата и възможност за директен отговор на пост. Добре, ама това напрактика прави микроблогинга да не изглежда микро и да не е съвсем блогинг, по-скоро прилича на грозен претрупан Фейсбук, от който повечето туйтърджии се опитват да се спасят. Гугъл винаги са имали нюх и са правили страхотни неща, но истината е че немогат да създадат по-гениална социална мрежа от Фейсбук и Туйтър и да се опитват да ги копират е обречена идея. Хората са свикнали с тези две популярни мрежи и няма да ги зарежат… за разлика от настолните игри, социалните мрежи не се напускат НИКОГА! Освен това Фейсбук има добре измислена и изградена инфраструктура за интегриране на приложения, 350 милиона… да – милиона, души, Туйтър е постоянно претоварен от нетърпеливи потребители, доста е тренди назапад и печели симпатията на хората предимно с простата си изчистена визия, която набляга на съдържание, а не на безсмислени функции. Buzz е нещо средно между тези две социални мрежи – ФБ и Туйтър, но за съжаление обединява предимно негативните им качествата – ни риба, ни рак. Може би Гугъл се надяват да отклонят част от хората към своята мрежа или пък да зарибят потребителите на Gmail да ползват Buzz. Съмняваме да успеят да направят, което и да е от двете, но само времето ще покаже.
Мен лично ме вълнува само един въпрос – дали ще доживеем един ден да играем Farmville в Buzz? 😀
Най-голямата спънка при разработката на богати уеб приложения до сега е липсата на двупосочна връзка – от клиента към сървъра и от сървъра към клиента. Решението на този проблем винаги е било голяма болка и страдания, като най-общо се ползват чести запитвания към сървъра, на които той в 90% от времето връща празен response или 
В последно време не съм писал нищо (става въпрос за писане на код) и взе да ми липсва… което май е нормално имайки предвид, че съм Софтуерен Инженер :-). Та, много умувах какво да направя, първо бях решил да разширя 
Follow me…