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

Навигация по лесу

Алгоритм поиска пути A* — это мощный инструмент для быстрой генерации оптимальных путей. Обычно A* демонстрируют при навигации по картам из сеток, но он может использоваться не только для сеток! Он может работать с любыми графами. Можно использовать A* для поиска пути в мире круглых препятствий.


В оригинале статьи все изображения интерактивны.

Как один алгоритм решает обе эти задачи? Давайте начнём с краткого описания того, как работает A*.

Алгоритм A*

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

На каждом шаге алгоритма A* оценивает множество частичных путей и генерирует новые пути, расширяя наиболее многообещающий путь из множества. Для этого A* хранит частичные пути в очереди с приоритетами, отсортированном по приблизительной длине — истинной измеренной длине пути плюс примерное оставшееся расстояние до цели. Это приближение должно быть недооценкой; то есть приближение может быть меньше истинного расстояния, но не больше него. В большинстве задач поиска пути хорошей преуменьшенной оценкой является геометрическое расстояние по прямой от конца частичного пути до конечной точки. Истинный наилучший путь до цели от конца частичного пути может быть длиннее, чем это расстояние по прямой, но не может быть короче.

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

Алгоритм Wave Function Collapse генерирует битовые изображения, локально подобные входному битовому изображению.

Локальное подобие означает, что

• (C1) Каждый паттерн NxN пикселей в выходных данных должен хотя бы раз встречаться во входных данных.
• (Слабое условие C2) Распределение паттернов NxN во входных данных должно быть подобным распределению паттернов NxN в значительно большом количестве наборов выходных данных. Другими словами, вероятность встречи определённого паттерна в выходных данных должна быть близка к плотности таких паттернов во входных данных.

Здравствуйте! Я решил попробовать себя на поприще game-dev'а и заодно рассказать и показать как это было. Вторая часть здесь.

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



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

Писать будем, используя фреймворк libGDX. Мне он больше всех понравился, как новичку в этом деле. Да и информации по нему я нашел больше. Итак, приступим.

В предыдущих статьях (раз, два) мы рассматривали классический hash map с хеш-таблицей и списком коллизий. Был построен lock-free ordered list, который послужил нам основой для lock-free hash map.
К сожалению, списки характеризуются линейной сложностью поиска O(N), где N — число элементов в списке, так что наш алгоритм lock-free ordered list сам по себе представляет небольшой интерес при больших N.
Или все же представляет?..

На AppsConf 2018, которая прошла 8-9 октября, я выступил с докладом про создание андроид-приложений целиком в одном Activity. Хотя тема известная, существует много предубеждений относительно такого выбора — переполненный зал и количество вопросов после выступления тому подтверждение. Чтобы не ждать видеозаписи, я решил сделать статью с расшифровкой выступления.

О чем я расскажу

1. Почему и зачем надо переходить на Single-Activity
2. Универсальный подход для решения задач, которые вы привыкли решать на нескольких Activity
3. Примеры стандартных бизнес задач
4. Узкие места, где обычно подпирают код, а не делают все честно

Steering behaviors помогают автономным персонажам реалистично двигаться благодаря применению простых сил, сочетание которых создаёт естественно выглядящее и импровизированное движение по окружению. В этом туториале я расскажу об основах теории steering behaviors, а также об их реализации.

Идеи, на которых построены такие поведения, предложены Крейгом Рейндольдсом; они не основаны на сложных стратегиях с использованием планирования пути или глобальных вычислений, а применяют локальную информацию, например, силы соседних объектов. Благодаря этому они просты в понимании и реализации, но в то же время способны создавать очень сложные паттерны движения.

Уже очень скоро завершится набор в Школу мобильной разработки, которая традиционно пройдет в Москве. Упор в ней будет сделан на практические занятия — командные мини-хакатоны, в которых помимо написания кода нужно будет принимать решения, разбираться с возникшими спорными вопросами и заниматься долгосрочным планированием. Помогать студентам — каждой команде индивидуально — будут ребята из Яндекса. Более подробно о предстоящей школе можно почитать здесь. Мы закончим принимать заявки 6 мая в 23:59 по московскому времени, а пока ещё есть время на выполнение заданий, мы решили разобрать прошлогодний вариант. Вы узнаете, какие ошибки часто допускают начинающие разработчики и чему следует уделить внимание при написании кода вашего первого приложения.



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

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

