— Не понимаю, почему люди так восхищаются этим Карузо? Косноязычен, гугнив, поёт — ничего не разберешь!
— А вы слышали, как поёт Карузо?
— Да, мне тут кое-что из его репертуара Рабинович напел по телефону.

Детектив по материалам IT. Часть первая

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

Проект мы переписали, уже без MVC, просто руководствуясь принципами – код перестал быть похож на клубок спагетти и сократился наполовину (об этом позже, в обещанной статье про то, как мы применяли «принципы» в своем проекте). Но хотелось понять, что же мы сделали не так, в чем была ошибка? И в течении долгого времени изучалось все, что содержало аббревиатуру MVC. До тех пор пока не встретились исходные работы от создателя – Трюгве Реенскауга…

И тогда все встало на свои места. Оказалось что фактически на основе принципов мы пере-изобретали «original MVC». А то, что зачастую преподносится как MVC, не имеет к нему никакого отношения… впрочем также как и к хорошей архитектуре. И судя по тому сколько людей пишет о несостоятельности «классического MVC», спорит о нем и изобретает его всевозможные модификации, не одни мы столкнулись с этой проблемой.

Более 30 лет собранные в MVC идеи и решения остаются наиболее значимыми для разработки пользовательских интерфейсов. Но как ни странно, несмотря на существующую путаницу и обилие противоречивых трактовок, разработчики продолжают довольствоваться информацией «из вторых рук», черпая знания о MVC из википедии, небольших статей в интернете и фреймворков для разработки веб-приложений. Самые «продвинутые» читают Мартина Фаулера. И почему-то почти никто не обращается к первоисточникам. Вот этот пробел и хотелось бы заполнить. И заодно развеять некоторые мифы.

PVS-Studio – это инструмент для поиска ошибок и потенциальных уязвимостей в исходном коде программ, написанных на языках C, C++, C# или Java. PVS-Studio относится к классу инструментов статического тестирования защищённости приложений (Static Application Security Testing, SAST). Анализатор ориентирован на практику непрерывной интеграции (CI) и позволяет выявлять ошибки на самых ранних этапах, когда их исправление почти ничего не стоит.

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

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

В итоге, пришел к выводу, что в этом процессе важно шоу. Но, что будет, если сделать протокол передачи данных, полностью ориентированный на впечатление пользователя? Так родился проект «Octave» — для мелодичной передачи данных.



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

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

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

Моя революционная книга обучит вас проверенным техникам по выявлению максимального количества недостатков в своём партнёре. Книга не затрагивает следующие области:

• Обсуждение проблем с сочувствием и пониманием.
• Помощь партнёру в устранении недостатков.

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

Как вам нравится такая книжка? Предполагаю, что она вам не очень по душе.

Вашему вниманию предлагается перевод поста Гергелия Ороса, занимающего должность Engineering Manager в Uber. В нем он делится своим взглядом на проектирование крупномасштабных систем, основанном на собственном практическом опыте работы в Uber и Microsoft. В сочетании с комментариями на Hacker News, которые добавляют весомые контр-аргументы и дополняют точку зрения автора, его статья стала одним из самых интересных постов недели. В статье используется термин «дизайн кода» для сравнения с традиционной «архитектурой» — о нем подробнее можно прочитать здесь.

На мою долю выпало достаточно опыта в проектировании и создании крупномасштабных систем. Я принимал участие в переписывании распределенной системы платежей в Uber, проектировании и релизе Skype на Xbox One и выпуске в открытый доступ RIBs — мобильного архитектурного фреймворка, созданного в Uber. Все эти системы имели тщательно продуманный дизайн, прошли через несколько итераций, с ними связано множество совещаний, проведенных у маркерной доски, и других обсуждений. Затем придуманный дизайн сводился к дизайн-документу, который распространялся среди других разработчиков для сбора дополнительной обратной связи, который продолжался до тех пор, пока мы не переходили к разработке.

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

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

Чжунго — самая развивающаяся страна в мире. Во всех сферах: производство, IT, биотехнологии. В прошлом году Китай показал крупнейший в мире валовый продукт, который составил 18% от мирового ВВП.

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

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

Старинная китайская гравюра. Дядюшка Ляо на прогулке придумывает iPhone 12 c ТВ-приёмником, пятью sim-картами, десятью камерами, термометром, шокером и пылесосом.

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

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

В мобильных играх много разных интерфейсов, включая HUD и огромное количество экранов для меты. UX-дизайнеры их проектируют, UI-дизайнеры отрисовывают, а чтобы всё это оказалось в движке существуют специально обученные люди — технические UI-дизайнеры. Ну или по-простому верстальщики. Частично их работа заключается в том, чтобы кропотливо из PSD-макета перенести все в префаб, чиселку за чиселкой. Еще они занимаются UI-анимациями, заливают спрайты, делают верстку адаптивной, расставляют ключи локализаций и так далее.

И мы поставили себе несколько целей:

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

Вот как это происходило.

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


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

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


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

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

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

