На самом деле черновик мало соответствует тому, что я говорил на самой конференции, потому лучше смотреть видео

Уверен, что все здесь присутствующие, наверняка написали свою первую строку JavaScript кода в внутри HTML-тега <script>. И наверняка у многих это случилось если еще не в 90-х, то как минимум в начале 2000-ных.

C тех пор и до недавнего времени JavaScript был “языком для интерактивных Web-страниц”. Тогда же и появился термин DHTML – такой HTML но Dynamic.
Потом, лет так 7-8 назад, появился GMail и вдруг мир обнаружил существование XMLHttpRequest (Вуаля!).
А за одно с ним появились Ajax и профессия Web Frontend Engineer.
Все это счастье жило в браузере – сначала в десктопном, потом, с приходом Nokia WRT и HTML5 – в мобильном…
Параллельно в полу-подпольном режиме существовал JavaScript в качестве скриптового языка внутри разных популярных и не очень приложений: это продукты Adobe, фреймворки для плагинов к Chrome, Opera, Mozilla, Apple Dashboard Widgets и встраеваемый Mozilla Rhino. Также JavaScript можно использовать при программировании интерактивных телефонных AТС (PBX).

В это же проскакивали вообще технологически странные решения поверх JavaScript – такие как например GWT, или тот же WebOS от Palm.

Позже появился серверный JavaScript. Поначалу в виде не выстрелевших поделок вроде фреймворка от Aptana (уже не помню точного названия), а потом и в виде всем известного Node.js.
(про ASP-код на JavaScript – я пожалуй не буду вспоминать :)

Эти 3 направления: браузер, скрипт-язык и сервер-сайд – это теперешние mainstream направления для JavaScript.

Я бы сейчас хотел еще рассказать про одну область применения JavaScript, которая по моему мнению станет mainstream-ом в течении ближайших пару лет – это телевизоры и разного рода ТВ-приставки (тюнеры, Set-Top-Box-ы).

Тема не очень то и новая, и насколько я знаю, как минимум один из здесь присутствующих с этим уже стыкался.
Началось все с того, что Yahoo создал дефакто стандарт для виджетов для ТВ – Yahoo TV Widgets.
Их поддержали Samsung и выпустил серию ТВ-устройств, которые сейчас называются SmartTV.
По сути они не сделали ничего особенного – просто подключили телевизор в интернет и открыли платформу.
Ну и конечно-же они позволили сторонним разработчика писать свои виджеты следуя спецификации Yahoo TV Widgets.
Эффект был потрясающий – пользователи “писали кипятком” от возможности смотреть Youtube, читать Twitter или качать торренты прямо в собственном телевизоре.
К тому же еще и Skype подлил масла в огонь – они сделали версию для ТВ с поддержкой USB web-камер.
Параллельно с этим развивалось IP-телевидение, а вместе с ним и специальные IPTV-приставки для него, называемые Set-Top-Box-ы, которые, окромя основной задачи (показывать ТВ-каналы), предлагали уйму дополнительных интерактивных услуг.
Например мой домашний провайдер позволяет заплатить кредиткой за ТВ+Интернет прямо с экрана телевизора.
Типичным примером такого SetTopBox-ом является Apple TV – кроме телевидения over the internet, это еще и все прелести iTunes в красивой алюминиевой коробочке :)

Так вот возвращаясь к теме нашей сегодняшней встречи, большая часть того что видно зрителю на современном SetTopBox-е (как например окошки, менюшки, индикаторы, переключатели и тд) – это все JavaScript.
Ну если быть откровенным то не просто JavaScript, но еще и HTML c CSS-ом.
Чаше всего все что вы видите на экране ТВ, и что не является аудио-видео-потоком – это JavaScript. Как то:
– Выбор каналов
– Регуляторы и индикаторы громкости, эквалайзеры
– Программы передач
– Интерактивные бегущие строки (a-la погода, курсы валют)
– Окошки c настройками самого Set-Top-Box или личного кабинета IPTV-провайдера (например состояние счета абонента)
– Интернет-видео: Youtube, Vevo, Vimeo
– Video On Demand медиатеки и Pay Per Watch системы
– Музыкальные проигрыватели или фото-слайдшоу
– Анимации и эффекты а-ля “видео-внутри-видео”
– Даже заказ пиццы из ближайшей пиццерии не вставая с дивана.

