В пилотной части я рассказал о задаче как можно подробнее. Рассказ получился долгим и беспредметным — в нем не было ни одной строчки кода. Но без понимания задачи очень сложно заниматься оптимизацией. Конечно, некоторые техники можно применять, имея на руках только код. Например, кешировать вычисления, сокращать ветвления. Но мне кажется, что некоторые вещи без понимания задачи просто никогда не сделать. Это и отличает человека от оптимизирующего компилятора. Поэтому ручная оптимизация все еще играет огромную роль: у компилятора есть только код, а у человека есть понимание задачи. Компилятор не может принять решение, что значение "4" достаточно случайно, а человек может.

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

Ещё в мае 2016-го Google громко анонсировал VR-платформу Daydream, но только теперь она становится действительно актуальна: маркировку «Daydream-ready» вслед за флагманом Pixel стали получать и другие смартфоны. Означает ли это, что для Android-разработчиков настало время разбираться с VR? Есть ли смысл посвящать этому своё время, если не имеешь отношения к игровой индустрии? С чем на практике сталкиваешься в мобильной VR-разработке?

На такие вопросы лучше всего может ответить человек с соответствующим опытом, и этот опыт есть у Александра Коршака: сначала он делал VR-приложение из личного интереса, затем в компании MERA разрабатывал мобильный видеоредактор с поддержкой 360-градусного видео, а теперь участвует в стартапе, связанном со сферическим видео, интернет- и TV-трансляциями. В результате он успел поработать и с тем же Daydream, и с предшествовавшим ему Cardboard, и с Gear VR — а мы расспросили его обо всём и сразу.

В 1998 году Looking Glass Studios выпустила стелс-игру Thief: The Dark Project. В то время аппаратное 3D-ускорение только зарождалось, поэтому в процессе разработки оно не использовалось, игра рендерилась только программно.

Я был основным автором базовой технологии рендеринга Thief (хотя я и не писал рендереры объектов и персонажей), а также связанных с ней элементов. Тот же движок рендеринга, модифицированный другими людьми для использования аппаратного 3D-ускорения, также использовался для рендеринга System Shock 2 и Thief 2.

Движок был написан примерно в одно время с Quake (хотя игра вышла намного позже), и общий внешний вид сильно напоминает Quake. Многие технологии были скопированы из Quake или вдохновлялись им, но часто их работа немного или значительно отличалась.

Программировать быстро — это легко! Так считает инженер-программист компании Google, который все публикации в своем блоге подписывает лаконичным «Макс». Макс также работает главным архитектором, комьюнити-менеджером и релиз-менеджером в Bugzilla Project. Мы в Alconost впечатлились и перевели его советы о том, можно ли как научиться программировать с космической скоростью.

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

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

Теперь давайте разберемся, как, собственно, стать быстрее? Может, это врожденное магическое умение? Надо ли быть «умнее» других, чтобы быть быстрым?

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

Буквально на днях Эрик Стромберг, бывший совладелец книжного сервиса Oyster, чуть более года назад проданного Google, рассказал о матрице, которая поможет вам найти идею для нового стартапа. Сама задумка создания подобной матрицы многим показалась чрезвычайно интересной. Пост Эрика, размещенный в его блоге на Medium, спровоцировал обширную дискуссию и вызвал интерес у мировых СМИ. Тем, кто еще не слышал об этой концепции, мы предлагаем ознакомиться с переводом резонансной публикации.

Энтузиаст технологий виртуальной реальности Teddy, известный в определённых кругах адаптацией устройства Razer Hydra для работы с Unity Development Kit, помог другому этузиасту 3D сканирования Ли Перри-Смиту (Lee Perry-Smith), известному в определённых кругах своей студией для мгновенного бесконтактного 3D сканирования людей в высоком разрешении.

В результате получилось интересное демо, раскрывающее потрясающие возможности сотрудничества технологий виртуальной реальности и 3D сканирования (местами 16+).

В прошлый раз в статье «Поиск линии корешка на фотографиях книжных разворотов» мы обещали рассказать о том, что случается с фотографией книжного разворота после этого, а именно — про устранение перспективных искажений и разгибание кривых строк текста. Без этого получить качественные результаты OCR практически невозможно.

