_{Блог разработчика интерфейсовКакая сейчас неделя? Какая сейчас учебная неделя? Четная или нечетная?}

По данным сайта Web Perfomance Today, средний вес страницы в 2015 году 1109 КБ. По прогнозам, к 2018 будет около 2 МБ. Загрузка изображений занимает в среднем 64% (711 КБ) всего времени загрузки страницы. Поэтому начинать оптимизацию скорости загрузки страницы нужно именно с графики.

Введение

В последние несколько лет голосовые интерфейсы окружают нас все плотнее. То, что когда-то демонстрировалось только в фильмах о далеком будущем, оказалось вполне реальным. Дело дошло уже до встраивания движков для синтеза (Text To Speech — TTS) и распознавания (Automatic Speech Recognition — ASR) речи в мобильные телефоны. Более того, появились вполне доступные API для встраивания ASR и TTS в приложения.

Ныне создавать программы с голосовым интерфейсом может любой желающий (не поскупившийся заплатить за движок). Наш обзор будет посвящен именно использованию имеющихся движков (на примере Nuance) а не созданию таковых. Также будут даны общие сведения необходимые каждому программисту впервые сталкивающемуся с речевыми интерфейсами. Статья также может быть полезна руководителям проектов, пытающимся оценить целесообразность интеграции голосовых технологий в их продукты.
Итак, начнем…

Но для затравки — анекдот:
Урок русского языка в грузинской школе.
Учитель говорит: «Дети, запомните: слова сол, фасол и вермишел пишутся с мягким знаком, а слова вилька, булька, тарелька – без мягкого знака. Дети, запомните, потому что понять это невозможно!»

Раньше этот анекдот казался мне смешным. Теперь — скорее жизненным. Почему так? Сейчас постараюсь объяснить…

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

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

И, пользуясь случаем, хочу напомнить, что у нас в Badoo уже несколько лет идет программа "Проверь Badoo на прочность" и мы платим за найденные уязвимости.

Все вокруг постоянно рассуждают о коррупции. А я хочу рассказать Вам о случае, на коррупцию очень похожем, но в среде чистого IT-бизнеса, на государство никак не завязанного.

Описываемый далее случай интересен именно с точки зрения взлома бизнеса, хотя статья больше посвящена взлому в смысле IT.

Начну с нетехнической части.

Эта статья — взгляд на тестирование ММО с «другой стороны баррикад», с точки зрения геймера. Я хочу рассказать о том, как сделать альфа-тест, ЗБТ и ОБТ эффективнее. И о том, почему бета-тестеры перестают писать баг-репорты и переходят «в оппозицию» к проекту.

Предисловие

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

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

В моей третьей статье про NES-игры я покажу техники, используемые для создания игровых движков, а именно реализацию скроллинга экрана, переключение банков памяти, организацию списка объектов, устройство системы анимаций персонажей, функции обновления игровых объектов (и обработку столкновений), устройство главной карты. Чтобы не быть голословным в описаниях, я буду приводить дизассемблированный код из конкретных игр (любимый всем «Darkwing Duck», с отсылками к «Chip & Dale» и «Duck Tales»), без него в этой статье не обойтись. В качестве примера рассматривается движок от «Capcom», на модификациях которого работает как минимум пара десятков игр.

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

Приветствую уважаемых читателей! Несколько лет подряд я писал на тему нашего сервиса мониторинга автотранспорта, об оборудовании, которое производим, приоткрывая внутренние аспекты производства и работы в целом. В этой статье я хочу рассказать о полном цикле производства такого очень важного элемента работы систем GPS мониторинга и контроля, как датчик уровня топлива (поисковики его знают как ДУТ). Будет теория, все чертежи и схемы для сборки данного продукта. Кому интересно — читаем далее.

Этим постом я бы хотел официально представиться и вкратце познакомить вас с нашим проектом. Меня зовут Павел Голубев, с 2009 года я работаю в сфере разработки и публикации мобильных приложений. Наша команда в свое время запустила SaaS-сервис Columbis для турагентств, позволяющий автоматизировать их деятельность. После этого я переехал в Соединенные Штаты, Сан-Франциско, и уже тут продолжил работу в сфере мобильной рекламы. В определенный момент у нас возникла потребность в платформе, которая позволила бы увеличить доход от рекламы в наших приложениях. На поиски подобного инструмента оптимизации трафика мы потратили несколько месяцев, после чего приняли решение сделать его сами. В итоге, разработка для внутренних нужд переросла в самостоятельный проект — Appodeal, в блоге которого и размещена данная публикация.

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

