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

Список лекций:

• Лекция 1. Введение
• Лекция 2. Функции, структуры, интерфейсы. Объектная модель
• Лекция 3. Асинхронная модель
• Лекция 4. Web. Работа с сетью
• Лекция 5. Работа с СУБД
• Лекция 6. Система тестирования
• Лекция 7. Reflect or generate?
• Лекция 8. Производительность
• Лекция 9. Context, unsafe, cgo

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

Сегодня поговорим о bash-скриптах. Это — сценарии командной строки, написанные для оболочки bash. Существуют и другие оболочки, например — zsh, tcsh, ksh, но мы сосредоточимся на bash. Этот материал предназначен для всех желающих, единственное условие — умение работать в командной строке Linux.

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

В «Симуляторе мечты» описывается старая добрая история мира из сериала Westworld – когда игрокам предлагают сложный мир со внутренними конфликтами, прямо шедевр искусства. А они сразу всех убивают и насилуют. Не обязательно в такой последовательности.

После выпуска Ultima Online Ричард Гэрриот сказал: «Мы думали, это будет что-то фантастическое. Мы потратили на неё огромное количество времени и сил. Но случилось то, что игроки просто шли и убивали всех так быстро, что игра даже не переходила на новый виток, и симулятор жизни даже не начинался. И эту часть, на которую мы потратили столько времени, даже никто ни разу не заметил, ни разу! И в итоге мы просто удалили ее из игры».

А дальше вводится совершенно сумасшедшая концепция оценки плотности сюжета – модель в голове игрока. Это очень многое для меня перевернуло.

Спустя полгода сообщество Go-разработчиков снова воссоединилось в нашем московском офисе 14 апреля. И теперь у нас есть возможность ознакомиться с тем, как проходила эта встреча. Пять докладов и прочие подробности ищите под катом.

Псевдотонирование: обзор

Про сегодняшнюю тему для программирования графики — псевдотонирование (дизеринг, псевдосмешение цветов) — я получаю много писем, что может показаться удивительным. Вы можете подумать, что псевдотонирование — это не то, чем программисты должны заниматься в 2012 году. Разве псевдосмешение — не артефакт история технологий, архаизм времён, когда дисплей с 16 миллионами цветов программистам и пользователям мог только сниться? Почему я пишу статью о псевдотонировании в эпоху, когда дешевые мобильные телефоны работают с великолепием 32-битной графики?

На самом деле псевдотонирование по-прежнему остаётся уникальным методом не только по практическим соображениям (например, подготовка полноцветного изображения для печати на чёрно-белом принтере), но и по художественным. Дизеринг также находит применение в веб-дизайне, где этот полезный метод используется для сокращения числа цветов изображения, что уменьшает размер файла (и трафик) без ущерба для качества. Он также используется при уменьшении цифровых фотографий в формате RAW в 48 или 64 бита на пиксель до RGB в 24 бита на пиксель для редактирования.

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

Этот пост является версией моей же англоязычной статьи "How to avoid gotchas in Go", но слово gotcha не переводится на русский, поэтому я буду использовать это слово как без перевода, так и немного непрямой вариант — "наступать на грабли".

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

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

Но один вопрос меня мучал долгое время — почему я сам никогда не делал этих ошибок? Серьезно, самые популярные из них, вроде путаницы с nil-интерфейсом или непонятного результата при append()-е слайса — в моей практике никогда не были проблемой. Каким-то образом мне повезло обойти эти подводные камни с первых дней своей работы с Go. Что же мне помогло?

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

От переводчика: данная статья написана Manuel Kiessling в сентябре 2012 года, как реализация статьи Дядюшки Боба о чистой архитектуре с учетом Go-специфики.



Перед этой статьей я перевел ее прообраз — смотреть здесь. Поскольку в рамках этой статьи будет активно использоваться описанное в статье Дядюшки Боба, то лучше начать с нее… если Вы, конечно, ее еще не читали.

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

В данной части будет описана общая концепция и работа с внутренним слоем.

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

Ускорение каких-либо процессов невозможно без детального представления их внутреннего устройства. Ускорение интернета невозможно без понимания (и соответствующей настройки) основополагающих протоколов — IP и TCP. Давайте разбираться с особенностями протоколов, влияющих на скорость интернета.

IP (Internet Protocol) обеспечивает маршрутизацию между хостами и адресацию. TCP (Transmission Control Protocol) обеспечивает абстракцию, в которой сеть надежно работает по ненадежному по своей сути каналу.

Протоколы TCP/IP были предложены Винтом Серфом и Бобом Каном в статье «Протокол связи для сети на основе пакетов», опубликованной в 1974 году. Исходное предложение, зарегистрированное как RFC 675, было несколько раз отредактировано и в 1981 году 4-я версия спецификации TCP/IP была опубликована как два разных RFC:

• RFC 791 – Internet Protocol
• RFC 793 – Transmission Control Protocol

Это перевод статьи Alex Danilo о User Timing API, опубликованной 21 января 2014.