Все это реализуется на JavaScript.

Выглядит это где-то приблизительно так:

Технически – внутри работает браузер WebKit или Opera версии около 9.5-10, который крутится на микро-линуксе поверх какой-то PowerPC, ARM или аналогичной архитектуры (чтоб не грелся и не жужжал вентиляторами).
Ко встроенному браузеру пригалается набор вне-браузерного JavaScript API для коммуникации с железом SetTopBox-a и иногда еще интерфейсы для управления дополнительными устройствами вроде USB-камеры или WiFi антенны.

Потомy с точки зрения программиста – разработка под телевизор или ТВ-приставку мало чем отличается от разработки под браузер.
Единственно НО, которое нужно постоянно держать в голове – это то, что главный инструмент ввода от пользователя – это все-таки пульт дистанционного управления, и привычные для ТВ интерфейсы, немного отличаются от того, что мы привыкли видеть в WEB, как по дизайну, так и по паттернам использования :)

Спасибо за внимание.

В последнее время много и часто приходится работать с HTTP-REST-JSON  API, в результате чего назрела необходимость в нормальном client tool для этого API. И если на роль полноценного HTTP-REST-клиента претендовать не приходится (первенство тут отдаем старому доброму консольному curl), то вот с “красивым” форматированием результата вызова API – приходилось повозиться.
Порою доходило до того, что ввиду сложности структуры результата, приходилось запускать developers console WebKit-a, копировать в буфер обмена строку-результат запроса, и выполнять  что-то вроде:

console.log(/*...long...long...long...string...goes...here..*/)

Во процессе борьбы с таким неудобством, в какой-то момент в недрах сети была найдена утилита jsonlint, которая умела структурировано выводить на экран JSON-обьект (такой себе аналог xmllint), но и с ней не сложилось – какие-то ее зависимости категорично отказывались устанавливаться посредством  MacPorts.

Вконце концов было принято решение набросать аналогичный tool самостоятельно.
Среди кандидатов на язык разработки подобной мелочи были Groovy, Groovy++, php и Node.JS).
Ввиду JavaScript-nature поставленной задачи грех было не воспользоваться Node.JS – и выбор оправдал мои ожидания.
Всего 30 минут “курения” node.js Manual & Documentation”, 10 строк кода, и нужнейшая утилита “в кармане”.

Исходный код приводить тут не буду – его можно поглядеть на github, покажу лишь несколько примеров использования полученной мини-утилиты на примере Twitter API (команды вводить unix-консоли):

1. Информации о Twitter-аккаунте конкретного пользователя:
curl -s "http://api.twitter.com/1/users/show/voituk.json" | jsonlint | less

2. Поиск в Twitter:
curl -s "http://search.twitter.com/search.json?q=@voituk" | jsonlint | less

Установить или обновить такую полезную “тулзу” можно простой консольной командой:
curl https://github.com/voituk/Misc/raw/master/nodejs/jsonlint > ~/bin/jsonlint && chmod a+x !#:3
(как это сделать на Windows – не спрашивайте ибо я даже не представляю как установить на Windows сам Node.JS)

Вот так вот неожиданно все получилось легко и просто посредством Node.JS.
Критика и пожелания приветствуются в коментариях.

function properHtmlFromText(text){
	while (text.search(/\</) != -1)
		text = text.replace(/\</, '&lt;');
	while (text.search(/\&/) != -1)
		text = text.replace(/\&/, '&amp;');
	while (text.search(/\r/) != -1)
		text = text.replace(/\r/, '');
	while (text.search(/\n/) != -1)
		text = text.replace(/\n/, '<br />');
	return text;
}

