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

Как сказано в Википедии:

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

Будьте осторожны

• Шаблоны проектирования — не «серебряная пуля».
• Не пытайтесь внедрять их принудительно, последствия могут быть негативными. Помните, что шаблоны — это способы решения, а не поиска проблем. Так что не перемудрите.
• Если применять их правильно и в нужных местах, они могут оказаться спасением. В противном случае у вас будет ещё больше проблем.

В статье приведены примеры на PHP 7, но пусть вас это не смущает, ведь заложенные в шаблонах принципы неизменны. Кроме того, внедряется поддержка других языков.

Многие разработчики знают, или должны знать, что Java-процессы, исполняемые внутри контейнеров Linux (среди них — docker, rkt, runC, lxcfs, и другие), ведут себя не так, как ожидается. Происходит это тогда, когда механизму JVM ergonomics позволяют самостоятельно задавать параметры сборщика мусора и компилятора, управлять размером кучи. Когда Java-приложение запускают без ключа, указывающего на необходимость настройки параметров, скажем, командой java -jar myapplication-fat.jar, JVM самостоятельно настроит некоторые параметры, стремясь обеспечить наилучшую производительность приложения.

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

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

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

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

Представляем статью авторства Пола Айриша и Пола Льюиса из команды Google Chrome о разработанной ими модели оценки производительности сайта. Ее можно с уверенностью назвать User-Centered Performance.

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

Конструкции, или почему не ломаются вещи, Дж. Гордон
Прекрасная, хоть и очень длинная штука, которая рассказывает про сопромат простыми словами и почти для детей. Но на уровне жёсткого хардкора. По своей полезности для осознания физики вокруг может сравниться с не менее прекрасной современной «Квантовая вселенная. Как устроено то, что мы не можем увидеть» Брайана Кокса и Джеффа Форшоу. Рекомендую обе. Будет, что почитать в дороге, если вдруг почувствуете, что играть на планшете надоело. И о чём подумать, когда выяснится, что вся та фигня, которую вам давали на уроках химии, физики и прочего в школе и университете вдруг начинает выстраиваться в стройную теорию.

Evil by Design, Крис Ноддер
Один из лучших подходов к проектированию чего-то хорошего — это спроектировать сначала самое ужасное из возможного. Пользователь обычно не скажет, как сделать ему хорошо, но точно знает, как бывает плохо. Например, юзер не говорит «я хочу, когда нажимаю на ссылку напоминания пароля, там в поле уже была введена почта», зато вполне способен сказать: «слушай, меня дико бесит, когда логинишься, тебе показывают новую страницу про то, что пароль не подошёл, и, чтобы его восстановить, надо ещё один долбанный раз вводить почту». Вся книга Криса состоит из таких «тёмных» шаблонов, когда какие-то гады намеренно вводят вас в заблуждение. Он там очень переживает за этику, поэтому вступления лучше пропустить. Единственная в этом обзоре книга на английском, но довольно простом.

Так уж вышло, что запуск cron в Docker-контейнере — дело весьма специфическое, если не сказать сложное. В сети полно решений и идей на эту тему. Вот один из самых популярных (и простых) способов запуска:

cron -f

Но такое решение (и большинство других тоже) обладает рядом недостатков, которые сходу обойти достаточно сложно:

• неудобство просмотра логов (команда docker logs не работает)
• cron использует свой собственный Environment (переменные окружения, переданные при запуске контейнера, не видимы для cron заданий)
• невозможно нормально (gracefully) остановить контейнер командой docker stop (в конце концов в контейнер прилетает SIGKILL)
• контейнер останавливается с ненулевым кодом ошибки

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

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

Пролог

В начале 2015 года я решил написать свою первую игру. В качестве движка я, не долго думая, выбрал Unity3D, так как у меня был опыт в C# и JavaScript, и знакомые, которые могли помочь. Я вспомнил одну мини-игру, в которую я играл в детстве, и решил сделать нечто похожее. Установил себе Unity и поставил себе цель сделать рабочий прототип за пару недель, параллельно изучая движок.

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

