Блог компании контур

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

Когда: 6-12 июля
Где: онлайн

Что случилось?

Code Challenge первое открытое онлайн-соревнование от Контура для хардкорных инженеров. Уже сейчас открыта песочница, а сам контест начнётся вечером, в понедельник 6 июля, и продлится 7 суток. Вместе мы попытаемся прорваться к центру вселенной через вражеские корабли и планеты древних цивилизаций. Конечно, с помощью кода и квестов.

Если вы уже слышали про соревнования ICFP Contest, CodinGame или Google Code Jam, вам точно понравится то, что мы приготовили.

А в чём суть контеста?

В каждом уголке галактики непрерывно идут бои за первенство. В боях участвуют флоты под управлением тактических ботов. Мы будем программировать своего бота (на C#, JS, Python или 1С %)), управлять космическими кораблями, побеждать врагов и захватывать новые планеты. Прокачать тактического бота помогут артефакты древних цивилизаций, но найти их будет непросто: все они спрятаны и зашифрованы.

Почему это интересно?

Умение писать ботов вряд ли пригодится кому-то в работе, однако соревновательное программирование развивает. В подобных соревнованиях нельзя взять первую попавшуюся стратегию приходится перебирать идеи, проверять их на практике и доводить до рабочего состояния. Соревнование даёт повод почитать про сложные алгоритмы, разобраться и применить их.

Кто может участвовать?

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

Как стартануть?

Капитан должен зарегистрировать команду. Сделать это можно не только до начала соревнования, но и во время него. Мы организовали битву таким образом, что играть будет интересно, даже если начинать сильно позже остальных. Никому, кроме капитана, регистрироваться не нужно: достаточно договориться об участии между собой и сообщить нам размер команды.

Вечером 6 июля мы откроем портал для боевых отрядов и начнём Межгалактический бой. Ссылка на игру и ключи от песочницы прилетят капитанам команд на почту заранее. Будет время изучить правила и запустить свои корабли в первые тестовые полеты.

А если победим?

Командам, обыгравших всех остальных, мы подарим сертификаты на Ozon.

Герои меча Брезенхэма и магии Чебышёва, в бой!

Ничего не планируйте с 17 по 20 июля, потому что в это время пройдет ежегодное международное соревнование ICFPC 2020. Собирайте команду и трое суток решайте секретную задачу от Контура. Чтобы быть в курсе всех новостей, получать подсказки и не пропустить регистрацию, подписывайтесь на Твиттер.

15 лет команда Контура участвовала в соревновании, а в этом году нас пригласили провести ICFPC 2020. Мы первая команда из России, которой доверили организацию, и это очень круто! Какую задачу мы приготовили пока секрет. Все участники узнают ее условия одновременно 17 июля, но уже сейчас в Твиттере можно увидеть некоторые спойлеры.

Почему нужно участвовать в ICFPC 2020

ICFPC командное соревнование. Соревнований для одиночек много: например, Facebook Hacker Cup и Google Code Jam. Если вам нравятся AI для игр, то codingame.com проводят отличные челенджи раз в 2-3 месяца. В одиночных соревнованиях топ обычно забит какими-то гениями, а в командных можно хорошо выступить за счет упорства и хорошей организации.

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

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

Задачи небанальные. Организатор соревнования меняется каждый год и старается превзойти предыдущего, поэтому задачи год от года становятся все интереснее. Обычно это университет, поэтому они добавляют в задачи отсылки к научным проблемам и классике computer science. Кроме того, ICFPC приурочен к научной конференции по функциональному программированию ICFP, и это влияет на задачи. Через раз приходится читать описания на функциональном псевдоязыке (не бойтесь, понятном для обывателей!), а потом программировать виртуальные машины и компиляторы.

Задача одна! За 72 часа команда неограниченного размера должна решить всего одну задачу. Но многогранную и трудную. Её нельзя решить оптимально, но можно решить лучше других команд. Самыми необычными и яркими задачами считаются задачи 2006 и 2007 годов, в которых балом правили виртуальные машины внутри виртуальных машин и а также реверс-инжениринг виртуальных машин.

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

Подробности соревнования появляются в Твиттере. Там же скоро появится ссылка на регистрацию.

Желаем удачи!

В свежем превью Rider, помимо прочего, появилась поддержка Авалонии. Авалония это самый крупный .NET фреймворк для разработки кроссплатформенного UI, и его поддержка в IDE отличный повод наконец разобраться, как писать десктопные приложения для любых платформ.

В этой статье я на примере простой задачи по реализации калькулятора покажу:

• как управлять разметкой,
• как связывать функциональность с компонентами,
• как управлять стилями.

Подготовка

Для работы я использовал:

• Kubuntu
• Visual Studio Code
• Git
• dotnet

Единственным обязательным инструментов в этом списке является сам дотнет. Остальное можете выбирать сами: любимую операционную систему и IDE (например, тот же Rider).
Для инициализации проекта мы воспользуемся шаблонами .NET приложений для Авалонии. Для этого нам потребуется клонировать репозиторий с шаблонами, а затем установить скачанные шаблоны:

git clone https://github.com/AvaloniaUI/avalonia-dotnet-templates.gitdotnet new --install /path/avalonia-dotnet-templates/

Типы проектов

Теперь, когда шаблоны установлены, мы можем создать новый проект на основе MVVM шаблона Авалонии:

dotnet new avalonia.mvvm -o ACalc

Перейдем в директорию проекта и обновим все версии пакетов на самые новые (на момент написания статьи):

dotnet add package Avalonia --version 0.10.0-preview6dotnet add package Avalonia.Desktop --version 0.10.0-preview6dotnet add package Avalonia.ReactiveUI --version 0.10.0-preview6

Давайте внимательнее посмотрим на структуру проекта, сгенерированную шаблоном:

• В папке Assets хранятся ресурсы, используемые нами в данном проекте. На текущий момент там лежит лого Авалонии, использующееся в качестве иконки приложения.
• В папку Model мы будем складывать все общие модели, используемые в нашем приложении. На текущий момент она пуста.
• Папка ViewModels предназначена для хранения логики, которая будет использоваться в каждом из окон. Прямо сейчас в этой папке хранится ViewModel главного окна и базовый класс для всех ViewModel.
• В папке Views хранится разметка окон (а также code behind файл, в который хоть и можно положить логику, но лучше для этих целей использовать ViewModel). На текущий момент у нас есть только главное окно.
• App.xaml общий конфиг приложения. Несмотря на то, что он и выглядит как еще одно окно, на самом деле, этот файл служит для задания общих настроек приложения.
• ViewLocator нам в этот раз не пригодится, так как он используется для создания кастомных контролов. Подробнее о нем можно почитать в документации Авалонии.

Запустим наше приложение командой dotnet run.



Теперь все готово для разработки.

Разметка

Начнем с создания базовой разметки. Перейдем в файл Views/MainWindow.xaml там будет храниться разметка главного окна нашего калькулятора.



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

Итак, заменим TextBlock на пустой Grid:

<Grid></Grid>

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

<Grid>    <Grid.RowDefinitions>        <RowDefinition Height="auto"></RowDefinition>        <RowDefinition Height="auto"></RowDefinition>        <RowDefinition Height="*"></RowDefinition>    </Grid.RowDefinitions></Grid>

Теперь заполним разметку основными компонентами добавим строку меню, базовый экран и вложенный Grid для блока клавиш:

<Grid>    <Grid.RowDefinitions>        <RowDefinition Height="auto"></RowDefinition>        <RowDefinition Height="auto"></RowDefinition>        <RowDefinition Height="*"></RowDefinition>    </Grid.RowDefinitions>    <!--строка меню-->    <Menu>    </Menu>    <!--Импровизированный экран нашего калькулятора-->    <TextBlock>    </TextBlock>    <!--Grid для клавиш-->    <Grid></Grid></Grid>

Отдельно остановимся на расположении клавиш в сетке.
Для начала нужно описать количество строк и столбцов в нашем Grid. А после разложить кнопки по соответствующим им строкам и столбцам, указав их координаты.

<Grid>    <Grid.RowDefinitions>        <RowDefinition></RowDefinition>        <RowDefinition></RowDefinition>        <RowDefinition></RowDefinition>        <RowDefinition></RowDefinition>        <RowDefinition></RowDefinition>    </Grid.RowDefinitions>    <Grid.ColumnDefinitions>        <ColumnDefinition></ColumnDefinition>         <ColumnDefinition></ColumnDefinition>         <ColumnDefinition></ColumnDefinition>         <ColumnDefinition></ColumnDefinition>         <ColumnDefinition></ColumnDefinition>    </Grid.ColumnDefinitions>    <Button Grid.Row="0" Grid.Column="0">1</Button></Grid>

Стоит отметить, что элементы внутри Grid могут занимать несколько ячеек. Для этого используются параметры ColumnSpan и RowSpan:

 <Button Grid.Row="3" Grid.Column="3" Grid.ColumnSpan="2">=</Button>

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

Последнее, что нам осталось сделать это задать параметры окна. Установим стартовые и минимальные размеры окна (они задаются в корневом элементе Window).

MinHeight="300"MinWidth="250"Height="300"Width="250"

После добавления всех элементов разметки наше окно калькулятора будет выглядеть так:

Основной функционал

С разметкой закончили, пора реализовать логику!

Начнем с добавления в папку Models нового Enum, который описывает возможные операции:

public enum Operation{    Add,    Subtract,    Multiply,    Divide,    Result}

Теперь перейдем в класс ViewModel/MainWindowViewModel. Здесь будет храниться основная функциональность нашего приложения.

Добавим в файл несколько приватных полей, с которыми мы будем работать:

private double _firstValue;private double _secondValue;private Operation _operation = Operation.Add;

Теперь реализуем основные методы:

• AddNumber добавляет новую цифру к числу.
• ExecuteOperation выполняет одну из операций, описанных в енаме Operation.
• RemoveLastNumber удаляет последнюю введенную цифру.
• ClearScreen очищает экран калькулятора.

Не будем останавливаться на реализации этих методов, в этом нет никакой специфики для Авалонии (реализацию вы можете посмотреть в репозитории проекта). Единственное, что нас интересует это то, что помимо перечисленных выше приватных полей, эти методы также оперируют публичным свойством ShownValue. О нем чуть позже.

Связывание

Теперь, когда у нас готовы и разметка, и логика, пора связать их друг с другом.
В Авалонию по умолчанию включен Reactive UI это фреймворк, предназначенный как раз для связывания View и Model при использовании MVVM. Подробнее о нем вы сможете прочитать на официальном сайте и в документации Авалонии. Конкретно сейчас нас интересует возможность фреймворка обновлять View при изменении данных.

Для хранения актуального значения, выводимого на экране, реализуем свойство ShownValue:

public double ShownValue{    get => _secondValue;    set => this.RaiseAndSetIfChanged(ref _secondValue, value);}

Получаемое из этого свойства значение будет выводиться на дисплее нашего калькулятора, а метод RaiseAndSetIfChanged позаботится о вызове уведомления при изменении значения свойства.

Привяжем это свойство к созданному на этапе разметки текстовому полю:

<TextBlock Grid.Row="1" Text="{Binding ShownValue}" />

Благодаря директиве Binding и методу RaiseAndSetIfChanged значение свойства Text в этом поле будет обновляться при каждом изменении значения свойства ShownValue.

Теперь добавим в MainWindowViewModel еще три публичных свойства для команд. Команды являются обертками вокруг функций, которые будут вызываться определенными действиями на UI.

public ReactiveCommand<int, Unit> AddNumberCommand { get; }public ReactiveCommand<Unit, Unit> RemoveLastNumberCommand { get; }public ReactiveCommand<Operation, Unit> ExecuteOperationCommand { get; }

Команды нужно инициализировать в конструкторе класса, связав их с соответствующими методами:

public MainWindowViewModel(){    AddNumberCommand = ReactiveCommand.Create<int>(AddNumber);    ExecuteOperationCommand = ReactiveCommand.Create<Operation>(ExecuteOperation);    RemoveLastNumberCommand = ReactiveCommand.Create(RemoveLastNumber);}

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

<Button Grid.Row="3" Grid.Column="2" Command="{Binding RemoveLastNumberCommand}"></Button>

Несколько сложнее дела обстоят с номерными кнопками и кнопками операций. Для них мы должны передать в качестве параметра вводимую цифру или операцию. Для этого в корневом теге Window нам нужно добавить пространство имен System:

xmlns:s="clr-namespace:System;assembly=mscorlib"

А затем обновить разметку кнопок, добавив в них связанный метод и параметр:

<Button Grid.Row="0" Grid.Column="0" Command="{Binding AddNumberCommand}">    <Button.CommandParameter>        <s:Int32>1</s:Int32>    </Button.CommandParameter>     1</Button>

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

Стили

Итак, логика нашего калькулятора полностью реализована, но его визуальная сторона оставляет желать лучшего. Самое время поиграться со стилями!

В Авалонии есть три способа управлять стилями:

• настроить стили внутри компонента,
• настроить стили в рамках окна,
• подключить пакет стилей.

Пройдемся по каждому из них.

Начнем с настройки стилей внутри конкретного компонента. Очевидный претендент на точечные изменения это экран нашего калькулятора. Давайте увеличим для него размер шрифта и перенесем текст вправо.

<TextBlock Grid.Row="1" Text="{Binding ShownValue}" TextAlignment="Right" FontSize="30" />

Теперь поиграемся со стилями в рамках окна. Здесь мы можем изменить вид всех компонентов определенного типа. Например, можно немного раздвинуть кнопки.

<Window.Styles>    <Style Selector="Button">        <Setter Property="Margin" Value="5"></Setter>     </Style></Window.Styles>

Как видите, конкретные компоненты, к которым применяется стиль, можно выбирать при помощи селектора. Больше о селекторах вы можете прочитать в документации Авалонии.

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



Чтобы упростить себе жизнь, можете воспользоваться готовым пакетом стилей. Давайте, к примеру, подключим для нашего калькулятора стиль Material. Для этого добавим соответствующий nuget пакет:

dotnet add package Material.Avalonia --version 0.10.3

А теперь обновим файл App.xaml и укажем в нем используемый пакет стилей и его параметры.

<Application ...             xmlns:themes="clr-namespace:Material.Styles.Themes;assembly=Material.Styles"             ...>    <Application.Resources>        <themes:BundledTheme BaseTheme="Dark" PrimaryColor="Purple" SecondaryColor="Amber"/>    </Application.Resources>    <Application.Styles>        <StyleInclude Source="avares://Material.Avalonia/Material.Avalonia.Templates.xaml" />    </Application.Styles></Application>

Установленный пакет обновит визуальный стиль нашего приложения, и теперь оно будет выглядеть так:



Такие же пакеты стилей можно создавать самостоятельно их можно использовать внутри вашего проекта или распространять в виде пакета на nuget. Больше информации о стилях и способах управления ими можно найти в документации.

Заключение

В этой статье мы разобрали самый простой пример использования Авалонии, но функционал этого фреймворка куда шире, и он растет с каждым днем. Помимо неоднократно упомянутой мной документации, вы также можете спросить совета в русскоязычном чате, посвященном Авалонии, или прямо здесь в комментариях.
А еще много интересного про Авалонию и .NET UI можно будет послушать на онлайн-митапе от Контура, который пройдет сегодня, в пять по Москве.

Все исходники проекта вы можете найти в репозитории на Github.

На этом все! Оставайтесь на связи, мы вернемся со статьями о более продвинутых возможностях Авалонии.

Несколько недель назад вышел .NET 5. На сайте Microsoft можно найти подробный анонс со всеми изменениями, но главный вопрос для меня, как для разработчика и что с того? Что мне с выхода пятого дотнета, как я могу его использовать, есть ли смысл переходить на новую версию прямо сейчас? На эти вопросы я постараюсь ответить дальше.

Перфоманс

Изменения в перфомансе это самая заметная часть релиза. О них много писали на сайте Microsoft и рассказывали на .NET Conf. Давайте посмотрим внимательнее и определимся, где, насколько и за счет чего выросла производительность.

Измерения перфоманса с этого скрина основаны на бенчмарках от TechEmpower. Здесь Microsoft сравнивают результаты замеров производительности .NET 3.1 с ожидаемыми значениями для .NET 5. Стоит заметить, что это именно ожидаемые значения реальных результатов от TechEmpower пока не было. Однако уже эти результаты выглядят впечатляюще ускорение на 38 процентов для Plaintext, на 42 для Json и на 20 процентов в категории Fortunes (пояснения по разным типам бенчмарков вы можете найти в вики TechEmpower).

Помимо результатов бенчмарков от TechEmpower, Microsoft также рассказывает и о других улучшениях. Например, сериализация JSON стала работать на 20% быстрее, а сериализация больших коллекций и массивов ускорилась аж в три раза.

Также замеры производительности делал автор библиотеки Fusion Александр Якунин. В двух статьях на Medium он сначала измерил, насколько ускорилась работа демок его библиотеки (от 20 до 105 процентов), а затем проверил пятый .NET на нескольких синтетических бенчмарках и также получил некоторое ускорение.

За счет чего это происходит? В первую очередь, благодаря изменениям в GC, которые привели к уменьшению количества аллокаций и ускорению сборки мусора. Кстати, все эти изменения осуществляются одновременно с переписыванием GC на C#, а значит его код становится куда доступнее, понятнее и безопаснее. Подробности можно почитать в статье от Microsoft.

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

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

private MemoryStream _stream = new MemoryStream();private DateTime[] _array = Enumerable.Range(0, 1000).Select(_ => DateTime.UtcNow).ToArray();[Benchmark]public Task LargeArray(){    _stream.Position = 0;    return JsonSerializer.SerializeAsync(_stream, _array);}

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

Языковое

Вместе с .NET 5 вышла и девятая версия C#. Официальную страничку с изменениями вы можете найти на сайте Microsoft, но давайте попробуем разобраться что именно здесь стоит внимания?

Самое заметное изменение это record-типы, позволяющие избавиться от бойлерплейта при написании DTO. Записи это иммутабельные ссылочные типы с простым и коротким объявлением. В них по умолчанию определены методы Equals, HashCode, Copy, Clone, PrintMembers и ToString разумеется, все они используют значения полей типа для выполнения операций. То есть Equals корректно сравнивает две записи по значениям, а не по ссылке.

Также записи поддерживают синтаксис копирования с изменением значений полей через with, например:

var person = new Person { FirstName = "Mads", LastName = "Nielsen" };var otherPerson = person with { LastName = "Torgersen" };

Больше о применении записей вы можете почитать в блоге Владимира Хорикова и в публикации от Konrad Kokosa.

Другое важное изменение это обновленный pattern matching. Теперь паттерны могут настраиваться по типам и операторам сравнения, причем несколько разных сравнений вы можете объединять через логические операторы. Например:

DeliveryTruck t when t.GrossWeightClass switch {    < 3000 => 10.00m - 2.00m,    >= 3000 and <= 5000 => 10.00m,    > 5000 => 10.00m + 5.00m}

Остальные изменения не столь заметны они касаются верхнеуровневых программ (возможность писать короткие программы без базового класса и функции main), упрощенного синтаксиса для new (без указания типа), init-only сеттеров и прочего.

Последние изменения в новом C#, которые хотелось бы упомянуть это расширенная поддержка для source generators. Этот функционал позволяет генерировать код при компиляции проекта и зачастую очень удобен для авторов библиотек. В новом релизе работу с генераторами кода сделали чуть проще, расширив функционал partial классов (с них сняли некоторые из старых ограничений) и добавив инициализаторы модулей (методы, которые вызываются до первого доступа к любому полю/методу модуля).
Хороший пример работы с генераторами кода вы можете найти в этой статье на Medium.

Отдельно стоит рассказать про F# 5. В новой версии языка добавилась масса классных возможностей для скриптов (например, директива для подключения nuget пакетов), slicing для более удобной работы с данными, а также улучшилась работа с quotation expressions и computation expressions. А еще сильно улучшился интероп с C# и перфоманс. Словом, новый релиз выглядит интересно и делает F# потенциально полезнее в продакшене. Полное описание всех изменений можно найти на сайте Microsoft.

Коротко язык оброс разнообразным сахаром. Самое заметное изменение в C# 9 это записи, но едва ли оно само по себе стоит обновления. С другой стороны, если вы будете обновлять версию дотнета по каким-то другим причинам, то у вас появится новый функционал, делающий язык чуть более мощным. Мелочь, а приятно.

Прочее

Помимо глобальных улучшений платформы Microsoft также неплохо поработали над отдельными библиотеками.

Например, в новой версии дотнета сильно улучшилась поддержка десктопа. WinForms и WPF наконец-то получили все преимущества .NET Core классный перфоманс, упаковка всего приложения в один .exe, работа без установленного на машине дотнета и и нет, не кроссплатформенность. Все это работает только под Windows.

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

С кроссплатформенностью все осталось по-прежнему. Релиз MAUI перенесли на .NET 6, а других решений для кроссплатформенного десктопа Microsoft пока не предлагает. Так что продолжаем использользовать Авалонию (или можно обратить свое внимание на Uno Platform перспективно выглядящий фреймворк для разработки на все и сразу).

Еще больше улучшений появилось для фулстек веб-разработки с использованием Blazor. Главное из них это улучшения производительности Microsoft обещают, что WebAssembly версия Blazor ускорится аж в три раза. Одной из основных причин такого роста производительности стал пререндер на стороне сервера. А еще добавили ленивую подгрузку зависимостей, изоляцию CSS/JS в рамках файла, новые контролы и многое другое. В общем, если вы собирались попробовать Blazor, но все никак не доходили руки сейчас он выглядит куда более production-ready технологией.

Из оставшихся изменений заметнее всего смотрятся те, которые призваны помочь микросервисам и работе с облачными сервисами в целом. Здесь и уменьшение размеров Docker-контейнеров, и улучшенная поддержка gRPC, и поддержка OpenAPI по умолчанию, и многое другое. Кстати, Azure полностью поддерживает .NET 5 со дня релиза.

А еще Microsoft выкатили Project Tye, который как раз является инструментом для удобного управления микросервисами. На текущий момент трудно сказать, стоит ли использовать Tye в продакшене, но обратить внимание и поиграться с ним в свободное время определенно нужно.

Коротко Microsoft улучшили поддержку отдельных инструментов и добавили приятных фич для облака. Если вы используете WinForms, WPF или Blazor обновиться определенно стоит.

Миграция

Давайте разберемся, насколько сложно будет мигрировать ваше приложение с .NET Core 3 на .NET 5?

Гайд по миграции от Microsoft говорит нам, что основные сложности в миграции коснутся приложений на Blazor, там произошло много ломающих изменений. Для большинства же остальных приложений понадобится просто обновить версию дотнета в application.json, файл проекта и версии зависимостей. А еще адрес докер-контейнера с .NET 5 немного отличается от соответствующего адреса для .NET 3.1:

docker pull mcr.microsoft.com/dotnet/core/aspnet:3.1docker pull mcr.microsoft.com/dotnet/aspnet:5.0

Другие отзывы о миграции, которые я смог найти например, вот этот гайд от Alexandre Malavasi и твит о миграции Fusion от Александра Якунина тоже говорят, что миграция проходит без каких-то специфических трудностей. Я также не столкнулся с особыми проблемами, пока мигрировал свои проекты и демки на новый дотнет. В любом случае, перед миграцией на новую версию советую внимательно изучить список ломающих изменений. А еще стоит посмотреть доклад про миграцию с .NET Conf.

Итого

Подведем итоги. Стоит ли мигрировать на новый дотнет и ради чего?

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

Другие важные причины для миграции это улучшения для Blazor и WPF/WinForms. Если вы используете любой из этих фреймворков, стоит попробовать перейти на .NET 5, все же изменения достаточно заметные и полезные. Однако стоит учитывать, что для Blazor миграция выйдет достаточно непростой.

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

И на этом все! Удачной миграции на новый дотнет. Оставайтесь на связи, мы вернемся с более подробными материалами про современные возможности дотнета.

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

Как все начиналось

Леша Кирпичников (beevee):

Идея податься в организаторы была вызвана какой-то нарастающей фрустрацией от того, что каждый год на контестах ничего нового. Задачи на оптимизацию, планирование движения бота или графовые алгоритмы, что мы видим каждый год, уже всем надоели. Начали думать, а как бы сделали мы. Вот бы было, как в легендарных 2006 или 2007. Смесь ностальгии по былым годам и недовольство тем, как сделано сейчас. Причем недовольство во многом и задачей, и тем, как технически устроена игра в эту задачу. Последние несколько лет мы не особенно удачно участвовали в контестах часто по техническим причинам. Например, разработали хорошее решение, но из-за особенностей того, как надо было сдавать решения на контесте, мы допустили нелепую ошибку и не вошли даже в топ-50. Все это вылилось в то, что мы стали стучать виртуальными кулаками по виртуальным столам и говорить: дайте нам попробовать, сделаем по-своему.

Последние два года мы писали организаторам, что хотим попробовать себя в новой роли и разработать следующее соревнование. В сентябре 2019 получили положительный ответ и предложение стать организаторами ICFPC 2020. Мы обрадовались, согласились и только потом задумались, куда именно мы вляпались :)

