авг 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 бутонче – домейнът струва пари :-P
  • Футър
  • Undo – в случай, че нещо се обърка тотално.

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


Етикети: , , , ,


юни 29 2010

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

Category: HTML5,WebLucho @ 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, защото този нов стандарт ще отвори вратите за един куп нови и интерактивни уеб приложения!


Етикети: , , , , ,


юни 25 2010

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

Category: Firefox,HTML5Lucho @ 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 :-)


Етикети: ,


мар 22 2010

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

Category: Dev,HTML5,WebLucho @ 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 за първи път :-P


Етикети: , ,


сеп 25 2009

Първа среща с Ubiquity

Category: Firefox,HTML5Lucho @ 01:40

Тези дни попаднах на поредното интересно нещо от Mozilla – Ubiquity. Накратко това е плъгин, който осигурява лесно и кратко писане на команди автоматизиращи последователност от действия или предоставящи интерфейс към услуга. На разположение е терминал, в който човек избира команда, извежда се малко панелче, в което се вижда резултата… и това е в общи линий. Това с което бие bookmarklet-ите е вграденото jQuery, възможността да има стотици команди (bookmark лентата е ограничена от към резолюция :P), предлагане на шаблонен интерфейс (попълвате дескрипшън, хелп, etc и те се появяват на правилното място в правилното време), прави Ajax заявки към произволен сървър, има разни шантави тематични аутокъмплийт списъци (nouns), notification bar-че  и още куп готини работи. Пише се на Javascript и Python (само за OS X и Linux, Windows не е стандартно с Python – така че няма как :-( ) и кода излиза умопомрачително кратък, главно заради хелпърите, които идват с Ubiquity и jQuery. Част от стандартните команди, които са в инсталацията са twitter клиент, бързо търсене на различни места, локиращо по IP скриптче, което дава линк към google maps, превод in-place на фрагменти от страница, скъсяване на линкове чрез tinyurl и други.

Разбира се, аз като open-minded developer на какъвто се правя напоследък, няма как да пропусна възможността да напиша нещо малко и от сърце за Ubiquity, а и ScreenShotMe стана толкова „популярен“ (трябва да измислят четворни кавички, двойните неотразяват добре реалността в този случай), че съм готов вече на всякакви експерименти – включително и писане на Ubiquity команда, която да прави снимка на текущата страница и да я праща (в ада :D) на сървиса. След около ден рисърч и зяпане из сорсовете на Firefox, се убедих че nsITransferable неподдържа „image/bmp“ data flavor – може би защото от BMP формата лъха твърде много на Microsoft, кой знае. Това директно изпотроши първоначалната ми идея юзера да цъка print screen и командата да изпраща целия екран. Но всяко зло за добро – докато разглеждах имплементацията на хелпърите на Ubiquity се натъкнах на нещо яко – начин да изрисуваш window-ски content в canvas. Това явление е тотална измишльотина на Mozilla, защото в HTML5 Canvas draft-та няма такива неща, но все пак спаси положението. Вярно – няма да записвам целия екран, но пък когато човек иска да print screen-не browser-а си, обикновено не иска да му се виждат всички табове например, така че от подобна функционалност, която да предлага снимка само на уеб страницата има смисъл, а и ще върви и под OS X (за разлика от предния път :-D).

// Най-добре натиснете "<>" горе вдясно на страницата, за да се разшири.
// Така създаваме нов запис на команда, която да ползваме от конзолата
CmdUtils.CreateCommand({

// име, аргументи, описание, превю, хелп са задължителни
  names: ["shotit"],
  arguments: [{role: 'object', nountype: noun_arb_text, label: "image format"}],
  description: _("Publishes the current browser snapshot on the web and puts a link to it in the clipboard."),
  homepage: "http://dailyffs.com/index.php/share-screen/",
  author: {name: "Lucho Yankov"},
  license: "GPL",
// preview може и да е метод, който да започне изпълнение веднага щом селектирате командата (без да натискате enter или да я изпълнявате даже), но на мен ми трябва само статичен текст
  preview: _("Publishes the current browser snapshot on the web and puts a link to it in the clipboard."),
  help: _("To specify the image format just put 'jpeg' or 'png' as command's parameter, if no format is specified and the image is smaller than 1200KB it will be saved as PNG, otherwise the JPEG format will be used."),

// execute е кодът, който ще се изпълни при стартиране на командата
  execute: function(args) {
    var window = CmdUtils.getWindow();
// Следващите няколко реда са взаимствани до голяма степен от имплементацията на CmdUtils.getWindowSnapshot
    var canvas = CmdUtils.getHiddenWindow().document.createElementNS("http://www.w3.org/1999/xhtml", "canvas");
    canvas.mozOpaque = true; // Дали canvas-ът да поддържа alpha или само солиден цвял (ускорява някои операции)
    canvas.width = window.innerWidth;
    canvas.height = window.innerHeight;
// Шантавият метод на canvas, който рисува прозорци - INSANE!
    canvas.getContext("2d").drawWindow(window, window.scrollX, window.scrollY, window.innerWidth, window.innerWidth, "rgb(255,255,255)");
    var data = null;
// Проверка, дали има експлицитно зададен формат на изображението и ако не, дали то не е твърде голямо за да го правим на PNG и директно да го запазим като JPEG.
// Параметрите трябва да са jpeg, jpg, j, png, p
    if (/^j(pe?g)?\s*$/i.test(args.object.text)) {
        data = canvas.toDataURL("image/jpeg");
    } else if (/^p(ng)?\s*$/i.test(args.object.text)) {
        data = canvas.toDataURL("image/png");
    } else {
        data = canvas.toDataURL("image/png");
        if (data.length > 1600*1024) data = canvas.toDataURL("image/jpeg");
    }
// Показваме в notification bar-а, колко данни се изпращат, за да придобие представа потребителя, дали ще чака докато остарее или повече
    displayMessage(_("Sending ") + parseInt(data.length/1024+1) + "KB...", this);
    MAIN_URL = "http://dailyffs.com/shotme/";
// Изпращаме изображението към сървъра и когато върне като отговор ключа индексиращ картинката, сглобяваме линк и го пъхаме в клипборда и в notification bar-а
    jQuery.post(MAIN_URL, "image="+data, function(key) {
        if (key == "ERROR") return;
        var url = MAIN_URL + "?" + key;
        Utils.clipboard.text = url;
        displayMessage({text: url, onclick: function(){window.open(url);}}, this);
      }
    );
  }
});

Резултата от усилията ми е качен в Git, напълно отворен и поощрен за разширение – http://gist.github.com/192995 , версията на Ubiquity за която го писах е 0.5.4 (в случай, че нещо при някой невърви).

Ако някой има идеи, предложения или питания да заповяда – коментарите са за това ;-)