Как увидел – плакал…
Наверное все-таки будем возобновлять ежедневные code-review…

P.S. В комментариях предлагаю поделиться “правильным” решением :)

С другой стороны Java. Вот тебе пользователь раз логотип при загрузке апплета, да побольше, побольше, а если ты вдруг забыл про то, что работаешь с великой и могучей Java, мы тебе иконку в трей кинем, чтобы он тебе оттуда напоминал что пора качать новую версию.
Вобщем, вы мою позицию поняли.

Недавно я задался вопросом, как организовать загрузку апплета на странице так, чтобы пользователь не увидел экрана загрузки. Вместо него я бы хотел, к примеру, разместить логотип и progress bar (не настоящий, а просто картинку, которая показывает, что процесс идет). Второе обязательное требование: чтобы приложение отображалось, как только GUI прорисован. Мы не хотим заставлять пользователя ждать лишнее время.

Перечитав комментарии http://voituk.kiev.ua/2008/05/28/java-deployment-toolkit/ я решил не использовать стандартный JavaScript от Sun. Я воспользовался альтернативой – скриптом из классного, но не очень известного проекта PulpCore. Этому проекту можно было бы посвятить отдельную заметку, отличная разработка заслуживающая более пристального внимания. После небольшой “доводки напильником” вышло отличное решение, которое я протестировал на тех браузерах, что были у меня под рукой.

Кроме “сокрытия” экрана загрузки, скрипт умеет определять версию JRE (как и аналог от Sun), делать “отложенную загрузку”: апплет загружается после того, как пользователь нажмет на кнопку.

Принцип работы скрипта прост: он определяет браузер и версию Java плагина, генерирует текст HTML элемента, который загружает апплет и отображает сплеш-скрин поверх него. Пользователь видит “правильный” сплеш, а не стандартный экран загрузки Java. Если же версия Java не подходит, отображается сообщение предлагающее пользователю решить эту проблему.

Когда апплет полностью загрузился и готов к тому чтобы предстать перед пользователем во всей красе, он (апплет) вызывает через LiveConnect функцию, которая убирает экран загрузки. Вуаля. Если LiveConnect по какой-то причине не сработал, сплеш автоматически исчезнет после таймаута.

Вот пример кода, который отобразит апплет на странице:

	<script type="text/javascript"><!--
		pulpcore_width = 500;
		pulpcore_height = 300;
		pulpcore_archive = "applet-17.jar";
		pulpcore_class = "TestApplet.class";
	//-->
	</script> 

	<div id="game">
		<script type="text/javascript" src="loader.js"></script>
		<noscript><p>To play, enable JavaScript from the Options or Preferences menu.</p></noscript>
	</div>

Примеры скрипта в действии можно посмотреть на сайте проекта PulpCore.

Вот так, просто и надежно мы оставляем пользователей в блаженном неведении, какая именно платформа делает работу. Жаль иконку из трея так же просто убрать не выйдет.

[UPDATED]
Проблему, вроде бы, решил. Удивительная штука. Проблема возникала при использовании HTTP Client из Commons. Обычный URLConnection работает отлично. Ладно уж, решение, описанное ниже можно изпользовать для более интересных задач.

Основное разочарование, которое меня ожидало: вопреки настройкам Java Plugin упорно не хотел использовать настройки прокси из браузера и нахально ломился напрямую (естественно, получая по рукам).
Вторая проблема, даже если дать пользователю возможность самостоятельно ввести настройки прокси (что далеко не каждый типичный пользователь сможет сделать), необходимо также “попросить” пользователя ввести логин-пароль для авторизации. Зачастую пароль совпадает с паролем XP-account’а пользователя, а эту информацию даже очень дружественному апплету даст не каждый.

