Когда то давно, в своем дебютном посте, я обещал рассказать о создании спрайтовой анимации с сортировкой по глубине… Ну, обещания нужно сдерживать:)
Igor Demyanov @DisDis
Пользователь
Как написать игру в стиле Tower Defense
19 min
Recovery Mode
Translation
Жанр Tower Defence один из самых популярных жанров игр на iOS. Причиной тому веселое времяпрепровождение, сдобренное постройкой башен для создания последней точки обороны против орд монстров, пытающихся эту самую оборону прорвать.
Представляю вашему вниманию перевод статьи, написанной Pablo Ruiz, и найденной мной на сайте raywenderlich.com.
В этом уроке будет показано, как создать игру Tower Defense с нуля, с помощью Cocos2D.
В процессе вы выучите следующее:
В конце урока, у вас будет свой фрэймворк для создания игр такого типа, который вы сможете расширять, добавляя новые типы врагов, башен и карт.
Для понимания этого урока, вам нужно базовое понимание Cocos2D. Если вы новичок, то можете взглянуть на более легкие уроки на сайте Рэя.
Представляю вашему вниманию перевод статьи, написанной Pablo Ruiz, и найденной мной на сайте raywenderlich.com.
В этом уроке будет показано, как создать игру Tower Defense с нуля, с помощью Cocos2D.
В процессе вы выучите следующее:
- Как создавать волны врагов и настраивать время их появления.
- Как заставить этих врагов двигаться по заданным точкам(waypoint'ам).
- Как строить башни на специально отведенных местах на карте.
- Как заставить башни стрелять во врагов.
- Как визуально представить waypoint'ы и радиусы атак башен.
В конце урока, у вас будет свой фрэймворк для создания игр такого типа, который вы сможете расширять, добавляя новые типы врагов, башен и карт.
Для понимания этого урока, вам нужно базовое понимание Cocos2D. Если вы новичок, то можете взглянуть на более легкие уроки на сайте Рэя.
Closure Platform. Костыли для Google Closure Library
17 min
Наша компания занимается разработкой собственного веб приложения. То есть без внешнего финансирования :) В этом есть как плюсы, так и минусы. Но то, что мне всегда нравилось и нравится, — это возможность попробовать что-то новое — технологии, подходы и решения. По некоторым причинам я не могу назвать сайт проекта, но могу поделиться тем опытом, который получил за время работы.
Так как я отвечаю за ту часть проекта, которая непосредственно видна пользователю, и с которой он вплотную работает, моя история и будет о ней).
Для начала, что бы читатель понимал о чём идёт речь, я хотел бы рассказать что у нас на «тёмной» стороне. А там Java, MySQL, Neo4J, Jetty, RabbitMQ и в конце этого длинного питона находиться nginx.
В конце 2010 года, мы, нашим «доблестным» отделом web-js, решили отказаться от старого шаблонизатора по ряду причин о которых ниже и перейти на что-то новое и действительно отвечающее реалиям нашего безумного проекта. Дело было в том, что в это время уже была реализована концепция виджетов и мест (place). Виджеты в нашем понимании — это некие независимые визуальные куски, которые общаются посредством каналов. По каналам можно передавать сообщения и подписываться на определённые типы сообщений. Виджет же, в свою очередь, не знает, где он находится в ДОМе — за это отвечают места (place). Большая проблема была в том, что виджет определял некие шаблоны, по которым он визуализировал данные. Мы можем использовать один и тот же виджет в разных местах, но выводить данные по-разному, следовательно, и пользователь мог взаимодействовать с данными по-разному. Но вернёмся к нашему древнему шаблонизатору. В то время все шаблоны подгружались и кешировались на клиенте в web-storage из-за чего была некая асинхронность в js коде — после создания виджета проходило какое-то время прежде чем можно было выводить данные. Мы хотели найти новое решение, которое бы убрало многие проблемы нашего шаблонизатора, например:
Мы проанализировали существующие на тот момент решения и выбрали Google Closure Library(GCL)… Да, я еще тогда не знал что Google даёт технологию, но не даёт инструментов по её использованию :)
К тому моменту проект насчитывал:
Ответ кроется в комплексном подходе, предлагаемым Closure. Мы хотели, чтобы:
js код сжимался, оптимизировался в продвинутом режиме
Все решения, которые были в сети на тот момент, давали что-то одно, гугл давал три связанных решения: Closure Compiler, Closure Template, Closure Stylesheets, которые работают как отдельно, так и вместе. И, когда они работают все вместе, то результат просто потрясающий!
Первое, с чего мы начали, — это проставили повсюду js зависимости… goog.require… Это было долго, заняло порядка 1 месяца. В результате, у нас упростилось подключение новых js файлов и логики — достаточно просто прописать зависимость и система автоматически подгрузит нужный код.
Гугл не даёт инструментария для использования своих технологий, но в самом гугле он есть, так как разработчики напрямую (через Г+) сообщили, что пишут в Эклипсе и у них полная поддержка Closure в нём.
Мы написали свой скрипт для Eclipse в виде Build Event, который при каждом сохранении js обновлял файл зависимостей deps.js для Closure. В то время практика была такая, что весь проект целиком (Tomcat, mysql, mq broker и т.д.) поднимался на машине у каждого разработчика, что отжирало 6гиг памяти и требовало около полутора-двух минут на старт всего проекта, так что мы тихо мигрировали на локальное проксирование js,css,img файлов через nginx, что значительно ускорило разработку. А то ждать пока эклипс пнёт томкат, чтобы тот начал обновлять файлы, было очень утомительно.
GSS чем-то похож на LESS, со своими особенностями.
Параллельно мы перешли с css на gss. Много проблем доставили всякие нестандартные атрибуты, а так в принципе достаточно просто переименовать css в gss. Единственное рекомендую сразу прошерстить свои css и внедрить mixin. Еще оставалась проблема с тем, что надо было как-то отслеживать какие файлы gss изменились и вызывать для них компилятор gss->css
Что из себя представляют SOY. Это шаблоны, написаные на html похожем синтаксисе, и компилируемые в js код. Это решает важную проблему с кэшированием на стороне клиента всех шаблонов.
Одновременно со всеми этими нововведениями мы переводили старые шаблоны на SOY (Closure Templates). SOY оказался просто сказкой для программистов, так как мы смогли полностью отделить визуальную часть от логики и легко интегрировать ее в js код, потому как компилятор проставляет зависимости(goog.require). Так как в SOY есть пространство имён, то мы сразу продумали то, что у нас namespace будет отражаться в файловой системе в виде папок — как в java.
Большая проблема заключается во времени компиляции всех файлов — это слишком долго, на Core i7 3770K компиляция всех gss и soy занимает 20 секунд. Поэтому мы сделали скрипт который отслеживает изменённые gss и soy и компилирует только их — Гугл почему то не предоставляет такие инструменты в открытом доступе.
Обновление: В процессе написания статьи, была внедрена оптимизация и время компиляции(в режиме отладки) составляет сейчас 8-9 секунд.
После решения этих проблем перед нами стояла последняя задача — заставить все эти три технологии работать вместе, чтобы ускорить работу сайта, ну и получить то, ради чего всё задумывалось.
Но тут выплыли некоторые нюансы: чтобы работало сжатие css селекторов нужно всюду в js использовать конструкцию goog.getCssName('display1') вместо прямого обращения 'display1'. То есть $element.addClasss('display1') нам нужно было заменить на конструкцию $element.addClasss(goog.getCssName('display1')). Кроме того, внутри goog.getCssName(...) нельзя использовать переменные и большое количество селекторов. То есть goog.getCssName('display'+value) не прокатит:), как не прокатит и goog.getCssName('display1 clearfix'). Это доставило много неудобств, из-за которых пришлось переписывать скрипты компиляции — чтобы они поддерживали возможность не сжимаемых css селекторов, так как весь старый код невозможно было сразу конвертнуть из вида «display-»+value во что-то нормальное. В самих SOY надо тоже по-особому выделять классы и идентификаторы которые будут сжиматься, {css display1} и т.д. На первом этапе у верстальщика был полный ад… Мы искали решение с подсветкой синтаксиса, в итоге мы нашли для Eclipse плагин который решил кучу проблем. (http://www.normalesup.org/~simonet/soft/ow/eclipse-closure-templates.en.html).
Что он умеет:
В общем, этот плагин стал для верстальщика манной небесной. SOY — развязывает вам руки, но и повышает ответственность. Чуть позже мы написали свои плагины для soy компилятора чтобы добавить нужные нам методы, наподобие конвертации строки в число и округление. На этом злоключения с SOY только начались. Дальше мы перевели серверные шаблоны на новый шаблонизатор. Для этого пришлось писать снова свои классы для поддержки тем и переводов. Для автоматической конвертации старых шаблонов в новый вид мы написали конвертер…
С переводами SOY на разные языки отдельная песня, гугл говорит: «там всё отлично». Там всё и вправду отлично, если есть инструменты:), а так вы можете генерить из soy файлов xlf файлы или файл. И вот тут оказалось, что никак нельзя взять старые переведённые xlf и просто добавить туда те, что не переведены… Это просто кошмар! Есть какой-то ужасный набор утилит для работы с этим форматом, но там нет того, что надо, у каждой фразы есть свой id, но он генерируется так изощренно, что даже сам класс генератор в Google Closure называется Fingerprint… Снова мы писали инструменты, которые позволили решить эту проблему.
Так же нам пришлось вынести из всех jsp страниц js код в отдельные модули, так как надо было готовиться к сжатию…
Так прошло еще 7 месяцев с начала нашего пути, у нас были все нужные инструменты, все нужные связи между тремя технологиями, но сжатие в продвинутом режиме не работало:) Снова возникли проблемы, связанные с тем, что jQuery и многие плагины некорректно собираются в продвинутом режиме, необходимо было писать и подключать externs. С jQuery и плагинами разобрались, теперь выяснилось что вызовы js в SOY тоже надо заменить на некие несжимаемые вызовы. Я понимаю, что GC не рекомендует использовать прямые вызовы в onclick, и это легко сделать, когда вы пишите проект с 0 на GC, но, когда у вас тонна старого кода, это совсем не так просто, поэтому мы создали файл export.js, в котором прописали прокси для внешних вызовов вот в таком виде:
Мы установили стандарт для всех таких экспортированных вызовов, вида function(event,this,...), то есть два первых параметра обязательно такие, а дальше какие угодно.
Решив эту проблему с экспортом (количество вызовов оказалось не более 20-30) оказалось, что всплыл еще один печальный факт с GCC(Google Closure Compiler). GCC сжимает в продвинутом режиме всё, что не «приколочено» кавычками ' или ", а, следовательно, вызовы внешних плагинов нужно было исправлять. Но самое большое разочарование заключалось в том, что клиент-серверное взаимодействие у нас работало на чётко документированном API, а после сжатия оно рушилось. Это снова откинуло нас на неопределённый срок…
Тут надо сделать отступление, сам Гугл передаёт не JSON-объекты, а массивы. Мы сначала думали, что это ProtoBuf — попробовали и оказалось, что нет, они просто ассоциируют каждый индекс массива с конкретным полем. Видимо, когда приходят данные с сервера, они их скармливают какому-то MessageFactory, который на основании мета-данных(тут возможны мета данные ProtoBuf для конкретного типа сообщений) связывает элементы с объектом. Если поступать как делает гугл, то, конечно, после сжатия и оптимизации никаких проблем нет и даже скорость повысится, так как с массивами работать быстрее).
Почему мы не поступили как гугл? Причина в том, что у нас много старого кода, который нам было необходимо поддерживать, но мы обязательно займёмся этой задачей, так как именно этот путь правильный.
Поиски решения привели к тому, что GCC мог отдавать карту преобразования имён, вида «старое поле объекта»:«новое название поля». Мы начали переделывать серверный код так, чтобы он мог поддерживать эту возможность, для этого был введён класс в общую для 5 сервисов библиотеку.
Вот такого вида:
Перед сборкой специальная утилита брала map, которую сгенерировала GCC, и правила этот класс. Но, когда мы уже думали, что всё готово, оказалось, что в силу некоторых причин некоторая часть исторических данных необходимых на клиентской стороне хранится в виде json в базе и пока нет возможности сделать по-человечески… Даже изменив название полей, в базе нереально всё изменить, а так как при каждом изменении js кода генерируется новый map, конвертировать нет шанса. Это было полное фиаско… И тут пришла идея сделать наоборот — ведь GCC не только может отдавать map, но и принимать map преобразования. Мы взяли класс Constants, сконвертировали в map, скормили его GCC, тот сжал весь код, но не тронул названия полей, связанные с Client-Server API. Всё было хорошо, пока не обнаружились странные ошибки, связанные с некоторыми полями. Например, поле «items» должно было остаться «items» в выходном файле, а оно переименовывалось в «items1». Сложность была в том, что определить зависимость было сложно, так как на простых примерах всё работало как часы. Пришлось брать исходники GCC и запускать их под отладкой, оказалось, что если в коде вы где-либо упоминаете название свойства в кавычках (" или ') "<property_name>", то компилятор переименовывает вашу переменную даже если в map было указано «items:items». Создав баг в трекере GCC и добавив однострочную заплатку в комментарии, мы пересобрали свой GCC и удачно сжали весь проект.
Дальше мы прикрутили source map для того, чтобы разобраться в этой куче сжатых и оптимизированных-непонятных a.b.Fs(… Для этого пришлось тоже написать свою утилиту, потому что GCC почему-то не умеет добавлять в конец сжатого модуля
Что же мы получили в качестве результата:
В несжатом виде 1.6 МБ js код + 1.4 МБ шаблоны ~ 3.0 МБ
38 модулей в обычном режиме сжатия весят 2830 Кбайт в zip 445Кб
38 модулей в продвинутом режиме сжатия 1175 Кбайт в zip 266Кб
Сайт реально стал быстрее работать, пусть мы и потратили на это 12 месяцев. Параллельно мы решали задачи по работе и потихоньку шли к цели…
Вся эта история написана для того, чтобы вы могли себе представить стоят ли все эти телодвижения результата. Если бы мы начали проект сейчас на GC Library, у нас было бы меньше проблем, но если у вас уже есть тонна старого кода, то этот процесс может затянуться.
И заставьте верстальщика писать документацию по SOY, чтобы он вписывал туда примеры и типовые решения, это поможет ему быстрее адаптироваться и разобраться.(Со слов нашего верстальщика:) )
П.С.: Если кому интересно то мы ведём всю документацию в Google Docs, а баги в JIRA.
Почему мы открываем полный стек инструментария для работы с GCL?
Ну сами технологии Open Source, но без костылей-инструментов они вообще никому не сдались. А я знаю есть много прекрасных сайтов где бы данные решения помогли. Ну и вообще я просто хочу сделать интернет чуть-чуть лучше:)
Итак, что вам нужно что бы развернуть Closure Platform. Это тестовый проект и базовая точка для начала разработки и для показа возможностей GCL.
OS: Linux OS, на худой конец OS X (BSD). Всё семейство Windows(мне вас только жаль:) ) идёт побоку из-за отсутствия нормального shell.
Java 1.6 и выше, ant, bash/sh и питон.
Большинство скриптов написано на bash, часть на java.
Почему не питон? Потому что он мне не нравится:)
Итак начнём.
git clone github.com/DisDis/ClosurePlatform.git
cd ClosurePlatform
ant
Запускаем в браузере WebUI/index.html
Теперь более подробно.
Структура проекта CP:
В папке tools есть файл config.properties
Для чего он нужен:
$DIR — это папка скрипта, который использует данные настройки
Параметер DEFINITION_GSS отвечает за gss, в котором будут размещены определения.
THEMES_PATH — путь до папки с темами (не откомпилированные gss и soy)
THEME_LOCALES — список поддерживаемых локализаций
LOCALE_SOURCE — в какой локале написаны тексты в soy
WEB_THEMES_PATH — папка куда будут складываться откомпилированные gss и soy
SOURCE_MAP_ROOT — путь до исходников, его легко потом завернуть через nginx куда надо.
SOURCE_MAP_FULLPATH — ну а это полный путь до конкретных не сжатых файлов
MODULE_PATH — путь до модулей
Все остальные параметры не так важны.
Установите плагин для SOY. Мы используем плагин для Eclipse.
В SOY файлах отлично работает ZenConding.
Добавьте событие на изменение файлов и вызывайте по нему ant soy_update
Сначала делают локализацию.
Тут есть два пути, на начальной стадии можно просто воспользоваться пустым шаблоном empty.xlf.template, скопировав и переименовав в соответствующие локали. Например: en.xlf, только нужно поменять внутри параметр target-language на нужный.
Но когда вы будете готовы к тому что бы переводить тексты в soy, запустите create.translate.sh
Что делает данный инструмент — он сканирует все темы, в каждой тебе берёт все soy и делает из них xlf файл, далее он берёт старый файл xlf и переводы, для которых desc совпадает, переносит в новый файл, элементы, для которых не удалось найти совпадения по desc, заносятся в файл потерянных переводов .lost.xlf. Их надо либо руками перенести в нужное место, либо удалить, если переводы уже не нужны.
Да вот такой костыль. Если вы сможете предложить более простой метод, то мы с радостью упростим этот шаг. Он довольно редкий, так что тут есть место для оптимизации.
Под Mac OS, правда, этот пункт работать не будет:)
За поиск изменённых gss и soy и дальнейшую компиляцию этих файлов отвечает скрипт compile.templates.sh. Его вы будете запускать очень часто, ну или автоматически через IDE. Скрипт работает в двух режимах, отладка и релиз.
Что он делает? Сканирует все темы на предмет файлов, которые изменились относительно времени изменения файла .timestamp и добавляет их в список на компиляцию.
Для каждого файла gss создаётся аналогичный файл css, имена не сжимаются. Для soy аналогично.
Что бы запустить в релиз режиме надо просто указать параметр RELEASE при старте скрипта: compile.templates.sh RELEASE
В этом случае все(независимо изменялись они или нет) gss скомпилируются в один compact.css, все имена сжимаются. Все SOY компилируются в отдельные файлы с жатыми именами селекторов.
Как уже писалось, есть случаи, при которых нельзя чтобы некоторые свойства объекта сжимались, например, Client-Server взаимодействие. Вы можете поступить как гугл, но я не видел таких решений, чтобы кто-то другой поступал как гугл, ведь только у них есть полный стек для использования GCL.
В проекте-примере я генерирую map несжимаемых свойств из java файла который берётся из src/com/example/utils/Constants.java
За генерацию отвечает скрипт constantsToMap.sh, который берёт файл Constants.java и по нему создаёт файл property.in.map.
Проверяя при этом чтобы название констант совпадало с содержимым (items = «items»).
property.in.map это файл в котором
В нашем случае старое и новое значение одинаковое. В стандартной поставке GCC некорректно обрабатывает константы, есть баг в трекере и патч.
В тестовом проекте находится пропатченная версия GCC, я не знаю когда заплатку примут в основную ветку, но сообщество может ускорить это ;)
Вы можете сгенерировать этот файл откуда угодно, просто для примера приведено решение для java, формат данных простой.
Для взаимодействия с внешним кодом, например, jQuery или плагинами, которые не будут сжиматься, нужно прописывать Extern которые подключатся в разделе “сборка модулей”.
Хранятся все extern файл в папке tools/cl-externs
В примере есть tools/cl-externs/example.js для проекта, более подробно можно узнать из оф. документации GCC.
За это отвечает папка tools/gcmodule и приложение gcmodule.jar, его проще запускать через ant soy.create.modules
Перед запуском надо собрать все gss и soy в релизном режиме. Это можно сделать через ant soy.compile-RELEASE
Чтобы упростить задачу и сделать эти два действия одной командой
ant check.modules
В модули можно объединять несколько файлов или даже папок. Модуль может зависеть от других модулей и т.д. Лучше выделить общие части вашего сайта в отдельный модуль, а для всех страниц сделать отдельные модули. Почему следует поступит именно так, будет описано ниже.
Для конфигурации модулей есть файл config.cfg
Итак, почему это не скрипт, вначале я хотел написать его на bash, но это оказалось очень сложно, из-за сортировки массивов, поэтому java.
Суть работы программы — она берёт из config.cfg список папок и файлов, генерирует через гугловый инструмент дерево зависимостей, потом сортирует его по модулям и дальше отдаёт компилятору. Это сделано для обычного режима сжатия, в продвинутом режиме компилятор может сам построить зависимости, но для проектов, которые не сразу начинают с GCL, это будет нереально. Поэтому, для переходной фазы вашего проекта вы будете использовать обычное сжатие, а там нужно чётко скармливать файлы в нужной последовательности. О том, как переключить в обычный режим сжатия будет написано в ниже.
Тут надо заметить одну вещь — за один запуск можно сгенерировать только одну локаль для одной темы, к сожалению, побороть это непросто. Но можно запускать с различными параметрами и решить эту проблему.
Итак, в тестовом проекте после запуска сборки модулей в папке WebUI/js/module/ru/* будут валяться наши модули и сгенерированные и обработанные(если запускать через ant) source map для каждого файла.
На выходе так же будет файл property.out.map — это файл, содержащий карту переименований полей:
Итак, файл настройки представляет из себя обычный JSON объект.
Что из себя представляют настройки:
Так как я отвечаю за ту часть проекта, которая непосредственно видна пользователю, и с которой он вплотную работает, моя история и будет о ней).
Для начала, что бы читатель понимал о чём идёт речь, я хотел бы рассказать что у нас на «тёмной» стороне. А там Java, MySQL, Neo4J, Jetty, RabbitMQ и в конце этого длинного питона находиться nginx.
GCL
В конце 2010 года, мы, нашим «доблестным» отделом web-js, решили отказаться от старого шаблонизатора по ряду причин о которых ниже и перейти на что-то новое и действительно отвечающее реалиям нашего безумного проекта. Дело было в том, что в это время уже была реализована концепция виджетов и мест (place). Виджеты в нашем понимании — это некие независимые визуальные куски, которые общаются посредством каналов. По каналам можно передавать сообщения и подписываться на определённые типы сообщений. Виджет же, в свою очередь, не знает, где он находится в ДОМе — за это отвечают места (place). Большая проблема была в том, что виджет определял некие шаблоны, по которым он визуализировал данные. Мы можем использовать один и тот же виджет в разных местах, но выводить данные по-разному, следовательно, и пользователь мог взаимодействовать с данными по-разному. Но вернёмся к нашему древнему шаблонизатору. В то время все шаблоны подгружались и кешировались на клиенте в web-storage из-за чего была некая асинхронность в js коде — после создания виджета проходило какое-то время прежде чем можно было выводить данные. Мы хотели найти новое решение, которое бы убрало многие проблемы нашего шаблонизатора, например:
- не было циклов
- сложность локализации (в текстах нельзя было вставлять переменные)
- не было условий и ветвления.
Мы проанализировали существующие на тот момент решения и выбрали Google Closure Library(GCL)… Да, я еще тогда не знал что Google даёт технологию, но не даёт инструментов по её использованию :)
К тому моменту проект насчитывал:
- ~ 500 js файлов
- ~ 30 css файлов
- ~ 300 шаблонов.
Ответ кроется в комплексном подходе, предлагаемым Closure. Мы хотели, чтобы:
js код сжимался, оптимизировался в продвинутом режиме
- удаление “мёртвого” js кода
- css сжимались и валидировались
- шаблоны проверялись, сжимались и хранились на стороне клиента.
- лёгкий перевод ресурсов на разные языки
Все решения, которые были в сети на тот момент, давали что-то одно, гугл давал три связанных решения: Closure Compiler, Closure Template, Closure Stylesheets, которые работают как отдельно, так и вместе. И, когда они работают все вместе, то результат просто потрясающий!
Изменяем js код
Первое, с чего мы начали, — это проставили повсюду js зависимости… goog.require… Это было долго, заняло порядка 1 месяца. В результате, у нас упростилось подключение новых js файлов и логики — достаточно просто прописать зависимость и система автоматически подгрузит нужный код.
Гугл не даёт инструментария для использования своих технологий, но в самом гугле он есть, так как разработчики напрямую (через Г+) сообщили, что пишут в Эклипсе и у них полная поддержка Closure в нём.
Мы написали свой скрипт для Eclipse в виде Build Event, который при каждом сохранении js обновлял файл зависимостей deps.js для Closure. В то время практика была такая, что весь проект целиком (Tomcat, mysql, mq broker и т.д.) поднимался на машине у каждого разработчика, что отжирало 6гиг памяти и требовало около полутора-двух минут на старт всего проекта, так что мы тихо мигрировали на локальное проксирование js,css,img файлов через nginx, что значительно ускорило разработку. А то ждать пока эклипс пнёт томкат, чтобы тот начал обновлять файлы, было очень утомительно.
Переход с CSS на GSS
GSS чем-то похож на LESS, со своими особенностями.
Параллельно мы перешли с css на gss. Много проблем доставили всякие нестандартные атрибуты, а так в принципе достаточно просто переименовать css в gss. Единственное рекомендую сразу прошерстить свои css и внедрить mixin. Еще оставалась проблема с тем, что надо было как-то отслеживать какие файлы gss изменились и вызывать для них компилятор gss->css
Миграция на SOY
Что из себя представляют SOY. Это шаблоны, написаные на html похожем синтаксисе, и компилируемые в js код. Это решает важную проблему с кэшированием на стороне клиента всех шаблонов.
Одновременно со всеми этими нововведениями мы переводили старые шаблоны на SOY (Closure Templates). SOY оказался просто сказкой для программистов, так как мы смогли полностью отделить визуальную часть от логики и легко интегрировать ее в js код, потому как компилятор проставляет зависимости(goog.require). Так как в SOY есть пространство имён, то мы сразу продумали то, что у нас namespace будет отражаться в файловой системе в виде папок — как в java.
Большая проблема заключается во времени компиляции всех файлов — это слишком долго, на Core i7 3770K компиляция всех gss и soy занимает 20 секунд. Поэтому мы сделали скрипт который отслеживает изменённые gss и soy и компилирует только их — Гугл почему то не предоставляет такие инструменты в открытом доступе.
Обновление: В процессе написания статьи, была внедрена оптимизация и время компиляции(в режиме отладки) составляет сейчас 8-9 секунд.
Объединение
После решения этих проблем перед нами стояла последняя задача — заставить все эти три технологии работать вместе, чтобы ускорить работу сайта, ну и получить то, ради чего всё задумывалось.
Но тут выплыли некоторые нюансы: чтобы работало сжатие css селекторов нужно всюду в js использовать конструкцию goog.getCssName('display1') вместо прямого обращения 'display1'. То есть $element.addClasss('display1') нам нужно было заменить на конструкцию $element.addClasss(goog.getCssName('display1')). Кроме того, внутри goog.getCssName(...) нельзя использовать переменные и большое количество селекторов. То есть goog.getCssName('display'+value) не прокатит:), как не прокатит и goog.getCssName('display1 clearfix'). Это доставило много неудобств, из-за которых пришлось переписывать скрипты компиляции — чтобы они поддерживали возможность не сжимаемых css селекторов, так как весь старый код невозможно было сразу конвертнуть из вида «display-»+value во что-то нормальное. В самих SOY надо тоже по-особому выделять классы и идентификаторы которые будут сжиматься, {css display1} и т.д. На первом этапе у верстальщика был полный ад… Мы искали решение с подсветкой синтаксиса, в итоге мы нашли для Eclipse плагин который решил кучу проблем. (http://www.normalesup.org/~simonet/soft/ow/eclipse-closure-templates.en.html).
Что он умеет:
- Подсветка и проверка синтаксиса SOY
- Проверка на правильный вызов вложенных шаблонов. Пропущенные и лишние параметры
- Быстрая навигация по шаблонам, через клавишу Ctrl
В общем, этот плагин стал для верстальщика манной небесной. SOY — развязывает вам руки, но и повышает ответственность. Чуть позже мы написали свои плагины для soy компилятора чтобы добавить нужные нам методы, наподобие конвертации строки в число и округление. На этом злоключения с SOY только начались. Дальше мы перевели серверные шаблоны на новый шаблонизатор. Для этого пришлось писать снова свои классы для поддержки тем и переводов. Для автоматической конвертации старых шаблонов в новый вид мы написали конвертер…
С переводами SOY на разные языки отдельная песня, гугл говорит: «там всё отлично». Там всё и вправду отлично, если есть инструменты:), а так вы можете генерить из soy файлов xlf файлы или файл. И вот тут оказалось, что никак нельзя взять старые переведённые xlf и просто добавить туда те, что не переведены… Это просто кошмар! Есть какой-то ужасный набор утилит для работы с этим форматом, но там нет того, что надо, у каждой фразы есть свой id, но он генерируется так изощренно, что даже сам класс генератор в Google Closure называется Fingerprint… Снова мы писали инструменты, которые позволили решить эту проблему.
Так же нам пришлось вынести из всех jsp страниц js код в отдельные модули, так как надо было готовиться к сжатию…
Последний бастион
Так прошло еще 7 месяцев с начала нашего пути, у нас были все нужные инструменты, все нужные связи между тремя технологиями, но сжатие в продвинутом режиме не работало:) Снова возникли проблемы, связанные с тем, что jQuery и многие плагины некорректно собираются в продвинутом режиме, необходимо было писать и подключать externs. С jQuery и плагинами разобрались, теперь выяснилось что вызовы js в SOY тоже надо заменить на некие несжимаемые вызовы. Я понимаю, что GC не рекомендует использовать прямые вызовы в onclick, и это легко сделать, когда вы пишите проект с 0 на GC, но, когда у вас тонна старого кода, это совсем не так просто, поэтому мы создали файл export.js, в котором прописали прокси для внешних вызовов вот в таком виде:
global_export["showLoginDialog"] = function(event, elem) {
//... вызов окна логина.
};
Мы установили стандарт для всех таких экспортированных вызовов, вида function(event,this,...), то есть два первых параметра обязательно такие, а дальше какие угодно.
Решив эту проблему с экспортом (количество вызовов оказалось не более 20-30) оказалось, что всплыл еще один печальный факт с GCC(Google Closure Compiler). GCC сжимает в продвинутом режиме всё, что не «приколочено» кавычками ' или ", а, следовательно, вызовы внешних плагинов нужно было исправлять. Но самое большое разочарование заключалось в том, что клиент-серверное взаимодействие у нас работало на чётко документированном API, а после сжатия оно рушилось. Это снова откинуло нас на неопределённый срок…
Тут надо сделать отступление, сам Гугл передаёт не JSON-объекты, а массивы. Мы сначала думали, что это ProtoBuf — попробовали и оказалось, что нет, они просто ассоциируют каждый индекс массива с конкретным полем. Видимо, когда приходят данные с сервера, они их скармливают какому-то MessageFactory, который на основании мета-данных(тут возможны мета данные ProtoBuf для конкретного типа сообщений) связывает элементы с объектом. Если поступать как делает гугл, то, конечно, после сжатия и оптимизации никаких проблем нет и даже скорость повысится, так как с массивами работать быстрее).
Почему мы не поступили как гугл? Причина в том, что у нас много старого кода, который нам было необходимо поддерживать, но мы обязательно займёмся этой задачей, так как именно этот путь правильный.
Поиски решения привели к тому, что GCC мог отдавать карту преобразования имён, вида «старое поле объекта»:«новое название поля». Мы начали переделывать серверный код так, чтобы он мог поддерживать эту возможность, для этого был введён класс в общую для 5 сервисов библиотеку.
Вот такого вида:
public interface Constants {
public static final String typeId = "typeId";
public static final String user_id = "user_id";
public static final String items = "items";
....
}
Перед сборкой специальная утилита брала map, которую сгенерировала GCC, и правила этот класс. Но, когда мы уже думали, что всё готово, оказалось, что в силу некоторых причин некоторая часть исторических данных необходимых на клиентской стороне хранится в виде json в базе и пока нет возможности сделать по-человечески… Даже изменив название полей, в базе нереально всё изменить, а так как при каждом изменении js кода генерируется новый map, конвертировать нет шанса. Это было полное фиаско… И тут пришла идея сделать наоборот — ведь GCC не только может отдавать map, но и принимать map преобразования. Мы взяли класс Constants, сконвертировали в map, скормили его GCC, тот сжал весь код, но не тронул названия полей, связанные с Client-Server API. Всё было хорошо, пока не обнаружились странные ошибки, связанные с некоторыми полями. Например, поле «items» должно было остаться «items» в выходном файле, а оно переименовывалось в «items1». Сложность была в том, что определить зависимость было сложно, так как на простых примерах всё работало как часы. Пришлось брать исходники GCC и запускать их под отладкой, оказалось, что если в коде вы где-либо упоминаете название свойства в кавычках (" или ') "<property_name>", то компилятор переименовывает вашу переменную даже если в map было указано «items:items». Создав баг в трекере GCC и добавив однострочную заплатку в комментарии, мы пересобрали свой GCC и удачно сжали весь проект.
Source map
Дальше мы прикрутили source map для того, чтобы разобраться в этой куче сжатых и оптимизированных-непонятных a.b.Fs(… Для этого пришлось тоже написать свою утилиту, потому что GCC почему-то не умеет добавлять в конец сжатого модуля
//@ sourceMappingURL= ...
Итог
Что же мы получили в качестве результата:
В несжатом виде 1.6 МБ js код + 1.4 МБ шаблоны ~ 3.0 МБ
38 модулей в обычном режиме сжатия весят 2830 Кбайт в zip 445Кб
38 модулей в продвинутом режиме сжатия 1175 Кбайт в zip 266Кб
Сайт реально стал быстрее работать, пусть мы и потратили на это 12 месяцев. Параллельно мы решали задачи по работе и потихоньку шли к цели…
Вся эта история написана для того, чтобы вы могли себе представить стоят ли все эти телодвижения результата. Если бы мы начали проект сейчас на GC Library, у нас было бы меньше проблем, но если у вас уже есть тонна старого кода, то этот процесс может затянуться.
И заставьте верстальщика писать документацию по SOY, чтобы он вписывал туда примеры и типовые решения, это поможет ему быстрее адаптироваться и разобраться.(Со слов нашего верстальщика:) )
П.С.: Если кому интересно то мы ведём всю документацию в Google Docs, а баги в JIRA.
Инструментарий
Почему мы открываем полный стек инструментария для работы с GCL?
Ну сами технологии Open Source, но без костылей-инструментов они вообще никому не сдались. А я знаю есть много прекрасных сайтов где бы данные решения помогли. Ну и вообще я просто хочу сделать интернет чуть-чуть лучше:)
Итак, что вам нужно что бы развернуть Closure Platform. Это тестовый проект и базовая точка для начала разработки и для показа возможностей GCL.
OS: Linux OS, на худой конец OS X (BSD). Всё семейство Windows(мне вас только жаль:) ) идёт побоку из-за отсутствия нормального shell.
Java 1.6 и выше, ant, bash/sh и питон.
Большинство скриптов написано на bash, часть на java.
Почему не питон? Потому что он мне не нравится:)
Итак начнём.
Быстрый старт
git clone github.com/DisDis/ClosurePlatform.git
cd ClosurePlatform
ant
Запускаем в браузере WebUI/index.html
Структура проекта
Теперь более подробно.
Структура проекта CP:
- src — тут должны хранится java исходники, в примере только Constants.java
- themes — темы, там хранятся gss, soy и локали.
- gss — стили
- 0-definitions.gss — определения
- *.gss — стили
- allowed.cfg — разрешённые параметры
- allowed_prop.cfg — разрешённые свойства
- fixed.cfg — названия которые не сжимаются
- .timestamp — это временный файл который хранит время последней удачной компиляции gss
- locales — переводы в xlf
- *.xlf — переводы
- empty.xlf.template — шаблон для пустой локализации
- templates — шаблоны
- (namespace) — путь до шаблонов
- global.properties — глобальные константы шаблонов
- .timestamp — это временный файл, который хранит время последней удачной компиляции soy
- gss — стили
- tools — инструментарий
- WebUI — то, что пойдёт на web-сервере в качестве root (если вы java разработчик, то вам это знакомо)
- js — код
- themes — откомпилированные данные тем
- css
- js — откомпилированные шаблоны
- img, data — данные для темы, картинки и всё остальное.
- *.html — станички
- build.soy.xml — это задачи для анта что бы упростить запуск инструментария.
Настройка
В папке tools есть файл config.properties
Для чего он нужен:
TIMESTAMP_FNAME=".timestamp"
DEFINITION_GSS="0-definitions.gss"
THEMES_PATH=$DIR/../themes
THEME_LOCALES="en,ru"
LOCALE_SOURCE="en"
WEB_ROOT_PATH=$DIR/../WebUI
WEB_THEMES_PATH=$WEB_ROOT_PATH/themes
TOOL_LOCALE_PATH=$DIR/cl-templates/extractor
TOOL_MERGE_PATH=$DIR/merge-xlf
#SOURCE MAP config
SOURCE_MAP_ROOT=http://sourcemap.cp.com
SOURCE_MAP_FULLPATH=$SOURCE_MAP_ROOT/js/module/__THEME__/__LOCALE__/
MODULE_PATH=$WEB_ROOT_PATH/js/module
$DIR — это папка скрипта, который использует данные настройки
Параметер DEFINITION_GSS отвечает за gss, в котором будут размещены определения.
THEMES_PATH — путь до папки с темами (не откомпилированные gss и soy)
THEME_LOCALES — список поддерживаемых локализаций
LOCALE_SOURCE — в какой локале написаны тексты в soy
WEB_THEMES_PATH — папка куда будут складываться откомпилированные gss и soy
SOURCE_MAP_ROOT — путь до исходников, его легко потом завернуть через nginx куда надо.
SOURCE_MAP_FULLPATH — ну а это полный путь до конкретных не сжатых файлов
MODULE_PATH — путь до модулей
Все остальные параметры не так важны.
Eclipse или другая IDE
Установите плагин для SOY. Мы используем плагин для Eclipse.
В SOY файлах отлично работает ZenConding.
Добавьте событие на изменение файлов и вызывайте по нему ant soy_update
Локализация
Сначала делают локализацию.
Тут есть два пути, на начальной стадии можно просто воспользоваться пустым шаблоном empty.xlf.template, скопировав и переименовав в соответствующие локали. Например: en.xlf, только нужно поменять внутри параметр target-language на нужный.
Но когда вы будете готовы к тому что бы переводить тексты в soy, запустите create.translate.sh
Что делает данный инструмент — он сканирует все темы, в каждой тебе берёт все soy и делает из них xlf файл, далее он берёт старый файл xlf и переводы, для которых desc совпадает, переносит в новый файл, элементы, для которых не удалось найти совпадения по desc, заносятся в файл потерянных переводов .lost.xlf. Их надо либо руками перенести в нужное место, либо удалить, если переводы уже не нужны.
Да вот такой костыль. Если вы сможете предложить более простой метод, то мы с радостью упростим этот шаг. Он довольно редкий, так что тут есть место для оптимизации.
Под Mac OS, правда, этот пункт работать не будет:)
Компиляция GSS и SOY
За поиск изменённых gss и soy и дальнейшую компиляцию этих файлов отвечает скрипт compile.templates.sh. Его вы будете запускать очень часто, ну или автоматически через IDE. Скрипт работает в двух режимах, отладка и релиз.
Debug
Что он делает? Сканирует все темы на предмет файлов, которые изменились относительно времени изменения файла .timestamp и добавляет их в список на компиляцию.
Для каждого файла gss создаётся аналогичный файл css, имена не сжимаются. Для soy аналогично.
Release
Что бы запустить в релиз режиме надо просто указать параметр RELEASE при старте скрипта: compile.templates.sh RELEASE
В этом случае все(независимо изменялись они или нет) gss скомпилируются в один compact.css, все имена сжимаются. Все SOY компилируются в отдельные файлы с жатыми именами селекторов.
Константы
Как уже писалось, есть случаи, при которых нельзя чтобы некоторые свойства объекта сжимались, например, Client-Server взаимодействие. Вы можете поступить как гугл, но я не видел таких решений, чтобы кто-то другой поступал как гугл, ведь только у них есть полный стек для использования GCL.
В проекте-примере я генерирую map несжимаемых свойств из java файла который берётся из src/com/example/utils/Constants.java
За генерацию отвечает скрипт constantsToMap.sh, который берёт файл Constants.java и по нему создаёт файл property.in.map.
Проверяя при этом чтобы название констант совпадало с содержимым (items = «items»).
property.in.map это файл в котором
<старое значение>:<новое значение>
В нашем случае старое и новое значение одинаковое. В стандартной поставке GCC некорректно обрабатывает константы, есть баг в трекере и патч.
В тестовом проекте находится пропатченная версия GCC, я не знаю когда заплатку примут в основную ветку, но сообщество может ускорить это ;)
Вы можете сгенерировать этот файл откуда угодно, просто для примера приведено решение для java, формат данных простой.
Extern
Для взаимодействия с внешним кодом, например, jQuery или плагинами, которые не будут сжиматься, нужно прописывать Extern которые подключатся в разделе “сборка модулей”.
Хранятся все extern файл в папке tools/cl-externs
В примере есть tools/cl-externs/example.js для проекта, более подробно можно узнать из оф. документации GCC.
Сборка модулей
За это отвечает папка tools/gcmodule и приложение gcmodule.jar, его проще запускать через ant soy.create.modules
Перед запуском надо собрать все gss и soy в релизном режиме. Это можно сделать через ant soy.compile-RELEASE
Чтобы упростить задачу и сделать эти два действия одной командой
ant check.modules
В модули можно объединять несколько файлов или даже папок. Модуль может зависеть от других модулей и т.д. Лучше выделить общие части вашего сайта в отдельный модуль, а для всех страниц сделать отдельные модули. Почему следует поступит именно так, будет описано ниже.
Для конфигурации модулей есть файл config.cfg
Итак, почему это не скрипт, вначале я хотел написать его на bash, но это оказалось очень сложно, из-за сортировки массивов, поэтому java.
Суть работы программы — она берёт из config.cfg список папок и файлов, генерирует через гугловый инструмент дерево зависимостей, потом сортирует его по модулям и дальше отдаёт компилятору. Это сделано для обычного режима сжатия, в продвинутом режиме компилятор может сам построить зависимости, но для проектов, которые не сразу начинают с GCL, это будет нереально. Поэтому, для переходной фазы вашего проекта вы будете использовать обычное сжатие, а там нужно чётко скармливать файлы в нужной последовательности. О том, как переключить в обычный режим сжатия будет написано в ниже.
Тут надо заметить одну вещь — за один запуск можно сгенерировать только одну локаль для одной темы, к сожалению, побороть это непросто. Но можно запускать с различными параметрами и решить эту проблему.
Итак, в тестовом проекте после запуска сборки модулей в папке WebUI/js/module/ru/* будут валяться наши модули и сгенерированные и обработанные(если запускать через ant) source map для каждого файла.
На выходе так же будет файл property.out.map — это файл, содержащий карту переименований полей:
<оригинальное название поля>:<новое название>
config.cfg
Итак, файл настройки представляет из себя обычный JSON объект.
{
options:<настройки>,
modules:[<модуль>]
}
Что из себя представляют настройки:
{
defines:{
/*Раздел с параметрами, их можно переопределять через командную строку и использовать в путях и названиях*/
"LANG":"ru",/* язык компиляции */
"THEME":"default",/*Тема*/
"OPTIMIZATIONS": /* Режим оптимизации */
/*"SIMPLE_OPTIMIZATIONS"*/
"ADVANCED_OPTIMIZATIONS"
},
deps:{
/* Настройка построителя зависимостей */
params:" -o list",
workPath:"../../tools/closure/bin",
exec:"python ./calcdeps.py"
},
compiler:{
/* Параметры компиляции */
params:" 
Что нового в работе с исключениями в C++11
8 min
В интернете довольно много говорят о новых возможностях C++11: auto, lambda, variadic templates. Но как-то обошли стороной новые возможности работы с исключениями, которые предоставляет язык и стандартная библиотека.
От предыдущей версии стандарта остался механизм генерации исключений (throw), проверка того, что мы находимся в процессе обработки исключения (std::uncaught_exception), механизм остановки, если исключение не было обработано. Также есть иерархия стандартных исключений на базе класса std::exception.
Новый стандарт добавляет к этим вещам еще несколько сущностей, которые, на мой взгляд, могут существенно упростить работу с исключениями в C++.
От предыдущей версии стандарта остался механизм генерации исключений (throw), проверка того, что мы находимся в процессе обработки исключения (std::uncaught_exception), механизм остановки, если исключение не было обработано. Также есть иерархия стандартных исключений на базе класса std::exception.
Новый стандарт добавляет к этим вещам еще несколько сущностей, которые, на мой взгляд, могут существенно упростить работу с исключениями в C++.
О компонентах и интерфейсах. Java
3 min
Recovery Mode
Вступление
В предыдущей статье я написал о разных способах оформления интерфейсов к компонентам и сокрытия их реализации в C++.
В этой статье расскажу вкратце, как в Java отделить интерфейс от реализации, а реализацию скрыть.
Я не буду рассматривать компоненты разных там Java EE, я рассмотрю самые обычные jar-ники-библиотеки.
Итак.
Сервис поиска комплектующих для коптеров и не только
1 min
Собирая квадрокоптер столкнулся с проблемой: выбор комплектующих огромный, а вот поиск по ним никудышный.
В свободное от работы время потихоньку клепаю поисковик по комплектующим: www.rcdetails.info
Сейчас БД уже содержит информацию о товарах с hobbyking.com, goodluckbuy и towerhobbies:
В свободное от работы время потихоньку клепаю поисковик по комплектующим: www.rcdetails.info
Сейчас БД уже содержит информацию о товарах с hobbyking.com, goodluckbuy и towerhobbies:
- более 800 бесколлекторных моторов;
- более 300 ДВС;
- примерно 400 регуляторов для бесколлекторных моторов;
- более 1300 литиевых аккумуляторов;
- почти 800 сервоприводов;
- почти 1000 винтов;
Приемы написания скриптов в Bash
7 min
Администраторам Linux писать скрипты на Bash приходится регулярно. Ниже я привожу советы, как можно ускорить эту работу, а также повысить надежность скриптов.
Заведите свою библиотеку функций, например myfunc.sh и положите ее, например в /usr/bin. При написании скриптов она не только поможет сократить ваш труд, но и позволит одним махом доработать множество скриптов, если Вы улучшите какую-либо функцию.
Например, в свете совета 2 можно написать такую функцию:
Совет 1
Не пишите скриптов, которые выполняют действия ничего не спрашивая. Такие скрипты нужны довольно редко. А вот всевозможного «добра» для копирования, синхронизации, запуска чего-либо, хоть отбавляй. И если в любимом Midnight Commander Вы вдруг нажали не на тот скрипт, то с системой может произойти все что угодно. Это как правила дорожного движения — «написано кровью».Совет 2
Отталкиваясь от предыдущего, в начало каждого скрипта неплохо помещать что-то вроде:read -n 1 -p "Ты уверен, что хочешь запустить это (y/[a]): " AMSURE
[ "$AMSURE" = "y" ] || exit
echo "" 1>&2Совет 3
Это ключевой совет из всех. Для того, чтобы не писать каждый раз одно и то же — пользуйтесь библиотеками функций. Прочитав много статей по Bash, я вынужден констатировать, что этой теме уделяется мало внимания. Возможно в силу очевидности. Однако я считаю необходимым напомнить об этом. Итак.Заведите свою библиотеку функций, например myfunc.sh и положите ее, например в /usr/bin. При написании скриптов она не только поможет сократить ваш труд, но и позволит одним махом доработать множество скриптов, если Вы улучшите какую-либо функцию.
Например, в свете совета 2 можно написать такую функцию:
Steam под Linux: началось закрытое бета-тестирование
1 min
Сегодня первым счастливчикам в почтовые ящики упало приглашение в закрытое бета-тестирование клиента Steam под Linux, о чём было сообщено в официальном сообществе:«Первая волна инвайтов выслана!
Если вы прошли опрос*, но вам так и не пришло письмо, не отчаивайтесь. Мы расширим бету в будущем большим количеством участников опроса.
Спасибо за вашу поддержку, помогающую выпустить Steam под Linux,
Команда Valve Linux.»
(*опрос, проводимый недавно на сайте Valve, в котором желающие могли заполнить некоторую информацию о своём Linux-е и железе).
Realtime на вашем ресурсе за несколько минут
8 min
Во время разработки игры мы столкнулись с необходимостью обеспечения максимального риалтайм обмена данных между пользователями, что повлекло за собой эксперименты с различными comet библиотеками.
Первый велосипед был построен на dklab realplexor, который, при очередной попытке его использования, как и ожидалось, нас подвел. Может у нас руки кривые, но добиться получения ивентов без задержек в 5-10-15 секунд у нас, к сожалению, не получилось.
Танцы с бубном продолжались долго, в результате чего мы решили остановиться на nginx_http_push_module, и потраченное время все же стоило того.
Первый велосипед был построен на dklab realplexor, который, при очередной попытке его использования, как и ожидалось, нас подвел. Может у нас руки кривые, но добиться получения ивентов без задержек в 5-10-15 секунд у нас, к сожалению, не получилось.
Танцы с бубном продолжались долго, в результате чего мы решили остановиться на nginx_http_push_module, и потраченное время все же стоило того.
Flash Player 10.2 + vdpau + 64-bit
1 min
Как известно, актуальных версий Adobe Flash Player для 64-битных систем Linux пока не существует. Да, есть Square. Но он не обновляется, да и GPU-декодинга видео в нём нет. Приходится использовать 32-битную версию.
Вот только и с ней GPU-декодинг видео из коробки не заработает. Что делать?
Собственно говоря, для многих пользователей 64-битных систем это вряд ли станет откровением. Но для тех, кто не слишком над этим задумывался или, как и я, только перешёл с 32-битной системы на 64-битную: нужно просто установить 32-битную версию библиотеки libvdpau.
Как это сделать — уже тонкости. Можно вручную расковырять 32-битные пакеты с драйверами и сунуть нужный файлик в /usr/lib32. Многое зависит от дистрибутива. Для Ubuntu есть простой способ — воспользоваться утилитой getlibs:
Три команды — и флеш на youtube перестаёт тормозить и дропать кадры.
Заметка не претендует на оригинальность. После того, как возможность использования 32-битной библиотеки пришла мне в голову, я просто воспользовался гуглом, и нашёл решение здесь. Просто решил сообщить тем, кто ещё не знает (если они ещё есть).
Вот только и с ней GPU-декодинг видео из коробки не заработает. Что делать?
Собственно говоря, для многих пользователей 64-битных систем это вряд ли станет откровением. Но для тех, кто не слишком над этим задумывался или, как и я, только перешёл с 32-битной системы на 64-битную: нужно просто установить 32-битную версию библиотеки libvdpau.
Как это сделать — уже тонкости. Можно вручную расковырять 32-битные пакеты с драйверами и сунуть нужный файлик в /usr/lib32. Многое зависит от дистрибутива. Для Ubuntu есть простой способ — воспользоваться утилитой getlibs:
wget frozenfox.freehostia.com/cappy/getlibs-all.deb
sudo dpkg -i getlibs-all.deb
sudo getlibs -p libvdpau1Три команды — и флеш на youtube перестаёт тормозить и дропать кадры.
Заметка не претендует на оригинальность. После того, как возможность использования 32-битной библиотеки пришла мне в голову, я просто воспользовался гуглом, и нашёл решение здесь. Просто решил сообщить тем, кто ещё не знает (если они ещё есть).
Демон для удаленного управления компьтером через e-mail
5 min
Здравствуй, Хабр!
В данной статье я хотел бы поделиться опытом в создании демона для удаленного управления компьютером командами через электронную почту.
В данной статье я хотел бы поделиться опытом в создании демона для удаленного управления компьютером командами через электронную почту.
График «мастер-детали» средствами Highcharts и jQuery UI
4 min
При наличии большого количества статистических данных, например таких, как котировки валют (и прочие данные, связанные с финансовой тематикой), потребление чего-либо (воды и т.д.), вообще говоря, любых данных, которые так или иначе можно представить в виде пары «дата — значение», бывает удобно представить их в графическом виде. Так как данные могут быть собраны за достаточно большой период времени, имеет смысле представлять их в виде пары графиков: «мастер»-график, на котором будут отображены все точки, и график «детали», где будут отображены точки за требуемый период. В данной статье я постараюсь рассказать, как построить график подобного типа при помощи стандартных средств библиотек HighCharts и jQuery UI.
Приведенное ниже решение, в принципе, является велосипедом, т.к. с появлением нового продукта от разработчиков HighCharts, который получил название HighStock, необходимость в реализации подобным способом отпадает. Впрочем, HighStock пока еще в состоянии beta.
Приведенное ниже решение, в принципе, является велосипедом, т.к. с появлением нового продукта от разработчиков HighCharts, который получил название HighStock, необходимость в реализации подобным способом отпадает. Впрочем, HighStock пока еще в состоянии beta.
Разработка мультитач веб-приложений
6 min
Translation
Мобильные устройства такие как сматрфоны или планшеты обычно имеют емкостный экран, чувствительный к прикосновениям для расширенного взаимодействия с пользователем.
С каждым днем мобильные приложения становятся все сложнее и сложнее. Веб-разработчикам тоже нужен API для использования всех возможностей тачскрина. Например, какой-нибудь аркаде или файтингу нужна необходимость нажатья нескольких кнопок, эту возможность может предоставить экран с поддержкой мультитач.
Apple ввел свое touch events API в iOS 2.0, вскоре устройства на Android тоже получили такую возможность и touch events API стал стандартом де-факто. Недавно была собрана рабочая группа W3C для работы над touch events specification.
В этой статье я рассмотрю touch events API, которое нам предоставляют устройства на iOS и Android, мы изучим какие приложения можно создавать, используя touch events API. В статье куча полезных примеров и техник, которые позволяют упростить написание приложений с touch events API.
С каждым днем мобильные приложения становятся все сложнее и сложнее. Веб-разработчикам тоже нужен API для использования всех возможностей тачскрина. Например, какой-нибудь аркаде или файтингу нужна необходимость нажатья нескольких кнопок, эту возможность может предоставить экран с поддержкой мультитач.
Apple ввел свое touch events API в iOS 2.0, вскоре устройства на Android тоже получили такую возможность и touch events API стал стандартом де-факто. Недавно была собрана рабочая группа W3C для работы над touch events specification.
В этой статье я рассмотрю touch events API, которое нам предоставляют устройства на iOS и Android, мы изучим какие приложения можно создавать, используя touch events API. В статье куча полезных примеров и техник, которые позволяют упростить написание приложений с touch events API.
Команда dd и все, что с ней связано
4 min
В UNIX системах есть одна очень древняя команда, которая называется dd. Она предназначена для того, чтобы что-то куда-то копировать побайтово. На первый взгляд — ничего выдающегося, но если рассмотреть все возможности этого универсального инструмента, то можно выполнять довольно сложные операции без привлечения дополнительного ПО, например: выполнять резервную копию MBR, создавать дампы данных с различных накопителей, зеркалировать носители информации, восстанавливать из резервной копии данные на носители и многое другое, а, при совмещении возможностей dd и поддержке криптографических алгоритмов ядра Linux, можно даже создавать зашифрованные файлы, содержащие в себе целую файловую систему.
Опять же, в заметке я опишу самые часто используемые примеры использования команды, которые очень облегчают работу в UNIX системах.
Многопоточность в Java: ExecutorService
2 min
Translation
В Java 5 было добавлено много вещей для организации многопоточности и особенно касаемо организации параллельного доступа. В этой и последующих статьях мы пройдемся по некоторыми из них.
Двадцать вопросов, которые помогают разработать алгоритм
5 min
Как разработать алгоритм, решающий сложную задачу? Многие считают, что для этого нужно «испытать озарение», что процесс этот не вполне рационален и зависит от творческой силы или таланта.
На самом деле решение любой задачи сводится к сбору информации о наблюдаемом объекте. Причем этот принцип применим как для решения самых сложных научно-исследовательских задач, так и для решения прикладных задач. Работа изобретателя напоминает не столько работу волшебника, сколько путешествие первооткрывателя по неизведанной территории. Главное качество хорошего изобретателя – умение собирать информацию.
Если вы хотите решить сложную задачу, собирайте информацию в самых разных направлениях. Ответив на следующие 20 вопросов, вы легко выстроите план работы над задачей.
На самом деле решение любой задачи сводится к сбору информации о наблюдаемом объекте. Причем этот принцип применим как для решения самых сложных научно-исследовательских задач, так и для решения прикладных задач. Работа изобретателя напоминает не столько работу волшебника, сколько путешествие первооткрывателя по неизведанной территории. Главное качество хорошего изобретателя – умение собирать информацию.
Если вы хотите решить сложную задачу, собирайте информацию в самых разных направлениях. Ответив на следующие 20 вопросов, вы легко выстроите план работы над задачей.
Основы Linux от основателя Gentoo. Часть 3 (2/4): Модель прав доступа
10 min
Translation
Второй отрывок третьей части серии руководств Linux для новичков. В котором вы сможете узнать, об одном из основных средств обеспечения безопасности в Linux. А именно, правах доступа и модели владения файлами.
Пишем свой драйвер под Linux
8 min
Хочу признаться сразу, что я вас отчасти обманул, ибо драйвер, если верить википедии — это компьютерная программа, с помощью которой другая программа (обычно операционная система) получает доступ к аппаратному обеспечению некоторого устройства. А сегодня мы создадим некую заготовку для драйвера, т.к. на самом деле ни с каким железом мы работать не будем. Эту полезную функциональность вы сможете добавить сами, если пожелаете.
То, что мы сегодня создадим, корректнее будет назвать LKM (Linux Kernel Module или загрузочный модуль ядра). Стоит сказать, что драйвер – это одна из разновидностей LKM.
Писать модуль мы будем под ядра линейки 2.6. LKM для 2.6 отличается от 2.4. Я не буду останавливаться на различиях, ибо это не входит в рамки поста.
Мы создадим символьное устройство /dev/test, которое будет обрабатываться нашим модулем. Хочу сразу оговориться, что размещать символьное устройство не обязательно в каталоге /dev, просто это является частью «древнего магического ритуала».
Ноутбук + 2 видеокарты — как жить?
4 min
Последнее время у производителей появилась тенденция ставить на ноутбуки две видеокарты — одна какая-нибудь простенькая интеловская для экономии электроэнергии, а другая — навороченная для игр и видео. Насколько я знаю, таким точно грешит Lenovo, и под эту же тенденцию попал и я со своим HP TouchSmart tm2-1080er. Если на предустановленной Windows 7 Home x64 возможность переключаться между картами, разумеется, имелась, то Windows 7 Professional x32 вторую видеокарту включать уже не захотел. Не лучше обстояла ситуацию и в Ubuntu — видеокарты определяются-то обе, а вот использоваться предпочитает только дефолтная интеловская. И питание жрут, разумеется, обе — как результат, ноутбук работает намного меньше, чем должен. Как мы будем с этим бороться?
Git Wizardry
17 min
1 Введение
В своей прошлой заметке я постарался осветить в общих чертах стиль работы с
распределенной системой контроля версий git и указать на отличия по сравнению с
классическими централизованными СКВ. Целью было прежде всего обобщение опыта
работы с системой без упоминания тонкостей синтаксиса отдельных команд.
Данный же топик задумывался как непосредственное введение в работу с git, нечто
среднее между tutorial и обобщенной справкой, до которого все же рекомендуется
прочитать упомянутое выше введение. Сознательно избегаются технические
подробности работы git, употребляются только общие для СКВ термины и
ограничивается список упоминаемых команд.