Итак, считаем, что мы уже нашли на фотографии линию корешка, воспользуемся этим знанием, чтобы определить ваниш-точки для страниц разворота (vanishing point). Ваниш-точки – это точки схождения параллельных прямых в перспективной проекции книги на плоскость изображения. Они обе должны располагаться на продолжении этой линии, но для каждой из страниц положение точки может быть свое. Схематически это показано на следующей иллюстрации (на самом деле, это лог для отладки). Линия корешка выделена красным, линии, пересекающиеся в ваниш-точках, – зеленым.

Преимущественно медиафайлы. На полном серьезе, без шуток.

Введение

Бывает, случается так, что вы хотите скачать альбом 2007 года исполнителя, который кроме вас известен 3.5 людям, какой-нибудь испанский ска-панк или малопопулярный спидкор европейского происхождения. Находите BitTorrent-раздачу, ставите на закачку, быстро скачиваете 14.7%, и… все. Проходит день, неделя, месяц, а процент скачанного не увеличивается. Вы ищете этот альбом в поисковике, натыкаетесь на форумы, показывающие ссылки только после регистрации и 5 написанных сообщений, регистрируетесь, флудите в мертвых темах, вам открываются ссылки на файлообменники вроде rapidshare и megaupload, которые уже сто лет как умерли.


_{Увы, частая ситуация в попытке хоть что-то скачать}

Такое случается. В последнее время, к сожалению, случается чаще: правообладатели и правоохранительные органы всерьез взялись за файлообмен; в прошлом году закрылись или были закрыты KickassTorrents, BlackCat Games, what.cd, btdigg, torrentz.eu, EX.ua, fs.to, torrents.net.ua, и еще куча других сайтов. И если поиск свежих рипов фильмов, сериалов, музыки, мультиков все еще не представляет большой проблемы, несмотря на многократно участившееся удаления со стороны правообладателей контента из поисковых систем, торрент-трекеров и файлообменников, то поиск и скачивание оригинала (DVD или Blu-Ray) фильмов и сериалов или просто ТВ-рипов 7-летней давности на не-английском и не-русском языке — не такая уж простая задача.

Сетки из шестиугольников (гексагональные сетки) используются в некоторых играх, но они не так просты и распространены, как сетки прямоугольников. Я коллекционирую ресурсы о сетках шестиугольников уже почти 20 лет, и написал это руководство по самым элегантным подходам, реализуемым в простейшем коде. В статье часто используются руководства Чарльза Фу (Charles Fu) и Кларка Вербрюгге (Clark Verbrugge). Я опишу различные способы создания сеток шестиугольников, их взаимосвязь, а также самые общие алгоритмы. Многие части этой статьи интерактивны: выбор типа сетки изменяет соответствующие схемы, код и тексты. (Прим. пер.: это относится только к оригиналу, советую его изучить. В переводе вся информация оригинала сохранена, но без интерактивности.).

После обновления на Android 7 мы заметили, что уведомления стали группироваться по приложению автоматически. Так как на момент выхода новой версии Android в нашем приложении еще не было истории уведомлений это изменение было достаточно критично — в одной группе отображается только 7 уведомлений. Это значит, что если приходит более 20 уведомлений в сутки через приложение — необходимо смахивать новые чтобы увидеть более старые.

Уведомления в группе сортируются по приоритету. Если у вас в группе 7 уведомлений и приходит еще одно низкого приоритета — оно сначала будет наверху, а потом улетит в самый низ и его совсем не будет видно списке, до тех пор пока вы не удалите некоторое число уведомлений.

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

В этой статье мы расскажем, почему официальный мануал не работает, и как мы нашли способ сделать все правильно.

Google выложил в открытый доступ библиотеку C++ Ceres Solver, которая осуществляет моделирование и анализ сложных проблем нелинейной минимизации суммы квадратов.

Метод наименьших квадратов используется в разных областях: от построения сложных кривых в статистике до построения 3D-моделей по фотографиям в системах компьютерного зрения. В Street View система используется для привязки ожидаемого положения автомобиля (модель) к реальным координатам (данные).

Предисловие

Вводим «AdMob» в Google и первым сайтом уже будет не AdMob-ский, а Google-ский сайт. После перехода на оный Вас начнут по немногу переманивать на темную сторону Firebase (недавно купленный Google).

Firebase дает довольно обширные возможности по аналитике (по крайней мере для меня, как программиста, а не маркетолога) рекламы в вашем приложениее (рост, вес, страна, кол-во просмотров, версии Android куда установливалось и тд. и тп.).

