Aug 01 2010

ScreenShootMe на 1 година

Category: Dev,HTML5,Web,Нонсенс — Lucho @ 23:25

Преди около година сътворих едно малко уеб-туулче, което да позволява бързо качване на скрийншот в мрежата – ScreenShootMe. Очакванията ми да стана свръх богат и да задмина Facebook по потребители не се сбъднаха, но и първоначалната ми идея никога не е била тази, де. Подбудите да го създам тогава бяха, че такъв инструмент ми е нужен и има смисъл от него. Виждам смисъл в него и сега – 1 година по-късно. Първата му версия беше функционална – имаше това което исках, но нямаше това, което искаха останалите хора – хубав вид. За това докато пътувах в автобуса от Созопол към София с изтощена батерия на телефона и празен поглед забит в хоризонта, реших да подобря творението си – да го направя “красиво”. И не просто реших, ами помислих сериозно какво искам, помислих за всеки детайл, за цветове, разположение – за всичко. Когато се прибрах веднага започнах работа по него и след 4-5 дни бях завършил всичко, което ми се въртеше в главата докато пътувах в автобуса. Всички промени касаят клиентската част – нищо по сървърната част или в Applet-а не е пипано, което беше и първоначалната идея – все пак е само фейслифтинг.

Ето и списък с промените:

  • Разположението – меню с всички бутони и контроли в ляво, до менюто е платното, а под тях е информативен текст.
  • Менюто се дели на 4 части – бутони с основни функции, бутон и контроли за crop, бутон и контроли за рисуване върху платното (избор на дебелина и цвят на четката), поле за въвеждане на специфичен ключ (ключа се ползва в URL-a с изображението).
  • Информативния текст се дели да две паралелни колони, като в лявата има информация за функциите на уеб-туулчето, а в дясната има текст с общо предназначение.
  • Състоянието на кенвъса по подразбиране трябва да има рекламен вид – да казва колко е лесно и полезно туулчето.
  • Цветовете: Тъмно синьо, жълто, оранжево и бяло (за текста). Топлите и студени цветове, някак си противно на логиката, си паснаха. Тъмно синьото и бялото бяха първите два избрани цвят, които да си призная, разбрах че си пасват благодарение на това лого – http://screenshoot.me/7r04fQ . За оранжавото знаех, че е енергичен цвят, а за жълтото че прави много добър контраст с черно и тъмни цветове (освен това ми е любим). И така от цялата каша се роди една палитра, която е ЕДИНСТВЕНАТА свястна палитра, която някога съм подбирал.
  • Бутоните и контролите представляват Canvas елементи и са изцяло генерирани от Javascript. Един ден ще бъдат заменени от HTML5 Web Forms.
  • Наех домейн за уеб-туулчето – screenshoot.me
  • Donation бутонче – домейнът струва пари 😛
  • Футър
  • Undo – в случай, че нещо се обърка тотално.

Това “разкрасяване” за пореден път подтвърди мнението ми, че хубавията дизайн се постига много по-трудно отколкото самата функционалност. Дано поне да си е заслужавало труда  и парите за домейн и да привлече повече потребители 😉

Tags: , , , ,

Jun 29 2010

HTML5 – Предисторията

Category: HTML5,Web — Lucho @ 15:44

Тази публикация е първата от поредица статии за 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, защото този нов стандарт ще отвори вратите за един куп нови и интерактивни уеб приложения!

Tags: , , , , ,

Jun 25 2010

Какво ново около Firefox 4.0 и HTML5

Category: Firefox,HTML5 — Lucho @ 23:02

В последно време покрай изпити, състезания и разни други неща изпуснах дирята на развитие на HTML5 съпортa от страна на Firefox. За всеобща радост обаче, Twitter ме осведомява прилично тъй като следвам доста Firefox контрибютъри. Та, от там знам че от скоро вече има работещo Web Socket API в нощните билдове на браузъра. Това значи че за FF4.0 (да, FF3.7 няма да има), който излиза през ноември 2010, ще можем да се поздравим с едно от най-нужните неща в съвременния web – истинска двупосочна връзка. С това огнената лисица ще стане втория браузър след Chrome, който поддържа Web Socket-и и мисля, че няма нужда да ви казвам колко много развързва ръцете на дивелопърите наличието на дуплексна връзка!

С това обаче добрите вести не свършват, оказва се че и по HTML5 Forms работата върви с пълна пара, но какво точно ще видим в следващата версия на браузъра е трудно да се каже на този етап.  Пълен списък с прогреса по различните елементи и атрибути има тук: https://wiki.mozilla.org/User:Mounir.lamouri/HTML5_Forms

Последното нещо, с което ще ви занимая е един доста впечатляващ експеримент – Smoke Screen . Накратко това дава възможност на вашия HTML5 браузър да показва Flash анимации без да ползва Flash player… ъ-ъ-ъ странно нали 🙂 . В случая цялата работа се извършва от Javascript + Canvas  елемент и преди да възкликнете “За какво би било полезно това, при положение че Flash плейърът е фрий”, ще ви напомня че  много съвременни смартфони не поддържат Flash (iPhone) и някои от CEO-тата на компаниите производители (Стив Джобс) публично се заклеха, че съпорт за Flash няма да има НИКОГА!

Та така, Web-a си върви, кучетата си лаят и определено ни чакат интересни месеци до излизането на Firefox 4.0 🙂

Tags: ,

Mar 22 2010

Бъдещето на телекомуникациите – Web Sockets

Category: Dev,HTML5,Web — Lucho @ 15:06

Най-голямата спънка при разработката на богати уеб приложения до сега е липсата на двупосочна връзка – от клиента към сървъра и от сървъра към клиента. Решението на този проблем винаги е било голяма болка и страдания, като най-общо се ползват чести запитвания към сървъра, на които той в 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 (може да го видите в кода на сървъра).

Кодът на клиента и сървъра е тук – http://gist.github.com/339983 .

Happy Web Socketing 😉

P.S. Незнам дали забелязахте, ама редакторът на спецификацията за Web Socket-ите е “Ian Hickson, Google, Inc.”, така че няма нищо странно, че  тези чудесии се появяват именно в Chrome за първи път 😛

Tags: , ,

« Previous Page