Прошёл хакатон по Yii Framework в TACC

18 и 19 июня прошёл хакатон по PHP фреймворку Yii, состоявшийся благодаря ТАСС, конференции DevConf и лично Вадиму Крючкову. В мероприятии участвовало 18 разработчиков, которые поделились на команды и занимались сразу несколькими задачами. Помимо небольших качественных багфиксов, которые вместе с тестами практически сразу попали в master, были сделаны наработки и по довольно глобальным вопросам: очередям и обработчикам сокетов.

Наработки creocoder-а по расширению очередей очень помогли, но не совсем подходили для дальнейшего развития. Устроили мозговой штурм, на второй день завершили дизайн (возможно ещё будет небольшая смена именования в интерфейсах) и начали реализовывать конкретные драйверы. Два человека из рабочей группы получили права на запись в репозиторий yii2-queue и намерены довести дело до конца.

Идея сделать удобной работу с сокет-соединениями была навеяна очередным бумом чат-ботов для Telegram, Slack и других мессенджеров. Хорошо продвинулись как в техническом плане, так и в плане дизайна.

Довольно сложной задачей оказалась поддержка SELECT FOR UPDATE из за разницы в реализации под поддерживаемые фреймворком СУБД и отсутствием нормального способа сделать под это юнит-тесты (если кто знает, как это можно протестировать через phpunit, делитесь).

Новый сайт получил pull request, реализующий раздел расширений. Он уже попал в master с некоторыми доработками. Работает это через API packagist (команда Yii планировала реализовывать это намного более сложным и трудоёмким способов). Ещё один небольшой шаг к новому прекрасному сайту сделан.

Конечно, хакатон — это не только непрерывная работа, но и интересное общение. Очень приятно было снова увидеть старых знакомых, вживую пообщаться с теми, с кем общались ранее только перепиской и познакомиться с единомышленниками. Вкусная пицца, посиделки, сувениры, экскурсия от ТАСС и знакомство с кухней столь серьёзной организации сделали эти два дня действительно прекрасными.

Спасибо всем, кто участвовал и да здравствует OpenSource!

Let's block ads! (Why?)

HolyJS: с первой попытки

Петербургская JavaScript-конференция HolyJS начиналась почти как авантюра. Затевать совершенно новую конференцию, когда время на подготовку очень ограничено — смелое решение.

Такой авантюризм хорошо соответствует духу самого JavaScript-мира, где всё происходит стремительно, а смелые решения зачастую необходимы. Но возможно ли в таком случае провести конференцию на высоком уровне, с интересными докладами и без организационных проблем? Что в итоге было на мероприятии? Под катом — рассказ о том, как оно прошло.

Конференция была сделана совместными силами: организацией занималась JUG.ru Group, а программу готовили SPB Frontend. Логичное разделение труда: у первых — большой опыт организации других конференций, у вторых — знание JS-мира, позволяющее обеспечить должный уровень докладов.

Впрочем, в открывающем кейноуте от Дениса Мишунова (Digital Garden AS) знание тонкостей JavaScript не требовалось: речь пошла не о них, а о тонкостях человеческого восприятия. Гонясь за миллисекундами и килобайтами, легко позабыть, что на фронтэнде вся эта гонка изначально нужна ради пользователя. А то, насколько будет хорошо пользователю, зависит не только от миллисекунд.

В некоторых случаях может доходить до того, что «медленнее» будет означать «лучше»: например, когда у пользователя ощущение, что происходит что-то очень важное, и моментальное выполнение покажется ему «халтурой». А в других лучше будет «быстрее», но при этом пользователь будет ощущать самым быстрым не тот сервис, в пользу которого говорят бенчмарки.

Доклад заканчивался отсылкой к документации Apple для разработчиков, в которой напрямую сказано: «The perception of performance is just as effective as actual performance in many cases».

Мишунова на главной сцене сменил Виктор Русакович (GP Software.travel) с докладом о реактивном программировании, и всё сразу стало куда технологичнее. Описав состав RxJS как «объекты, операторы и магия», Русакович подробно прошёлся по второму пункту. Цель «расписать каждый оператор» не ставилась (их попросту слишком много), но конкретные примеры, проиллюстрированные «шариками» с сайта RxMarbles, позволяли получить хорошее общее представление.

Затем Дино Эспозито говорил о распознавании устройств и различном отображении сайтов на них. Он напоминал, что, с одной стороны, user agent string доверять нельзя («как-то мы тестировали дешёвый китайский планшет, так он выдавал себя за iPad»), но с другой, определять параметры устройства и полагаться на responsive web design тоже не панацея («главная проблема в том, что он одинаково обходится с компьютерным окном браузера шириной в 480 пикселов и со смартфоном, у которого ширина экрана 480 пикселов»).

Любопытно было наблюдать контраст с тем, как тот же Эспозито выступал двумя днями ранее на DotNext. В .NET-мире он крупный авторитет, и на соответствующей конференции блистал на главной сцене, как рок-звезда перед заворожёнными поклонниками. Здесь же был просто одним из докладчиков второго зала, и таким плотным потоком остроты не обрушивал. Впрочем, спутать его с кем-то другим все равно не получилось бы: такую харизму не спрячешь.

Его сменил Михаил Дружинин (Luxoft) с рассказом о порталах на JavaScript: «Бывает нужно разместить на одной странице несколько разных модулей. И если они не зависят друг от друга, то в этом случае ещё повезло...». Но пока Михаил разбирал, как в этом может помочь фреймворк F2, в третьем зале Алексей Симоненко с докладом «Как я перестал верить технологиям» (и завидной бородой) критиковал беготню за новыми фреймворками и прочими инструментами.

С бурным развитием JS-мира неудивительно, что в нём синдром серебряной пули особенно силён: тут чуть ли не каждый день что-то новое обещает исправить все ошибки предшественников и сделать ваш проект гораздо успешнее. Но статья «No Silver Bullet», в этом году отмечающая 30-летие, не стала с момента сочинения менее актуальной. Поэтому неудивительно и появление возражений «куда вы так несётесь, посмотрите на реальных примерах, как переход на что-то новое совершенно не избавлял от всех проблем».

Симоненко оригинально построил доклад, начав с прославления нового чудодейственного средства Hype.js и лишь затем признавшись, что его не существует. Позже он привёл классическую диаграмму The Hype Cycle, напоминающую, что для любой новой технологии характерен «пик завышенных ожиданий», обычно сменяющийся болезненным разочарованием. Поэтому, пока кто-то постоянно прыгает с одной технологии на другую, уже напрыгавшийся и набивший шишек спикер советовал «работайте с тем, что знаете».

В обеденном перерыве, как и накануне на Mobius, можно было услышать обсуждения задач от EPAM. Их набор частично отличался, но задача об инфицированной шахматной доске снова попала в список — и снова обращала на себя внимание. Помимо задач, стенд EPAM запомнился многим возможностью поиграть с развивающим конструктором Qubidoo, заставив шарик катиться по жёлобу. На сайте конструктора написано «от 3 лет до 140 IQ», и это ироничное определение похоже на правду: на HolyJS взрослые мужчины увлечённо возились с игрушкой, способной вызвать интерес у трёхлетнего.

А после обеда Василика Климова (Artec Group) рассказывала про WebGL. Для обычного фронтэндера без опыта работы с 3D-графикой тема может показаться далёкой и пугающей, но Василика объясняла, что бояться нечего: при использовании библиотеки Three.js всё оказывается куда проще, чем можно предположить. От общих слов и эффектных демо-роликов она перешла непосредственно к тому, как пишут шейдеры, и примеры оказались вполне доступными для зрителей без WebGL-опыта: ну да, чтобы превратить цветную модель в чёрно-белую, из трёх цветов по RGB стоит выводить среднее арифметическое, логично.

Помимо отмеченной многими содержательности доклада, он впечатлял ещё и в совсем другом отношении. Пока что на IT-конференциях нечасто можно увидеть, как обаятельная девушка объясняет мужчинам «зря вы боитесь, я разобралась, тут ничего страшного», и кому-то из зрителей такая картина могла рвать шаблон. Но судя по появлению мероприятий вроде Ladies Code, где среди прочих участвовала та же Василика, интерес женщин к IT растёт, и в будущем это может стать куда более привычной картиной.

Затем в том же зале Кирилл Сухомлин (EPAM Systems) говорил о том, откуда берутся новые JS-фичи, и это ярко показывало отличие JS-мира от других. На конференциях DotNext и Mobius не вставал вопрос, откуда берутся новые фичи в .NET или Swift — там сразу ясно, кто всему голова. А в случае с JavaScript о роли Ecma International задумываются куда меньше.

Зато в процессе его развития случаются такие же казусы, как и в других мирах. Как объяснял Кирилл, четвёртая версия ECMAScript была самой амбициозной, но в итоге оказалась заброшенной, и пятую, наоборот, можно было назвать «дуем на воду». Это заставляло вспомнить то, что Дино Эспозито на DotNext говорил о происходящем с (ASP).NET Core: Microsoft устроил революцию, но ещё не доведя её до релиза, испугался результатов и дал по тормозам.

Сам Эспозито тем временем нашёл себе на конференции интересное занятие. На HolyJS, кроме него, был только один англоязычный спикер, так что слушать весь день доклады Дино не мог. Но он обнаружил подходящего собеседника, принявшись болтать с ним и фотографировать его: это был «робот Федя», легко перешедший на английский. Сложно сказать, кто из этой пары выглядел колоритнее и остроумнее.

Закрывал конференцию кейноут от Вячеслава Егорова (Google), работавшего над движком V8. Получалась интересная симметрия с открывающим кейноутом: оба были о производительности, но первый о психологии и восприятии, а второй, наоборот, о технологическом хардкоре и внутренностях движков.

И даже в топ-10 докладов по отзывам зрителей эти два выступления оказались на соседних позициях, уступив только неверию в технологии:

1. Алексей Симоненко — Как я перестал верить технологиям
2. Вячеслав Егоров — Производительность JavaScript через подзорную трубу
3. Денис Мишунов — В погоне за производительностью: психология пользователя
4. Виктор Грищенко — Swarm: синхронизируем рой устройств
5. Николай Рыжиков — JаvaScriрt внутри PostgreSQL
6. Алексей Охрименко — Парсеры — это Спарта
7. Василика Климова — Практическое применение WebGL
8. Роман Дворнов — CSSO: оптимизируем CSS
9. Игорь Зотов — Iskra JS: JаvaScriрt в микроконтроллере
10. Михаил Новиков — Удобные API с GraphQL

Доклад Егорова перекликался с тем, что на Java-конференциях устраивает Алексей Шипилёв: глубокое знание «кишочков» сочеталось с задорным изложением, а суровые числа бенчмарков — с яркими иллюстрациями. Более того, даже в выборе иллюстраций у этих двух спикеров есть пересечения:

На этом выступлении, когда конференция было уже на финишной прямой, внезапно возникла проблема с техникой, и на некоторое время зал остался без слайдов. Как заметил Егоров, прямо перед докладом Алексей 23derevo Фёдоров сказал ему «Раз за всё мероприятие ещё не произошло ни одного технического факапа, значит, на твоём что-то произойдёт, готовься». Забавно было видеть, насколько точными оказались эти слова: фраза из анекдота «стена рухнула точно по графику» получала вполне буквальное воплощение.

Но затем техника ожила, и дело дошло до завершительного слайда «Спасибо». А в остальном конференция прошла удивительно беспроблемно для первого раза, и зрительские отзывы показали: если устраивать HolyJS и было авантюрой, то она явно удалась.

Let's block ads! (Why?)

Достучаться до госорганов или что делать, если в открытых данных кто-то не прав?

