ScreenShootMe на 1 година

2 коментара

Публикувана на 01.08.2010 от Lucho в Dev |HTML5 |Web |Нонсенс

, , , ,

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

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

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

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

  • Twitter
  • Facebook
  • HackerNews
  • Google Bookmarks
  • Suggest to Techmeme via Twitter
  • RSS
  • PDF
  • email

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

0 коментара

Публикувана на 29.06.2010 от Lucho в HTML5 |Web

, , , , ,

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

  • Twitter
  • Facebook
  • HackerNews
  • Google Bookmarks
  • Suggest to Techmeme via Twitter
  • RSS
  • PDF
  • email

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

1 коментар

Публикувана на 22.03.2010 от Lucho в Dev |HTML5 |Web

, ,

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

  • Twitter
  • Facebook
  • HackerNews
  • Google Bookmarks
  • Suggest to Techmeme via Twitter
  • RSS
  • PDF
  • email

FarmBot… или какво да правим докато нямаме личен живот

7 коментара

Публикувана на 10.03.2010 от Lucho в Dev |Web |Нонсенс

В последно време не съм писал нищо (става въпрос за писане на код) и взе да ми липсва… което май е нормално имайки предвид, че съм Софтуерен Инженер :-) . Та, много умувах какво да направя, първо бях решил да разширя 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-ове, което изпълнява целта напълно!

Моля, запишете си нужните продукти за да сготвиме бота :-)

1.  Логвате се в ФБ по стандартния начин

2. Отивате тук – http://developers.facebook.com/tools.php и избирате от падащото меню на Method > stream.get (това извежда timeline-a ви)

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 … но пък това е в духа на блога ми все пак :-P

  • Twitter
  • Facebook
  • HackerNews
  • Google Bookmarks
  • Suggest to Techmeme via Twitter
  • RSS
  • PDF
  • email

Buzz е новият Twitter… че какво му има на стария?!

2 коментара

Публикувана на 11.02.2010 от Lucho в Web |Нонсенс |Социални

Такааа, след близо 4 месеца без да напиша нищо ново най-накрая се реших. Провокира ме новата услуга на Google – Buzz. Може би ако Google не ми натрапваха един глупав сплашскрийн с глупави въпроси по него, докато се мъча да си видя мейла в Gmail, нямаше да се налага да пиша лоши неща за новата им услуга… но сега се налага.

За тези от вас, които все още живеят в пещерите, ще ви кажа че Buzz е просто поредната микроблогинг услуга, която копира идеята на Twitter, но е добавила няколко фенси неща, като например тъмбнейлове на клипчетата и възможност за директен отговор на пост. Добре, ама това напрактика прави микроблогинга да не изглежда микро и да не е съвсем блогинг, по-скоро прилича на грозен претрупан Фейсбук, от който повечето туйтърджии се опитват да се спасят.  Гугъл винаги са имали нюх и са правили страхотни неща, но истината е че немогат да създадат по-гениална социална мрежа от Фейсбук и Туйтър и да се опитват да ги копират е  обречена идея. Хората са свикнали с тези две популярни мрежи и няма да  ги зарежат… за разлика от настолните игри, социалните мрежи не се напускат НИКОГА! Освен това Фейсбук има добре измислена и изградена инфраструктура за интегриране на приложения, 350 милиона… да – милиона, души, Туйтър е постоянно претоварен от нетърпеливи потребители, доста е тренди назапад и печели симпатията на хората предимно с простата си изчистена визия, която набляга на съдържание, а не на безсмислени функции. Buzz е нещо средно между тези две социални мрежи – ФБ и Туйтър,  но за съжаление обединява предимно негативните им качествата – ни риба, ни рак.  Може би Гугъл се надяват да отклонят част от хората към своята мрежа или пък да зарибят потребителите на Gmail да ползват Buzz. Съмняваме да успеят да направят, което и да е от двете, но само времето ще покаже.

Мен лично ме вълнува само един въпрос – дали ще доживеем един ден да играем Farmville в Buzz? :-D

  • Twitter
  • Facebook
  • HackerNews
  • Google Bookmarks
  • Suggest to Techmeme via Twitter
  • RSS
  • PDF
  • email

Share your screen