// така създаваме нов запис на команда, която да ползваме от конзолата
CmdUtils.CreateCommand({

// име, аргументи, описание, превю, хелп са задължителни
names: [„shotit“],
arguments: [{role: ‘object’, nountype: noun_arb_text, label: „image format“}],
description: _(„Publishes the current browser snapshot on the web and puts a link to it in the clipboard.“),
homepage: „http://dailyffs.com/index.php/share-screen/“,
author: {name: „Lucho Yankov“},
license: „GPL“,
// preview може и да е метод, който да започне изпълнение веднага щом селектирате командата
// (без да натискате enter или да я изпълнявате даже), но на мен ми трябва само статичен текст
preview: _(„Publishes the current browser snapshot on the web and puts a link to it in the clipboard.“),
help: _(„To specify the image format just put ‘jpeg’ or ‘png’ as command’s parameter, if no format is specified and the image is smaller than 1200KB it will be saved as PNG, otherwise the JPEG format will be used.“),

// execute е кода, който ще се изпълни при стартиране на командата
execute: function(args) {
var window = CmdUtils.getWindow();
// следващите няколко реда са взаимствани до голяма степен от имплементацията на CmdUtils.getWindowSnapshot
var canvas = CmdUtils.getHiddenWindow().document.createElementNS(„http://www.w3.org/1999/xhtml“, „canvas“);
canvas.mozOpaque = true;
canvas.width = window.innerWidth;
canvas.height = window.innerHeight;
// шантавият метод на canvas, който рисува прозорци – INSANE!
canvas.getContext(„2d“).drawWindow(window, window.scrollX, window.scrollY, window.innerWidth, window.innerWidth, „rgb(255,255,255)“);
var data = null;
// проверка, дали има експлицитно зададен формат на изображението и ако не,
// дали то не е твърде голямо за да го правим на PNG и директно да го запазим като JPEG.
// параметрите трябва да са jpeg, jpg, j, png, p
if (/^j(pe?g)?\s*$/i.test(args.object.text)) {
data = canvas.toDataURL(„image/jpeg“);
} else if (/^p(ng)?\s*$/i.test(args.object.text)) {
data = canvas.toDataURL(„image/png“);
} else {
data = canvas.toDataURL(„image/png“);
if (data.length > 1600*1024) data = canvas.toDataURL(„image/jpeg“);
}
// Показваме в notification bar-а, колко данни се изпращат, за да придобие представа потребителя,
// дали ще чака докато остарее или повече ;-)
displayMessage(_(„Sending „) + parseInt(data.length/1024+1) + „KB…“, this);
MAIN_URL = „http://dailyffs.com/shotme/“;
// изпращаме изображението към сървъра и когато върне като отговор ключа индексиращ картинката го сглобяваме
// и го пъхаме в клипборда и в notification bar-а
jQuery.post(MAIN_URL, „image=“+data, function(key) {
if (key == „ERROR“) return;
var url = MAIN_URL + „?“ + key;
Utils.clipboard.text = url;
displayMessage({text: url, onclick: function(){window.open(url);}}, this);
}
);
}
});



авг 22 2009

Share your screen

Category: Dev,Firefox,HTML5,Web,НонсенсLucho @ 03:43

Напоследък съм изгубил творческата си искра, в работата се занимавам с .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



« Предишна страница