Project Hospital — это игра об управлении зданием больницы со всеми стандартными аспектами жанра: динамическими сценами, создаваемыми игроком, множеством активных персонажей и объектов, развёрнутой системой UI. Чтобы заставить игру работать на разном оборудовании, нам пришлось приложить много усилий, и это стало отличным примером печально известной «смерти от тысячи порезов» — множества мелких шагов, решающих кучу очень специфических проблем и кучи времени, потраченного на профилирование.

Уровень производительности: чего мы хотели достичь

На раннем этапе разработки мы определились с основными параметрами: максимальной величиной сцен, уровнем производительности и системными требованиями.

Мы поставили перед собой задачу обеспечить поддержку не менее сотни активных и полностью анимированных персонажей на одном экране, трёх сотен активных персонажей суммарно, тайловых карт размером примерно 100x100 и до четырёх этажей в здании.

Мы твёрдо были уверены, что игра должна работать в 1080p с приличной частотой кадров даже на интегрированных графических картах, и саму по себе эту цель достичь было не так трудно: основным ограничивающим фактором является ЦП, особенно при увеличении объёмов больницы. Современные интегрированные видеокарты начинают испытывать проблемы только при разрешениях примерно от 2560 x 1440.

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

Я постоянно делаю коммиты в проекты open source (Red Hat и др.). И заметил, что больше всего времени отнимают негативные код-ревью, субъективные по сути. Чаще всего такое происходит с коммитами, где мейнтейнеру по какой-то причине не нравится ваше изменение. В лучшем случае такая стратегия код-ревью приводит к потере времени в бессмысленных спорах; в худшем случае он активно препятствует коммиту, создавая враждебную и элитарную среду.

Код-ревью должен быть объективным, кратким и, по возможности, содержать только определённые факты. Это не политический или эмоциональный спор, а технический. Его цель — продвижение вперёд, развитие проекта и всех участников. Любой коммит должен оцениваться только по существу, а не по субъективному мнению.

На этой неделе достаточно крупных мелких радостей не нашлось, зато нашлись 3 совсем мелкие мелкие радости.

termtosvg

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

Традиция, бесспорно, хорошая и правильная. Только записывать такие анимации бывает трудно/лень/некогда. Авторы termtosvg пристрелили всех зайцев одим выстрелом и дали программистам прекрасную штуку для записи консольных демок.

Даже в очень крупных компаниях часто отношение к разработчикам, как к грибам: держат в темноте и кормят навозом. Пишите код, родные, и не высовывайтесь. Этот подход может быть удобен для многих (в том числе иногда — для самих разработчиков в случае не очень адекватного менеджмента), но с точки зрения бизнеса неоптимален. Моя позиция: разработчики должны иметь возможность узнавать всё то, что происходит в компании и на рынке, но без давления. Захотел — копнул и разобрался, не захотел — не надо.

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

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

Как проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Требования и спецификации — пережиток прошлого?

Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндексе, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.

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

Не буду лукавить: основная задача статьи — возбудить интерес. Так что в ней будет минимум пространных рассуждений и максимум конкретики.

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

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

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

О том, как мы выбирали систему мотивации для разработчиков Calltouch, рассказывает руководитель разработки Роман Хохлов.


Источник изображения

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

Меня зовут Рушан, и я автор Telegram‑канала Нейрон. Не забудьте поделиться с коллегами или просто с теми, кому интересны такие статьи.

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

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



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

Поэтому давайте немного развлечёмся и напишем точную систему уведомлений о свободной парковке с помощью Python и глубокого обучения

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

Поле

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

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

Туториал создавался в Unity 2018.3.0f2.


Поле, готовое к использованию в тайловой игре жанра tower defense.

Игра жанра Tower Defense

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

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

Домашний сервер, где происходит многое из описанного ниже:

Что надо сохранять?

Самое важное и объёмное у меня — фотографии. Изредка видео, но очень изредка — оно слишком много места занимает и слишком много времени отнимает, потому я его не слишком люблю, снимаю только короткие ролики, которые валяются в той же куче, где и фотографии. На текущий момент фотоархив у меня занимает примерно 1,6 терабайта и растёт где-то на 200 гигабайт в год. Другие важные вещи гораздо менее объёмны и с ними меньше вопросов в плане хранения и бэкапа, десяток-другой гигабайт можно распихать по куче бесплатных или очень дешевых мест, начиная от ДВД и заканчивая флэшками и облаками.