Решение, которое я нашел, это “костыли” для апплета. Если апплету так тяжело послать примитивный HTTP запрос на хост, с которого он сам загружен, надо поручить эту работу тому, кто с ней нормально справляется: браузеру. Ведь ajax запросы учитывают все настройки прокси, а при помощи LiveConnect из JavaScript можно вызывать публичные методы апплета.
На самом деле, и из апплета можно вызывать функции JavaScript, но по заверениям форумчан эта функциональность иногда не работает.

Самое простое решение, которое я смог придумать: JavaScript периодически опрашивает апплет: не хочет ли тот послать какой-нибудь запрос. Текст запроса апплет возвращает в некотором публичном методе. Если запрос не пустой, JavaScript посылает асинхронный запрос к серверу (Ajax), передавая текст запроса из апплета прямо на сервер. Когда от сервера приходит ответ, JavaScript передает его назад апплету. Таким образом, JavaScript с Ajax запросами выступает в качестве шины для асинхронного обмена сообщениями.

Вот код JavaScript’а:

// Every 5 seconds poll applet for request
var executer = new PeriodicalExecuter(poll, 5);

// That's the method that actually polls applet
function poll() {
	var applet = document.getElementById('tstapp');

	// get() is a public method of applet
	var request = applet.get();

	// If there's some request from applet - send it to server
	if (request.length > 0)
		sendRequest('http://someserver.org/script.php', request);
}

// I use prototype.js to do all Ajax-related stuff for me
function sendRequest(url, data) {
		var myAjax = new Ajax.Request(
		url,
		{method: 'post', parameters: data, onComplete: ajaxResponse}
	);
}

// This is a callback method invoked when response from
// server is ready. Just passes result to applet
function ajaxResponse(originalRequest) {
	passResponse(originalRequest.responseText);
}

// Pass response back to applet
function passResponse(resp) {
	var applet = document.getElementById('tstapp');
	applet.put(resp);
}

Апплет тоже довольно примитивный:

public class TestApp3 extends JApplet {

	private JTextField textField;

	public void init() {
		textField = new JTextField();
		textField.setText("nothing yet");
		add(textField);
	}

	public String get() {
		return "request text";
	}

	public void put(String response) {
		textField.setText(response);
	}
}

Естественно, для использования этого способа в реальном мире, необходимо сделать несколько дополнений. К примеру, корректно обработать ситуацию, когда апплет не успевает загрузиться за первые 5 секунд жизни страницы.

Я еще не опробовал этот метод на реальном проекте, но выглядит конструкция вполне жизнеспособно. Я протестировал связь JavaScript/апплет под FF, IE и Safari (спасибо Farcaller и его MacOS) везде работает нормально.

Как всегда оказалось, что идея связать Ajax и апплет пришла не мне первому в голову. Вот ссылочка на демку, которая использует эту связку для сохранения данных страницы на клиенте.

Из того, что понравилось сразу – это возможность выполнять JavaScript-код не по событию полной загрузки страницы (window.onLoad), а сразу после загрузки и инициализации DOM-дерева. Т.е. можно уже выполнять манипуляции с DOM-деревом не дожидаясь загрузки стилей, изображений и остальных медиа-компонентов.

В jQuery реализуется это 2-мя способами:

$(document).ready(function(){...})

и в сокращенной нотации

