Что такое CI

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

Если вы не знаете как настроить CI в своем проекте, я приглашаю вас "под кат"

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

В начале я не планировал как-то раскрывать или упоминать эту тему, но потом подумал, что оформить "Best Practices" было бы неплохо даже для себя и своей команды.

Так что, если вам интересно, как мы делали сеть для нашей Armored Warfare: Assault, добро пожаловать под кат.

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

В этой статье мы рассмотрим, каким образом можно наблюдать за работой продукта и его боевым окружением, научимся собирать жизненно необходимые метрики и представлять их в удобоваримом виде. Узнаем, что такое Time Series и как они могут помочь нашим и сторонним приложениям в процессе диагностики. Подробно познакомимся с лидерами рынка инструментов для мониторинга, специализированным хранилищем InfluxDB и системой визуализации данных Grafana.

Прототипом статьи является доклад Анатолия Кулакова на DotNext 2017 Moscow. Анатолий получал образование специалиста по информационной безопасности, затем зарабатывал как суровый C++ разработчик под Linux. Когда надоело кодировать и захотелось творить, перешёл на C#. Пишет на .NET с первых его версий. Занимается проектированием и построением бизнес-приложений, распределённых и отказоустойчивых систем. Отдыхает с ES, CQRS и DDD.

Перед просмотром можно загрузить слайды в формате PDF.

Осторожно, трафик! В этом посте присутствует огромное количество картинок — слайдов и скриншотов с видео в формате 720p. На слайдах присутствует важный для понимания статьи код.

В основе этой статьи доклад Дениса Иванова (@DenisIvanov) на РИТ++ 2017, в котором он поделился опытом разработки и запуска в продакшен REST-сервиса на ASP.NET Core на Kubernetes. На текущий момент это сделать уже можно без особенных проблем и бояться использовать .NET Core, судя по опыту 2ГИС, не стоит.

Конфигурация: ASP.NetCore на Linux позволила не только использовать существующую on-premise платформу, но и принесла еще несколько дополнительных плюсов, в частности, в виде полноценных Docker и Kubernetes, которые сильно упрощают жизнь.

О сервисе

С 1 апреля 2017 года в продуктах 2ГИС появилась иконка, на которую можно нажать и начнет проигрываться видео. Рекламодатели, которые размещаются в справочнике, теперь могут купить новый способ размещения рекламы, а все продукты нашей компании (мобильные, онлайн, API), ходят на сервис, про который я буду сегодня рассказывать.

Топология этого сервиса примерно представлена на картинке ниже. Сервис помечен облачком в центре, он, по сути дела, является бэкендом для продуктов. Когда продукт приходит и говорит: «Дай мне для этого рекламодателя всю информацию о видеорекламе», сервис ему послушно ее отдает. Это информация такого плана: такая-то обложка лежит на таком-то CDN, такой-то видеофайл в таких-то разрешениях лежит там-то и там-то, само видео длится такое количество времени и прочее.


Осторожно: много информации и кода.

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