• какую рекламную сеть выбрать;
• как к ней подключиться;
• насколько высокая заполняемость (fill rate) у этой сети;
• насколько высокий eCPM для региона вашей аудитории в конкретной сети;
• какой тип оплаты подходит для вас (CPI/CPM/CPC);
• есть ли плагин для фреймворка, в котором вы ведете разработку;
• как в конечном итоге вывести свои деньги.

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

Лет 7-8 назад мне случайно попалась игра CharmSolitaire, скопированная вместе с другими играми с чужого винта в процессе обмена информацией. Это такой не совсем обычный карточный пасьянс. В незарегистрированной версии на игру отводится один час, и открыта только половина уровней. В той копии время уже почти закончилось. Денег на покупку у меня не было, поэтому скорее всего я бы ее удалил. Но в то время я немного увлекался взломом и решил попробовать найти регистрационный код. Опыт был довольно интересным. В статье рассказывается об основных особенностях защиты, а также о том, как security through obscurity может ее ослабить.

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

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

Когда друзья меня спросили, почему я заинтересовался Blend4Web и стал изучать его, однозначного ответа не получилось. Да, я использую Unity и это мой основной инструмент. Его возможностей с головой хватает для реализации любых задумок. Но я люблю и Blender, так как работаю с ним уже много лет. Все модели, анимации, кинематографические сцены я делаю исключительно в нем. A Blend4Web выглядит очень достойным движком реального времени для WebGL.

И в один прекрасный момент я задумался, а может ли Blend4Web конкурировать со столь популярным Unity, и если да, то в каких сферах…

Компиляция и декомпиляция try-with-resources, или рассказ о том, как я фиксил баг и что из этого вышло.

Введение

Какое-то время назад backlog рабочего проекта почти опустел, и вверх всплыли различного рода исследовательские задачи. Одна из них звучала весьма интригующе: прикрутить к проекту мутационное тестирования используя PITest. На Хабре уже есть весьма подробный обзор этой библиотеки (с примерами и картинками). Пересказывать эту статью своими словами я не буду, но все же рекомендую с ней предварительно ознакомиться.

Признаюсь, что идеей мутационного тестирования я загорелся. Почти без дополнительных усилий получить инструмент поиска потенциально опасных мест кода — оно того стоит! Я без промедления взялся за дело. На тот момент библиотека была относительно молодой, как следствие — весьма сырой: здесь нужно немного пошаманить с конфигурацией maven’а, там — пропатчить плагин для Sonar’а. Однако через некоторое время я все же смог проверить проект целиком. Результат: сотни выживших мутаций! Эволюция в масштабе на нашем build-сервере.

Засучив рукава я погрузился в работу. В одних тестах не хватает верификаций заглушек, в других вместо логики вообще непонятно что тестируется. Правим, улучшаем, переписываем. В общем, процесс пошел, но число выживших мутаций убывало не так стремительно, как хотелось. Причина была проста: PIT давал огромное количество ложных срабатываний на блоке try-with-resources. Недолгие поиски показали, что баг известен, но до сих пор не исправлен. Что ж, код библиотеки открыт. От чего бы не склонировать его и не посмотреть, в чем же дело?

Чем дальше мы уходим в XXI век, тем интенсивнее становятся процессы нарастания информационного поля и технической инфраструктуры. Если буквально 5-7 лет назад многие задачи в компаниях решались по старинке и даже в крупных организация можно было встретить «амбарные книги», то сегодня автоматизация проникла во все сферы: от службы персонала до отдела производства. Как только принимается решение об автоматизации какого бы то ни было процесса (выбора CRM, корпоративного портала, системы документооборота, биллинговой системы или решения для комплексной автоматизации), даже беглый взгляд в поисковую систему и обращение к профильным сайтам вызывает панику. И это закономерно: вместе с проблемой выбора возникает ряд вопросов, без решения которых автоматизация сведется к самому страшному финалу — развёрнутое за серьёзные деньги программное обеспечение станет нефункционирующим балластом, а процессы останутся за пределами автоматизации.

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