$((function(){...})

Но так как я являюсь давним пользователем prototype.js  – сразу же захотелось такую же возможность и в нем. Как оказалось в версии 1.6 она уже есть, и использовать её можно таким образом:

document.observe('dom:loaded', function(){ ... })

или

Event.observe(document, 'dom:loaded', function(){ ... })

Работоспособность проверял на Prototype 1.6.0.2 в Firefox3, Internet Explorer 6 и Safari (Win+Mac).

Назначение библиотеки – сделать развертывание и запуск Java-приложений в среде Web (апплетов, WebStart-приложений) более простой и комфортной.
При этом библиотека берет на себя задачи по определению установленных JRE, проверки соответствия их версий минимальным требуемым приложением, установке обновлений (если необходимо) и конечно же кроссбраузерного добавления обьектов на страницу.
Получается такой себе аналог SWFObject для Java.

Использовать Java Deployment Toolkit  очень просто – достаточно подключить на web-страницу единственный JavaScript-файл:
[javascript]<script src=”http://java.com/js/deployJava.js”></script>[/javascript]

Пример добавления аплета на страницу будет выглядеть так:

deployJava.runApplet({codebase:"http://voituk.kiev.ua/demo/",
  archive:"TumbleItemProject.jar", code:"components/TumbleItem.class",
  width:"600", Height:"95"},
{maxwidth:120, nimgs:17, offset:-57, img:"images/tumble"}, "1.5")

где первый параметр метода runApplet() – параметры тэга <APPLET>,
второй – параметры, передаваемые самому апплету (значения <PARAM>),
третий – минимальная версия JRE необходимая для запуска апплета.

Что  по cути отличается от использования старого доброго тега <APPLET> только формой нотации (JSON вместо HTML).

При этом, при попытке зайти на страницу с апплетом с помощью браузера, без установленного (или с устаревшим) Java Plugin, будет предложено установить последнюю версию оного.

Итак, сам линк выводится в результатах поиска в самом низу возле нижней строки поиска, нажимаем и попадаем на страничку http://www.google.com.ua/experimental/
Суть проекта в чем. Можно принять участие в разработке новых фишек на гугле. Среди тех которые в разработке есть очень много интересных, по крайней мере для меня, но думаю каждый найдет что-то и для себя, то чего ему очень нехватало все это время. Полный перечень приводить не буду, зайдите сами гляньте, как говорится лучше один раз увидеть.

Например “Keyword suggestions”. Позволяет увидеть результаты поиска по мере набора.
Или “Keyboard shortcuts” из названия понятно что за фишка. Она позволяет пользоваться горячими клавишами. Должен заметить очень удобно :).
Ajax рулит вообщем. Одно огорчило некоторые фишки у меня не работали и одновременно можно попробовать только одну, но это все еще в разработке поэтому жаловаться грех.
Советую всем присоединиться, тем более можно выставить свою оценку для каждой фишки и тем самым почувствовать себя участником грандиозного проекта :)

Для построения полноценного современного web-интерфейса были выбран набор библиотек и компонентов, которым хочу с вами и поделиться.

0. Основа.
Prototype.js – библиотека, существенно упрощающая JavaScript-разработку.
Этот выбор был больше идиологическим, чем практическим, поскольку я знаком с этой библиотекой намного лучше чем с другими.
Ипользование prototype.js, как основы, а также нежелание “тянуть в проект все подряд”, накладывают такие ограничения на выбор других компонентов интерфейса – он должен быть создан на основе prototype.js, в противном случае должен не конфликтовать с нею.
И конечно же такой компонент должен легко принимать вид, соответствующий корпоративному стилю и утверржденному дизайну.

1. Таблицы. Для отображения и манипулированияи табличными данными выбрал TableKit, отличная библиотека, достойная наивысшей оценки.
Очень немаловажным является то, что её использование не требует написания серверного кода – а это в свою очередь позволяет легко и быстро внедрить её в уже существующий проект.
В принципе толком и выбирать было не из чего, да больше ничего и нужно – тут и сортировка с автоопределением типа содержимого, и изменение размера, и встроенное редактирование значений с возможностью реализовать свой редактор значения, – все как во “взрослых” и платных ASP.NET компонентах.
Просмотреть демо

2. Выбор дат
Какое же приложение по анализу без выбора интервалов дат?
После достаточно длительного блуждания по сети выбор пал на DatePicker от Eulerian Technologies. Также как и TableKit, он легко интегрируется в существующий проект без замены серверного кода.
Единственное что прийшлось модифицировать, так это убрать визуальные эффекты (а вместе с ним и зависимость от script.aculo.us), и добавить русскоязычную версию.

Скачать версию с поддержкой русского языка можно здесь.

К сожалению в дальнейшем, в проекте прийшлось заменить DatePicker на “более привычный господам менеджерам” набор select-box-ов, но тут же DatePicker не виноват:)