источник картинки: http://ift.tt/28SJcGX

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

Источниками открытых данных в основном являются госорганы, при взаимодействии с которыми есть, как минимум, одна большая проблема — 30 дней на ответ. Не все программисты обладают достаточным терпением, да и для представителей коммерческих компаний такое ожидание неприемлемо. Но, даже если вы дождались ответа, радоваться приходиться далеко не всегда — иногда вы получаете ответы не на все заданные вопросы, иногда вам предлагают обратиться в другие госорганы, что требует дополнительного ожидания. Попробуем систематизировать, какие еще есть способы «достучаться» до госорганов по вопросам, связанным с их открытыми данными.

Нулевой способ, доступный только для «избранных» — найти знакомого или знакомого знакомого в интересующем госоргане. Да, этот способ нельзя назвать официальным, но, к сожалению, он самый эффективный (могу предположить, что это связано с «менталитетом» или «традициями в госуправлении»). В некоторых случаях это единственный вариант относительно быстро получить интересующие данные или комментарии, поэтому нетворкинг и посещение мероприятий жизненно необходимы (как истинный интроверт пишу об этом с болью).

Первый и самый традиционный способ, — это официальные обращения. Чаще всего их можно отправить через электронную форму на сайте или на официальную электронную почту (хорошо, что не нужно пользоваться Почтой России или приносить обращения лично). Несомненный плюс этого способа — это регулирование законом 59-ФЗ, согласно которому ответить вам обязаны. Минусы — ответ придется подождать месяц. Образцы обращений по запросу информации можно посмотреть на сайте ИРСИ, но основные правила просты: будьте вежливы и конкретны, полезным будет сослаться на нормативно-правовую базу.

Пример 1. Обращение через электронную форму в Федеральное Казначейство. При использовании данных по госконтрактам аналитиками Инфокультуры было замечено, что в выборке по контрактам, где 'ИНН поставщика = ИНН Сбербанка' встречаются контракты с физ. лицами и компаниями, которые явно не относятся к Сбербанку. Не найдя объяснения этому явлению, был отправлен соответствующий запрос в Федеральное Казначейство, которое отвечает за данные портала ГосЗакупки. Ответ пришел через неделю (это очень быстро для госоргана), но он оказался бесполезным: обращение рассмотрено, персональную ответственность несет лицо, заполняющее документы от имени заказчика, в госзакупках реализован предупреждающий контроль. Что делать с ответственностью заказчика и почему предупреждающий контроль не работает осталось не ясным.

Ответ ФК

После беглого анализа данных выяснилось, что чаще всего неправильные данные указывают муниципальные организации (особенно детские сады), поэтому ошибки при заполнении документов можно списать на низкую ИТ-грамотность (имхо).

Пример 2. Обращение через электронную почту в Муниципалитет Санкт-Петербурга. Это мой любимый запрос, потому что в нем госорган сделал все ошибки, которые только можно было сделать, а все эксперты, посвященные в проблему, считали, что муниципалитет прав. Проблема была в том, что в бюджете Дворцового муниципального образования использовался один и тот же код для обозначения двух разных муниципальных программ (что недопустимо согласно Бюджетного кодекса). Для меня этот вопрос был принципиален, потому что при анализе бюджетов Санкт-Петербурга мы брали за аксиому уникальность сочетания «код муниципальной программы» — «наименование муниципальной программы» и наличие данной ошибки влияло на обработку данных. Первое электронное письмо в Дворцовый осталось без ответа. Перезвонила я им через четыре месяца, так и не получив ответа. Ответившая на звонок девушка перестала дышать, когда услышала, что молчат они 4 месяца (а 59-ФЗ никто не отменял). Она перевела меня на секретаря, тот на бухгалтера, а по версии «бухгалтера» на сайте «были ошибочные данные, в ее данных все в порядке и они опубликуют правильные файлы на сайте». Конечно же они ничего не опубликовали. И, после повторного звонка, заявили, что у них все в порядке и они отправят разъяснения по почте, потому что я не понимаю бюджетную классификацию.

Разъяснения Дворцового МО

Муниципальная программа (согласно Бюджетного Кодекса) кодируется 7 знаками. В ответе говорится, что у Дворцового МО она кодируется 11 знаками (включая код раздела и подраздела). Чтобы доказать наличие ошибки, потребовалось обратиться в Комитет финансов СПб, после пересылки ответа которого Дворцовый признал ошибку (дополнительно проконсультировавшись с Комитетом финансов СПб) и пообещал ее исправить в 2016 году. Попутно они согласились возобновить публикацию своего бюджета в XLS (считаю это дополнительным бонусом).

Интересно, что в Комитете финансов СПб мнения разделились и параллельно с официальным ответом, согласно которого коды повторяться не могут, я получила неофициальный, согласно которого коды повторятся могут.

Выводов два. Первый: в бюджетах муниципалитетов действительно много ошибок (и опечаток). Второй: есть трудности с правильным пониманием бюджетной классификации муниципальными органами.

Пример 3. Запрос данных о муниципальных бюджетах Ленобласти. На примере Санкт-Петербурга выяснилось, что бюджеты 100 муниципалитетов собирать по их официальным сайтам очень долго и утомительно. Появилось предположение, что их можно запросить у регионального комитета финансов. Предположение оказалось провальным: муниципальная власть не является третьим уровнем власти и не подчиняется региональной, поэтому муниципальные данные есть только у муниципалитетов (запрашивать их у регионов и Минфина бесполезно). Но мне показался необычным процесс коммуникаций с Ленинградской областью. Все обращения отправляются с сайта Ленобласти (а не напрямую с сайта интересующего госоргана) и попадают в «центр обращений», из которого их отправляют в нужные госорганы. Весь следующий день до меня дозванивалась представительница Ленобласти, которой для регистрации обращения требовалось узнать, в каком городе я живу (понятия не имею, зачем это нужно и почему этого вопроса не было в электронной форме), но после этого ответ был получен за 4 (!) дня.

На встрече Минфина с разработчиками, которая прошла 16 июня, выяснилось, что при наличии «проблем» с муниципалитетами обращаться нужно или в Генеральную прокуратуру (или писать письмо В.В. Путину). Предвкушаю, как и тот и другой адресаты будут рады получать кучу писем от Инфокультуры с такими важными в масштабах государства проблемами, как опечатки в муниципальных бюджетах :).

Второй способ коммуникаций — написать на почту, предназначенную для вопросов по открытым данным (например, opendata@minfin.ru у Минфина), администратору или технической поддержке сайта, оставить вопрос на специальном форуме (например, форум Казначейства на budget.gov.ru). В этом случае есть шанс, что ответ вы получите быстрее и ваш вопрос попадет напрямую к отвечающим за открытые данные людям, а при использовании форумов ответ будет доступен не только вам, но и всем заинтересованным. Правда, такие письма не всегда приравнены к официальным обращениям, и вероятность не получить никакого ответа все же есть.

Третий способ, набирающий особенную популярность в июне, — участие в хакатонах и конкурсах. один из хакатонов пройдет на этих выходных в Петербурге и будет посвящен финансовым данным, другой — в Москве в июле, ну а всем известный конкурс Минфина BudgetApps в представлении не нуждается. Госорганы не только начинают участвовать в подобных мероприятиях, но и сами их организовывают. А это значит, что вы не только можете получить прямой доступ к представителям госорганов на самом мероприятии (поверьте, отвертеться от неожиданных вопросов, заданных в живую намного сложнее, чем придумать отписку за месяц), но и получить дополнительный канал связи (форму для запросов или специальную почту). Ценность этого способ в том, что не только вам нужны госорганы, но и они нуждаются в вас — как минимум, отчетность и пиар никто не отменял, а в идеальном случае это сопровождается еще и искренней заинтересованностью госорганов в получении содержательного результата. И, даже если на мероприятии представители госорганов не присутствуют, вы всегда можете обратиться к менторам и экспертам, которые могут связать вас с ними или что-то подсказать.

Есть еще один, эксклюзивный, способ общения с Минфином — это встречи с разработчиками, которые проходят второй год (не уверена, что о них всегда можно узнать заранее, но будем считать, что это так). Одна из первых встреч прошла год назад, самая последняя — на прошлой неделе. И, по-моему, они начинают “работать” — докладов больше и они содержательнее, госорганы немного вникли в предметную область (открытые данные) и начинают понимать, о чем говорят, представители коммерческих компаний готовят содержательные доклады. Единственный минус — “информационное сообщение” Минфина об этих встречах пока страдает: встреча длилась два часа, докладов было много, ответы на вопросы звучали интересные, а информационное сообщение только о 20-минутном докладе Минфина (да еще и написано так, что даже заинтересованным в открытых данных читать скучно).

Если ни один из описанных способов не помог — не отчаивайтесь, обращайтесь не к первоисточнику, а к сообществу, экспертам и проектам. Например, обо всем, что относится к госконтрактам и госфинансам (да и в целом к открытым данным), вы можете спросить у нас ;-).

Let's block ads! (Why?)

Почему я отказался от 500 000 долларов, послал к черту инвесторов и закрыл свой стартап

Отчет с Moscow Data Science Meetup 27 мая

27 мая в офисе Mail.Ru Group прошёл очередной Moscow Data Science Meetup. На встрече собирались представители крупных российских компаний и научных организаций, а также энтузиасты в области машинного обучения, рекомендательных систем анализа социальных графов и смежных дисциплин. Гости делились друг с другом своим опытом решения практических задач анализа данных. Предлагаем вашему вниманию видеозаписи и презентации трёх докладов, представленных на встрече.

Дмитрий Носов, Rambler&Co, H2O на Spark: как мы пили газировку и чуть не захлебнулись

H2O — интересная и многообещающая платформа машинного обучения. Она может порадовать аналитика скоростью работы с большими объемами данных, набором алгоритмов, наличием API для нескольких языков программирования, и, конечно же, красивыми и подробными отчетами по построенным моделям. H2O написана на Java, поэтому работает везде^TM, в том числе на кластере Spark. В докладе спикер поделился своим опытом использования H2O на Spark и YARN, а также причинами отказа от использования H2O в production-окружении, несмотря на все ее положительные качества.

Видеозапись выступления: it.mail.ru/video/724

Павел Филонов, «Лаборатория Касперского», Глубокое обучение и извлечение признаков в прогнозировании временных рядов

Автоматическое выделение признаков, которые имеет место при построении глубоких сетей, видится перспективным инструментом, способным значительно сократить объём работ по подготовке данных. В докладе рассмотрена задача прогнозирования значений временного ряда и сравнены подходы к ее решениям как с использованием ручного выделения признаков, так и построенные на полностью автоматической обработке сырых данных.

Видеозапись выступления: it.mail.ru/video/723

Александр Дьяконов, ВМК МГУ, Решение задачи Search Results Relevance (на платформе Kaggle)

Разобрана задача по определению релевантности поисковой выдачи, которая решалась на прошлогоднем «Практическом семинаре по АД kaggle». Был описан очень простой алгоритм, который не использует сложных методов анализа текстов, словарей и ансамблей алгоритмов, и который, тем не менее, смог попасть в десятку сильнейших среди более чем 1300 участников.

Видеозапись выступления: it.mail.ru/video/722

Let's block ads! (Why?)

Виртуальная реальность в проектировании дата центров

В последнее время искусственная, или виртуальная, реальность (VR) все более распространяется в сфере потребительской электроники, а также в обрабатывающей промышленности, здравоохранении, образовании и т.д. Но в индустрии ЦОД данное направление практически не применяется, не взирая на то, что именно серверы отвечают за визуализацию контента, отображаемого большинством гарнитур виртуальной реальности.