Про цель

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

Когда ICFPC только появился, 22 года назад, соревнование для программистов было редким явлением. Сейчас по миру проходит очень много разных соревнований, в такой реальности непонятно, какое место занимает ICFPC. Наш ответ такой: у всех остальных соревнований есть вполне определенный формат, а ICFPC это единственное место, где этот формат можно как угодно нарушить и делать максимально нестандартную штуку. Хочешь ботов писать иди на Coding Game и Russian AI Cup, хочешь алгоритмы на codeforces, а хочешь что-то необычное, свежее, непохожее ни на что на ICFPC.

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

Максимально продуманная легенда

Разрабатывали соревнование мы с сентября 2019 до самого последнего дня начала контеста. Да и во время контеста тоже что-то доделывали. Параллельно с задачей придумывался сеттинг: мир, в котором эта задача могла существовать.

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

Зачем этот турнир? Что будет с проигравшими? Какой приз ждет победителей? Мы не знаем! Но наверняка лучше выиграть, чем проиграть :) Поэтому за 72 часа наша задача выбрать самый лучший алгоритм, который способны сделать земляне, и отправить в финальную битву именно его. Финал в ICFP Contest это и есть наш земной турнир между лучшими программистами со всей Земли за право поучаствовать в инопланетном соревновании от имени всех землян.

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

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

