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

Уверен, что все здесь присутствующие, наверняка написали свою первую строку 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, как по дизайну, так и по паттернам использования :)

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

port echo inactive | sed 's/ //g' | xargs port uninstall

Обратите внимаение что именно “port echo”, а не “port list” (почему именно так – не знаю)

Исполнение такой комманды почти вдвое (с 8.3Gb до 4.6Gb) уменьшило место занятое под MacPorts (что в эпоху дороготоящих SSD винчестеров весьма не бесполезно)

В последнее время много и часто приходится работать с 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.
Критика и пожелания приветствуются в коментариях.

Вот еще одна классическая задачка, которую опять же согласно слухам спрашивают в Google, и совершенно точно когда-то спрашивали в давно сгинувшей (или правильно говорить “переродившейся в Cogniance?”) Sonopia.

Итак у вас есть 8 шаров одинакового размера, при этом 7 из них весят одинаково, а один – существенно больше.

Задача: используя не более 2х взвешиваний типа “больше-меньше”, определить тяжелый шар.

Предистория состоит в том, что в процессе естественной эволюции кода и оптимизации запросов к MySQL RDBMS,  работа с “центральной” таблицей всей схемы БД (как несложно догадаться – это таблица videos), свелась к простому алгоритму:

1. выбрать сложным запросом из разных таблиц все video_id, удовлетворяющие нужным критериям
2. по полученному списку video_id, выбрать информацию о видео (aka SELECT … FROM videos WHERE id IN (…))

Причиной появления подобного use-case стал внушительный размер той самой videos.  А о катастрофичности любых JOIN-ов на большие (10Gb+) InnoDB-таблицы уже было написано немало. Хотя бы на том же MysqlPerfomanceBlog.com.

Следовательно, если у нас есть выборки из таблицы ТОЛЬКО по primary key – то это первый кандидат на миграцию в key-value RDBMS.  Что мы, собственно, и пытались опробовать.

Среди массы кандидатов (а их оказалось действительно много), для первоначальных проб выбрали MemcacheDB.
Причины весьма прозаичны, и были надиктованы “путем наименьшего сопротивления”:

• В проекте уже активно используется Memcached, клиент которого уже 100% совместим с MemcacheDB.
  Следовательно никаких сторонних библиотек “тянуть” в проект не нужно
• Реализации клиентов для Memcached/MemcacheDB есть почти под все мыслимые и немыслимые платформы и языки программирования. Тут конечно огромное спасибо Бреду Фицпатрику и его Danga.com.
• Memcached клиенты предоставляют базовый развномерный (хоть документация  и говорит о weight-based распределении) шардинг. В результате и MemcacheDB это перенял.
• В основе backend-a MemcachedDB лежит BerkleyDB – одна из старейших и надежнейших key-value RDBMS, которая до сих под активно поддерживается Oracle Corp.
• BerkleyDB поддерживает репликацию. И что самое приятное – как синхронную, так полу-синхронную и асинхронную.
• Memcached-клиенты поддерживают сжатие данных, что является немаловажым фактором при использовании дорогостоящих SSD-винчестеров.

В результате всего вышесказанного был проведен небольшой performance benchmark test.

Железо:

Использовался тестовый сервер 2 x Core2Quad / 16GB of RAM / 4 x 146Gb SAS HDD in RAID10
MySQL: v5.4.2 , InnoDB, innodb_buffer_pool=6Gb, по максимуму оптимизирован для интерсивной записи.
MemcaheDB: 1Gb of RAM, index type – hash, skip transaction support

Производительность записи:

Создание 1 000 000  записей.
MySQL: среднее время записи – 5.6 sec / 10k  (5.6 секунд на 10 000 записей)
MemcacheDB: среднее время записи – 4.1 sec / 10k
При включенном transaction support в MemcacheDB – около 7 sec/ 10k

Как видно MySQL не сильно отстает на записи, но при этом предоставляет полноценный ACID.

Производительность чтения:

Из ранее созданного миллиона записей случайным образом выбиралась одна запись по primary key.
MySQL: среднее время чтения – 1.7 sec / 10K
MemcacheDB: среднее время чтения – 0.7 sec / 10K

Т.е. в данном случае MemcacheDB более чем в 2 раза опережает MySQL.
Думаю если заняться тюннингом первого, то можно этот разрыв увеличить куда существеннее.

Размер данных:

Соотношение размеров файлов с данными (и индексами) получилось 1.5Gb  (MemcacheDB) против 2.3Gb (MySQL), т.е.  в 1.5 раза в пользу MemcacheDB.
Сравнение проводилось без использования сжатия в MemcacheDB и без использования MySQL ROW_FORMAT=COMPRESSED.

Вот такой вот небольшой sidenote вышел. В результате, пока еще мне не совсем понятно нужно ли оно мне или нет.
Если все-таки решеним испольовать MemcacheDB в production environment -  обязательно отпишусь о результатах.

По “долгу службы” довелось пощупать интересную технологию, до которой раньше не доходили руки. Думаю, Google App Engine будет интересен не только мне, поэтому начинаю мини-цикл статей о разработке для App Engine. 

После того, как вы впервые войдёте в сервис appengine, вам нужно будет подтвердить свою “личность”. Google вышлет на номер указанного вами телефона SMS с текстом вроде Google App Engine Code: 1234567. Лично мне SMSка дошла меньше чем за минуту (такой способ куда лучше бумажной почты, которую Google использует для Adsense). Такая проверка проводится только для первого создаваемого приложения.

Следующий шаг – зарегистрировать имя-идентификатор для приложения.

Теперь регистрация окончена, приступаем к разработке. App Engine работает на Java 6 и именно эта платформа является рекомендуемой, хоть и Java 5 тоже поддерживается. Я навскидку не смог придумать, что может пойти не так, если приложение скомпилированное на Java 5 запустить на JVM шестой версии, но Google’у виднее.

Скачиваем и распаковываем Google App Engine SDK для Java http://code.google.com/appengine/downloads.html.

Теперь дело за малым – написать простое приложение и отправить на сервер :-)

Тут Google оставил меня без материала для заметки, поскольку минимальный Hello World уже есть в комплекте SDK. Хранится он в папке demos\new_project_template. Тут есть и build.xml и статический контент, и сервлет и даже пара файлов с конфигурацией для самых распространённых logging API: Log4J и JUL (java.util.logging). Скопировав содержимое в папку, где будет жить ваш проект, вы получите отличный каркасс для начала разработки. Единственное, что нужно теперь сделать – указать путь к развёрнутому SDK: либо в параметрах при запуске ant либо прямо в build.xml.

Перед тем, как запустить приложение на локальном “эмуляторе” appengine, давайте посмотрим, что ещё есть в “комплекте”. Кроме стандартного web.xml в WEB-INF лежит файл appengine-web.xml – дополнительная конфигурация для движка appengine:

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
 <!-- Replace this with your application id
    from http://appengine.google.com -->
 <application>juriytest</application>
 <version>1</version>
</appengine-web-app>

Как и следует из комментария, в теге application нужно указать id приложения, котрый был зарегистрирован на appengine.

Кроме того в src/META-INF находится файл jdoconfig.xml, который является (неожиданно) конфигурацией для JDO – persistance механизма, который используется в среде appengine. Сейчас его трогать не будем, пускай живёт, hello world и без него запустится.
В проекте есть файл index.html, как пример статичного контента и HelloAppEngineServlet.java, который является привычным сервлетом без экзотики.

Чтобы запустить приложение локально выполняем ant runserver из корня тестового проекта.
Для того, чтобы “доставить” приложение на живую платформу нужно использовать утилиту из SDK: bin\appcfg.cmd

appcfg.cmd update www

www тут – путь к “развёрнутому” проекту. Appengine не поддерживает war файлы, а вместо этого работает с директориями с той же структурой. После того, как build.xml собрал для нас проект в папку www указанной выше командой можно загрузить его на appengine.

Пара полезных моментов и “граблей”.

App Engine сохраняет всё что вы напишите в System.out и System.err в логи. При этом e.printStackTrace в логи упорно не попадает. Немного сбивает с толку.

Логи в административном интерфейсе обновляются не моментально, а только через несколько секунд.

Последние грабли стоили жизни моим нервным клеткам. В конфиге appengine указывается версия проекта. Не надейтесь, что если будет указана версия выше текущей развёрнутой, то новая версия заменит старую. Всё обстоит совершенно не так. Новая версия затирает развёрнутую версию с таким же индексом. Затем, пользователь выбирает, какая из версий будет доступна по умолчанию. То есть, я могу развернуть версии 1, 2, 3. После разворачивания версии 3, пользователи видели только версию 1, пока в интерфейсе администратора не будет указана другая.

На этом пока что всё. В следующей заметке опишу, как заставить app engine работать с groovy.

