Всем привет! Целых 4 года я не писал на Хабр. Последняя моя серия постов была о различных инструментах и приемах, которые мы применяли на нашей прошлой игре (разрабатывая ее на Unity). С тех пор игру ту мы благополучно выпустили, а также выпустили и новую. Так что теперь можно немного выдохнуть и написать несколько новых статей, которые могут быть кому-то полезны.


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

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

Для начала, кратко перечислю из чего собирается картинка в нашей игре:

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

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

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

Получив задачу разработать приложение для нашей предстоящей внутренней конференции в рамках OLX Group, моя команда задумалась о том, как сократить время создания приложения для iOS и Android, потому что нам и без этого было чем заняться. Первое, что мне пришло в голову, — использовать Kotlin, т.к. он может компилироваться на других платформах. Спойлер: не все пошло так, как изначально планировалось, но мы сделали всё вовремя, попутно узнав много нового!

Итак, это рассказ о том, как мы делали приложение OLX Group Product & Tech Conference в рекордно сжатые сроки.

Привет!

Меня зовут Алтай и я уже более трёх лет изучаю ASO (App Store Optimisation). По-русски, оптимизация приложений в магазинах приложений. Запомним эту аббревиатуру.

А теперь главное – ASO помогло мне сэкономить $500.000. Вот так!

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

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

Мы в компании занимаемся разработкой детских приложений. Пока мы выпустили только одно приложение в Google Play и App Store и это – Маленькие истории (сказки, где ребёнок становится главным героем). У приложения сейчас 600.000 установок, и почти все эти установки получены бесплатно!

Маленькие истории были зафичерены множество раз в App Store в различных подборках.
*фичеринг – это когда редактора добавляют ваше приложение в какую-нибудь подборку в магазине.


Также у нас есть три призовых места на различных конкурсах, причём два из них первые.

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

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

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

В данной статье я расскажу о своём опыте "заворачивания" Laravel-приложения в Docker-контейнер да так, что бы и локально с ним могли работать frontend и backend разработчики, и запуск его на production был максимально прост. Так же CI будет автоматически запускать статические анализаторы кода, phpunit-тесты, производить сборку образов.

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

• "Использую докер для локальной разработки. Ставлю laradock и беды не знаю". Круто, но как обстоят дела с автоматизацией и запуском на production?
• "Собираю один контейнер (монолит) на базе fedora:latest (~230 Mb), ставлю в него все сервисы (nginx, бд, кэш, etc), запускаю всё супервизором внутри". Тоже отлично, прост в запуске, но как на счёт идеологии "один контейнер — один процесс"? Как обстоят дела с балансировкой и управлением процессами? Как же размер образа?
• "Вот вам куски конфигов, приправляем выдержками из sh-скриптов, добавим магических env-значений, пользуйтесь". Спасибо, но как же на счёт хотя бы одного живого примера, который я бы мог форкнуть и полноценно поиграться?

Для нетерпеливых — ссылка на репозиторий, склонировав который ты сможешь запустить Laravel-приложение одной командой. Так же не составит труда его запустить на том же rancher, правильно "слинковав" контейнеры, или использовать продуктовый вариант docker-compose.yml как отправную точку.

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



В основе статьи — доклад Алексея Кудрявцева с Joker 2017. Алексей уже лет 10 пишет Intellij IDEA в JetBrains. Под катом вы найдете видео и текстовую расшифровку доклада.

Всем привет!

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

Вкратце:

• Пруф уже реализован на C++, JS и PHP, подходит для Java.
• Быстрее чем coroutine и Promise, больше фич.
• Не требует выделения отдельного программного стека.
• Дружит со всеми средствами безопасности и отладки.
• Работает на любой архитектуре и не требует особых флагов компилятора.

Наверняка многие уже успели наиграться с китайскими солнечными фонариками и разочароваться в них. Попробуем разобраться в вопросе: в чём причина их малой яркости и можно ли с этим что-то сделать?

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

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



В основе статьи — доклад Алексея Богачука (solution-архитектора компании EPAM) с конференции HolyJS 2018 Piter. Под катом — видео и расшифровка доклада.

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

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

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

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

Возможность многократного применения анимаций позволяет использовать анимации из Asset store и с таких вебсайтов, как mixamo.com, для ваших собственных персонажей. Это экономит кучу времени!

В этом туториале вы узнаете, как подготовить гуманоидную модель в Blender и как перенести её в Unity. В частности, вы научитесь следующему:

• Создавать арматуру (скелет) персонажа и выполнять её риггинг (привязку скелета к мешу)
• Модифицировать персонаж добавлением аксессуаров и объектов
• Экспортировать модель в FBX
• Импортировать модели Blender
• Создавать и настраивать гуманоидный аватар
• Прикреплять к персонажу объекты
• Анимировать гуманоида в Unity

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

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

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

Разумеется, это не означает «всё плохо и использовать Kotlin вместе с Java не надо», а означает, что стоит знать о нюансах и учитывать их. На нашей конференции Mobius Сергей Рябов рассказал, как писать на Kotlin такой код, к которому будет комфортно обращаться из Java. И доклад так понравился зрителям, что мы не только решили разместить видеозапись, но и сделали для Хабра текстовую версию:

18-летний Ювин Тан доказал, что классические компьютеры могут решать «задачу рекомендаций» почти так же быстро, как квантовые. Этот результат аннулирует один из наилучших примеров квантового ускорения расчётов.

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

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

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

Закрадывалась ли вам в голову идея переписать своё жирное энтерпрайзное приложение с нуля? Если с нуля, то это ж ого-го. Как минимум кода будет раза в два меньше, верно? Но ведь пройдёт пара лет, и оно тоже обрастёт, станет легаси… времени и денег на переписывание не так много, чтобы делать идеально.

Успокойтесь, начальство всё равно не даст ничего переписать. Остаётся рефакторить. На что лучше всего потратить свои невеликие ресурсы? Как именно рефакторить, где проводить чистки?

Название этой статьи — в том числе отсылка к книге Дяди Боба «Чистая Архитектура», а сделана она на основе замечательного доклада Victor Rentea (твиттер, сайт) на JPoint (под катом он начнёт говорить от первого лица, но пока дочитайте вводную). Чтения умных книжек эта статья не заменит, но для такого короткого описания изложено весьма хорошо.

Идея в том, что популярные в народе вещи вроде «Clean Architecture» действительно являются полезными. Сюрприз. Если нужно решить вполне конкретную задачу, простой изящный код не требует сверхусилий и оверинжиниринга. Чистая архитектура говорит, что нужно защищать свою доменную модель от внешних эффектов, и подсказывает, как именно это можно сделать. Эволюционный подход к наращиванию объема микросервисов. Тесты, которые делают рефакторинг менее страшным. Вы ведь уже знаете всё это? Или знаете, но боитесь даже подумать об этом, ведь это же ужас что тогда делать придётся?

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

Одна из критических проблем, которые возникают при построении многопользовательских систем – масштабирование. Существуют различные варианты решения это проблемы: шардинг, сервисная модель, Entity-Component System. Сегодня рассмотрим все варианты, а также обсудим практический кейс решения вопроса. Присоединяйтесь!