Формулировка задачи, Иван Зайцев и Пеговка

Часто в ICFPC громоздкая формулировка задач. Однажды было 40 страниц спецификации, и мы ее читали 4 часа. Это нас деморализовало. И у нас появилась идея: что если сделать контест без спецификации вообще? Вместо четких правил будут инопланетные сообщения, которые участникам нужно будет разгадывать самостоятельно. Когда придумывали сценарий, было очевидно, что сообщения из космоса мы должны как-то получить.

Так родился образ астронома Ивана Зайцева, который принимает на свой радиотелескоп в Пеговской обсерватории сообщения от инопланетян и просит помощи в их расшифровке. Это все стало первым вводным видео на ломаном английском

Для него Леша Кирпичников отрастил бороду (шутка, она сама отросла за время карантина), нашел медицинский халат, принес перфокарты. Мы распечатали текст, который Леша читает, чтобы он был как бы написан на перфокарте. Сделали бейдж с именем Ивана Зайцева, работника Пеговской обсерватории. В пользу легенды также создали блог Ивана Зайцева

Запись первого видео

Реквизит

Кроме этого видео, были посты в блог и еще два вводных видео.

В общем, всеми силами старались создать логичную историю. Это было максимально нестандартно. Никто так не делал раньше. Поэтому в самом начале контеста народ активно спрашивал: Что делать то? Где правила, инструкции, какой код писать? Как очки зарабатываются?. На что мы отвечали Ребята, какие еще очки! Мы получили сообщение от ИНОПЛАНЕТЯН, помогайте нам его расшифровать быстрее!. Все разгадки участникам нужно было закидывать в чат Discord, а мы собирали все дельные идеи в публично доступную спецификацию. Коллективный разум разгадывает в 10 раз быстрее, чем отдельные люди. Спецификация к задаче появилась через 4,5 часа, и вся она состояла из цитат участников в чате.