__________
Спонсор заметки: “Идеал”, раскрутка сайта в Украине

Загрузить файлы раскладки: Ukrainian_crud_remap.icns и Ukrainian_crud_remap.keylayout

public class A {

	public static void main(String[] args) {
		System.out.println("This is wrong");
	}

	public static void main(String[] args) {
		System.out.println("This is right");
	}
}

2. Написать стандартный Hello World на Java. При этом нельзя использовать ни одной точки с запятой. Закодированные UTF символы тоже использовать нельзя.

Ответы я опубликую через сутки, а пока что жду комментариев.

P.S. За мной уже закрепилась слава человека, обожающего абсолютно бесполезные, с практической точки зрения, задачи. Я пришел к выводу, что для таких “упражнений” слово “задача” совсем не подходит. Все привыкли, что “задачи” это упражнения, которые развивают какие-то практические навыки. К примеру “реализовать генератор случайных чисел на Java” это задачка. А для того, что публикую я, лучше подходит слово “загадка”. Так что вот вам свежая “без окон без дверей полна горница людей”.

1. Указать место для складирования ScreenShots (по умолчанию – ~/Desktop )
(те что создаются системным shortcut-ом Command+Shift+4 & Command+Shift+3)

vadim@Voituk:~>defaults write com.apple.screencapture location ~/Pictures/Screenshots
vadim@Voituk:~>killall SystemUIServer

Аналогично меняется и формат скриншотов (злые языки говорят что поддерживается png, jpg, tiff, pdf):

vadim@Voituk:~>defaults write com.apple.screencapture type jpg
vadim@Voituk:~>killall SystemUIServer

2. Иногда при перезагрузке (часто если подключен внешний монитор) пропадает Bluetooth.
Решение сродни “давайте выйдем и зайдем – авось заведется” – выключаю Мак, отключаю все внешние устройства, вынимаю батарею.
Жду минуты 2-3 и включаю.
Время “простоя” использую для протирания ноутбука влажной салфеткой :)

3. Поначалу очень непривычно было, что в column mode Finder, в списках, директории и файлы идут вперемешку.
Частично эту проблему можно решить, нажав Command+J и выбрав “Arrange by Kind”.
В результате  директории будут в списке рядом, но не всегда в начале списка.
Окончательно можно решить проблему “грязным хаком”: сделать чтоб при сортировке по типу, директория (тип Folder) шла самой первой.

Для этого открываем файл
/System/Library/CoreServices/Finder.app/Contents/Resources/English.lproj/InfoPlist.strings
и сразу за комментарием /* General kind strings */ меняем строку
“Folder” = “Folder”;
на
“Folder” = ” Folder”;
(с пробелом перед буквой “F”)

После редактирования перезапускаем “Finder”. /me счастлив

Самые неотложные дела очень удобно записывать на желтых стикерах, и клеить на монитор.
Единственный минус – через 3-4 месяца они отваливаются.
(с) Народная шутка

За последние несколько лет я перепробовал порядка 2х десятков разных сервисов для формирования TODO-листов. Больше 2х дней ни одим не пользовался, и во всех случах по одной причине – о списке забывается, если он не находится постояно перед глазами.
Для примера, сегодня я нашел записи полу-годичной (!!!) давности в своем GMail Tasklist :) Тут уже и шутка из эпиграфа статьи превращается совсем не в шутку.
И это GMail, которым я пользуюсь ежедневно! А что уже говорить про всякие “оторванные” от рабочего процесса TadaList, TooDoo и им подобные?

В результате уже больше года я вынашиваю идею взять Юру, пива и за вечер налабать реализовать нормальный удобный web-ориентированный TODO-лист, который можно будет спокойно загрузить в sidebar браузера и он всегда будет на виду.

Уже даже начал писать functional overview и requirements specification, и наверное даже через недельку-две уже и приступил бы к реализации, если бы не сегодняшний утренний твит Макса Ищенко:

После чего необходимость реализовывать что-то свое попросту отпало – все уже украдено изобрели до нас:
Открываем Firefox, создаем новый Bookmark на видимой панели закладок, называем его TODO (ну или по желанию), как URL указываем “http://mail.google.com/tasks/ig?pli=1″, ставим галочку “Load this bookmark in the sidebar” – и вуаля!

Получится что-то вроде:

Т.е. на 100% то – что я искал.

Единственное, что смущает – не придумал как перенести этот sidebar  на правую сторону браузера, но думаю это решаемо.