Для данной статьи необходимы базовые знания по Dagger 2. В примерах использовался Dagger версии 2.11

Dagger 2 позволяет забайндить несколько объектов в коллекцию, даже в тех случаях, когда байндинг этих объектов происходит в разных модулях. Dagger 2 поддерживает Set и Map мультибайндинг.

Привет, харб! Примерно год назад я выкладывал статью о том, как я в прямом эфире создал выживалку за 150 часов. На этот раз хочу представить вам сетевой шутер, который я создал за 25 заходов по 3 — 4 часа. Всего вышло около 90 часов и в итоге мы создали онлайн шутер, в который сыграли вместе со зрителями.



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

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

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

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

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

Модуль dagger-android позволяет заинжектить зависимости в следующие базовые компоненты андроида:

Activity, Fragment, Service, DaggerIntentService, BroadcastReceiver, ContentProvider.

Если мы используем классы из библиотеки поддержки (например AppCompatActivity, android.support.v4.app.Fragment), то нам надо использовать соответствующие классы из дополнительной даггер библиотеки поддержки (dagger-android-support).

В данной статье рассматривается использование специализированного модуля Dagger 2 под android и подразумевается, что у вас есть наличие базовых знаний по Dagger 2.

В Dagger 2.10 был представлен новый модуль специально для Android. Данный модуль поставляется как дополнение, состоящий из дополнительной библиотеки и компилятора.
В версии 2.11 были некоторые небольшие изменения, в частности некоторые классы, были переименованы, поэтому будет использоваться именно эта версия.

В этой серии статей я расскажу о внутреннем устройстве Android  —  о процессе загрузки, о содержимом файловой системы, о Binder и Android Runtime, о том, из чего состоят, как устанавливаются, запускаются, работают и взаимодействуют между собой приложения, об Android Framework, и о том, как в Android обеспечивается безопасность.

В данном материале можно будет увидеть различные инструменты и подсказки, которые здорово облегчают жизнь Android разработчикам. Большая часть собрана напрямую от знакомых разработчиков и содержит вещи, которые должен знать каждый. Дополнения и расширения приветствуются, и если вы знаете о каком-то крутом механизме, который не был упомянут в статье, не поленитесь перейти в оригинал и открыть pull request.

Эта статья является продолжением моего введения в алгоритм A*. В ней я показал, как реализуются поиск в ширину, алгоритм Дейкстры, жадный поиск по наилучшему первому совпадению и A*. Я стремился как можно больше упростить объяснение.

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

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


Для поиска этого пути можно использовать алгоритм поиска по графу, который применим, если карта представляет собой граф. A* часто используется в качестве алгоритма поиска по графу. Поиск в ширину — это простейший из алгоритмов поиска по графу, поэтому давайте начнём с него и постепенно перейдём к A*.

Занимаясь разработкой почтового приложения под Android, мы в Mail.Ru очень часто анализируем, насколько удобно для конечного пользователя построена навигация внутри нашей программы. Думаю, что не стоит объяснять насколько это важно, потому что все, кто пользуются мобильными приложениями, и без этого знают, что продукт, который не предоставляет интуитивно понятную и быструю навигацию, будет проигрывать тем продуктам, которые об этом позаботились. Удобство и тщательно продуманная навигация – это то, за что пользователь будет либо любить ваше приложение, либо каждый раз проявлять невероятные усилия, чтобы не разбить свой телефон об пол.

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

В статье я расскажу о том, с какими проблемами мне пришлось столкнутся как со стороны Android SDK, так и со стороны задачи (алгоритма кластеризации). Основная задача статьи – не научить делать так называемыми “custom view”, а показать проблемы, которые могут возникнуть при их создании.

Тема будет интересна тем из вас, кто имеет мало (или не имеет вовсе) опыта в создании чего-то подобного, а также тем, кто хочет словить лулзов с автора в сто первый раз уверовать в «гибкость» Android SDK.