Почему Иван Зайцев

Имя хоть и простое, но выбрано не случайно.
Оно состоит из двух частей:

1. Есть канадский астроном Yvan Dutil. Он один из авторов сообщения, которое в 1999 и 2003 гг. земляне отправляли к звездам с помощью радиотелескопа в надежде найти там разумную жизнь.
   Многие, наверное, знают о существовании SETI института поиска внеземного разума. Но есть еще и менее известный институт METI, который изучает возможности не просто наблюдения за космосом, а общения с внеземными цивилизациями. И с Земли уходило в космос уже несколько десятков посланий. Несколько из них имели вполне профессионально составленное содержание. Смотрите Arecibo message (1974) и CosmicCall (1999 и 2003). В нашем сеттинге мы находимся по другую сторону, мы получатели подобного сообщения.
   Тут есть интересная проблема, как составить сообщение и суметь в нем рассказать что-то нетривиальное существу, восприятие которого, может быть, сильно отличается от нашего. Они не знают, где верх и низ, не знают базовых понятий, с помощью которых можно это донести. Yvan Dutil один из авторов сообщения, которое реально отправили в космос.
2. Александр Зайцев человек, фамилию которого мы взяли.
   Это российский астроном, радиофизик, глава российской организации SETI. Он один из идеологов и активистов, благодаря которым как раз и реализовались проекты CosmicCall и CosmicCall2.

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