Вот вам анекдот из конца 90-ых. Я (Dave Baggett) был одним из двух программистов (вместе с Andy Gavin), разрабатывающих Crash Bandicoot для PlayStation 1.



Оперативная память была главной проблемой даже в те времена. У PS1 было всего 2MB RAM, и нам приходилось совершать безумные вещи, чтобы уместить в них игру. У нас были уровни, содержащие более 10MB чистых данных, и эти 10 мегабайт должны были постранично загружаться и выгружаться в память динамически, без каких-либо видимых задержек для игрока, при фреймрейте в 30 кадров в секунду.

Вступление

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

1. String, StringBuffer, StringBuilder (реализация строк)
2. Pattern, Matcher (регулярные выражения)

Реализация строк на Java представлена тремя основными классами: String, StringBuffer, StringBuilder. Давайте поговорим о них.

В данной статье речь будет о локальной низкоскоростной сети взаимодействия блоков управления автомобиля BMW — I/K-bus. А точнее о том, как с ней могут взаимодействовать приложения из под Linux. На картинках проиллюстрирую созданный мною вариант.

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

Информационно-развлекательная система выполняется на устройствах, в основе которых контроллеры с заложенными программами. Я буду здесь называть эти устройства блоками управления. Каждый такой блок управления несёт свою функциональную нагрузку, будь то поддержание температуры салона, регулировка положения сидений, воспроизведение музыки и видео, навигация и прочее. Весь этот набор блоков управления должен взаимодействовать друг с другом, управляться с места водителя и пассажиров, передавать диагностические данные. Для этой цели и была разработана сеть I-bus. В последствии появилась технически идентичная сеть K-bus и их объединение I/K-bus.

Перед разработчиками довольно часто встаёт выбор — сделать всё правильно, потратив на решение задачи уйму времени, или сделать так, чтобы работало, не особо вдаваясь в детали того, как именно это получилось. Со стороны заказчика, разумеется, наиболее привлекательной является некая золотая середина, которая в данном случае заключается одновременно и в хорошем понимании программистом выполненного таска, и в как можно меньшем количестве затраченных на него человеко-часов. С разработчиками тоже не всё так однозначно — с одной стороны, понимать, что происходит в своём собственном коде, это вполне естесственное желание (особенно если поддержка данного продукта также будет лежать на его плечах), а с другой стороны, если результаты работы приложения представлены в наглядном виде (графики / звуковые или видео-фрагменты etc), разработка разовая, и отдел тестирования говорит, что всё хорошо, то почему бы не проскроллить оставшуюся часть рабочего времени Хабр, посвятив время себе любимому?

Ближе к делу. В одной из предыдущих статей я уже упоминал о программе под названием «Говорилка». Несмотря на название, сама по себе она ничего не озвучивает, а лишь является связующим звеном между пользователем и речевыми движками, предоставляя более удобный интерфейс и возможность конфигурации. Одним из наиболее популярных в узких кругах движков является «Digalo 2000 text-to-speech engine» (далее — Digalo), ссылку на который можно найти как раз на сайте «Говорилки». Как вы уже, наверное, догадались из тематик моих предыдущих статей, не всё с ним так хорошо, и без багов тут также не обошлось. На этот раз проблема проявилась при озвучивании текста «ааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааа». Немного поэкспериментировав, я обнаружил, что при достижении определённого количества «неразрывных» символов Digalo начинает крашиться, предлагая отладить свой процесс. Ну, а что, почему бы и нет?

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

• Реализация AI: как сделать максимально просто?
• RPC клиент-сервер: json или бинарная «самопальщина»?
• Асинхронные сокеты или многопоточная архитектура?
• Кеширование объектов на уровне приложения или больше памяти для СУБД?
• Работа с БД без Reflection API: действительно ли это так сложно?

        Сегодня мы продолжим рассматривать архитектуру и особенности реализации игрового backend'а на С++ для онлайн игры на примере ММО РПГ «Звездные Призраки». Это вторая часть статьи про сервер, начало можно прочитать здесь.