Первым делом был найден пост, но он для Eclipse, а после первых попыток сделать по примеру — начались предупреждения о depricated да и вообще ошибки.

Прочитав больше информации стало понятно, что переход AdMob на firebase произошел недавно и разбиратся придется самому.

Я ясно помню тот день в далеком 2014 году, когда я решил заняться программирование под Android. Это оказалось лучшим решением, которое я принял в моей жизни. Уже прошло почти два с половиной года, и за это время у меня возможность кое-чему научиться.

Когда я только начал, я не знал никого, кто мог бы научить меня, показать, как правильно нужно делать. И я совершил МНОЖЕСТВО ошибок, в так же потратил кучу времени на то, чтобы потом их исправить.

Полтора года спустя, мне выпал шанс поработать с очень талантливыми и опытными Android-разработчиками, которые направляли меня и помогли мне привести все в порядок. Эти две составляющие научили меня многому. Я понял, что надо ДЕЛАТЬ, а самое главное, что НЕ НАДО.

И уже какое-то время я, как могу, стараюсь помогать другим разработчикам — прямо или косвенно. Вот мои профили: StackOverflow и Github.

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

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

Доброго времени суток, уважаемые хабражители. Я работаю в большой IT компании Android-разработчиком.

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

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

В статье присутствуют цены на те или иные услуги сайтов с которыми мне удалось связаться.

Седьмого ноября стартует Russian AI Cup 2016. Это ежегодный чемпионат по программированию искуственного интеллекта, организуемый Mail.Ru Group. Russian AI Cup проводится в форме игры, чтобы получилось наглядно, понятно и просто. Вкратце: участники создают алгоритм, который описывает игровую стратегию. Получившийся бот сражается с другими такими же, а лучший из них побеждает в раунде. Таким образом, из серии раундов организуется турнир, проходящий в несколько этапов.

С одной стороны, основная механика игры довольно проста и минимально рабочую стратегию реально написать за пару часов (для быстрого старта в чемпионате можно заглянуть сюда, там же можно найти небольшой tutorial). С другой же — в игре получилось много нюансов, и оттачивать стратегию, поднимаясь вверх по турнирной таблице, можно до бесконечности. В этом году предлагаем вам на месяц стать магом и сразиться на средневековом поле боя в MOBA-игре CodeWizards. Впрочем, обо всем по порядку.

Простите, реформаторы образования – нам всё ещё нужны зубрёжка и повторение

Я была капризным ребёнком, росшим на лирической стороне жизни, и относилась к математике и науке так, будто они были симптомами чумы. И потому странно, что я превратилась в человека, ежедневно имеющего дела с тройными интегралами, преобразованиями Фурье и, жемчужиной математики – уравнением Эйлера. Сложно поверить, что из матофоба я превратилась в профессора прикладных наук.

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

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

1. Consistent, Thin and Dumb

Hector Zarate, Spotify

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

Если вы занимаетесь спортом, то хорошо знаете, как физические упражнения развивают силу, ловкость, выносливость. Это полезные качества в реальной жизни: вы сможете поднять мешок картошки одной рукой, забежать на 20-й этаж без лифта, обогнать автомобиль на велосипеде (средняя скорость движения автомобилей в Москве составляет 24 км/ч). Тренировки тела действительно помогают в реальной жизни.

А что насчёт тренировок мозга? Казалось бы, тот же принцип должен срабатывать в тренировке когнитивных способностей. К сожалению, это не так.

Я был крайне удивлён, найдя мало статей про динамическое программирование (далее просто динамика) на хабре. Мне всегда казалось, что эта парадигма довольно сильно распространена, в том числе и за пределами олимпиад по программированию. Поэтому я постараюсь закрыть этот пробел своей статьёй.

# Весь код в статье написан на языке Python

Основы

Пожалуй, лучшее описание динамики в одно предложение, которое я когда либо слышал:

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

Язык C++ очень часто обвиняют в неоправданной сложности. Конечно же, язык C++ сложен. И с каждым новым стандартом становится все сложнее. Парадокс, однако, состоит в том, что постоянно усложняясь, C++ последовательно и поступательно упрощает жизнь разработчикам. В том числе и обычным программистам, которые пишут код попроще, чем разработчики Boost-а или Folly. Чтобы не быть голословным, попробую показать это на небольшом примере «из недавнего»: как в результате адаптации к различным условиям тривиальный класс превратился в легкий хардкор с использованием policy-based design.