Из чата организаторов

Почему Пеговка

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

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

Итого задача участников была такая

1. Расшифровать инопланетное послание.
2. Понять, что там описывается язык программирования и виртуальная машина, его выполняющая, с дисплеем и тачскрином :)
3. Реализовать на своем любимом языке программирования виртуальную машину и выполнить на ней последнее самое большое сообщение от инопланетного корабля.
4. В запустившейся программе (участники назвали ее galaxy из-за значка, которым она обозначалась у инопланетян) разобраться с особенностями инопланетного пользовательского интерфейса, понять, что речь идет о галактическом турнире.
5. Найти обучающие туториалы и изучить с их помощью правил игры.
6. Написать бота, который будет играть в игру и победит всех.

Как придумывали концепцию задачи

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

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

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

Паша Егоров (xoposhiy):

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

Так, еще в 1960 году, когда человечество было уверено, что в ближайшие лет 5 установит радиосвязь с марсианами, немецкий математик опубликовал книгу Lincos. Проектирование языка для межпланетного общения. Часть 1. Несколько сотен страниц подробно описывают, как общаться с инопланетянами. Начать в этой книге предлагается с математики и логики, а далее на примере диалогов двух собеседников вводить более сложные понятия, например, хорошо и плохо.

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

Паша Егоров взялся за эту идею и начал ее прорабатывать. Он приносил на встречи такие картинки:

