Отгремели выстрелы минувшего Ludum Dare 44, но тяга делать игры, оттачивать свое мастерство ещё не покидает меня, да и думаю многих. Проглядывая главную страницу онлайн-мероприятия, я наткнулся на интереснейший пост, где автор задался вопросом составления инструментария, помогающего разработчикам (командам) создавать свои игровые шедевры. В статье автор задался целью собрать в один список набор инструментов, псевдо-случайным образом генерирующих различные ресурсы для вашей игры, начиная от фиксированной палитры цветов, заканчивая простейшей chiptune-like фоновой музыкой и спрайтами персонажей.

Под катом перевод данной заметки, с небольшими комментариями и примечаниями от себя.

Раздел 1. Soft Skills

1. Я молчу на совещаниях. Стараюсь делать внимательное и умное лицо, даже если мне все равно.

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

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

Каждый в IT-индустрии знает, насколько сложно оценить срок выполнения проекта. Трудно объективно оценить, сколько времени займёт решение трудной задачи. Одна из моих любимых теорий заключается в том, что здесь имеет место просто статистический артефакт.

Предположим, вы оцениваете проект в 1 неделю. Предположим, есть три одинаково вероятных результата: либо он займёт 1/2 недели, либо 1 неделю, либо 2 недели. Медианный результат фактически такой же, как и оценка: 1 неделя, но среднее значение (aka average, aka expected value) составляет 7/6 = 1,17 недель. Оценка фактически откалибрована (беспристрастна) для медианы (которая равна 1), но не для среднего.

Колин Кролл был со-основателем Vine и HQ Trivia, невероятно успешных компаний с миллионами довольных пользователей. Энтони Бурден был шеф-поваром, журналистом и философом, принесшим чувство осознанности и причастности в миллионы жизней. Робин Уильямс был потрясающим актером и комедиантом.

Что общего у всех трех? Каждый из них достиг высот в своей отрасли и все они умерли слишком рано. Их преждевременная кончина — трагедия.

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

Данная статья посвящена сравнительному анализу логических сущностей из произведения немецкого философа Георга Вильгельма Фридриха Гегеля "Науки логики" с их аналогами или их отсутствием в программировании.

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

Примечание: Если вы считаете, что на построении архитектуры съели хотя бы полпёсика, то эта статья не для вас.

Модель — абстрактное представление реальности в какой-либо форме.

Предполагаем, что архитектор уже закончил со сбором требований к будущей системе и их анализом.

Разработку архитектуры нужно начинать только с понятия и принятия фундаментальной концепции работы с информацией (данными): передача, хранение и обработка. Притом формы ввода/выводы информации, схемы обработки, абстрактные структуры массивов и элементов данных сами по себе тоже являются информацией (как и всё приложение) и подчиняются той же фундаментальной концепции.

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

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

Персонаж — это личность. Без истории нет индивидуальности. Каждый хороший персонаж начинается с истории, а дизайн персонажа должен рассказать эту историю.

В своей предыдущей статье How To Make Low Poly Look Good я говорил, что главная цель низкополигонального (low poly) дизайна — донести сообщение через наименьшее количество форм.

Это особенно справедливо, когда вы создаёте низкополигонального персонажа. Нужно рассказать историю, использовав как можно меньше форм.

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

---

Я буду работать в Blender. В Maya, Max и других 3D-редакторах есть похожие инструменты, так что не беспокойтесь об этом.

Часть 1. Общий алгоритм поиска

Введение

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

Цель данной статьи — объяснить поиск пути в целом и A* в частности очень понятным и доступным образом, положив таким образом конец распространённому заблуждению о том, что эта тема сложна. При правильном объяснении всё достаточно просто.

Учтите, что в статье мы будем рассматривать поиск пути для игр; в отличие от более академических статей, мы опустим такие алгоритмы поиска, как поиск в глубину (Depth-First) или поиск в ширину (Breadth-First). Вместо этого мы постараемся как можно быстрее дойти от нуля до A*.

Примечание. Сокращенный перевод, скорее пересказ своими словами.
UPD: как отметили в комментариях, примеры не идеальны. Автор не ищет лучшее решение задачи, его цель объяснить сложность алгоритмов «на пальцах».

