• Причины внедрить в процесс разработки статический анализатор кода PVS-Studio

      Причины внедрить в процесс разработки статический анализатор кода PVS-Studio

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

        image


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

        Читать дальше →
      • Как уязвимость в Яндекс.Станции вдохновила меня на проект: Музыкальная передача данных

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

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



          Под катом я расскажу, как сделан прототип, и дам ссылку на демку. Вы сможете сами послушать, как звучит любое сообщение :)
          Читать дальше →
        • Code review по-человечески (часть 1)

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

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

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

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

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

          Как вам нравится такая книжка? Предполагаю, что она вам не очень по душе.
          Читать дальше →
        • Архитектура программного обеспечения переоценена, простой и понятный дизайн — недооценен

          • Перевод
          image

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

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

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

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


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


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


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



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


            Читать дальше →
          • Оптимизация производительности .NET (C#) приложений

              image

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



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

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

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

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

                Вот как это происходило.
                Читать дальше →
              • Проблема дверей в дизайне шутеров

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


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

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

                Иллюстрация проблемы (GIF)

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

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

                Если расширить дверной проём, чтобы коридор выходил на арену, то мы получим другую версию той же проблемы. В чём-то она будет лучше, в чём-то хуже. Даже после увеличения порога ничто по-прежнему не привлекает игрока на арену, и ничто в коридоре не выталкивает его оттуда.
                Читать дальше →
              • Век живи — век учись. Часть 2. Вуз: 5 лет или 5 коридоров?

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


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

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

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

                  Делитесь своим опытом в комментариях — может быть, благодаря стараниям команды RUVDS и читателей Хабра чьё-то первое сентября окажется немного осознаннее, правильнее и плодотворнее. 
                  Читать дальше →
                • Курс Молодого Геймдизайнера 2: баланс прогрессии и динамики без математики



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

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

                    Бонусом в конце — несколько ссылок по теме.
                    Читать дальше →
                  • Курс Молодого Геймдизайнера: как считать баланс персонажей и снаряжения без математики



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

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

                      Статья будет полезна тем, кому надо заняться балансом, но не знает с чего начать, а также начинающим геймдизайнерам, которые будут выбирать специализацию. Ну и всем, кто просто интересуется, чем занимаются ГД, когда не придумывают новые виды лутбоксов.
                      Читать дальше →
                    • Peephole микрооптимизации в С++ и C# компиляторах

                        В школе, когда мы решали уравнения или считали формулы, мы пытались их сперва сократить несколько раз, к примеру Z = X - (Y + X) сокращается в Z = -Y. В современных компиляторах это подмножество так называемых peephole-оптимизаций, в которых мы по, грубо говоря, набору шаблонов сокращаем выражения, заменяем инструкции на более быстрые для конкретного процессора и т.п. В этой статье я собрал наборчик таких оптимизаций, которые удалось найти в исходниках LLVM, GCC и .NET Core (CoreCLR).


                        Начнем с простых примеров:


                          X * 1        =>  X
                        -X * -Y        =>  X * Y 
                        -(X - Y)       =>  Y - X  
                        X * Z - Y * Z  =>  Z * (X - Y) 

                        проверим последний пример в С++ и в C#:


                        int Test(int x, int y, int z) {
                            return x * z - y * z;  //  =>  z * (x - y)
                        }

                        и посмотрим на ассемблер от Clang (LLVM), GCC, MSVC и .NET Core:

                        Читать дальше →
                      • Отображаем контент на распознанном изображении по определенным правилам

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


                          Читать дальше →
                        • Пять ошибок, которые я допустил как ведущий разработчик

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

                          image

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

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

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

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

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

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


                          Читать дальше →
                        • Я прочитал 80 резюме, у меня есть вопросы

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

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


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

                            image

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

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

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

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

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

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

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

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

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

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

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

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

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

                            И я продолжил.
                            Читать дальше →
                          • ООП мертво, да здравствует ООП

                            • Перевод
                            image

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


                            Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым 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).
                            Читать дальше →
                          • Job System. Обзор с другой стороны

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

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

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

                            Читать дальше →