Мы их весело разгадывали, и через какое-то время стало понятно, что это самая проработанная часть. К ноябрю 2019 у нас был прототип сообщений от инопланетян, в частности описание виртуальной машины (на основе SKI-комбинаторов). Мы определились, что после введения этого языка программирования мы дадим участникам большое сообщение, для расшифровки которого им надо будет написать виртуальную машину, исполняющую код на инопланетном языке. После исполнения кода перед глазами участников должен появиться тачевый интерфейс инопланетной операционной системы (мы его называли aPad как iPad, только aPad от alien). А вот что будет внутри этой операционки, до последнего оставалось загадкой. У нас были готовы авторская реализация виртуальной машины и несколько примеров программ, которые можно было на ней запустить.

Турнир и космические битвы

В декабре 2019 мы активно обсуждали содержание операционки. Победившей была идея PlanetWars. Бои кораблей, которые вращаются вокруг планеты в двумерном пространстве. Первые картинки этого выглядели так:

Идея требовала работы с числами с плавающей точкой. Это была проблема вводить на инопланетном языке стандарт IEEE 754 никому не хотелось. Но тогда на нас накатило вдохновение, полученное от решения задачек из 12 дня Advent Of Code, которые как раз тогда мы все решали: гравитация должна быть дискретной. Долгое время эта часть контеста так и называлась у нас с префиксом АoC в честь Advent of Code, который подарил нам идею.

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

(траектории на картинке декоративные, в пиксельном отображении их не было)

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

Инопланетный интерфейс

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

Саша Храмцов:

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

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

(история галактических боев с просмотром каждого боя)

Вторая задача: как отображать интерактивные элементы интерфейса. Ведь теперь мы не можем сказать Давайте добавим кнопки над полем с кораблями поле бесконечное и у него нет над. За много итераций и подходов родилась идея со слоями. Каждый раз когда взаимодействуешь с какой-то штукой, она предлагает тебе следующее взаимодействие, и для этого у тебя появляется новый слой интерфейса с новой информацией с новыми кликабельными элементами. У нас получился такой объемный интерфейс, как голографические экраны в фантастических фильмах.
Саша Храмцов

Я себя просто представлял инопланетянином, висящим в пространстве перед таким голографическим объемным многослойным дисплеем. Так я ставил себя на место пользователя.

(интерфейс космического боя и управления кораблем)

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

Наша версия:

Одна из версий участников:

(это главный экран операционной системы, центр галактики точка (0, 0))

Саша Храмцов:

Передо мной стояла еще и такая задача: картинки, которые получаются у участников, должны быть настолько клевыми, чтобы им захотелось выкладывать их куда-то. В инстаграм, например. Среди организаторов мы говорили, что все должно быть instagrammable. Я придумал порядка 16 цивилизаций по всей галактике, для каждой была своя иконка, которая ее характеризует. Их можно было нажимать, открывать, разглядывать.

Во время контеста мы собирали скриншоты, которые участники публиковали в чате, твиттере и инстаграме получился целый альбом!

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

Про перевернутые картинки

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

Из чата участников:

Потом нас осенило, что можно пойти еще дальше и перевернуть вообще все в интерфейсе вверх ногами! Вот какая была логика. Изображения инопланетяне передают просто в виде последовательности пикселей, расположить эти пиксели сверху вниз придумали наши участники сами. Потому что у людей так принято: слева направо, сверху вниз. И ошиблись! Потому что у инопланетян принято не так. Конечно же, ось Y у инопланетян должна быть направлена вверх, к звездам. Как у математиков :) И пиксели логично (по-инопланетянски логично) было располагать тоже снизу вверх. Участники тоже поняли это, но переделывать никто не стал. На вопросы в чате А почему все вверх ногами? другие участники отвечали Тут так принято!, Так исторически сложилось и Лень переделывать. Все, как в жизни! Как мы и задумывали :)

Предлагаем вам трехминутную экскурсию по интерфейсу Галактики:

Инфраструктура

В прошлые годы во время участия мы всегда расстраивались из-за того, как сделаны системы сдачи решений: как правило нужно было собирать zip-файл, в котором лежали бы исходники, исполняемый файл и инструкция, как все это запускать. В 2020 году должно быть по-другому. Есть же автоматизированные CI/CD, можно все собирать по коммиту в репозиторий. Автоматически запускать в докере. И участникам не надо будет вообще ничего для сдачи делать, кроме обычного коммита в гит. Поэтому мы вложились в инфраструктуру очень сильно. Мы собирали коммиты из репозиториев команды, считывали из специального файла в репозитории, какой язык они используют, и запускали их код в подходящем докер образе. После сборки проводились тесты, и если все хорошо, специальная турнирная система запускала код в турнир: выбирала соперников и запускала игру друг против друга.

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

Наша инфраструктура была готова к большим нагрузкам. Мы проводили нагрузочное тестирование. Можно было увеличить количество ресурсов динамически при росте нагрузки. Для этого у нас была гибридная система из своего и дополнительного кластеров в AWS на случай большой нагрузки.

В общем, мы сделали то, что как промышленные разработчики умеем делать и не можем без удобства: сайт, CI/CD, гит, масштабирование.

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

Никита Сивухин:

Я занимался техническими аспектами, делал интеграцию с Амазоном. Оказалось, что там не все так просто и Амазон не может тебе дать неограниченное количество мощностей, даже если мы готовы за это платить. Но в результате все получилось. Мы добились почти максимального возможного параллелизма: время обработки одного раунда турнира было 2 минуты. Примерно столько же, сколько длился один бой между парой соперников.

Про 72 часа контеста на стороне организаторов

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

Во время самого контеста у каждого из нас были 16-часовые рабочие дни все эти трое суток. Была договоренность, что круглосуточно в чате должен быть хотя бы один из команды. Так, у нас была техподдержка 24/3 и мы активно отвечали участникам и помогали решать их проблемы.
Попеременно кто-то уезжал домой, кто-то оставался. Кроме техподдержки, мы запускали и останавливали разные этапы турнира, записывали следующие видео, писали твиты и посты в блог, следили за инфраструктурой и иногда что-то допиливали в ней. Финальное видео записывали тоже в процессе контеста. Всего было 56 видео, из них только парочку мы записали до начала, остальное в процессе. Видео, открывающее контест, записывали в последний час перед стартом.

(Организаторы контеста за работой)

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

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

(Иван Зайцев смотрит трансляцию и переживает за судьбу землян)

(кадр из трансляции: можно было подглядеть крутые стратегии. На картнке корабль защитника разделился на много-много маленьких корабликов и их траектории выглядят запутанным клубком)

Демо боя можно посмотреть в отчете победителей

Про зрелищность и атмосферу

У ICFPC есть проблема: топовым командам обычно выгодно до последнего держать в секрете свои лучшие алгоритмы и выкладывать их в последние 5 минут. Чтобы все думали, что у них нет хорошего решения, и у противников не было шансов проанализировать и подготовиться.

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

Атмосфера соревнования была скорее дружеской: все обсуждали идеи, общались, подшучивали друг над другом. Например, мы изменили название постоянного участника ICFPC команды The Cat #1. Написали специальный код, который в лидерборде переименовывал название команды на текущее место, которое они занимают, например, место 12 и название становится The Cat #12. Это просуществовало часов 6, прежде чем ребята из команды написали в чат: Эй, вы чего сделали название нашей команды динамическим?))) Вы клевые, нам понравилось!.

Каким получился для вас этот контест

Вероника Самохина(aminopyrodin): Эпично сложным и необычным.
Леша Кирпичников: Мы делали контест, в который понравилось бы играть воображаемой идеализированной версии нашей команды. Команде из 5 или больше промышленных разработчиков, которые готовы почти не спать и рубиться все 72 часа, но при этом команде из гораздо более умных и крутых участников, чем мы сами. Это и хорошо, и плохо: нам бы точно понравилось в это играть, но были и команды с другими ценностями, которым это совсем не зашло. В конечном итоге по-другому и быть не могло: вряд ли мы бы стали делать что-то, что не понравилось бы нам самим.
Саша Храмцов: Максимально мозголомный, эпический и масштабный. Потому что история, которая за всем этим лежала, развернулась очень широко. Получилась настоящая история. Контест из виртуального превратился в настоящий.
Никита Сивухин: Многогранный и продуманный. Было очень много точек взаимодействия и компонентов системы как снаружи, так и внутри.