ЦОД характеризуется несколькими показателями и коэффициентами, значения которых и являются объектом изменения при его оптимизации. Обладая информацией о значениях данных и показателей, возможно запланировать меры, которые помогут повысить энергоэффективность дата-центра. Но подобные действия достаточно трудоемкие и опасные, ведь ошибки могут привести к сбою в работе ЦОД и даже к потере данных. Для того, чтобы поменять расположение серверных стоек также понадобится немало сил и времени. Но с помощью виртуальной реальности все эти манипуляции можно оптимизировать и сделать более надежным. Достаточно составить виртуальную модель, которая позволит определить правильность воздушных потоков и измерить необходимые показатели. Таким образом получится провести все вычислительные процессы, мониторинг и проектирование в полной безопасности по отношению к работоспособности ЦОД.

У виртуальной реальности есть огромный потенциал — ее можно применять для проектирования и строительства серверных ферм. По мнению генерального директора колокейшн-провайдера Aegis Data Грега Маккалоха, именно дата-центры способны максимально эффективно использовать подобную технологию. И возможностей для этого предостаточно. В частности, VR особенно пригодится в проектировании и строительстве фактического помещения под ЦОД. Ведь с помощью виртуальной реальности получится визуализировать полезное внутреннее пространство и увидеть, как будет выглядеть само здание. Также и потенциальные клиенты смогут самостоятельно, удаленно «посещать» машзалы, в которых они собираются арендовать пространство. Это удобно, экономит время и деньги. Кроме того комплексное изучение визуализации модели ЦОД поможет принять более основательное решение в выборе площадки для хранения данных. И удаленные партнеры получат возможность просматривать систему физической безопасности дата-центра, включающую камеры видеонаблюдения, системы биометрической идентификации, тамбуры-шлюзы и многие другие элементы.

Несмотря на то, что рассматриваемая технология пока еще находится на ранней стадии своего развития, Маккалох уверен, что VR-гаджеты уже являются достаточно полезными и эффективными инструментами для удовлетворения потребностей индустрии ЦОД. Они успешно используются при проектировании коммерческих зданий, поэтому ничто не мешает адаптировать их и для проектирования дата-центров.

Ниже находится видеоролик от Google, который показывает использование виртуальной реальности для демонстрации ЦОД. Это — виртуальная экскурсия по дата-центру поискового гиганта в городе Даллас (штат Орегон, США).

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

Гаджеты виртуальной реальности могут стать весьма эффективными инструментами для продвижения коммерческих дата-центров, их проектирования и расширения инфраструктуры. Кроме того виртуальная реальность открывает новые возможности для обучения персонала серверных ферм или оптимизации взаимодействия между несколькими дата-центрами. Например, проведений совместных виртуальных конференций с участием операторов сразу нескольких ЦОД одной организации, расположенных в разных геолокациях.

Но одновременно с получением выгоды, операторам ЦОД нужно осознать, что рынок виртуальной реальности будет неустанно расти. И по прогнозам, на 2016 год число проданных VR-гаджетов достигнет 9,6 млн штук. Подобная тенденция востребованности аудиовизуального медиа-контента для гаджетов виртуальной реальности рано или поздно приведет к новым вызовам для владельцев дата-центров. Они будут вынуждены наращивать число систем хранения данных и серверов, должным образом расширяя вспомогательную инфраструктуру своих корпоративных или коммерческих серверных ферм.

Let's block ads! (Why?)

Security Week 25: уязвимости в Windows, libarchive и Wordpress, новые старые трюки криптолокеров

Поговорим о тренировке. Вместе с криптолокерами в наш уютный ландшафт угроз пришли казалось бы давно забытые трюки: от «албанского вируса» (набор для самостоятельной зашифровки данных) до макросов в офисных документах. По меркам тех угроз, про которые действительно интересно читать, это прошлый век и детский сад, но вот проблема — работают ведь. В случае макросов от пользователей требуется сделать пару лишних кликов, в процессе выводятся предупреждения (опасно!), но нет, все кликается, загружается и приводит к реальным убыткам и потере данных, хорошо если только на одном компьютере. По нашим данным, число криптоатак на пользователей за последние два года выросло в пять раз — и этот тот случай, когда количество рано или поздно переходит в качество.

Подавляющее большинство криптолокеров, а особенно такие трояны начального уровня, по-прежнему без проблем блокируются стандартным защитным софтом. Увы, это не исключает заражение полностью — и дело не в том, что стопроцентной защиты не бывает. Недавно я ссылался на пример, когда к неплохо защищенной инфраструктуре подключается внешний фрилансер с ноутбуком без антивируса и устраивает локальный армагеддон.

Недавно к арсеналу древних трюков добавился еще один. Вместо макросов в офисные документы внедряют ссылки на внешние объекты с помощью технологии OLE (новость, исследование Microsoft). В документе этот хитрый маневр выглядит примерно как на картинке. В одном из случаев использовалась довольно топорная социнженерия: «Нажмите, чтобы разблокировать этот контент и доказать, что вы не робот». В Ворде такая конструкция выглядит чрезвычайно подозрительно, но ведь работает. И что с этим делать?

Все выпуски дайджеста доступны по тегу.

В случае с обычными пользователями понятно что делать — антивирус надо ставить. В случае компаний все сложнее, выше я уже привел пример, почему не всегда получается заблокировать все и везде. Сотрудников надо обучать. Желательно, чтобы тренинги по тому, что мы называем security awareness, отличались от росписи в журнале за инструктаж на случай пожара. Обучение должно быть регулярным, цели его должны быть понятны всем — именно поэтому мои коллеги, отвечающие за тренинги, говорят, что надо обязательно включать в программу не только обычных сотрудников, но и начальство, вплоть до топ-менеджеров. С точки зрения технаря это решение возможно выглядит немного странным, ну а куда деваться? Одним из качественных изменений в индустрии ИБ является именно расширение понятия безопасности за пределы борьбы хорошего кода с плохим. Безопасность — это люди, их запрограммировать не получится, и гневным циркуляром проблему не решить. Но пробовать надо: не будучи алгоритмизируемым решением, тренинги дают вполне измеряемую эффективность.

Неделя патчей: Windows, Wordpress, libarchive

Обнаружение уязвимостей в софте и выпуск патчей — это такой регулярный элемент новостного фона по теме безопасности. Настолько привычный, что в список самых посещаемых такие новости выбиваются нечасто: в моем еженедельном сериале это происходит примерно раз в квартал. Вот и настал такой момент: на повестке дня сразу три важных патча.

В Microsoft залатали уязвимость в протоколе Web Proxy Auto Discovery (новость, бюллетень MS). И Microsoft, и первооткрыватель, исследователь из китайской компании Tencent, много деталей не раскрывают. В схеме работы протокола обнаружили возможность отката к уязвимому «процессу обнаружения прокси-сервера», конкретно эксплуатируется «предсказуемость идентификаторов транзакций при работе с Netbios». В списке подверженных — все версии Windows, начиная с 7, но по факту дыра присутствует даже в Windows 95, и, естественно, в неподдерживаемой более XP.

Возможно причиной малого количества деталей является универсальность атаки. По словам исследователя, эксплойт может прилететь и в виде URL в браузере, и в виде вредоносного офисного документа, и даже на флешке (например с помощью вредоносного шортката). Дальнейшее развитие атаки нельзя назвать простым делом, но в итоге появляется возможность перехвата трафика или подмены доверенных сетевых устройств.

Исследователи из Cisco нашли три уязвимости в опенсорсной библиотеке libarchive (новость, исследование). В случае с открытым софтом важнее даже не характер уязвимости, а понимание — кто подвержен. В этом может помочь список зависимого софта на сайте библиотеки. Все три уязвимости могут эксплуатироваться с помощью подготовленного архива определенного формата, конкретно подвержены 7-Zip и RAR. Кроме того, теоретически можно эксплуатировать уязвимость, когда библиотека работает с данными mtree, штатной утилиты в FreeBSD. Все три уязвимости позволяют выполнять произвольный код.

Наконец, очередной апдейт Wordpress до версии 4.5.3 закрывает 24 уязвимости (новость, анонс Wordpress). Большая часть уязвимостей позволяет получить контроль над веб-сайтом. Дополнительно были исправлены 17 багов — причем все относительно свежие, они были «добавлены» в последних трех релизах открытой CMS.

Что еще произошло:
Проект Let's Encrypt сообщает о выпуске пятимиллионного бесплатного сертификата HTTPS. Одновременно с этим выяснилось, что компания Comodo, продающая SSL за деньги, зачем-то пытается зарегистрировать на себя торговую марку Let's Encrypt в США. Фу таким быть.

Индийскую рекламную фирму inMobi, зарабатывающую в том числе на баннерах в мобильных приложениях, оштрафовали в США на почти миллион долларов за отслеживание пользователей без их ведома. Рекламная сеть этой компании предположительно «накрывает» больше миллиарда устройств.

Древности:
«Tired-1740»

Резидентный опасный вирус, стандартно записывается в COM-, EXE- и OVL-файлы при их загрузке в память для выполнения. Периодически расшифровывает и выводит на экран фразу: «I think you're too tired to the bone. You'd better go home», а затем перезагружает компьютер. Перехватывает int 21h.

Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 85.

Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

Let's block ads! (Why?)

[Перевод] Модуль PowerShell для Intel IoT Gateway

Шлюзы Intel для интернета вещей могут работать под управлением различных операционных систем. Одна из них – Windows 10 IoT. Сегодня мы поговорим о модуле для PowerShell IntelIoTGatewaySetup, который создан специально для поддержки IoT-шлюзов в среде Microsoft Windows.

Официально этот модуль называется «Intel IoT Gateway Module for Microsoft Windows PowerShell». Он помогает настроить операционную систему шлюза на заданный уровень безопасности (Security SKU).

Основные сведения

Модуль входит в состав пакета Windows Configuration Software for Intel IoT Gateway. Пакет можно найти по вышеприведённому названию и скачать в Центре загрузки Intel. В настоящее время поддерживаются операционные системы Windows 10 IoT Enterprise и Windows 10 IoT Core.

IntelIoTGatewaySetup позволяет настраивать следующие функции безопасности Windows, указанные в описании уровней безопасности. Предусмотрено три уровня безопасности. В частности, это, в порядке возрастания обеспечиваемого уровня защиты, Basic SKU, Medium SKU, и High SKU. Каждый следующий уровень расширяет возможности предыдущего. Итак, вот список настраиваемых функций.

• Windows Update, Windows Defender, Windows Firewall, Windows User Account Control, USB Removable Media Lockdown, Virtualization Based Security, App Locker, Code Integrity.
• BitLocker с поддержкой модуля TPM для Windows 10 IoT Enterprise. Хотя в определениях уровней безопасности упомянуто использование TPM и сетевой разблокировки (Network Unlock) для среднего и высокого уровней, модуль PowerShell настраивает лишь BitLocker с поддержкой TPM, так как Network Unlock требует дополнительной сетевой инфраструктуры.

Хотя модуль IntelIoTGatewaySetup и настраивает множество параметров в соответствии с заданным уровнем безопасности, он не касается следующих возможностей:

• UEFI, Secure Boot и TPM. Всё это является частью аппаратных требований и требований к микропрограммам для шлюзов Intel. Таким образом, эти функции на шлюзе будут уже включены.
• Уровни привилегий учётных записей. Можно создать, в зависимости от особенностей использования системы, учётную запись с ролью администратора или обычную учётную запись со стандартным набором прав.
• ASLR. Эта возможность по умолчанию поддерживается и включена в ОС Windows, таким образом, в дополнительной настройке она не нуждается.
• Measured Boot. Эта функция реализуется благодаря прошивке UEFI, TPM и Windows. Она так же не нуждается в дополнительной настройке.
• Remote Attestation. Эта функция нуждается в настройке дополнительной сетевой инфраструктуры и в дополнительном программном обеспечении.
• BitLocker + Network Unlock. Технология Network Unlock требует настройки дополнительной сетевой инфраструктуры и возможностей DHCP-драйвера в UEFI. В результате модуль PowerShell способен настроить лишь BitLocker с поддержкой TPM.
• USB Filter. Для настройки этой функции в соответствии с особенностями использования шлюза, применяйте групповые политики для того, чтобы управлять USB-устройствами, основываясь на Device ID или Class ID.
• Keyboard Filter. Для настройки этого фильтра воспользуйтесь инструментом Windows ICD.
  

В папке IntelIoTGatewaySetup находятся следующие основные компоненты:

• Readme.rtf. Обычный сопроводительный файл с инструкциями по началу работы.
• ModuleInstallation.ps1. Вспомогательный скрипт для установки модуля IntelIoTGatewaySetup.
• Папка IntelIoTGatewaySetup. Здесь содержится сам модуль.
  

Установка модуля

Если у вас имеется шлюз, оснащённый дисплеем и клавиатурой, команды PowerShell, необходимые для установки модуля, можно исполнять непосредственно на шлюзе. После установки команды PowerShell, которые предоставляет модуль, так же можно исполнять прямо на шлюзе. Мы называем это локальной установкой и локальным исполнением команд.

Шлюз может быть расположен вне пределов физической досягаемости, кроме того, у него могут отсутствовать монитор и устройства ввода. В таком случае нужно воспользоваться другим компьютером, назовём его компьютером разработчика, который позволит организовать удалённое управление шлюзом и его настройку. Ниже мы будем рассматривать именно такой сценарий. Мы называем его удалённой установкой и удалённым исполнением команд.

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

Итак, для удалённой установки модуля нужно выполнить следующие шаги.

Для начала – вот список операций, которые нужно произвести на шлюзе для того, чтобы обеспечить удалённый доступ к PowerShell.

• Если на шлюзе установлена Windows IoT Core, то всё уже готово к работе, ничего больше делать не нужно.
• Если же шлюз оснащён Windows IoT Enterprise, нужно разрешить удалённое взаимодействие с PowerShell, используя эту и эту инструкции. Например, для того, чтобы включить удалённый доступ к PowerShell, воспользуйтесь нижеприведёнными командами.

  #Получим индекс NIC активного NIC 
  Get-NetAdapter
  #$index – это полученный индекс.
  #Переключим целевое активное соединение в приватный режим.
  #В качестве разделителя в строке команды используется комбинация пробел + обратная галочка.
  Set-NetConnectionProfile -InterfaceIndex $index `
  -NetworkCategory Private
  #Включим удалённый доступ
  Enable-PSRemoting -Force
  

Теперь, когда шлюз готов к работе, займёмся компьютером, выполнив следующие шаги с использованием окружения PowerShell.

1. Убедитесь в том, что две следующих учётных записи, созданные на соответствующих устройствах, имеют административные полномочия. А именно:

• Учётная запись для компьютера разработчика, с которой осуществлён вход в систему.
• Учётная запись на шлюзе, которой мы воспользуемся позже.

2. Запустите интерпретатор командной строки PowerShell от имени администратора.

3. Для того, чтобы запустить скрипт ModuleInstallation.ps1 нужно, чтобы в PowerShell использовалась политика выполнения скриптов AllSigned или RemoteSigned. Взгляните на следующие командлеты: Get-ExecutionPolicy и Set-ExecutionPolicy. Они позволяют, соответственно, узнавать и задавать политику выполнения. Например, с помощью такой команды можно задать использование политики RemoteSigned.

Set-ExecutionPolicy RemoteSigned

4. Воспользуйтесь точечной нотацией при вызове скрипта ModuleInstallation.ps1. Для того, чтобы это сделать, введите символ точки «.» и пробел перед путём к запускаемому скрипту. Этот подход позволяет запустить скрипт в текущей области действия.

. .\ModuleInstallation.ps1

5. Затем взгляните на справку по модулю, о котором мы здесь говорим, ознакомьтесь с примерами его использования. Для этого воспользуйтесь такой командой Get-Help Install-IntelIoTGatewaySetup –Full

6. Выполните команду Install-IntelIoTGatewaySetup для установки модуля с компьютера разработчика на шлюз. Правила использования этой команды можно найти в справочных материалах из предыдущего шага. Например, можно воспользоваться следующей последовательностью действий:

#$path это путь к папке, в которой находится загруженный модуль,
# например: ‘C:\IntelIoTGatewaySetup’
#$remoteip это IP-адрес удалённого шлюза,
#например: ‘192.168.2.5’
#$remoteaccount это учётная запись на шлюзе,
#например, ‘Tester’ или ‘Domain\Tester’
#В качестве разделителя в строке команды используется комбинация пробел + обратная галочка.
Install-IntelIoTGatewaySetup –ModuleLocalPath $path `
-RemoteGateway $remoteip `
-RemoteAccount $remoteaccount –Verbose

Обратите внимание на то, что при локальной установке можно исполнить команду Install-IntelIoTGatewaySetup непосредственно на шлюзе. Для деинсталляции модуля предусмотрена команда Uninstall-IntelToTGatewaySetup. Подробности об этом можно найти в справочных материалах к модулю.

7. После установки воспользуйтесь PowerShell для выполнения команд нашего модуля на шлюзе. Об особенностях использования PowerShell на удалённых системах можно почитать здесь. Например, выполните, по порядку, нижеприведённые команды.

1. Запустите службу WInRM, если она ещё не запущена.

   if ((Get-Service WinRM).Status.ToString() -ne 'Running') {
   # Запуск службы WinRM 
   Write-Verbose "Start WinRM service."
   net start WinRM
   }
   

   
   
2. Добавьте удалённый шлюз в список TrustedHosts.

   #Эта команда удалит исходный TrustedHosts и приведет к использованию $remoteip.
   #Кроме того, она может добавить новое значение к списку TrustedHosts.
   #Справку можно вызвать командой Get-Help Set-Item.
   #$remoteip это IP-адрес удалённого шлюза.
   #В качестве разделителя в строке команды используется комбинация пробел + обратная галочка.
   Set-Item WSMan:\localhost\Client\TrustedHosts `
   -Value $remoteip –Force
   

   
   