Прототипом статьи послужил доклад Дмитрия Сошникова на конференции DotNext 2017 Moscow. Дмитрий — технологический евангелист компании Майкрософт, занимается популяризацией современных технологий разработки программного обеспечения среди начинающих разработчиков. Специализируется в области интернета вещей, в разработке универсальных приложений Windows, в области функционального программирования и на платформе .NET (F#, Roslyn). Лично провел несколько десятков хакатонов по всей России, помогал многим студенческим стартапам начать свои проекты в различных областях. Доцент, к.ф.-м.н., ведет занятия в МФТИ и МАИ, член Российской ассоциации искусственного интеллекта, летом — ведущий кафедры компьютерных технологий детского лагеря ЮНИО-Р.

Осторожно, трафик! В этом посте присутствует огромное количество картинок — слайдов и скриншотов с видео в формате 720p.

Разработчики постоянно задают нам вопросы о налогах, которые должны платить при выводе средств на российское лицо по договору с Apple. Поводом беспокойства служит известный Налог на Гугл, введенный с начала 2017 года.

Поэтому мы разместили в свободном доступе перевод последней редакции Apple Developer Program License Agreement Schedule 2 и подготовили налоговые комментарии к нему.

Кому интересно, смотрим далее.

История про CLion, docker, conan, cmake, ninja, cotire и gdb.

Небольшое предисловие

Разработкой на C++ я занимаюсь уже лет 15 и когда-то начинал с «Watcom С». О нем у меня остались самые теплые воспоминания. Но, так как мне больше приходилось писать для консоли UNIX, я перешел на vim в качестве IDE. В целом, он достаточно удобен. Его плагины творят чудеса, можно настроить autocomplete, просмотр иерархии классов, быстрый переход к определению или поиск, в общем всё, что должны уметь IDE, там можно поднять. Боль приходит в тот момент, когда ты пытаешься установить и освоить новый плагин. Это всё заводится не везде и не всегда, и, зачастую, жрет проц и память похлеще любой java.

Периодически я поглядывал на Qt Creator. Но так и не решился на него перейти.

Первое знакомство

И вот, в один из таких моментов мне на глаза попался CLion.

Всем привет! В нескольких статьях я хотел бы поделиться опытом создания подобия ММО игры используя Unreal Engine и Netty. Возможно архитектура и мой опыт кому-то пригодится и поможет начать создавать свой игровой сервер в противовес unreal dedicated server, который слегка прожорлив или заменить собой фреймворки для разработки многопользовательских игр такие как Photon.

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

Часть 1. Общая картина, сборка библиотек, подготовка клиента и сервера к обмену сообщениями
Часть 2. Наращивание игрового функционала + алгоритм Diamond Square

TCP-стеганография не является чем-то принципиально новым, например Джон Торакис в 2016 году реализовывал на Питоне довольно интересные вещи, жаль не все они есть в открытом доступе. Не была она принципиально новой и на момент написания статей Торакисом. Вот пост на Хабре 2009 года, описывающий идею и, например, программа Covert_TCP далекого (а может и не очень) 1996 года, написанная на чистом Си и реализующая довольно тонкие настройки.

Если Covert TCP предлагает передавать по одному байту полезной нагрузки в TCP пакете, Торакис использовал от 2 до 6 байт на пакет и предложил идею создания протокола в протоколе. Но даже таким образом затруднительно передать большие массивы данных.

Тут на помощь может прийти система одноразовых сообщений. Действительно, почему бы не объединить 2 подхода, раз они изобретены до нас?

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

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

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



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

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

Основные пункты, от которых я отталкивался:

1. С клиентской стороны никакого Flash, только html + js;
2. Одна машина должна тянуть как можно больший онлайн игроков;
3. Возможность горизонтального масштабирования;
4. Низкий порог вхождения в игру и быстрый старт;
5. Чуть более разнообразный геймплей, чем в слитерио;
6. Красивый и запоминающийся домен;

Привет всем! Меня зовут Сергей Камардин, я программист команды Почты Mail.Ru.

Это статья о том, как мы разработали высоконагруженный WebSocket-сервер на Go.

Если тема WebSocket вам близка, но Go — не совсем, надеюсь, статья все равно покажется вам интересной с точки зрения идей и приемов оптимизации.

Apache Cassandra — это одна из популярных распределенных дисковых NoSQL баз данных с открытым исходным кодом. Она применяется в ключевых частях инфраструктуры такими гигантами как Netflix, eBay, Expedia, и снискала популярность за свою скорость, способность линейно масштабироваться на тысячи узлов и “best-in-class” репликацию между различными центрами обработки данных.

Apache Ignite — это In-Memory Computing Platform, платформа для распределенного хранения данных в оперативной памяти и распределенных вычислений по ним в реальном времени с поддержкой JCache, SQL99, ACID-транзакциями и базовой алгеброй машинного обучения.

Apache Cassandra является классическим решением в своей области. Как и в случае с любым специализированным решением, её преимущества достигнуты благодаря ряду компромиссов, значительная часть которых вызвана ограничениями дисковых хранилищ данных. Cassandra оптимизирована под максимально быструю работу с ними в ущерб остальному. Примеры компромиссов: отсутствие ACID-транзакций и поддержки SQL, невозможность произвольных транзакционных и аналитических транзакций, если под них заранее не адаптированы данные. Эти компромиссы, в свою очередь, вызывают закономерные затруднения у пользователей, приводя к некорректному использованию продукта и негативному опыту, либо вынуждая разделять данные между различными видами хранилищ, фрагментируя инфраструктуру и усложняя логику сохранения данных в приложениях.

Возможное решение проблемы — использование Cassandra в связке с Apache Ignite. Это позволит сохранить ключевые преимущества Cassandra, при этом скомпенсировав ее недостатки за счет симбиоза двух систем.

Как? Читайте дальше, и смотрите пример кода.

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

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

Ещё в качестве идеи Xamarin.Forms понравился всем WPF разработчикам: популярность создания приложений под Android и iOS росла, WPF становился пережитком, а востребованность WPF разработчиков неуклонно стремилась к нулю — Forms звучал, как спасение. Появилась надежда, что мы со своим знанием XAML и паттерна MVVM будем кому-нибудь нужны. Конечно, изначально Xamarin.Forms оказался сырым, с большим количеством багов и отсутствием некоторых жизненно необходимых вещей (вспомнить хотя бы input control без возможности указания maxwith).

Прошло три года и Microsoft приобрел Xamarin. Теперь он поставляет его вместе с Visual Studio, и как следствие: багов стало меньше, а возможностей из коробки — больше. Но осталась одна проблема: приложения с единым интерфейсом не получаются нативными. То есть, если появляется различие в интерфейсах Android и iOS, разработчик сталкивается с болью в виде создания отдельных ViewModel под каждую платформу…и это только цветочки.

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

Управляемая память в .Net поделена на стек и несколько хипов. Самые важные из хипов – это обычная (эфемерная) куча и LOH. Эфемерная куча – это то место, где живут все обычные объекты. LOH – это то место где живут большие (больше 85000 байт) объекты.

LOH обладает некоторыми особенностями:

• Объекты в LOH никогда не перемещаются
• LOH только растет и никогда не уменьшается (т.е. если объект собран сборщиком мусора, размер LOH все равно остается неизменным)
• Хип LOH освобождается только тогда, когда LOH полностью пуст

Из этих двух особенностей LOH происходят два важных следствия, про которые часто забывают:

• Память в LOH может оказаться фрагментированной. Т.е. происходит то, с чем так боролись в unmanaged мире: в какой-то момент у вас может быть 10Mb свободной памяти, но вы не сможете выделить память под объект размером 1Mb
• Если вы однажды выделили память под большой объект, а потом используете только маленькие, то вы фактически лишаете себя большого куска памяти. При чем, если у вас в LOH был список или хэш-таблица размером N, а вы добавили в него один элемент, то список реаллоцируется и растет в два раза, сответственно размер LOH составит как минимум 3*N (N – исходные данные, 2N – копия данных и резерв под новый размер). Следующий рост потребует в LOH непрерывный кусок памяти размером в 4*N, а так как такого куска в LOH у нас нет (есть только N), его придется позаимствовать из адресного пространства процесса. В итоге размер LOH вырастет до 7*N, и так далее.

Если вспомнить, что LOH аллоцируется кусками по 16Mb, то все происходящее покажется еще более разрушительными. С первым следствием можно бороться аккуратно переиспользуя объекты. Со вторым — не используя большие объекты. Получается как-то не очень, особенно если с большими коллекциями работать все-таки хочется. Посмотрим, что как можно решить эту проблему.

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

• Внедрить оптимизацию платежей на всех этапах процесса бронирования.
• Скорректировать бизнес-модели и процессы проведения платежей.
• Сфокусироваться на платежах как на основой стратегии удовлетворения клиентов.

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

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

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

[Примечание переводчика: перевод первой части этой статьи уже есть на Хабре, но её автор почему-то не завершил работу.]

Рендерер Quake III

Рендерер Quake III стал эволюционным развитием рендерера Quake II с аппаратным ускорением: классическая часть построена на архитектуре «двоичного разбиения»/«потенциально видимых наборов», но добавлены два новых заметных ключевых аспекта:

• Система шейдеров, построенная поверх фиксированного конвейера OpenGL 1.X. Это было большим достижением для 1999 года. Она обеспечивала большое пространство для инноваций в эру до повсеместно распространённых сегодня вершинных, геометрических и фрагментных шейдеров.
  
• Поддержка многоядерной архитектуры: клиент-серверная модель OpenGL блокирует некоторые методы и система потоков частично решает эту проблему.

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

Если есть время, и заказчик хочет чуть большего, то гуглят реализацию наиболее популярного алгоритма (коим является «расстояние Левенштейна») и вписывают его.

В данной статье, я опишу сильно доработанный алгоритм, основанный, правда, на расстояния Левенштейна, и приведу примеры кода на C# нечеткого поиска по названиям, например: кафе, ресторанов или неких сервисов… В общем всё, что можно перечислить и имеет от одного до нескольких слов в своем составе:

«Яндекс», «Mail», «ProjectArmata», «world of tanks», «world of warships», «world of warplanes» и т.д.

Содержание

• Часть 0. Перечень GUI элементов, используемых в статьях
• Часть 1. Атрибуты
• Часть 2. Окна
• Часть 3. Редактор класса, наследника от MonoBehavior или ScriptableObject
• Часть 4. Редактор класса, кастомный редактор для сериализуемой переменной

Предисловие

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

Большая часть взята из опыта использования, куда попала из родной документации движка. Вы легко можете сами найти необходимую информацию, поворошив документацию Unity 3D. Просто, по собственному опыту скажу, что у многих программистов либо нет времени, либо нет желания копаться в мантрах. Поэтому и выкладываю максимально краткое руководство по основным редакторским возможностям, которые я использовал на работе и в своих проектах.

Reactive log stream processing with RxJava — Part l

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

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