Big O нотация нужна для описания сложности алгоритмов. Для этого используется понятие времени. Тема для многих пугающая, программисты избегающие разговоров о «времени порядка N» обычное дело.

Если вы способны оценить код в терминах Big O, скорее всего вас считают «умным парнем». И скорее всего вы пройдете ваше следующее собеседование. Вас не остановит вопрос можно ли уменьшить сложность какого-нибудь куска кода до n log n против n^2.

Структуры данных

Выбор структуры данных зависит от конкретной задачи: от вида данных и алгоритма их обработки. Разнообразные структуры данных (в .NET или Java или Elixir) создавались под определенные типы алгоритмов.

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

Здесь мы будем использовать только массивы чисел (прямо как на собеседовании). Примеры на JavaScript.

Я только что завершил шестинедельный процесс трудоустройства на должность middle-senior разработчика на рынке, где сейчас ведется активная охота за талантами (Амстердам). Иными словами, я побывал на куче собеседований. Чтобы аккуратно разведать, какие компании мне больше всего подходят, я старался задавать побольше вопросов. Тут нужно найти правильный баланс, исходя из своих потребностей и того, кто с вами общается.

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

Эта статья написана по материалам моего выступления на HR Meetup #5, проходившего 5 октября 2018 года в г. Ростове-на-Дону.

О себе

Меня зовут Игорь Шелудько.

Я – предприниматель в сфере разработки и продаж программного обеспечения с 2000 года. У меня высшее техническое образование. Cвою трудовую деятельность я начинал как программист, также руководил небольшими командами.

Примерно полтора года назад я занялся коммерческим рекрутингом IT-специалистов – то есть не только для себя и своих проектов, а в пользу посторонних компаний. За 2018 год я «закрыл» 17 достаточно сложных вакансий для 10 компаний. Было еще около десятка компаний, с которыми я работал, но не смог или не успел помочь. В основном я подбирал веб-разработчиков, доводилось подбирать аналитиков и проект-менеджеров.

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

Вероятно, я не сделаю для вас какие-то открытия, скорее всего я повторю то, что вы уже слышали или читали ранее.

Привет, Хабр! Мы нашли очень крутую статью Designing Digital Products with Mental Models в блоге коллег из США, перевели ее и публикуем здесь. Автор статьи — дизайнер Тим Шеинер. Рекомендуем ее к прочтению всем, кто имеет отношение к разработке цифровых продуктов.

Лучший способ добиться взаимопонимания в проектной команде.

Перевод — это сложно

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

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

Итак, вы решили сделать новый проект. И проект этот — веб-приложение. Сколько времени уйдёт на создание базового прототипа? Насколько это сложно? Что должен уже со старта уметь современный веб-сайт?

В этой статье мы попробуем набросать boilerplate простейшего веб-приложения со следующей архитектурой:

Что мы покроем:

• настройка dev-окружения в docker-compose.
• создание бэкенда на Flask.
• создание фронтенда на Express.
• сборка JS с помощью Webpack.
• React, Redux и server side rendering.
• очереди задач с RQ.

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

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

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

Привет, Хабр! Приглашаем всех желающих на конференцию «(ИТ-) архитектор в ИТ-проектах и организациях» в центральный офис ЛАНИТ на Мурманском. Это будет серия вечерних встреч с экспертами, которые поделятся своим пониманием задач архитектора в сфере информационных технологий. Выступления можно будет послушать 20, 22, 27 и 29 марта. Регистрируйтесь и приходите. Для тех, кто не сможет прибыть лично, мы сделаем трансляцию в прямом эфире в группе ЛАНИТ на facebook.

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

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

Что вас бесит сильнее всего, когда вы пытаетесь организовать читаемые логи в вашем NodeJS приложении? Лично меня чрезвычайно напрягает отсутствие каких-либо вменяемых зрелых стандартов по созданию trace ID. В этой статье мы поговорим о том, какие есть варианты создания trace ID, разберемся на пальцах как работает continuation-local storage или CLS и призовем на помощь силу Proxy, чтобы завести все это с абсолютно любым логером.