3. Создайте удалённую сессию PowerShell на удалённом шлюзе.

   #$remoteip это IP-адрес удалённого шлюза. 
   #$remoteaccount это учётная запись с административными полномочиями
   #на удалённом шлюзе. 
   #В качестве разделителя в строке команды используется комбинация пробел + обратная галочка.
   $s = New-PSSession -ComputerName $remoteip ` 
   -Credential "localhost\$remoteaccount"
   

   
   
4. Выполните эти команды на удалённом шлюзе.

   #Запустите удалённый скрипт для тестирования
   Invoke-Command -Session $s -ScriptBlock {
   #В этом блоке можете запустить желаемые команды PowerShell. 
   #Эти команды будут запущены на удалённом шлюзе.
   
   #взглянем на сведения о нашем модуле 
   Get-Command -Module IntelIoTGatewaySetup 
   Get-Module IntelIoTGatewaySetup 
   }
   

   
   
5. Закройте удалённую сессию PowerShell после того, как выполните все необходимые команды.

   Remove-PSSession -Session $s
   

Использование модуля

Здесь мы, так же, как в предыдущем разделе, исходим из предположения, что для работы со шлюзом используется компьютер. Расскажем о том, как пользоваться модулем. Для начала, если вы этого ещё не сделали, включите использование удалённого PowerShell на шлюзе. Теперь, на компьютере разработчика, выполните следующие шаги.

• Воспользуйтесь той же процедурой, которая описана в п.7 предыдущего раздела. Все следующие примеры рассчитаны на то, что исполняемые на удалённом шлюзе команды будут помещены внутрь блока конструкции Invoke-Command.
• После установки модуля воспользуйтесь командой Get-Help с параметром –Full для того, чтобы узнать подробности о командах модуля. Например, выполните следующую команду для того, чтобы получить список всех команд, доступных в модуле:

  Get-Command -Module IntelIoTGatewaySetup
  

  
  
• Для настройки уровня безопасности служат команды Enable-IoTWinSecurities и Disable-IoTWinSecurities. Они, в свою очередь, вызывают другие команды модулей. Полезно будет взглянуть на справку по ним (Get-Help Enable-IoTWinSecurities –Full). Вот примеры работы с ними.
• Для того, чтобы включить базовый уровень безопасности («Basic» SKU) и задействовать приведённый в примере пароль восстановления BitLocker, выполните следующие команды.

  #$RecoveryPW это пароль восстановления для BitLocker,
  # который вы хотите использовать.
  #Например: $RecoveryPW =
  # '099825-222222-607607-626285-132319-115621-083204-229482'
  #В качестве разделителя в строке команды используется комбинация пробел + обратная галочка.
  Enable-IoTWinSecurities -SKU "Basic" `
  -BitLockerRecoveryPW $RecoveryPW `
  -AddPowerShellRemotingFirewallRule -ErrorLog –Verbose
  

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

Например, предупреждение может содержать рекомендацию о том, что сначала надо перезагрузить систему для того, чтобы завершить установку необходимых средств Windows, а потом снова выполнить команду установки.

Для того, чтобы отключить / удалить настройки уровня безопасности, выполните следующую команду:

Disable-IoTWinSecurities -ErrorLog -Verbose

Отдельные команды, используемые в Enable-IoTWinSecurities и Disable-IoTWinSecurities, можно применять и самостоятельно, для настройки отдельных функций безопасности.

Если TPM «не готов к использованию», его, сначала, нужно установить. В противном случае не получится включить BitLocker.

Если AppLocker настроен в соответствии с высоким уровнем безопасности («High» SKU), пользователи не смогут использовать PowerShell для добавления новых функций Windows. В соответствии с архитектурой системы, файл DISMHOST.EXE, который используется PowerShell, находится во временной папке, в директории, соответствующей учётной записи пользователя, а этот файл окажется заблокированным. В результате пользователи не смогут использовать наши команды для включения VBS, так как эта команда попытается установить необходимую ей функцию Windows. При выполнении команды Enable-IoTWinSecurities мы сначала выполняем установку VBS. Если нужно установить функции Windows, выполните перезагрузку системы для того, чтобы завершить их установку, а затем снова запустите команду.

Для функционирования системы User Mode Code Integrity нам нужно установить ключ реестра для того, чтобы разрешить размещению нашего модуля войти в режим Full Language Mode для Code Integrity Policy. В частности, рассматриваемый здесь модуль, по умолчанию, устанавливается по адресу %Program Files%\WindowsPowerShell\Module. Если это не так, соответствующий ключ реестра нужно настроить самостоятельно. Для этого нужно поместить путь, по которому установлен модуль (например, %Program Files%\WindowsPowerShell\Module) в запись типа REG_MULTI_SZ, которая называется «TestPath» и расположена в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\TRSData.

Итоги

Сегодня мы рассказали вам о новом средстве для настройки IoT-шлюзов Intel, которые работают под управлением Microsoft Windows. Рассмотренный здесь модуль для PowerShell, IntelIoTGatewaySetup, позволяет взаимодействовать со шлюзами как локально, так и удалённо, а собранные в нём команды помогают упростить и ускорить процедуры настройки шлюзов.

Let's block ads! (Why?)

[Из песочницы] Скелетная анимация в играх. Обзор техник и ресурсов

Anima — это душа, отличающая живое от мертвого. Аристотелевская душа — это принцип движения, проявляющегося в четырёх видах: перемещение, превращение, убывание и возрастание. Спустя почти две с половиной тысячи лет мы используем те же категории в компьютерной графике. Скелетная анимация определяет перемещение, морфинг служит для превращений, а убывание и возрастание это обычное масштабирование. Анимированная графика оживляет образ, вдыхает в картинку душу, и это, на мой взгляд, даже важнее, чем достоверная игра света и тени.

Создание качественных скелетных 3D анимаций сегодня, пожалуй, самая труднодоступная для инди разработчиков задача. Вероятно поэтому так мало инди игр в 3D, и так много проектов в стилях пиксель арта или примитивизма, а также бродилок без персонажей в кадре. Но теперь это соотношение может измениться…

Попробуйте сосчитать количество разнообразных анимаций в Uncharted 4. По моим оценкам там около часа уникальных движений, не считая лицевой анимации (850 выражений по словам авторов). Подобные игры задают фантастическую планку качества.

Примеры анимации Uncharted 4 (>40мб GIF)

Если физический рендеринг и создание качественно освещенных статичных сцен становятся доступны энтузиастам благодаря мощным бесплатным игровым движкам и инструментам 3D моделирования, то создание хорошей анимации требует оборудования для захвата движений и длительной кропотливой работы по их внедрению. Одна из самых доступных систем это костюм neuronmocap стоимостью порядка $1.5к без учета доставки.

Мне не удалось отыскать примеров создания хотя-бы близкой по уровню анимации при помощи ручного кадрового подхода или какой-либо процедурной анимации. Максимум что возможно сделать вручную, на мой взгляд, — это простые удары, быстрые движения и стилизованная мультяшная анимация. Но как сделать реалистичную ходьбу по лестнице, где очень много деталей, связанных с переносном центра тяжести и балансом тела? Невозможно их все воспроизвести вручную. Может быть я ошибаюсь, и кто-нибудь покажет работы специалистов такого уровня?..

Все это я вспоминаю для того, чтобы оценить по достоинству щедрый подарок от Mixamo. Он буквально открывает дверь на новый уровень для независимых разработчиков: компания Adobe купила Mixamo, и теперь 2.5 тысячи скелетных анимаций для персонажей они отдают совершенно бесплатно "for unlimited commercial or non commercial use":
www.mixamo.com

Еще пол года назад можно было их получить только выложив порядка $36 000 (ну или спиратив в сети). Помимо анимаций компания также предлагает бесплатную версию инструмента для ригинга и скининга персонажей, инструмент для создания множественных уровней детализации с минимальными потерями качества (LOD), генератор персонажей и плагин для захвата лицевой анимации.

Существуют и не менее проработанные наборы анимаций, доступные для приобретения энтузиастами. Но такой гигантский и качественный набор впервые оказался доступен совершенно бесплатно. Еще одним неплохим источником клипов остается база анимаций Университета Карнеги — Меллон и ее адаптированная под Unity версия, однако качество и содержание этой базы не так хороши.

Кроме ручной кадровой анимации и захвата движения актера, существуют и интересные процедурные методы симуляции движений: эволюционное моделирование, нейронные сети, task based locomotion. Что интересно, на конференции SIGGRAPH 2016 этим непростым техникам уделяют много внимания. Но широким кругам независимых разработчиков эти вещи пока не доступны, и мне самому хотелось бы больше узнать о возможности их реального применения. Однако сегодня есть и доступные инструменты, симулирующие мускульную динамику (Euphoria Engine и Puppet Master для Unity3d), которые позволяют привнести разнообразные реакции персонажей на обстоятельства.

Получить качественные и разнообразные анимационные клипы это только первая часть задачи.
Вторая часть заключается в том, чтобы корректно использовать полученные анимации при управлении персонажем. Для этого сначала нужно решить, как вообще сдвигать персонажа в сцене: на основании данных самой анимации (1), либо на основании каких-то иных соображений (например физики твердого тела) (2). То есть, либо анимация будет вычисляться исходя из произвольного (физического) движения объекта в пространстве (2), либо само смещение в пространстве будет исходить из записанной анимации, игнорируя иные вмешательства (1).

У обоих подходов есть достоинства и недостатки. В прежние времена, до массового использования захвата движений, вопрос об этом почти не стоял — персонажи двигались процедурно, на основании каких-то простых принципов, а анимационные клипы просто проигрывались для некоторого соответствия этому движению. Но чем лучше становилась анимация и графика в целом, тем заметнее становилось несоответствие движения ног и смещения персонажа, а также неестветсвенность динамики движения.

Одним из ярких примеров может быть игра Guild Wars 2 где анимация движений и графика уже достаточно хороши, но вот большой диапазон возможных скоростей и направлений движения персонажа не обеспечен столь же большим набором анимаций, и персонажи либо буксуют на месте, либо проскальзывают вперед как по льду. Та же проблема долгое время преследует и игры на движке Gamebryo (серия TES: Morrowind, Skyrim), да и многие другие.

Настоящее движение человека нелинейно — сначала мы наклоняемся вперед, затем выбрасываем ногу, и только потом начинаем движение, быстро ускоряясь после соприкосновения стопы с землей, и двигаемся по инерции до следующего шага. Подобрать функцию, точно описывающую подобное движение, сложно, и редко кто вообще об этом задумывается. Что уж говорить о более сложных движениях — стрейфе, переходах между направлениями, торможением и поворотами.

Поэтому для достижения реализма нам в любом случае потребуется гигантский набор разнообразных клипов с движениями в различных направлениях, с различной скоростью, и т.п… Кроме того, анимационные клипы редко можно использовать изолированно, воспроизводя один за другим. Чаще всего в игре присутствует множество анимаций, между которыми не заготовлено специальных анимированных переходов. Поэтому для их симуляции применяется плавное смешивание через линейную интерполяцию поворотов костей. Для удобной настройки таких переходов используется т.н. конечный автомат или машина состояний (State machine). В UE и Unity для этого есть специальные инструменты: Persona и Mecanim. Каждый узел там это некоторое состояние скелетной модели (заготовленный анимационный клип или результат их смешения — Blend Tree). Когда выполнены некоторые заданные условия, осуществляется плавный переход из одного состояния в другое, во время которого оба оказывают пропорциональное времени влияние на повороты костей и смещение объекта. Таким образом достигается иллюзия непрерывности движения.

Состояние может быть не одиночным клипом, а смешанным по тому же принципу набором клипов (Blend Tree / Blend Space). Например из клипов движений персонажа в стороны можно выбрать несколько, смешав их пропорционально вектору желаемого движения, и получить движение под любым произвольным углом. Однако существуют такие анимации, для которых смешивание оборачивается некорректными позами. Например когда одна анимация двигает ноги персонажа вперед, а другая вбок, линейное смешивание может привести к пересечению ног друг с другом. Чтобы этого избежать нужно тщательно подбирать анимационные клипы, синхронизировать их фазу, длину и скорость, либо добавлять отдельный клип специально для данного вида движений. Все это сложная и кропотливая работа. И чем больше возможных состояний и переходов между ними, тем сложнее привести их в согласие друг с другом, и проследить за тем, чтобы все нужные переходы срабатывали когда это требуется.

1) Самым очевидным решением является захват движений реального актера при помощи Motion Capture и привязка смещения персонажа в игре к смещению «корневой кости» в самой анимации — принцип Root Motion. Тогда персонаж будет двигаться ровно так, как двигался актер во время записи.

Выглядит очень реалистично. Более того, это единственный способ достоверно воспроизвести сложные маневры вроде выпадов, уворотов и паррирования атак холодным оружием.

Но этот подход несет в себе и очевидные проблемы.

Допустим, персонаж хочет подвинуться к краю обрыва: актер на записи наклоняется, поднимает ногу и делает смелый широкий шаг по сцене. А персонаж шагает прямо в пропасть… Чтобы этого избежать, нужно прервать шаг где-то посередине, но это не только выглядит неестественно, но и затрудняет игроку выбор нужного момента из-за нелинейности движения, в котором может быть долгая подготовка (наклон), а затем резкое уверенное движение (шаг). Можно записать несколько вариантов движений. Допустим: осторожные маленькие шаги, нормальные, и бег. А затем смешать их по параметру требуемой скорости, который можно увеличивать линейно и предсказуемо. Но что если нам нужны движения в стороны? Значит для каждого варианта ширины шага нам нужны еще три-четыре варианта (за вычетом зеркальных). А еще персонаж должен уметь поворачивать во время движения. Значит для каждого варианта нам нужны движения с поворотом. А если поворот может быть быстрым и медленным? Значит еще раз умножаем число необходимых клипов на два. А теперь нам нужно движение по наклонной поверхности! А потом нам захочется, чтобы персонаж умел делать тоже самое вприсяди. Итого — просто сотни и тысячи вариантов анимации которые нужно смешивать и следить за тем, чтобы это происходило корректно и приводило к движениям с нужной скоростью. И все равно, во многих случаях управление будет ощущаться как «ватное», поскольку инерция актера и наша невозможность предусмотреть все возможные человеческие маневры будет лишать игрока контроля над персонажем. Эту проблему, к слову, прочувствовали на себе игроки в The Witcher 3, поэтому в одном из крупных обновлений разработчики внедрили альтернативный вариант управления, где анимация быстрее отзывается на управление в ущерб реализму. В шутерах же проблема нелинейности движения обретает особенно выраженный характер: игроку часто приходится выглядывать из-за угла и быстро уходить обратно, и момент резкой смены направления может очень отличаться — игроку требуется как можно скорее вернуться обратно за укрытие, а у нас нет возможности предсказать заранее, какой ширины шаг он планировал и проиграть соответствующую анимацию. Игроку, в свою очередь, будет трудно привыкнуть к ширине шага, которую делает его персонаж, и к скорости этого шага, чтобы прервать его вовремя.

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

Поэтому техника Root Motion используется часто в одиночных играх от третьего лица, где управление осуществляется контекстуально — в зависимости от наличия укрытия, препятствия, режима движения или других обстоятельств, и редко применяется в сетевом режиме и MMOG.

Из последних заметных проектов, использующих Root Motion, можно выделить The Witcher 3. Трудно переоценить усилия, вложенные в производство всех его движений.

Пример анимации The Witcher 3 и ее съемки

2) Другое решение обратно принципу Root Motion — нужно приводить анимацию в наиболее точное соответствие с произошедшим или планируемым движением. Тогда многие описанные выше проблемы решаются — движение персонажа можно сделать равноускоренным и предсказуемым с возможностью сколь угодно быстрой смены направления. Но как привести нелинейную и инерционную анимацию в соответствие с таким движением? Интересный комплексный подход описали разработчики игры Paragon. Суть его заключается в том, чтобы находить и проигрывать только нужную серию кадров анимации для достижения требуемого смещения/поворота, пропуская лишние. И использовать инверсную кинематику для модификации ширины шага.

Первая очевидная трудность при приведении анимации в соответствие с движением, в том, что движение уже произошло, а анимация еще не проиграна. Поэтому очень пригодится система предсказания движения, вычисляющая положение персонажа для следующего кадра. Затем, зная смещение, которое должен осуществить персонаж за следующий кадр, нужно пропустить столько кадров анимационного клипа движения, сколько будет нужно чтобы достичь требуемого смещения, и проиграть тот кадр, на котором требуемое смещение достигнуто. В таком случае анимация станет воспроизводиться с измененной скоростью, так, чтобы точно соответствовать фактическому смещению, и эта скорость может быть быстрее или медленнее оригинальной, поскольку невозможно заставить реального актера поддерживать постоянное ускорение или скорость. Данный подход позволит сгладить анимацию и привести в соответствие с любой сложной процедурной моделью движения, меняющейся во время игры (персонаж может выпить какое-нибудь ускоряющее зелье или оказаться замедлен противником). Недостатком, разумеется, является то, что анимация может стать менее реалистичной из-за сильных изменений в скорости. Однако на практике это дает очень хорошее окно доступных вариаций в котором нарушения скорости незаметны. А вкупе с поправками ширины шага при помощи инверсной кинематики, покрывает еще больший диапазон.

Но, к сожалению, этот метод довольно сильно нарушает привычный подход к анимированию, и поэтому я не смог найти простого способа реализовать его, например, с использованием стандартного анимационного компонента Unity. В Unreal Engine также пока нет необходимого функционала, однако разработчики обещают когда-нибудь перенести низкоуровневые наработки, сделанные для Paragon, в общедоступную версию движка. Основной сложностью является поиск и воспроизведение нужного кадра на основании данных о фактическом смещении и повороте. Для этого авторы предлагают делать пре-процессинг анимационных клипов и генерировать для каждого из них дополнительный блок данных: Distance Curve, в котором будут покадрово сохранены значения смещения и поворота корневой кости относительно начала или конца анимации. Затем, в ходе выборки, можно производить быстрый бинарный поиск нужного кадра, где достигнуты соответствующие параметры смещения и поворота, и воспроизводить его.

Пока же можно ограничиться прежним подходом, и делать менее точную подгонку скорости анимации к скорости планируемого движения, ориентируясь только на скорость персонажа за последний кадр. Самое главное — неплохой набор душ для экспериментов теперь имеется!

Let's block ads! (Why?)

[Перевод] Язык Go, микросервисы и DevOps – хорошая компания?

Привет, Хабр!

Напоминаем, что все желающие по-прежнему могут приобрести отличную книгу Сэма Ньюмена "Создание микросервисов". Поскольку наши ожидания эта тема более чем оправдала, мы продолжаем искать связанную с ней литературу и не так давно обратили внимание на книгу о программировании микросервисов на языке Go

Интересную статью с обоснованием этого подхода мы нашли в блоге Agile Maverick, и ее перевод размещаем под катом.

Приятного чтения!

Сейчас все говорят о микросервисах и DevOps. Поставьте эти словечки себе в профиль – и вас сразу начнут осаждать рекрутеры. Я побывал в Мюнхене на нескольких интересных митапах по микросервисам, и меня наиболее удивило, что эта тема пользуется наибольшим интересом в сообществах Java и Scala. Удивило потому, что Java и Scala – очень насыщенные языки, в которых есть из чего выбирать.

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

Я понимаю микросервисную архитектуру в более целостном ключе. Я бы сказал, что и вся экосистема должна быть проще и компактнее. Реализация – лишь одна сторона медали. Другая сторона – это время исполнения и сопутствующие фреймворки. Здесь мы подходим к теме DevOps – философии, стремящейся увязать друг с другом две эти стороны.

Виртуальная машина Java оптимизирована для работы с долгоиграющими приложениями, в ней действует одна из наиболее выверенных и затейливых систем сборки мусора. Используется в боевых условиях уже более 10 лет. Тем не менее, когда мне доводится видеть современные высокодоступные архитектуры – сразу напрашивается вопрос: а нужны ли долгоиграющие приложения для реализации абсолютного большинства существующих сервисов?

Приведу пример. Я участвовал в разработке приложения для кодировки видео, и это приложение как назло должно было работать круглосуточно с минимальными задержками. Мы думали, остановиться ли на стабильном языке программирования вроде Java или написать приложение на Go, где использовались бы имеющиеся библиотеки на C для кодирования и декодирования, однако такой проект мог обернуться утечками в памяти. Наконец, мы решили разделить приложение на различные процессы; статический бэкенд почти не изменился, поскольку передавал информацию по практически не изменившемуся протоколу, а еще у нас была функционально богатая клиентская часть, где существовал риск утечек. Обе части использовали разделяемую память. Оказалось, что вариант хороший. Поскольку Go стартует быстро, мы перезапускали клиентскую часть раз в десять секунд. Оказалось, что проблема – не в утечках памяти, а в оперативных обновлениях.

За много лет в Java сложилось много нетривиальных решений – например, фреймворк log4j для логирования. На примере контейнерных решений вроде OpenShift можно убедиться, что теперь снова принято работать с stdout и stderr. Нет необходимости внедрять изощренные решения для логирования на уровне языка. Этот пример позволяет судить, как DevOps и новые среды времени выполнения меняют правила игры.

Типичный docker-образ на Go docker имеет размер около 15 MB; сравните его с образом для JVM на Java, размер которого — около 300 MB. Разница 1 к 10. Java JVM оптимизирована под экономный расход памяти, но все равно требует примерно в 10 раз больше памяти, чем Go.

В Go не так много унаследованных фреймворков, поэтому и зависимостей обычно мало, а код зависимостей входит в состав бинарного файла. Поэтому отпадает необходимость в таких сложных инструментах как Maven. В контейнерной среде релиз нового образа необходим всякий раз, когда меняется одна из зависимостей в цепочке. А значит, на Java Java мы должны обновлять такие контейнеры достаточно часто. Хуже того, зависимости обычно запрятаны где-то глубоко.

Java и Scala – это языки для объектно-ориентированного программирования. Но при работе в сравнительно простых предметных областях такие решения кажутся мне довольно затратными. «Гибкий» аспект философии Go позволяет организовать разработку не только не хуже, но и гораздо понятнее.

Java известен своим огромным конвейером и множеством инструментов для непрерывной интеграции вроде Jenkins, которые развились вокруг этого конвейера. В Go конвейеры получаются гораздо короче, проще и быстрее – ведь мы получаем бинарные файлы, уже готовые к исполнению.

В 1990-е был настоящий бум серверов приложений Java – считалось, что они обеспечат независимость разработки от операционной системы и аппаратного обеспечения. Читая спецификацию JEE, мы также рассчитывали на простоту удаленных взаимодействий и компонент-ориентированную разработку. Когда я вижу контейнер docker, на котором работают Java-приложения, всегда вспоминаю о новой версии EJB. В принципе, стек Java не упростился, но теперь он упакован в контейнер. Такая упаковка даром не дается, поскольку добавляется еще один уровень сложности; вы с ним познакомитесь, как только попробуете отладить сеть такого docker-контейнера.

Go docker – вариант для масштабирования сервисов, но сложную среду времени исполнения он не спасает. Если у вас всего один простой сервис, то простые бинарные файлы Go можно выполнять прямо на хосте. Если же речь идет о более сложном приложении, то сервисы можно положить, например, в контейнер и запускать их в PaaS-среде вроде OpenShift. Чтобы протестировать сервис на ноутбуке разработчика, контейнер не нужен, всяческая связанная с ним магия – тоже.

Go прост, и обучаешься ему достаточно быстро. Основные концепции Go усваиваются всего за неделю-две. Поэтому новые коллеги могут с успехом изучить реализации сервисов, а разработчики или операторы могут быстрее фиксить баги, не отвлекаясь при этом от основной работы, даже если не они реализовывали эти сервисы. Автономные команды – дело хорошее, но если у вас всего трое коллег, то обеспечить круглосуточную доступность становится реально сложно.

Go, где вариантов не так много, помогает быстрее освоиться с решением тем разработчикам, которые сами его не писали. Не требуется углубляться в философию разработки. Разумеется, всегда можно реализовывать сервисы и в более простом стиле на более насыщенных языках, например, на Java или Scala, но в данном случае нужно научиться самоограничению, обсуждать все детали с командой – соответственно, микросервисная архитектура обрастает огромной документацией.

Мне кажется, Go идеально подходит для реализации микросервисов. Почему же этот язык так медленно усваивается в сообществе разработчиков?

Думаю, просто никто не любит резких изменений. Мы попробовали изменить всего одно измерение в многомерном мире программирования. Это измерение – размер сервиса. По моему опыту, изменить одно измерение еще недостаточно, чтобы пошла эволюция. Поскольку все измерения взаимосвязаны, они влияют друг на друга. Решив упростить приложение, переделав его в виде микросервисов, мы должны также упростить и исполняющую среду, и язык программирования, с которым работаем. Иначе получим лишь новую головную боль – например, придется управлять сразу множеством JVM, которые занимают кучу места в памяти и запускаются довольно медленно. Либо получим множество мелких объектно-ориентированных решений, которые будут распределенными, а значит – более сложными. Наконец, мы просто запутаемся со множеством сервисов, образующих огромное дерево зависимостей.

По-моему, не меняя всех измерений сразу, мы словно пересаживаемся с лошади на машину, но берем с собой седло и шпоры.

Давайте не просто писать микросервисы, но и адаптировать под них всю архитектуру. Go отлично для этого подходит. Если предметная область сервиса расширится, вы всегда сможете дополнительно воспользоваться Java или Scala.

Let's block ads! (Why?)

[Перевод] Типографика в дизайне электронных писем

В разработке дизайна для email-рассылок многие специалисты недостаточно много внимания уделяют типографике. Тем не менее, даже несмотря на некоторую ограниченность электронной почты как среды для дизайнерских решений, работа с типографикой может сделать письма значительно лучше.

Сегодня мы представляем вашему вниманию адаптированный перевод исследования Анны Иман (Anna Yeaman), соосновательницы и директора американского агентства, которое было изначально опубликовано на страницах авторитетного ресурса SmashingMagazine.

В прошлом году я прочитала пост Яна Константина (Jan Constantin) «Тенденции и современные методы типографского дизайна» и тут же решила провести похожую работу, но применительно к почтовой рассылке. В то время я изучала адаптивную веб-типографику. Я выделила группу сайтов, которые мне понравились, и попыталась разобраться, в чем секрет их типографики, чтобы потом применить новые знания к разработке дизайна email-рассылки.

После того, как я познакомилась с работой Константина, мне захотелось понять, как другие дизайнеры email-рассылок использовали адаптивную типографику. В итоге я собрала 50 примеров почтовой рассылки из разных сфер, в которых, на мой взгляд, подобрана качественная типографика, и решила проверить, есть ли у них что-то общее. Исходные данные и результаты этой работы вы можете посмотреть в Google-таблице.

Методология

Учитывая тот факт, что около 50% всех электронных писем открывается с мобильных устройств, все письма, выбранные для исследования, были адаптивными, состояли из одной колонки основного текста и заголовка. Я собрала статистику по трем типам устройств в зависимости от ширины экрана: большим (ПК), средним (450 пикселей) и маленьким (320 пикселей).

Google-таблица с полным обзором по каждому письму

Я знала, что выборка из 50 писем вряд ли окажется статистически значимой. Я лишь хотела выявить ряд общих тенденций. Средним значением в статье я обозначаю математическое ожидание. Самым популярным значением – то, которое встречается чаще всего. Также в нескольких случаях я использую понятие медианного значения. Все письма, исследованные в работе, рассылались в период с ноября 2014 года по январь 2015 года. В работе я пользовалась такими инструментами, как WhatFont, Charcounter и WebPagetest.

Как письмо отображается на трех типах устройств в приложении WhatFont

Что мне было интересно

Я отвечала почти на те же вопросы, что и Константин, за рядом исключений. В общей сложности было сделано около 90 выводов, и в этом посте рассмотрены лишь основные:

• Насколько популярны гарнитуры с засечками и без засечек в заголовках и в теле письма?
• Какие гарнитуры используются чаще всего?
• Какой размер шрифта чаще всего встречается в теле письма, и меняется ли эта частота при переходе с ПК на мобильное устройство?
• Каково среднее число символов в строке для каждого типа экрана?
• Какова самая популярная ширина строки в письме на ПК?
• Каково среднее отношение высоты строки в теле письма к размеру шрифта?
• Каково среднее отношение между высотой и длиной строки в теле письма?
• Используется ли в заголовке и в теле письма один и тот же цвет?
• Какие цвета чаще всего используют для фона?
• Как выравнивается текст в заголовке и в теле письма в зависимости от типа экрана?
• Какой размер шрифта чаще используется в заголовках?
• Прикрепляют ли ссылки к заголовкам?
• Каковы размер и цвет текста подзаголовка письма и отображается ли этот текст на мобильных устройствах?
• Как долго в среднем загружается письмо?
• Как много весят веб-шрифты по сравнению с картинками?

Шрифты с засечками и без засечек

• 74% шрифтов, которые использовались в заголовках, были без засечек;
• 64% шрифтов, которые использовались в теле письма, были без засечек;
• Самые популярные шрифты без засечек в заголовках – Helvetica (16%) и Arial (14%);
• Самые популярные шрифты с засечками в заголовках – Georgia (14%) и Merriweather (4%);
• Самые популярные шрифты без засечек в теле письма – Helvetica или Neue Helvetica (20%), Arial (10%);
• Самые популярные шрифты с засечками в теле письма – Georgia (24%), Merriweather и Times (по 4% каждый);
• Шрифты с засечками на 10% чаще использовались в теле письма, чем в заголовках;
• В теле письма встречались всего 5 различных шрифтов с засечками и 15 различных шрифтов без засечек;
• В заголовках встречались 24 разных типа шрифтов, из которых 16 встречались по одному разу;
• В теле письма встречались 20 разных типов шрифтов, из которых 11 встречались по одному разу;
• Times New Roman оказался непопулярен: его не использовали ни в одном из заголовков.

Helvetica стала самым популярным шрифтом в заголовках и использовалась в 16% случаев, как, например, в рассылках Offscreen и TGD. Georgia чаще всего использовалась в теле письма (24%), как, например, в рассылках Mr Porter и New York Times. Набирают популярность две гарнитуры из набора Google Fonts – Merriweather и Open Sans, которые можно увидеть в рассылке iOS Dev Weekly и InVision.

Самые популярные гарнитуры в заголовках и в теле письма

Константин отмечает, что шрифты с засечками стали использоваться намного чаще в основных текстах веб-сайтов (61,5%). Наше исследование показало, что для писем этот показатель составляет 36%. Возможно, в своей работе он больше изучал новостные сайты, в которых чаще встречаются шрифты с засечками. Кроме того, в рассылке редко встречается много текста, так как основной контент обычно располагается на посадочной странице. Интересным примером является сайт Крейга Мода (Craig Mod), который использует шрифт с засечками Lora из Google Fonts как в заголовках, так и в теле письма. Чаще всего шрифты с засечками и без засечек используются вместе: примером может служить классическая комбинация Helvetica-Georgia в рассылке MailChimp.

В 36% случаев в теле письма используются шрифты с засечками, в 64% – шрифты без засечек

Для выбора гарнитуры рекомендую прочитать пособие «Комбинируем гарнитуры» и статью «Классные комбинации шрифтов». Помимо этого, Пол Эйри (Paul Airy) пишет о том, как комбинировать шрифты в email-рассылке. И если вы думали, что в письмах не встречаются веб-шрифты, то вы ошибаетесь.

Тело письма

На сайте Butterick’s Practical Topography пишут: «В любом проекте первым делом надо красиво оформить основной текст и только потом беспокоиться об остальном». Во многих статьях по типографике также говорят, что начинать нужно всегда с оформления основного текста. Самое главное – соблюдать пропорции между размером шрифта, форматом или длиной строки и высотой строки, учитывая при этом еще и ширину экрана устройства.

Размер шрифта

• Самый популярный (44%) размер шрифта на ПК – 16 пикселей;
• Медианный размер шрифта на ПК – также 16 пикселей (среднее значение – 15,7 пикселей);
• В теле письма, открывающегося с ПК, размер шрифта менялся от 13 до 20 пикселей;
• Самый популярный (38%) размер шрифта на мобильных устройствах – 16 пикселей;
• Медианный размер шрифта на мобильных устройствах – также 16 пикселей (среднее значение – 15,58 пикселей);
• В теле письма, открывающегося с мобильного устройства, размер шрифта менялся от 13 до 20 пикселей;
• В 72% случаев при переходе с ПК на мобильное устройство размер шрифта не менялся;
• В оставшихся 28% случаев при переходе с ПК на мобильное устройство текст чаще уменьшался (64%), чем увеличивался (36%).

Ключевым фактором в выборе размера шрифта является расстояние [от читателя] до экрана устройства. Экран ПК располагается на расстоянии вытянутой руки, поэтому 20-пиксельный текст письма от Robocat, набранный шрифтом Helvetica (на фото справа), читать проще, чем рассылку Patagonia с 14-пиксельным Muli (на фото слева). iA пишет, что в своем приложении Writer при чтении на iPad компания использует более крупный шрифт, чем на iPhone, потому что iPad мы держим чуть дальше от себя.

На расстоянии текст размером 20 пикселей (справа) воспринимается легче, чем текст размером в 14 пикселей (слева)

Формат строки

Еще один фактор, о котором нельзя забывать при учете пропорций шрифта – это формат строки, то есть ширина тела письма. Формат строки измеряется либо в пикселях, либо в количестве символов в строке – разработчики электронных писем обычно не работают с кеглем. Роберт Брингхерст (Robert Bringhurst) советует использовать в строке текста письма с одной колонкой, адаптированного под ПК, от 45 до 75 символов, идеальный вариант – 66 символов (с учетом пробелов).

• 600 пикселей – самая популярная ширина тела письма для ПК (диапазон – от 480 до 760 пикселей, среднее значение – 623 пикселя);
• 540 пикселей – средняя ширина колонки на ПК;
• В строке текста на ПК в среднем располагается 78,5 символа;
• В строке текста шириной 450 пикселей в среднем располагается 53,86 символа;
• В строке текста шириной 320 пикселей в среднем располагается 39,02 символа;
• Формат строки на мобильных устройствах варьируется от 22 до 57 символов;
• В 76% случаев этот диапазон сужается до 36-46 символов.

Я провела небольшой эксперимент со шрифтом Georgia размером 16 пикселей при среднем формате строки в 540 пикселей. При таких параметрах число символов в строке будет чуть больше 70, и это не так плохо, если учесть, что 75 – максимум. Но в идеале лучше сократить число символов до 66, при этом ширина строки оказывается в районе 480 пикселей.

Роберт Брингхерст советует располагать в одной строке от 45 до 75 символов, идеальный вариант – 66 символов. Источник: Practical Typography

По подсчетам Константина, на строке веб-страницы в среднем располагается 83,9 символа. В нашем исследовании в строке тела письма содержится в среднем 78,5 символа. При просмотре писем на мобильном устройстве среднее число символов сокращается до 39. Typecast рекомендует придерживаться диапазона 35-40 символов при просмотре писем на обычном смартфоне. По результатам нашего исследования, в этот диапазон попало 48% писем.

Самым популярным (53%) форматом строки в шаблонах писем, адаптированных для ПК, был вариант шириной в 600 пикселей. В целом ширина экрана изменялась от 480 до 760 пикселей. Если вы хотите сделать колонку более широкой, просто увеличивайте размер шрифта до тех пор, пока не достигнете оптимального числа символов. Трент Уолтон (Trent Walton) предлагает оригинальное решение: нужно поместить символ «*» на две отметки – в 45 и 75 символов. Таким образом, если в какой-то момент обе звездочки оказываются в одной строке, это значит, что шрифт нужно увеличить.

Высота строки

Ниже представлены основные выводы, касающиеся высоты строки.

• При размере шрифта в 16 пикселей самой популярной высотой строки была высота в 24 пикселя;
• Среднее отношение высоты строки к «высоте» (общему объему) текста составило 1,51 (у Константина – 1,46);
• При 450-пиксельной ширине строки отношение высоты строки к высоте текста снижается до 1,49;
• При 320-пиксельной ширине строки отношение высоты строки и к высоте текста снижается до 1,45;
• 22% компаний, попавших в исследование, уменьшают высоту строки для писем, адаптированных под мобильные устройства;
• 52% устанавливают высоту строки в пикселях;
• 24% устанавливают высоту строки в процентах;
• Отношение длины строки к ее высоте в среднем составляло 23,1 (у Константина – 24,9);
• Отношение величины отступа между абзацами к высоте строки в среднем составляло 1,38 (у Константина – 1,39).

Стандартное правило: высота строки должна быть в 1,5 раза больше размера шрифта. То есть если размер шрифта – 16 пикселей, значит, высота строки составит 24 пикселя. Проведенное исследование подтверждает это правило: отношение высоты строки к размеру шрифта составило 1,51. Чем больше длина строки, тем большей можно сделать ее высоту.

Тим Браун (Tim Brown) называет такое изменение высоты «плавным» или «текучим». Джейсон Санта Мария (Jason Santa Maria ) поясняет: «Когда ваш взгляд доходит до конца строки, вам нужно увидеть промежуток между строками и понять, где находится следующая строка, чтобы не потеряться… Если строки становятся короче, значит, их можно разместить немного плотнее». Мы также отметили снижение этого отношения при переходе на мобильное устройство – оно упало с 1,51 до 1,45.

Высота строки в рассылке NYT Cooking снижается с 30 пикселей на ПК до 25 пикселей на смартфоне (отношение высоты строки к размеру шрифта снижается с 1,6 до 1,5)

52% дизайнеров email-рассылок устанавливает высоту строк в пикселях. Некоторые компании, например, Semplice, меняют высоту строки для разных элементов письма. 24% выставляют высоту в процентах. К примеру, Lagom устанавливает высоту 150%. Оливер Райхенштайн (Oliver Reichenstein) считает, что 140% – «неплохой ориентир», хотя многое зависит от выбранной гарнитуры. Пол Эйри советует выставлять высоту в процентах, потому что в пикселях сложнее подобрать нужное соотношение. Тем не менее, разработчики, скорее всего, привыкли к пикселям, так как они поддерживаются многими почтовыми клиентами.

Цвет

• #000000 (черный) был самым популярным цветом текста (20%), следом за ним идет #333333 (сумеречный серый) (16%);
• В письмах использовалось 28 различных оттенков серого, большинство из которых – темно-серые;
• 56% авторов рассылок использовали одинаковый цвет текста как в заголовке, так и в теле письма;
• 26% в теле письма использовали более светлый оттенок серого, чем в заголовке, 4% – более темный, а 14% брали разные цвета;
• 72% в качестве фона использовали #FFFFFF (белый);
• 48% не вставляли ссылки в тело письма, 20% выделяли ссылки другим цветом, 18% выделяли цветом и подчеркивали, 10% только подчеркивали, и 4% использовали другие варианты;
• #000000 был самым популярным цветом для основного заголовка (24%), следом за ним – #333333 (16%);
• 40% подзаголовков отличались цветом от основного заголовка: например, выделялись более светлым оттенком серого.

Несколько цветовых комбинаций для заголовка (вверху) и тела письма (внизу)

Оливер Райхенштайн пишет: «На высококонтрастном экране предпочтительнее выбирать либо темно-серый цвет для основного текста, либо светло-серый – для фона вместо оттенков черного и белого».

#FFFFFF стал самым популярным (72%) цветом для фона письма

При использовании более насыщенных шрифтов Джейсон Санта Мария советует либо увеличить высоту строки, либо выбрать более светлый тон, чтобы не нагружать остальной контент. Разработчики иногда регулируют цвет текста на разных устройствах в зависимости от того, как отображаются на них шрифты разных размеров. В Photoshop невозможно четко определить, подходит шрифт для рассылки или нет: приходится изучать его поведение в браузере с помощью самодельных прототипов, Typecast или Typetester.

Выравнивание

• 54% основных заголовков на ПК выровнены по центру, 46% – по левому краю;
• 54% основных заголовков на мобильных устройствах выровнены по левому краю, 46% – по центру;
• 74% создателей рассылок выравнивают основной текст на ПК по левому краю, остальные 26% – по центру;
• 76% выравнивают основной текст на мобильном устройстве по левому краю, остальные 24% – по центру.

Если основной текст выровнен по центру, то читать бывает сложнее, так как каждый раз приходится искать начало следующей строки

Пользователи, на которых мы тестировали рассылки, постоянно говорили, что текст, выровненный по центру, читать сложнее. «Возможно, блоки, в которых много текста, читать чуть сложнее. Думаю, это потому, что текст выровнен по центру», – написал один участник эксперимента в UserTesting. То же можно сказать и о более узких экранах мобильных устройств. Подписи, короткие предложения и заголовки, выровненные по центру, воспринимаются нормально, но когда дело доходит до абзацев, текст приходится выравнивать по левому краю. Как упоминается в «Оде центрированному тексту», целые абзацы никогда нельзя выравнивать по центру.

Средний размер шрифта в заголовках

• 30 пикселей – самый популярный (18%) размер в заголовках на ПК (30 пикселей – также и медианный размер, а средний размер – 31,6 пикселя);
• Размеры шрифта в заголовках на ПК делились на две группы: от 24 до 26 пикселей и от 28 до 36 пикселей;
• Шрифт в заголовках в среднем был ровно в два раза крупнее шрифта в теле письма (31,6 и 15,7 пикселя соответственно);
• Шрифт в заголовках на ПК в среднем был в 1,2 раза больше высоты строки (это соотношение варьировалось от 0,65 до 1,8);
• Ссылки не крепились к 62% основных заголовков на ПК;
• 68% создателей рассылок не меняли размер шрифта в заголовке при переходе с ПК на 450-пиксельный формат ширины письма; 87,5% из тех, кто менял размер шрифта, уменьшали его;
• 64% выбирали одинаковые размеры шрифта для заголовка на ПК и на мобильных устройствах (один масштаб);
• На мобильных устройствах для основного заголовка чаще всего выбирали размер в 30 и 32 пикселя (оба по 12%);
• Средний размер шрифта в основном заголовке на мобильном устройстве (320 пикселей) составил 28,48 пикселя (медианный размер шрифта был 26,5 пикселя)
• Отношение размера шрифта в заголовке к высоте строки в среднем составляло 1,17 для мобильных устройств;
• Только 14% использовали в заголовке одни прописные буквы (как правило, это были магазины одежды);
• 72% использовали подзаголовки;
• Средний размер шрифта подзаголовков – 27,9 пикселя (для десктопа).

Многие разработчики писем не пользуются тегами h2, h3 и т.д., поэтому я фиксировала первый и второй по величине шрифты в заголовках с помощью приложения WhatFont. Самый популярный размер шрифта в основных заголовках на ПК – 30 пикселей, тогда как у Константина этот показатель составляет 38 пикселей по Сети в целом. Возможно, более мелкий шрифт выбирается для удобства чтения как на ПК, так и на мобильных устройствах.

64% использовали одинаковый масштаб в заголовках на всех типах устройств. Если говорить об оставшихся 36%, то 87,5% из них уменьшали масштаб на мобильных устройствах. К примеру, в рассылке от Mr Porter размер шрифта на мобильном устройстве уменьшен с 30 до 25 пикселей – небольшое изменение, которое делает стиль более элегантным, в отличие от громоздких заголовков на ПК.

Размер шрифта заголовка в рассылке Mr Porter снижается с 30 пикселей на ПК до 25 пикселей на мобильном устройстве

О точных размерах заголовков нет единого мнения, хотя в десктопной версии шрифт заголовка был в среднем в два раза больше шрифта в теле письма. Для сравнения, на Typecast пишут, что их значения h1 в три раза больше шрифта основного текста, хотя в интернете можно найти и более крупные заголовки. Если хотите поэкспериментировать с разными соотношениями, воспользуйтесь сервисом Modular Scale. Кроме того, есть стандартная типографская шкала:

Шкала из «Основ стиля в типографике» Роберта Брингхерста. Изображение: Retinart

В качестве альтернативы использования размера шрифта для визуального выделения, Марко Дугоньич (Marko Dugonjić ) предлагает менять стиль текста: например, курсив, все прописные или капитель [англ. small caps]. Посмотрите его демо-вариант (раздел «Выделение со сменой стиля»). Этот подход будет особенно полезен на мобильных устройствах, где меньше пространства для крупных заголовков. Еще один вариант – переключиться на узкий шрифт. Заголовки являются творческой площадкой для дизайнеров. Здесь у них появляется больше вариантов для размеров шрифтов и выравнивания, а также больше возможностей использовать веб-шрифты, в отличие от текста в теле письма.

Текст под заголовком

Записи под заголовком находятся вверху письма. Это первый текст, который пользователи обычно видят на своих смартфонах, вместе с именем отправителя и темой. В своем исследовании я разграничиваю понятия инструктивной надписи, например, «Смотреть онлайн», и отрывка текста, который более информативен и зачастую дополняет тему письма. Litmus подробно рассматривает этот вопрос в своем обзоре и приводит в нем таблицу приложений, которые отображают текст под заголовком.

• 66% создателей рассылок используют текст под заголовком на ПК;
• 36% включают в него только инструкции, 33% – инструкции и отрывок письма, 30% – только отрывок;
• Самый популярный размер текста под заголовком на ПК – 11 пикселей (33%), далее 12 пикселей (18%) и затем 10 пикселей (12%) (среднее значение – 12,3 пикселя);
• Размеры шрифта текста под заголовком варьируются от 9 до 18 пикселей;
• Отношение размера текста под заголовком к размеру основного текста в среднем составляло 0,78;
• Отношение размера текста под заголовком к высоте строки на ПК в среднем составляло 1,11;
• 76% использовали в тексте под заголовком гарнитуры без засечек;
• Самым популярным шрифтом без засечек был Arial, с засечками – Georgia;
• В текстах под заголовком использовались 22 разных цвета, самый популярный – #000000, затем #999999;
• 82% поддерживали текст под заголовком на мобильных устройствах, 18% его скрывали;
• Самый популярный размер текста под заголовком на мобильных устройствах – 11 пикселей (40%), далее 16 пикселей (22%) и затем 14 пикселей (18%) (средний размер шрифта – 12,9 пикселя);
• Размеры шрифтов текста под заголовком на мобильных устройствах варьировались от 8 до 16 пикселей;
• 71% сохраняли размер при переходе на мобильные устройства, 22% увеличивали шрифт, 7% уменьшали;
• Отношение размера текста под заголовком к размеру основного текста на мобильном устройстве в среднем составляло 0,85.

Текст под заголовком отображается вместе с именем отправителя и темой письма

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

• Время, за которое отображался первый элемент письма, в среднем составляло 0,94 секунды;
• Время полной загрузки письма в среднем составляло 2,64 секунды;
• Общее число HTTP-запросов в среднем составляло 24;
• Число запросов на изображения в среднем составляло 13,7, то есть 57% от общего числа запросов;
• Полностью загруженное письмо в среднем весило 711 КБ;
• Изображения в письме весили в среднем 568 КБ;
• На изображения приходилось 79,8% объема всего письма;
• Размер изображений изменялся от 9 КБ до 4,4 МБ, из них 50% весили 200 КБ и более;
• Веб-шрифты в среднем занимали 69,7 КБ (9,5% объема всего письма);
• 30% использовали веб-шрифты (самым популярным был Open Sans, затем Merriweather).

Первоначально я включила в свое исследование производительность, так как часто слышала о том, как веб-шрифты ее снижают. Если взглянуть на список 20 лучших шрифтов Google Fonts, можно увидеть, что их средний объем составляет 28 КБ (формат WOFF) на один шрифт. Если учесть, что большинство участников исследования использовало по три шрифта, то сумма сходится (средний объем загруженного шрифта составлял 69,7 КБ). Хотя веб-шрифты иногда могут стать причиной для беспокойства, они занимают всего 9,8% общего объема письма. Сравните их с изображениями, которые занимают 79,8% от всего письма.

Гай Поджарный (Guy Podjarny) также отмечает, что изображения несут основную нагрузку в письме. Полезный инструмент, о котором вы могли не знать – Litmus. Он показывает число картинок, размер и время загрузки во время предварительного просмотра.

<Изображения в среднем составляют 79,8% от общего объема письма (средний объем загруженного изображения составляет 568 КБ)

Согласно этой ленте, письмо H&M загружается за 4,095 секунды, т.е. в этот момент что-то только начинает появляться на экране

Заключение

Изначально я хотела узнать, как сайты вроде iA, Fray, Medium и Pelican Books создают такие «эталонные» примеры подбора типографики, и попытаться использовать их идеи как основу для разработки гайдлайнов по дизайну email-рассылок. К примеру, может ли существовать четкая связь между размером шрифта и величиной отступа на мобильных устройствах?

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

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

Тем не менее, проведенное исследование дает некоторую основу для разработки дизайна электронных писем: например, если за размер основного текста берется 16 пикселей при высоте строки в 24 пикселя, вам остается лишь выбрать подходящую гарнитуру и отрегулировать длину строки. Особенно полезными оказались найденные пропорции, советы по выбору соотношений между размерами шрифтов для различных типов экранов и некоторые основные положения вроде «плавного» изменения высоты. Также стоит заглянуть в Google-таблицу с результатами исследования, потому что они ценны сами по себе и содержат работы экспертов в области типографики, у которых есть чему научиться.

Основные выводы

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

• 74% используют шрифты без засечек в основных заголовках, 64% используют шрифты без засечек в теле письма;
• Средний размер шрифта в теле письма при просмотре на ПК – 15,7 пикселя, при просмотре с мобильного устройства – 15,58 пикселя;
• Средняя ширина письма для ПК составляет 623 пикселя;
• Среднее число символов в строке письма, открытого на ПК, – 78,5, при ширине письма в 450 пикселей – 53,86;
• Длина строки в письме, открытом на мобильном устройстве, варьируется от 22 до 57 символов;
• Отношение высоты строки к размеру шрифта на ПК в среднем составляло 1,51 и снижалось до 1,45 на мобильном устройстве (320 пикселей);
• Отношение длины строки к ее высоте в среднем составляло 23,1;
• 76% текста на мобильных устройствах выровнено по левому краю;
• Размеры шрифтов в заголовках десктопных версий делились на две группы: от 24 до 26 пикселей и от 28 до 36 пикселей;
• Размер шрифта в основном заголовке на мобильном устройстве (320 пикселей) в среднем составлял 28,48 пикселя;
• Размер шрифта текста под заголовком на ПК в среднем составлял 12,3 пикселя, на мобильном устройстве – 12,9 пикселя;
• Размер шрифта в заголовках был вдвое больше размера шрифта в теле письма (31,6 и 15,7 пикселя соответственно);
• Отношение размера шрифта текста под заголовком к размеру шрифта основного текста составляло 0,78 на ПК, на мобильных устройствах – 0,85;
• Среднее время, за которое загружается первый элемент письма, составило 0,94 секунды;
• Общее число HTTP-запросов в среднем составило 24.

Let's block ads! (Why?)