Если по каким-то причинам DatePicker и вам не пришелся по душе, то стоит обратить внимаение на Scal но IMHO он ещё достаточно “сырой”.
В идеале хотелось бы элемент управления аналогичный том, который используется в Google Analitics.

3. Графики и диаграммы – тоже немаловажная часть любой визуализации
Тут также неоспоримым лидером является Plotr – наверное единственный charting framework на базе prototype.
Если же требуется повышенная переносимость и поддержка относительно древними браузерами, то стоит обратить внимание на, основанный на технологии Flash, Fusion Charts фреймворк.

4. Индикатор прогресса – также достаточно часто применяется для планирования и анализа.
Из того что удалось “нагуглить” самый приятный “взгляду и коду” – это WebAppers Progress Bar

5. Вспомогательные интерфейсные элементы – к ним я отнес небольшие и часто несложные вспомогательные интерфейсные элементы.
Базовый набор предоставляет самый известный (особенно среди пользователей Ruby On Rails) основанный на prototype.js фреймворк script.aculo.us – это инструменты перестаскивания, сортировок, автодополнения, подсказок, inplace-редактирования, меню и тд.

Конечно же данная заметка не претендует на полноценный обзор prototype-based решений для построения интерфейсов, потому хотелось бы услышать об опыте использования других “связок”, основанных на prototype либо аналогах.

RSS или Atom по сути является XML-форматом достаточно простой структуры, потому разбор такого документа средствами встроенного в баузер JavaScript ничего сложного из себя не представляет.
Сложнее приходится с загрузкой RSS feed-а ввиду того, что загружать данные посредством Ajax можно только с того домена, с которого был загружен сам JavaScript скрипт.
Вот тут на помощь приходит Google Feed API -с его помощью из JavaScript на странице можно получить доступ к любому RSS-потоку, проиндексированному Google Feedfetcher (эдакий Google Bot только для RSS), а ввиду повального использования Google Reader – можно смело утверждать что таким образом доступен любой RSS-фид.

Для того, чтоб использовать Google Feed API на своем сайте необходимо получить API KEY.
После получения API KEY дописываем в <head> блок нашей страницы такой код:
[html]

<script src="lastpost.js" type="text/javascript"></script>
      <script type="text/javascript">
      google.load("feeds", "1")
      google.setOnLoadCallback(function() {
        showLastPostWidget('lastpost_id', "http://voituk.kiev.ua/feed/", 10)
      });
</script>

[/html]
В том месте, где нужно вывести последние статьи с блога дописываем:
[html]

<div id="lastpost_id">Loading...</div>

[/html]
Осталось разобраться что же делает функия lastpost.js и функция showLastPostWidget:
[js]

function showLastPostWidget(id, url, count) {
       var feed = new google.feeds.Feed(url)
       feed.setNumEntries(count)
       feed.includeHistoricalEntries()
       feed.load(function(res) {
         if (res.error) return;
         var container = document.getElementById(id);
         container.innerHTML = '';
         if (!container) return;
         for (var i = 0; i <res.feed.entries.length; i++) {
           var entry = res.feed.entries[i]
           var a = document.createElement("a")
           a.href=entry.link
           a.appendChild(document.createTextNode(entry.title))
           var div = document.createElement("div")
           div.appendChild(a)
           container.appendChild(div)
        }
      })
     }

[/js]
Как видно из кода она загружает последние count feed-ов из указанного url, и добавляет их внутрь контейнера, id которого указывается первым параметром.

Все просто, понятно – и ни строчки серверного кода.

Стоит только добавить что внешний вид блока последних заметок легко регулируется стилями.
Например:
[css]#lastpost_id div {
margin: 1px;
background-color: #EBEBEB;
}[/css]

Этот widget приведен скорее как демострация возможностей Google FEED API, но и в таком виде ничего не мешает использовать его на своем сайте/блоге.

Действующий пример можно увидеть здесь или на этом сайте в правой колонке.