Компактные устройства для просмотра слайдов через линзу выпускались во всём мире, и в СССР в том числе (примеры: 1 и 2). Сегодня внутрь такого прибора можно поместить Raspberry Pi Zero с небольшим дисплеем. Практически все винтажные детали, включая линзу и выключатель, при этом остаются на месте. К RetroPie автором «прикручена» тема в стиле «Звёздных войн» (разработчики — CoinJunkie и ArcadePunks).

От переводчика: RetroPie — лишь один из вариантов, vi за такой линзой будет тоже здорово смотреться даже без cool-retro-term, только вместо геймпада понадобится клавиатура. Колонка станет ненужной, потребляемый ток соответственно уменьшится.

Продолжая серию дайджестов «Стартап дня», сегодня я представляю самые интересные проекты за сентябрь-октябрь 2018 года. Если хотите ознакомиться с остальными, то прошу в мой блог. Записи доступны в Facebook, ВК, ICQ и Телеграм.

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

Помните правила великого Кутузова, который четко и ясно видел стратегические цели? Он считал, что стратегия должна всегда превалировать над тактикой. Для победы вполне допустимо пожертвовать отдельной битвой, ведь «главное не крепость взять, а войну выиграть».

Преподаватели Binary District подготовили список книг для будущих студентов курса Project Management in IT: это база, способная сделать из хорошего управленца лучшего. Список настолько хорош, что по крайней мере половину книг можно смело рекомендовать вообще всем, кто хочет стать лучшей версией себя.

Привет, Хабр! Со временем, маркетологам начинает хотеться делать воронки ремаркетинга по событиям, а потом еще и преследовать по всем каналам.

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

Чтобы было проще масштабировать ремаркетинг на другие системы, сейчас мы сделаем синхронизацию событий GA в Метрику, Facebook, VK, MyTarget.


Поехали!

«Всё — яд, всё — лекарство; то и другое определяет доза.»
Парацельс

Принято отсчитывать историю Agile от февраля 2001 года, когда появился на свет довольно странный документ — Agile Manifesto. По большому счёту текст документа скомпонован из философских очевидностей (например, «простота — искусство не делать лишней работы») и спорных утверждений (например, «лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды»). Но этот документ странен не столько своим содержанием (мало ли что может прийти в голову на лыжном курорте), сколько эпичностью последовавших изменений в отрасли разработки программного обеспечения. В кратчайшее время появилось множество методик, реализующих методологию «гибкой» разработки, которые торжественным маршем пошли по миру, захватывая умы Исполнителей и кошельки Заказчиков. Адептами этот движ преподносится как некая волшебная пилюля, решающая всё. Дошло до того, что благородному дону честному программисту уже стало неприличным признаться в причастности к разработке ПО по традиционной ориентации методологии. Попробуем же разобраться в причинах и следствиях явления, на примере Scrum-а, как наиболее распространённого проявления Agile.

В Интернете найдется немало статей, посвященных адаптивным логотипам. Наиболее популярным примером является сайт Responsive Logos, который показывает различные варианты известных логотипов для разных размеров экрана. Когда я впервые увидел это, я подумал, что это не более, чем просто ловкий трюк. В конце концов, это просто div для спрайта большого изображения в качестве фона. Так было до того момента, пока я не услышал доклад на Smashing Conference от MikeRiethmuller под названием «За пределами медиазапросов». Кроме того, я настоятельно рекомендую прочитать его же статью «Большой потенциал SVG».



Я узнал две вещи, которые меня потрясли:

1. При использовании SVG вы можете отказаться от атрибута viewBox и установить новую систему координат на вложенных элементах SVG путем применения нового viewBox. (Да, я знаю. Это звучит странно. Ниже я объясню все более подробно).
2. Когда вы используете медиазапросы внутри SVG-файлов, а затем вставляете изображение через тег img или в качестве фонового изображения CSS, медиазапросы привязаны к ширине изображения. Практически такое же поведение, как и при использовании контейнерных запросов.

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

«Бесплатно? Звучит дороговато!» — с подобными возгласами устаешь бороться. Также тяжело постоянно объяснять почему АТС бесплатна, что это принцип работы дать максимум и что нигде не заложены тысячи скрытых платежей.



С этого лета специально для сомневающихся и желающих найти цену АТС в тарифах, мы ввели платные тарифные пакеты на облачную АТС Zadarma (при этом бесплатные условия остаются прежними). Зачем это было сделано и когда платный тариф может быть еще выгоднее чем бесплатный опишем ниже.