Один технический специалист нашей компании PayOnline, которая занимается автоматизацией приема платежей, предложил перевести статью автора Pascal de Vink, который проработал тим-лидом уже 2 года. Когда Pascal только занял эту должность, оказалось, что ко многим вещам он был просто не готов. Эта статья поможет избежать многих ошибок на пути от разработчика к лидеру команды. Ниже идет непосредственно перевод.

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

Меньше заниматься разработкой

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

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

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

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

Если вкратце — эксперимент провалился, в людях я в очередной раз разочаровался, а в последующих обновлениях мы пришли к банальной схеме «платежи + реклама». Зато удалось нащупать такой баланс между бесплатным контентом, премиум конктентом и ненавязчивой рекламой, который позволил и не разочаровать игроков (средняя оценка на Android — 4.75 при ~280.000 установок!), и окупить разработку (около 150.000 руб).

О рекламе стоит упомянуть сразу отдельно — в нашем случае это исключительно «видеореклама с вознаграждением за просмотр» (rewarded/incentivized video ads). В конце статьи расскажу, каких значений eCPM можно ожидать при ~10.000 показов в день в России от таких платформ, как UnityAds, Vungle, AdColony и Applovin.

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

Итак — про соль


Так в Африке ею и торгуют. Толщина кусков, вероятно определяется толщиной пласта. Слабенькие пласты.

Солить или не солить. А зачем вообще соль, может лучше без неё? Заменитель соли? Ценная соль с минералами и розового цвета — а зачем козе баян? Рекламные посты — хороший способ приготовить лапшу на уши.

Как-то на ФБ среди френдов образовалась дискуссия о том, сколько уровней управления должно быть для обеспечения эффективной деятельности организации. Вспомнил доклад Арнольда (не терминатора, а математика), представленный почти 20 лет назад, на семинаре при Президентском совете РФ. В докладе был сделан достаточно неожиданный вывод.

«Многоступенчатое управление, описываемое нашей моделью при n > 3, неустойчиво. Двухступенчатое управление приводит к периодическим колебаниям, но не вызывает катастрофического нарастания колебаний, происходящего при трех- и более ступенчатом управлении. Настоящую устойчивость обеспечивает только одноступенчатое управление, при котором управляющее лицо более заинтересовано в интересах дела, чем в поощрении со стороны начальства».

Как такое возможно, если в организации тысячи сотрудников?

Многие наверняка слышали о режимах смешивания (blend modes), которые присутствуют в большинстве популярных программ для работы с изображениями и видео. Там это — важный инструмент создания контента, давно уже ставший неотъемлемой их частью.

А что же в играх?

Допустим, появилась необходимость использовать Color Dodge смешивание для системы частиц или UI-художник сделал красивую графику для игрового интерфейса, но некоторые его элементы используют какой-нибудь Soft Light. А может, вам понадобилось подвергнуть трёхмерный объект Divide-смешиванию, чтобы получить эффект прямиком из кинокартин Линча?



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

Добрый день, хабра.

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

Больше видимости.

Фото Андрея Бодрова.

Часто в дискуссиях, особенно когда обсуждается реализация западных космических программ, проскакивают комментарии типа "Это все пиар" или "Это все Голливуд". Подразумевается, что за красивыми картинками нет реального содержания или оно незначительно, тогда как у нас дома происходит свершение за свершением, но у России свой особый путь, поэтому оглашать отечественные достижения вроде нет необходимости. На мой взгляд, такая позиция близорука и просто глупа. Попробуем разобраться, что такое космический пиар, нужен ли он Роскосмосу и РАН и зачем?

TL;DR. Мы пытались охватить многое, поэтому статья получилась пугающе объемной. Но, надеюсь, познавательной. А еще под нее ностальгировать можно.

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

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

Мой странный творческий путь занес меня в разработку игр. Благодаря отличной студенческой программе от IT-компании, название которой СостоИт из одной Греческой МАленькой буквы, сотрудничающей с нашим университетом, удалось собрать команду, родить документацию и наладить Agile разработку игры под присмотром высококлассного QA-инженера (здравствуйте, Анна!)

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

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

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

Макс Волошин (@willie), директор по развитию Redmadrobot, рассказывает об общих принципах делегирования и практиках внутри компании.