4 коментара

Публикувана на 22.08.2009 от Lucho в Dev |Firefox |HTML5 |Web |Нонсенс

Напоследък съм изгубил творческата си искра, в работата се занимавам с .NET 2 (нестига, че е .NET ами и е от 2004г :-( ) не съм почивал цяло лято и ми се ще да пиша на Ruby и Rails или Objective C за iPhone. Та сред всички тези несгоди и поради факта, че съм програмист все пак (а добрите програмисти решават проблеми ежедневно и би трябвало и своите да могат да решат!!!) предприех някои стъпки за измъкване от блатото, като една от тях беше да си пиша малко проектче за мое лично удовлетворение. Първоначалната идея изникна в главата ми по напълно случаен начин, с времето идеята се развиваше и променяше, пишех по малко код и очаквах вдъхновението ми да се върне и да ми каже какво да правя… е този момент дойде днес – тази вечер.

Първоначалната ми идея, с която няма да ви занимавам сега, включваше използване на HTML 5 Canvas – платно на което може да се рисува и дава пълен достъп до битмапа – красота! Естествено този стандарт е все още слабо разпространен сред браузърите, защото е нов (Microsoft-ския Trident още не го подържа изобщо, бахти изостаналата нация :-P ). Идеята включваше и Рейлс, но прагматичното в мен победи и пожела да запълня 99% свободен bandwith на хостинга ми (да, блога ми е толкова популярен, че ползвам <1% от линията :-( ). Това води след себе си сравнително неприятното задължение да пиша на PHP… но няма да се лъжем, на PHP се пише много бързо, ама много, много бързо и грозно и… абе селска работа! Предните седмици, докато чаках вдъхновението, реших да проуча въпроса, как мога да взема изображение от клипборда и да го плесна на кенвъса, оказа се нетолкова лесна история, но възможна все пак. Цената не е прекалено висока – ползвам Java Applet-че, което върши цялата работа всъщност. Алтернативата е Flash, но доколкото разбрах Flash 10 налагал по-строги ограничения за боравене с клипборда, а и не обичам Flash и ActionScript (винаги ме е боляло много след интервенция с тях). Големият проблем е, че някъде при прехвърлянето на битмапа от клипборда през аплета към javascript-ския код нещата стават много бавно и това може да отнеме до няколко секунди, за по-големи изображения, но като се абстрахираме от това – ТО РАБОТИИИИ!!!! Следващото нещо, което направих е функционалност за селектиране на фрагмент от кенвъса, почти като в Paint или друг редактор… и в общи линии до тази вечер бях стигнал до тук, когато ме осени идеята – selection tool-а става на crop tool и целия проект се превръща в 3-click-screen-share. Гениално наистина, print screen, paste, [optional: crop], save и получаваш линк… а и подобно нещо не съм виждал да има досега… е друг е въпросът колко често на човек му трябва подобно нещо, но като се замисля, че иначе трябва да отваряш image editor, пък после да save-ваш, пък после да го публикуваш някъде, и накрая да пратиш линк – it is retarded!

Първоначалната версия на услугата е тук: http://dailyffs.com/shotme/

За сега всички енджини без този на Microsoft подържат в някаква степен Canvas, като за FireFox 3.5 приложението върви на 100%. Естествено за view на изображението впоследствие не е необходимо нищо специално и всеки браузър би свършил работа, така че всички ще могат да видят скрийншота ви – спокойно ;-)

Ако някой има предложения или поне му е харесала идеята или пък го е отвратила, може да напише мнението си тук. Чуждият фийдбек е стимул, стимул за подобряване, изпипване и разширяване на идеята. Ако има интерес ще наема нов domain и ще се постарая да оправя забавянията, да сложа една четка, че да може да оградите примерно определено място от изображението, на което искате да наблегнете.

Хубаво е когато човек дава свобода на въображението и творчеството си, кара те да се чувстваш щастлив и да си изпълнен с идеи и енергия… даже и цената, която трябва да платиш да е малко писане на PHP :-P

  • Twitter
  • Facebook
  • HackerNews
  • Google Bookmarks
  • Suggest to Techmeme via Twitter
  • RSS
  • PDF
  • email

Switch to our mobile site