В digital-агентстве Convergent, где я работаю, в потоке множество проектов, и у каждого из них может быть собственная админка. Есть несколько окружений (дев, стейдж, лайв). А ещё есть разные внутрикорпоративные сервисы (как собственной разработки, так и сторонние вроде Redmine или Mattermost), которыми ежедневно пользуются сотрудники.
Наша команда всегда была распределённой между несколькими офисами, но с учётом событий последнего года все сотрудники перешли на удалёнку. Так мы столкнулись с необходимостью организовать всё многообразие внутренних и клиентских сервисов в единой системе.
Основные данные вычислительных экспериментов по реорганизации ярусно-параллельной формы (ЯПФ) информационных графов алгоритмов (ТГА) приведены в предыдущей публикации. Цель текущей публикации – показать окончательные результаты исследований разработки расписаний выполнения параллельных программ в показателях вычислительной трудоёмкости собственно преобразования и качества полученных расписаний. Данная работа является итогом вполне определённого цикла исследований в рассматриваемой области.
Долгое время я терпел ограничения РосКомНадзора и соответствующие действия провайдеров по различным ограничениям доступа к сайтам - но с определённого момента устал, и начал думать как бы сделать так, чтобы было и удобно, и быстро, и при этом с минимумом заморочек после настройки... Хочу оговориться, что цель анонимизации не ставилась.
Вообще, эта проблема имеет несколько решений... Но я решил бороться с провайдером их же методом.
В этой статье рассказывается, как с нуля изготовить 3D-модель Луны. Казалось бы, Зачем создавать модель Луны самому, если её можно купить? Хотя бы потому, что при самостоятельном изготовлении модели Луны вы сможете задавать желаемые параметры, например размеры и толщину оболочки, разрешение изображения, пределы вращения, положение секущей плоскости, сможете сделать отверстие для лампы и так далее. Приступим же к творению своей собственной Луны.
Продолжаем наши исследования по выбору рациональных планов (здесь к месту использование термина каркасов, ибо на этом этапе от конкретных технологий параллельного программирования будем абстрагироваться) выполнения параллельных программ (ПВПП) по графовому описанию
алгоритмов. Приоритетом при этом будем считать получение ПВПП с максимальным использованием вычислительных ресурсов (собственно параллельных вычислителей), такая цель соответствует представлению о плотности кода (об этом понятии подробнее ниже).
Естественным перед началом анализа будет указание ограничений на ширину и глубину исследований. Принимаем, что многозадачность в рассматриваемых параллельных системах осуществляется простейшим путём - перегрузкой всего блока (связки) выполняющихся операторов (одновременное выполнение операторов разных программ не предполагается) или же система работает в однозадачном режиме; в противном случае высказанное в предыдущей фразе утверждение может быть неверным. Минимизация объёма устройств временного хранения данных (описано здесь) проводиться не будет. На этом этапе исследований также не учитываются задержки времени на обработку операторов и пересылку данных между ними (для системы SPF@home формально эти параметры могут быть заданы в файлах с расширениями med и mvr).
В предыдущей публикации была описана технология получения ПВПП на основе модели потокового (Data-Flow) вычислителя. Обычно считают, что правила выбора операторов для выполнения в такой машине подчиняются логике действия некоторых сущностей, совместно выполняющих определённые действия – “актёров” (actors); при этом естественным образом моделируются связанные с характеристиками времени параметры обработки операторов. В общем случае при этом отдельные операторы выполняются асинхронно. В публикации показано, что описанный принцип получения ПВПП приемлем (при выполнении несложных условий) и для машин архитектуры VLIW (Very Long Instruction Word, сверхдлинное машинное слово), отличающихся требованием
одновременности начала выполнения всех операторов в связке. В расчётах использовали модель ILP (Instruction-Level Parallelism, параллелизм уровня машинных команд).
Почти 4 года прошло с выпуска первой статьи об учебном квадрокоптере Геоскан Пионер. За это время формат конструктора для сборки учебного квадрокоптера успел набрать популярность - он хорошо подходит как для организации учебного процесса со школьниками или студентами, так и для использования на различных хакатонах, соревнованиях, или при выполнении на его базе исследовательских проектов.
Ключевые элементы обучения на сегодняшний день - это развитие навыков программирования для решения задач автономного полета коптера, понимание основ алгоритмов управления и работа с различными функциональными модулями. Для юных пользователей порог входа был снижен за счёт возможности использования визуального блочного программирования в плагине для TRIK-Studio, а вот создание более сложных программ требовало знакомства с языком Lua.
В 2020 году линейка Пионеров дополнилась новыми моделями - появились младший и старший «братья» Мини и Макс. И если по размеру и массе братья стоят по ранжиру - Мини самый маленький и легкий, а Макс самый большой и тяжелый, то по функционалу младший уже готов дать фору своему предшественнику (назовём его Классическим Пионером).
Tarantool — это платформа in-memory вычислений с гибкой схемой данных. На её основе можно создать распределённое хранилище, веб-сервер, высоконагруженное приложение или, в конце концов, сервис, включающий в себя всё вышеперечисленное. Но какой бы ни была ваша промышленная задача, однажды настанет момент, когда её решение придётся мониторить. В этой статье я хочу дать обзор существующих средств для мониторинга приложения на базе Tarantool и пройтись по основным кейсам работы с ними.
Я работаю в команде, которая занимается разработкой, внедрением и поддержкой готовых решений на основе Tarantool. Для вывода наших приложений в эксплуатацию на контуре заказчика было необходимо не только разобраться в текущих возможностях мониторинга, но и доработать их. Большая часть доработок в результате вошла в те или иные стандартные пакеты. Данный материал является текстовой выжимкой этого опыта, и может пригодиться тем, кто решит пройти по той же тропе.
Поговорим о вре́менных данных, служащих для информационного обмена между отдельными вычислителями в (максимально близкорасположенных) параллельных вычислительных системах.
С весны нынешнего года я разрабатываю статически типизированный встраиваемый скриптовый язык Umka, о концепции которого в своё время была статья на Хабре. При этом по своей основной профессии я занимаюсь алгоритмами систем автоматического руления тракторами — о некоторых подходах к комплексированию датчиков в этих системах я тоже писал. Теперь эти два направления деятельности причудливо пересеклись.
Для исследования поведения трактора в некоторых специфических сценариях (например, на склонах при наличии бокового проскальзывания) понадобился программный симулятор трактора, который верно моделировал бы не только кинематику, но и динамику машины. При этом алгоритм контроллера руления предполагалось постоянно видоизменять и немедленно наблюдать эффект этих изменений. Для такой задачи тандем C++ и Umka выглядел вполне органичным: основной код симулятора, требующий высокого быстродействия, был реализован на C++, а логика контроллера была вынесена в скрипт на Umka.
Вероятно, читатель уже заподозрил во мне нездоровую тягу к изобретению велосипедов. Попробую объясниться и заодно рассказать, что вышло из этой немного странной затеи.
Привет, меня зовут Игорь, и я разработчик решений на Tarantool в Mail.ru Group. Я работаю над витринами маркетинга в реальном времени для Мегафона. При мониторинге часто требуется использовать перцентили. Они позволяют понять, как система работает бóльшую часть времени, в отличие от усреднения значений, которое сильно подвержено влиянию выбросов. Если 9 из 10 запросов выполняются за 1 секунду, а один за 10 секунд, то среднее будет 1,9 секунды, а 50-перцентиль — 1 секунда. Это лишь один пример того, что среднее значение не подходит для мониторинга. Возникает необходимость считать перцентили, для этого мы добавили в tarantool/metrics Summary-коллектор.
Данная история состоит из трёх частей, т.к. я выпустил три игры:
● Beasts Battle
● Necromancer Returns
● Magicians Legacy
В прошлых частях я рассказал, как я пришел к разработке гексагональной пошаговой игры Beasts Battle и как не отбились мои расходы на игру Necromancer Returns.
Здесь можно почитать первую и вторую статьи.
Фальстарт
В феврале 2018 года вышла игра Necromancer Returns, которая не оправдала мои ожидания по продажам, и я ушел в депрессию. Но в апреле 2018 года у меня возникла мысль сделать следующую игру на основе этого движка, только чтобы вся графика была уже нарисована в 3D и отрендерена под 2D в изометрии. Мысль была такая: “по-быстрому” придумать новый мир, нарисовать его, запихнуть новых юнитов — и готово. Я списался с художником, который подключился в конце разработки Necromancer Returns и стал для меня основным. Он полностью перерисовал весь интерфейс для мобильной версии Necromancer Returns, а потом мы обновили и версию в Steam.
В качестве примера мастер-мастер кластера Tarantool я предлагаю сделать небольшую текстовую мультиплеер-игру, где каждый участник стремится набрать большее число очков.
Каждый игрок будет некоторым узлом, который меняет данные в игровом мире. Эти данные реплицируются между узлами. Таким образом, репликация Tarantool будет являться своего рода транспортом для игрового процесса.
У всех есть какое-то представление о франшизе World of Tanks. Но, как правило, оно «снаружи» (пользовательское) и общее. А что, если посмотреть изнутри, и рассмотреть какие-то очень конкретные вопросы? Скажем, на каком языке пишут тесты для мобильной World of Tanks Blitz, и по каким причинам выбрали его?
Студия разработки мобильных «танков» MS-1 компании Wargaming присутствовала на нашей конференции Heisenbug, и там мы позадавали такие вопросы Дмитрию Сычеву — Lead QA Automation в World of Tanks Blitz. А теперь решили для Хабра сделать и текстовую версию этого небольшого разговора.