Высокая производительность веб-приложений является решающей для достижения хорошего user experience. В то время, как веб-приложения становятся все более сложными, понимание влияния производительности жизненно небходимо для создания конкурентноспособного user experience. За последние несколько лет в браузерах появились различные API, позволяющие анализировать производительность сети, время загрузки и т.д., но они не предоставляют необходимую информацию с достаточной гибкостью для поиска проблем, которые замедляют приложение. Использование User Timing API предоставляет механизм, позволяющий определить какая часть вашего приложения является наиболее медленной. В этой статье будет показана работа с User Timing API и примеры его использования.

Производительность всегда играла ключевую роль в программном обеспечении. А в веб-приложениях её значение ещё выше, поскольку пользователи легко могут пойти к конкурентам, если сделанный вами сайт работает медленно. Любой профессиональный веб-разработчик должен об этом помнить. Сегодня по-прежнему можно успешно применять массу старых приёмов оптимизации производительности, вроде минимизации количества запросов, использования CDN и не использования для рендеринга блокирующего кода. Но чем больше разработчики применяют JavaScript, тем важнее становится задача оптимизации его кода.

Можете представить, что Вам больше никогда не придется устанавливать зависимости и настраивать конфигурации вручную на вашем сервере непрерывной интеграции? А вы верите в то, что каждый шаг вашего билда может быть по-настоящему изолированным и работать исключительно в Docker контейнерах? В конце концов, хотели бы вы попробовать инструмент, который входит в топ 20 всех открытых проектов, написанных на Golang, и имеет 9k+ звездочек на Github?

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

Перевод статьи Andrew Hobden "Pretty State Machine Patterns in Rust". Ссылка на оригинал в конце.

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

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

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

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

Не будем лукавить: JavaScript никогда не был идеальным языком программирования. Одним из слабых мест в JS была модульность, а точнее её отсутствие. Действительно, зачем в скриптовом языке, который анимирует падающие на странице снежинки и валидирует форму, заботиться об изоляции кода и зависимостях? Ведь всё может прекрасно жить и общаться между собой в одной глобальной области — window.

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

Эта статья появилась в результате общения с участниками TC39 и разработчиками фреймворков, а также чтения исходных кодов, блогов и книг. Мы рассмотрим следующие подходы/форматы: Namespace, Module, Detached Dependency Definitions, Sandbox, Dependency Injection, CommonJS, AMD, UMD, Labeled Modules, YModules и ES2015 Modules. Кроме того, мы восстановим исторический контекст их появления и развития.

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

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

Однажды мне понадобилось в Zabbix сделать мониторинг потери пакетов между мастером и репликами (репликация плохо себя чувствует если канал не очень хороший). Для этого, в Zabbix есть встроенный параметр icmppingloss, на удаленный хост отправляется серия ICMP пакетов и результат фиксируется в системе мониторинга. И вот параметр добавлен, триггер настроен. Казалось бы задача выполнена, однако как говорится «Доверяй, но проверяй». Осталось проверить что триггер сработает когда потери действительно будут. Итак, как сэмулировать потерю пакетов? Об этом, да и не только, пойдет речь под катом.

Введение

В 2017 году большинство популярных веб-игр типа agar.io использует для передачи данных WebSockets через TCP. Если бы в браузерах был встроенный UDP-аналог WebSockets, то это бы сильно улучшило работу с сетями в этих играх.

Вводная информация

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

Всё это отлично работало многие годы, но недавно веб-сайты стали более интерактивными и перестали отвечать парадигме «запрос-ответ» протокола HTTP. Для решения этой проблемы изобретены современные веб-протоколы, такие как WebSockets, WebRTC, HTTP 2.0 и QUIC, имеющие потенциал значительного улучшения интерактивности сети.

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

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

Для наглядного примера я буду использовать маршрутизатор Mikrotik CCR1036-8G-2S+ и коммутатор CRS125-24G-1S.

Этот вариант на данный момент работает в нескольких гостиницах Москвы и Московской области.
Поставим условную задачу, чтобы на каждом коммутационном узле присутствовала сеть класса А (10.1.0.0/24) для работников фирмы и сеть класса С (192.168.1.0/24) для WiFi для посетителей.

Допустим, у нас имеется коммутационный узел A c маршрутизатором Mikrotik CCR1036-8G-2S+, коммутационный узел B с коммутатором CRS125-24G-1S. Коммутационные узлы А и В будут соединены каналом связи (Trunk) в нашем случае по витой паре (каналов связи (trunk) может быть несколько в зависимости от количества коммутационных узлов; также если имеется ВОЛС и оптический модуль SFP mikrotik, то можно trunk назначить и на SFP). Приведу ниже схему с использованием trunk по витой паре.


Приступим к настройке коммутационного узла A с маршрутизатором Mikrotik CCR1036-8G-2S+.

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



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

С 1 февраля 2017 года вступили в силу поправки к закону 54-ФЗ о контрольно-кассовой технике.

Эти поправки вносят ряд изменений и новых требований по работе с кассами и кассовыми чеками. О том, как мы адаптировали CMS «1С-Битрикс» под новую редакцию закона, чтобы облегчить жизнь интернет-магазинам, читайте под катом.