• Мультиплеер в быстрых играх (части I, II)



    1. Части I, II (синглплеер с авторитарным сервером)
    2. Часть III (Появление врага)
    3. Часть IV (Хэдшот!)


    Предлагаю вашему вниманию перевод статьи Fast-Paced Multiplayer (Part I): Introduction.

    Разработка игры — само по себе непростое занятие. Но мультиплеерные игры создают совершенно новые проблемы, требующие разрешения. Забавно, что у наших проблем всего две причины: человеческая натура и законы физики. Законы физики привнесут проблемы из области теории относительности, а человеческая натура не даст нам доверять сообщениям с клиента.
    Читать дальше →
  • Как теория ограничений помогает зарабатывать больше — личный опыт Логомашины

      image

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

      Книга Элияху Голдратта «Цель» подсказывает, что пропускная способность такой системы труб будет стремиться к пропускной способности самого узкого места. Другими словами, вы могли не искать трубы пошире — если в системе есть участок с диаметром 2 см., весь водопровод будет работать как труба в 2 сантиметра.

      Как этот принцип помогает зарабатывать больше? Сейчас расскажу.
      Читать дальше →
    • «Scrum. Революционный метод управления проектами». Книга за 15 минут

        image

        Недавно мы в MakeRight.ru с удовольствием прочитали книгу «Scrum. Революционный метод управления проектами» Джеффа Сазерленда. О чем она? В двух словах — о том, как организовать слаженную командную работу.
        Начав внедрять элементы скрама на практике, мы пришли к выводу, что идеи книги действительно работают.

        Революционный ли это метод, как указано в названии? Не знаем. Но, возможно, те, кто не читал книгу и не знаком с методикой, почерпнут для себя ряд полезных идей из нашего саммари (краткого изложения). Итак…
        Читать дальше →
      • GDPR — новые правила обработки персональных данных в Европе для международного IT-рынка

          image

          В мае 2018 года Европа переключится на обновлённые правила обработки персональных данных, установленные Общим регламентом по защите данных (Регламент ЕС 2016/679 от 27 апреля 2016 г. или GDPR — General Data Protection Regulation). Данный регламент, имеющий прямое действие во всех 28 странах ЕС, заменит рамочную Директиву о защите персональных данных 95/46/ЕС от 24 октября 1995 года. Важным нюансом GDPR является экстерриториальный принцип действия новых европейских правил обработки персональных данных, поэтому российским компаниям следует внимательно отнестись к ним, если услуги ориентированы на европейский или международный рынок.

          Новый регламент предоставляет резидентам ЕС инструменты для полного контроля над своими персональными данными. С мая 2018 года ужесточается ответственность за нарушение правил обработки персональных данных: по GDPR штрафы достигают 20 миллионов евро (около 1,5 млрд руб.) или 4% годового глобального дохода компании. В настоящей статье мы проанализировали новые правила обработки персональных данных в ЕС и сформулировали рекомендации для российских компаний по методам реагирования на GDPR.
          Читать дальше →
        • Непрерывная интеграция/внедрение приложения Symfony с помощью docker-compose и GitLab CI

          • Tutorial

          В статье я поделюсь своим опытом автоматизации всего процесса разработки приложения Symfony с нуля от настройки инфраструктуры до деплоя в production. От development- и до production-окружения для запуска приложения будет использоваться docker-compose, а все процедуры непрерывной интеграции/внедрения будут запускаться через GitLab CI/CD Pipelines в docker-контейнерах.


          Подразумевается, что вы знакомы с docker и docker-compose. Если нет или вы не знаете как его установить, я подготовил инструкцию по подготовке локального окружения разработчика. Фактически, для работы над приложением потребуется только Docker, VirtualBox и, опционально, Yarn.

          Читать дальше →
        • Как вычислить (город пользователя) по IP

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

            Местоположение — это важно.


            Читать дальше →
          • Docker, как показатель зрелости

            Когда мы были детьми, мы многого не понимали, что на данный момент является абсолютно очевидным. "Почему я не могу есть одни конфеты? Почему бутерброды — не еда, я же это ем? Почему я не могу спать с хомяком? Зачем чистить зубы каждый день, да еще целых два раза?!" Действительно, зачем? Но будучи взрослыми, зрелыми людьми, мы не задаемся подобными вопросами.


            Похожая ситуация происходит и в мире IT (возможно, это касается любой профессиональной деятельности). Многих вещей на начальных стадиях мы можем не понимать. "Зачем, да и вообще кому нужны всякие Symfony, если есть WordPress? Зачем тратить время на автоматическое тестирование, если и так все работает? Git? Linux? SOLID, DRY, DDD, TDD? Что за страшные слова?". Новичкам сложно понять, зачем нужно так много всего. Осознание приходит со временем и вскоре такие вещи становятся не только понятными, но и очевидными.


            Хочу рассказать свою историю того, как я дорос до Docker и что этому поспособствовало.

            Читать дальше →
          • GitHub Flow: рабочий процесс Гитхаба

            • Translation
            Краткое предисловие переводчика.
            Захватывающе интересная статья одного из разработчиков «GitHub Inc.» о принятом в компании рабочем процессе потребовала употребить пару специальных терминов при переводе.

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

            Другое понятие, «deploy», на русский часто переводят словом «развёртывание», но в моём переводе я решил вспомнить оборот из советского делопроизводства — «внедрение инноваций на производстве» — и стану говорить именно о «внедрении» новых фич. Дело в том, что описанный ниже рабочий процесс не имеет «выпусков» (releases), что делает несколько неудобными и речи о каком-либо «развёртывании» их.

            К сожалению, некоторые переводчики бывают склонны грубо убивать сочную метафору «иньекции» (или даже «впрыскивания», если угодно), содержающуюся в термине «code injection», так что и его также переводят словосочетанием «внедрение кода». Эта путаница огорчает меня, но ничего не могу поделать. Просто имейте в виду, что здесь «внедрением кода» я стану назвать внедрение его именно в производство (на продакшен), а не в чей-нибудь чужой код.

            Я стремился употреблять словосочетание «в Гитхабе» в значении «в компании GitHub Inc.», а «на Гитхабе» — в значении «на сайте GitHub.com». Правда, иногда разделять их сложновато.

            Проблемы git-flow


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

            Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

            Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

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

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

            Рабочий процесс Гитхаба


            Читать дальше →
          • Unit-тестирование скриншотами: преодолеваем звуковой барьер. Расшифровка доклада

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


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


              Читать дальше →
            • Что такое анти-паттерны?

                Анти-паттерны — полная противоположность паттернам. Если паттерны проектирования —
                это примеры практик хорошего программирования, то есть шаблоны решения определённых задач. То анти-паттерны — их полная противоположность, это — шаблоны ошибок, которые совершаются при решении различных задач. Частью практик хорошего программирования является именно избежание анти-паттернов. Не надо думать, что это такая непонятная теоретическая фигня — это конкретные проблемы, с которыми сталкивался практически каждый разработчик. Кто осведомлен, тот и вооружён! Рассмотрим же несколько расрпотранённых анти-паттернов в программировании.
                Да, рассмотрим!
              • Паттерны ООП в метафорах

                  Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
                  Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.
                  Читать дальше →
                • Нагрузочное тестирование «не-HTTP». Ч.2 Gatling

                    В первой части статьи мы провели сравнительный анализ средств нагрузки на Java для JMeter, ушли от XML тест-планов и достигли 30K RPS с одной машины, нагружая «не-HTTP» сервис на примере Apache Thrift.

                    В этой статье рассмотрим еще один инструмент для нагрузочного тестирования — Gatling и, как и обещали ранее, постараемся увеличить его производительность в десятки раз.

                    Читать дальше →
                  • Symfony + RabbitMQ Быстрый старт для молодых

                    • Tutorial
                    Всем доброго времени суток, друзья.
                    Сегодня захотелось поговорить о том, как можно работать с RabbitMQ в Symfony и совсем чуть-чуть о некоторых подводных комнях. В конце я напишу парочку интересных моментов о кролике (рус. перевод «rabbit») для тех, кто совсем в танке.

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

                    Статья 1
                    Статья 2
                    Статья 3
                    Статья 4
                    Статья 5

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

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

                    Если вы уже знаете, что такое консумер и почему в нем нужно делать $em->clear() + gc_collect_cycles, а после закрывать соединение с базой данных, то, скорее всего, вы ничего нового для себя не узнаете. Статья скорее для тех, кто не хочет разбираться с AMQP протоколом, но которым нужно прямо сейчас применять очереди и выбор почему-то бездумно пал на RabbitMQ, а не тот же легковесный beanstalkd.
                    Если же у вас микросервисная архитектура и вы ждете, что я расскажу вам как сварить коммуникацию между компонентами через AMQP, как красиво делать RPC, то я сам чего-то подобного очень давно жду на Хабре…
                    Читать дальше →
                  • Малюсенький CI вашего Symfony проекта за 2 минуты

                      Без воды о том, как за 10 минут сделать:
                      1.Проверяем ваш composer.json на серьезные и несерьезные ошибки, вроде неоптимального autoload
                      2.Проверяем ваш composer.lock на security уязвимости в пакетах
                      3.Проверяем вашу базу данных, что ничего не забыли
                      4.Проверяем ваши YAML файлы
                      5.Проверяем Coding Style по Symfony
                      Читать дальше →
                      • +20
                      • 9.5k
                      • 7
                    • Symfony Flex, как будет выглядеть ваше приложение с Symfony 4

                      • Translation
                      Symfony 4.0 выйдет в релиз в конце ноября 2017 года. Следующие несколько недель будут опубликовываться статьи о новых идеях и основных изменениях в Symfony 4.

                      Symfony 3.0 был скучным и являлся более лаконичной версией Symfony 2.8:
                      Symfony 3.0 = Symfony 2.8 — Deprecated Features.

                      Но что же будет представлять из себя Symfony 4.0 в отличии предыдущих версий:
                      Symfony 4.0 = Symfony 3.4 — Deprecated Features + Новые концепции разработки приложений.

                      Или вот еще один вариант развития событий:
                      Symfony 4.0 = Symfony 3.0 + All features added in 3.x — Deprecated Features + Новые концепции разработки приложений.
                      Читать дальше →
                    • Онлайн шутер на Unreal Engine 4 за 90 часов (видео создания + исходники)

                        Привет, харб! Примерно год назад я выкладывал статью о том, как я в прямом эфире создал выживалку за 150 часов. На этот раз хочу представить вам сетевой шутер, который я создал за 25 заходов по 3 — 4 часа. Всего вышло около 90 часов и в итоге мы создали онлайн шутер, в который сыграли вместе со зрителями.

                        image

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

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

                          Свершилось!


                          PostgreSQL приходит в Россию

                          Наша компания официально завершила перевод документации PostgreSQL текущей версии на русский язык и в этой публикации мы хотим поведать, как это было. Мы также хотели бы рассказать о пути, который мы прошли для достижения этой цели (и какие направления мы перепробовали), но это, пожалуй, тема для отдельной статьи.

                          Перевод самого PostgreSQL на русский язык начался в далёком 2001 году, тогда вышла только версия postgresql 7.1, и в самом postgresql усилиями в том числе и наших разработчиков только появлялась возможность локализации сообщений (см. тут). Впервые перевод сообщений на русский был включён в версию 7.2, вместе с переводами на французский, немецкий, шведский, китайский и чешский.
                          Читать дальше →
                        • Применение принципа poka-yoke в программировании на примере PHP

                          • Translation


                          Всем привет! Я Алексей Грезов, разработчик Server Team Badoo. Мы в Badoo всегда стараемся сделать так, чтобы наш код было легко поддерживать, развивать и переиспользовать, ведь от этих параметров зависит, насколько быстро и качественно мы сможем реализовать какую-либо фичу. Одним из способов достижения этой цели является написание такого кода, который просто не позволит совершить ошибку. Максимально строгий интерфейс не даст ошибиться с порядком его вызова. Минимальное количество внутренних состояний гарантирует ожидаемость результатов. На днях я увидел статью, в которой как раз описывается, как применение этих методов упрощает жизнь разработчикам. Итак, предлагаю вашему вниманию перевод статьи про принцип "poka-yoke".

                          Читать дальше →
                        • «Я не могу просто ходить с флагом «Postgres – наше всё». Нужно руками доказывать, что это работает» – Алексей Лустин

                            Наш сегодняшний собеседник – Алексей Лустин, IT-евангелист в мире 1С, инженер по инфраструктуре в концепциях DevOps и NoOps для 1С.

                            Алексей и его коллеги занимаются профессиональным обслуживанием бизнесов, работающих с платформой 1С. Они обучают клиентов, как эффективно использовать 1C на связке PostgreSQL + Linux. Оказывается, что очень часто проблема заключается не в самой платформе, а в неумелой эксплуатации. На PG Day'17 Russia Алексей проведет мастер-класс по переходу на PostgreSQL для 1С под кодовым названием Борьба со страхами.

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


                            image altPG Day: Алексей, расскажите о себе. Кто вы, чем занимаетесь, как пришли к своей специализации?

                            Алексей: Я называю себя евангелистом Automation Driven Development. Это такая концепция “от автоматизации деятельности айтишников”, чтобы разработчики и инфраструктурщики избавлялись от рутины и освобождали время для интересной работы. Последние четыре года стараюсь подружить два мира с помощью концепции CICD (Continuous Integration и Continuous Delivery): разработчиков и инфраструктурщиков. Ради этого и была организована наша команда. Причем основной приоритет именно на “мир 1С”, как наименее автоматизированный с точки зрения процесса.
                            Читать дальше →