Про планы

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

---

Победители

Main round, 1st place

Первое место в основном раунде получила команда Closed and Restricted Boltzmann Machine (denplusplus). Ребята лучше всех выполнили задание, писали на Python, играли под нейтральным флагом, потому что все выходцы из России, но живут и работают в разных местах западного побережья США.

Main round, 2nd place

Второе место заняли две команды из Японии: многократные победители ICFPC Unagi, которые писали на Rust, и команда японских студентов 182020, их язык программирования C++. Эти команды обе заняли одно место, потому что их алгоритмы хоть и были разными, но показывали практически одинаковую результативность в турнире: то одна, то другая команда выходила вперед. Мы не смогли их разделить по разным местам и дали обеим командам второе место.

Lightning Round

Команда powder победитель lightning раунда. Этот раунд длится первые 24 часа: выигрывает та команда, которая добилась наибольшего прогресса за это время. В нашем случае они решили больше всех туториалов, обучающих, как вести космические бои. В составе команды четыре человека из разных стран. Ребята писали на языке Haskell.

Judges Prize

Приз жюри получила команда ребят из Уфы WILD BASHKORT MAGES (ripatti). Они так увлеклись написанием виртуальной машины, запускающей галактику, что решили реализовать своих ботов для игры так, что они играли без реверс-инжениринга протокола игры (как делали большинство), а нажимая на экран галактики и распознавая изображения. Неэффективно, но впечатляюще. Использовали язык OCaml.

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

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

Что почитать дальше

Пройти путь участника соревнования и попробовать расшифровать инопланетные сообщения

Начать нужно вот с этой страницы. Скачать recording of this message и попытаться понять, что же имелось в виду.

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

Чтобы отправлять сообщения инопланетянам, нужно воспользоваться нашим прокси-телескопом. Инструкция здесь.

Когда все сообщения до 41-го будут расшифрованы, попробуйте понять, что инопланетяне хотят от нас в главном 42-м сообщении.

Почитать книгу про реализацию функциональных языков программирования

Главная книга, которая помогала нам делать контест, это The Implementation of Functional Programming Languages, которую совершенно бесплатно можно прочитать здесь

Буквально нескольких первых глав достаточно, чтобы достойно справиться с задачей, описанной в инопланетных сообщениях :)

Сразиться в космическом бою с другой командой

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

Мы оставили работающий сервер, на котором это можно сделать. Найти себе достойного соперника среди участников ICFPC можно в нашем дискорд-чате

Вдохновиться и посмотреть пару хороших фильмов по теме

• Контакт 1997 года
• Прибытие 2016 года

У нас в Контуре большое сообщество аналитиков. Ребята регулярно проводят летучки, ходят друг к другу на стажировки и раз в год встречаются на командном выезде. И всё было хорошо, пока аналитиков не стало 150! Тогда мы решили, что формат ежегодного выезда устарел и придумали сделать свою конференцию. С самого начала мы хотели пригласить в гости инженеров из других компаний Екатеринбурга, но онлайн подарил нам возможность позвать вообще всех желающих.

Когда: 20 и 21 августа
Где: на Ютуб-канале Технологии в Контуре

У нас классные спикеры

Мы делаем конференцию для себя, а значит, выбираем только самые интересные материалы. Во-первых, нам самим есть, что рассказать: за год наши аналитики приняли десятки вызовов, накопили море опыта и кучу интересных историй. Во-вторых, аналитики в Контур приходят всерьёз и надолго и со временем плохо представляют себе процессы за его пределами. А ведь любопытно! Поэтому мы позвали в гости экспертов из четырёх классных компаний: Додо Пицца, Жизньмарт, Боксберри и ЦИТ.

Программа огонь!

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

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

Менеджерам и разработчикам тоже будет интересно

Наша конференция не только для аналитиков, но и для всех, кто с ними пересекается. Или наоборот. К примеру, Ксюша Лысенко из компании Жизньмарт расскажет про то, как они справляются и выстраивают процессы вообще без аналитиков. Кирилл Сурганов из ЦИТа поделится особенностями настройки всего цикла заказной промышленной разработки. А ребята из Додо Пиццы расскажут про выход на зарубежные рынки и порассуждают, кто главный: бизнес или всё таки разработка?

Ну и заключительный призыв

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

Приходите поговорить о границах работы аналитиков и о том, как эти границы нарушать.

Наши тестировщики из Новосибирска соскучились по встречам с единомышленниками и приготовили онлайн-митап, который нельзя пропустить. Катя Синько порассуждает о том, как занять проактивную позицию и улучшить выстроенные процессы в команде. Инна Шундеева расскажет, как стать автоматизатором и не отступать перед трудностями. А Люда Малеева из Miro поделится советами, как организовать релизы без багов и что правильно делать, если на боевой их всё-таки нашли.

Когда: 9 июля в 16:00 (Мск)
Где: Ютуб-канал Контура

Менять процессы нельзя страдать Катя Синько, Контур

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

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

Качество релизов ответственность команды Люда Малеева, Miro

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

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

5 открытий: дневники автоматизатора Инна Шундеева, Контур

Всё больше тестировщиков руками смотрят в сторону автоматизации. Но этот путь кажется начинающим сложным и тернистым. А как стать автоматизатором, который смог?

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

До встречи! Жмите колокольчик на Ютубе, готовьте прохладительные напитки, подключайтесь и смотрите онлайн-митап Kontur Tech Talks по тестированию.