Высшее образование в России — это тотем, фетиш, пунктик и идея фикс. С детства нам внушалось, что «поступить в институт» это джек-пот: все дороги открыты, работодатели выстроились в очередь, зарплата летит на карту. У этого явления есть исторические и социальные корни, но сегодня вместе с популярностью вузов высшее образование стало обесцениваться, и на то также есть причины. На такой почве отлично приживаются истории про бросивших вуз Билла Гейтса и Стива Джобса, которым «отсутствие образования» не помешало стать главными в своей сфере на этой планете. Между тем я берусь утверждать: высшее образование нужно, полезно, формирует специалиста более высокого уровня, ну а с Джобсом и Гейтсом не всё так просто, как пишут в мемах и на каких-нибудь «фишках». Давайте сегодня обсудим, как пройти 5 (6) курсов, а не коридоров и выжать из них профессиональный и личностный максимум. Gaudeamus igitur juvenes dum sumus, друзья!

С незабвенного Башорга по мотивам цитаты

Это вторая часть цикла «Век живи — век учись»

Часть 1. Школа и профориентация
Часть 2. Вуз
Часть 3. Дополнительное образование
Часть 4. Образование внутри работы
Часть 5. Самообразование

Делитесь своим опытом в комментариях — может быть, благодаря стараниям команды RUVDS и читателей Хабра чьё-то первое сентября окажется немного осознаннее, правильнее и плодотворнее. 

Предыдущая статья про баланс персонажей и снаряжения собрала много отзывов и я решил не тянуть с продолжением.

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

Бонусом в конце — несколько ссылок по теме.

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

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

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

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

Ведущий разработчик — не зря «ведущий». Эту фраза была услышана на одной из конференций по IT-менеджменту и вызвала вопрос, а почему собственно «не зря»? Именно этот вопрос и подтолкнул меня написать эту статью.



Оценивая свой опыт, могу сказать, что основные характеристики ведущего разработчика можно свести к 3 пунктам:

• Думает не только о своей грядке, но и обо всем огороде (это ключевое качество). Готов выстраивать стандарты и следить за их исполнением.
• Отлично знает свой язык и фреймворк, превосходно разбирается в архитектуре, имеет солидный опыт работы за плечами. «Солидность» не обязательно означает время проведенное за клавиатурой, важно количество и качество написанных проектов.
• Хочет и может аргументированно доносить свое мнение, отстаивать его и искать компромисс при необходимости.

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

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

Чуть более года назад я ушел с позиции ведущего разработчика окончательно и решил сделать небольшую ретроспективу своих самых досадных ошибок. Итак:

Ошибка номер 1. Оверменеджмент

У нас не очень простое собеседование. Нужно пройти 3 шага:

1. Прислать резюме, программист его посмотрит, лайкнет если всё хорошо. Рекрутер позвонит, задаст несколько вопросов.
2. Встретиться или созвониться с нами. Узнаем, какой вы специалист.
3. Прийти на тестовый день. Познакомиться с командой и поработать вместе. Пообщаться с техническим директором, обсудить зарплату и получить оффер.

Я три месяца был тем программистом, который оценивает резюме. Мне есть о чём с вами поговорить.

— Папа, расскажи мне сказку, — подошел ко мне крошка сын.

— Может быть не прямо сейчас, сына? У меня пинкидемон какой-то резиновый попался, от него пули отскакивают, — пробормотал размахивая свитчем я, — вот дойду до точки сохранения и…

— Сейчас, — наставал сын, — Надо.

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

— Обещаю не жаловаться, — радостно отрапортовал сын.

Своего обещания, он, конечно, не сдержал. Потому что я рассказал историю Магрибского Молитвенного Коврика.

— Это какая-то неправильная сказка, — возмущался малыш, — В ней нет ни логики, ни смысла, ни морали.

— Добро пожаловать в реальный мир, сына. У нас тут такое всё.

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

А вот это был удар ниже пояса. Репутацию нужно было спасать.

— Ты потер нужную лампу, сынуля. Я литератор. Я могу поправить любую историю.

— Ты заново перепишешь сказку?

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

И я продолжил.

Источники вдохновения

Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!

Слайды Араса выложены здесь: http://aras-p.info/texts/files/2018Academy — ECS-DoD.pdf, а код находится на github: https://github.com/aras-p/dod-playground.

Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).

Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!

TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).

В новой версии unity 2018 года наконец официально добавили новую систему Entity component system или сокращенно ECS которая позволяет вместо привычной работы с компонентами объекта работать только с их данными.

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

В Unity3D с выходом версии 2018 появилась возможность использовать нативную (для Unity) ECS систему, сдобренную многопоточностью в виде Job System. Материалов в интернете не особо много (пара проектов от самих Unity Technologies да пара обучающих видео на ютубе). Я попробовал осознать масштаб и удобность ECS, сделав небольшой проект не из кубов и кнопок. До этого у меня не было опыта проектирования ECS, так что два дня ушло на изучение материалов и перестроение мышления с ООП, день ушел на восхищение подходом, и еще один-два дня — на разработку проекта, борьбу с Unity, выдергивание волос и курение семплов. В статье содержится немного теории и небольшой пример проекта.