Менторская программа

  Екатеринбург    Набор идёт до 27 сентября  

О программе

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

Как стать участником

Форма сдачи появится очень скоро. Оставь заявку сейчас и мы напомним тебе, когда можно будет регестрироваться :)

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

Проекты 2020

1. Плагин Roslyn Syntax Visualizer в JetBrains Rider

Ментор: Борзов Артем

Нужен C# разработчик

Описание проекта

Наша команда занимается разработкой различных DSL, которые позволяют обрабатывать большие объёмы структурированных данных.

Roslyn — один из инструментов, которым мы пользуемся при создании языков. С помощью него можно конструировать абстрактное синтаксическое дерево (AST) C#, которое затем может быть скомпилировано прямо в памяти, либо использоваться как обычный код. Просмотр AST участка C# кода сильно упрощает задачи создания и преобразования собственных синтаксических деревьев. В Visual Studio для этой цели есть Roslyn Syntax Visualizer, но многие используют Rider, в котором очень не хватает подобной функциональности. Да, существуют веб версии данных инструментов (например, http://roslynquoter.azurewebsites.net/ и https://sharplab.io/), но куда удобнее разглядывать синтаксические деревья, не покидая любимую IDE. Плагин так же будет полезен при разработке анализаторов кода.

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

2. Electron_UI + Python_ETL = <3

Ментор: Лысый Сергей, Десятников Артем

Нужны JS-разработчик, проектировщик

Описание проекта

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

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

 

3. Оптимизация распределенной системы обработки очереди задач

Ментор: Перевощиков Иван

Нужен C# разработчик

Описание проекта

Конвейер обработки сообщений в нашем проекте по автоматизации документооборота в ритейле построен на базе реализации паттерна Distributed Task Queue. Это значит, что отдельные этапы обработки сообщений в процессе их доставки клиентам выполняются независимыми агентами «консьюмерами». Каждый этап обработки сообщения должен производиться один и только один раз. Наша распределенная очередь задач реализована при помощи NoSQL БД Cassandra. Нагрузка на эту подсистему в продакшене достигает 1000 новых задач в секунду.

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

  • Реализовать механизм разделения ресурсов между группами задач внутри процесса консьюмера, гарантирующий прогресс по задачам в каждой группе (гарантия liveliness свойства). Это позволит более гибко масштабировать кластер с консьюмерами.
  • Оценить выигрыш от перехода на асинхронную модель исполнения кода (async/await) внутри консьюмеров. Это позволит более эффективно утилизировать системные ресурсы и, в конечном счете, обслуживать тот же поток входящих запросов меньшим количеством консьюмеров.

4. Отказоустойчивый FTP-шлюз. Продолжение

Ментор: Ярин Захар

Нужен C# разработчик

Описание проекта

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

В качестве основного хранилища данных, где содержится вся информация о передаваемых пользователями сообщениях, мы используем NoSQL БД Cassandra. Сейчас наш FTP-шлюз устроен примерно следующим образом:

  • Непосредственное взаимодействие с пользователями по FTP-протоколу осуществляется при помощи FileZilla Server.
  • ​Сообщения, которые пользователи загружают на FTP-сервер, перекладываются в основное хранилище сервисом-демоном, развернутым рядом с FileZilla Server. Этот демон подвешивается на события FileSystemWatcher-а, который настроен мониторить те же каталоги файловой системы, на которые мапится FileZilla Server. За счет этого мы достигаем суб-секундных задержек между моментом времени попадания файла на FTP-сервер и моментом времени его копирования в основное хранилище.
  • Обратный процесс выгрузки сообщений из основного хранилища в файловую систему, куда смотрит FileZilla Server, производится еще одним сервисом-демоном, который читает внутреннюю ленту событий в Кассандре, содержащую «лог изменений в файловой системе, выставленной через FTP».
  • Пользователи могут не забирать предназначенные им файлы в течение нескольких дней, поэтому для обеспечения отказоустойчивости FTP-шлюза мы должны поддерживать в достаточно актуальном состоянии реплику файловой системы,  выставленной через FileZilla Server, на соседней машине. Репликация состояния файловой системы (в частности, удалений файлов с FTP-сервера) основана на анализе логов FileZilla Server, которые преобразуются в записи в вышеупомянутой ленте событий.

В прошлом году рамках менторской программы мы предлагали реализовать проект proof-of-concept отказоустойчивого FTP-шлюза, который бы работал без использования локальной файловой системы. То есть реализовать FTP-сервер так, чтобы в качестве его storage-engine-а использовалось наше основное хранилище данных в Кассандре. Такое решение можно попробовать разработать на основе технологии FUSE по аналогии, например, с s3fs-fuse. Отдельно заметим, что о программировании FTP-протокола с нуля здесь речи не идет. Нужно будет взять какой-нибудь достаточно широко распространенный FTP-сервер с исходным кодом и интегрировать систему с ним.

По итогам менторской программы в прошлом году получился Docker-образ с частично написанной файловой системой, обращающейся в Cassandra. В качестве FTP-сервера был выбран ProFTPD. В этом году предлагаем закончить написание файловой системы, протестировать её работу в связке с FTP-сервером и внедрить её в наш сервис EDI, переписав существующие сервисы на работу с Cassandra вместо файловой системы.

5. Контур.Студент

Менторы: Третьяков Андрей, Третьяков Максим, Исаков Анатолий, Шабалков Дмитрий, Степанов Кирилл

Нужны нескольких C# разработчиков и один фронтендер

Описание проекта

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

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

Планируем писать backend на ASP.NET CORE, фронтенд на React'e.

Огромным плюсом будет

для бекендера:

• хорошее понимание работы HTTP
• опыт проектирования и написания API
• опыт работы с SQL базами

для фронтендера:

• опыт работы с React, Redux, Typescript/Flow

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

6. Плагин в Visual Studio Code для своего DSL

Ментор: Хапов Роман

Нужен C# разработчик, который готов при необходимости немного кода написать на TypeScript (можно научиться в процессе).

Описание проекта

Описание проекта

Легко ли проверить пользовательский отчёт на предмет ошибок всяких разных? На самом деле, нет, и тому есть множество различных причин.
Например: большое количество различных контролей и форм (типов отчётности), а ещё размер файлов с данными, который может достигать десятки гигабайт!

Чтобы бороться с такими ужасами, мы придумали свой предметно-ориентированный язык (DSL) и назвали его KCLang. Его основное предназначение — удобство описания правил проверки отчётов аналитиками. Вот, кстати, предполагаемый вид кусочка кода на этом языке:

in ⠀Файл/Отчёт⠀ {
⠀⠀if (count(ОтдаёмКотиковВХорошиеРуки) > 42) ⠀{
⠀⠀⠀⠀⠀⠀⠀check sum_of_cats:sum(Значения/@КоличествоКотиков) ⠀===⠀ 100500
⠀⠀⠀⠀⠀⠀⠀described with "Сумма котиков должна быть очень большой, а не {sum_of_cats}"
⠀⠀⠀⠀}
}

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

Всё бы хорошо, но на любом языке неудобно писать без подстроенного под него редактора, и KCLang не стал исключением: аналитики захотели IDE!
Писать IDE с нуля очень сложно, однако есть выход: плагин для visual studio code, в котором будет описана основная логика обработки текста KCLang'a, а vs code возьмёт на себя бОльшую часть сложной и рутинной работы, на подобии обеспечения редактора, подсветки, подсказок и т.д.

У такого плагина будет клиент-серверная архитектура. Клиент — код, который выполняется в редакторе, он должен принимать результаты работы языкового сервера и конвертировать их в понятный для vs code формат. Языковой сервер в свою очередь инкапсулирует логику обработки текста (например, переименование переменных) и работает отдельно от редактора.

Почитать про разработку плагинов для vs code можно тут: https://code.visualstudio.com/api

Таким образом, мы хотим иметь аналог ReSharper'a для нашего языка, и ищем для этого человека, который сделает хорошо!

Задачи

  • изучить способы создания плагинов для visual studio code, например, познакомиться с Language Server Protocol
  • посмотреть на существующий код различных плагинов, сделать из увиденного правильные выводы
  • превратить вышенаписанное в великолепный плагин для visual studio code с автодополнением, поиском ошибок и т.д.

Требования

Подразумевается, что ты:

  • умеешь писать на C# как минимум маленькие самостоятельные проекты (как это было, например, в курсе основ программирования от Контура)
  • имеешь базовые представления о гите { ну, хотя бы название слышал (: }
  • знаешь основные паттерны ООП

При этом в наших сердцах откликаются знания и\или стабильное желание разобраться в:

  • алгоритмах и структурах данных
  • парсинге текста и обработке AST
  • стандартных подходах разработки компиляторов и прочих IDE

А ещё из личностных характеристик приветствуется:

  • умение поддержать разговор о котиках =(^_^)=
  • самостоятельность
  • упорность

И самое главное требование: иметь личные тапочки, которые можно принести в офис! 

Примерное описание процесса менторской программы

Выбирается один или несколько дней, в которые герой, взявшийся за задачу, приходит в офис на МП5, кушает печенки,
обсуждает вектор и сроки решения текущей подзадачи, получает\даёт обратную связь.

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

Впрочем, никто не будет против обсудить другие подходы к организации рабочего процесса ;) 

Ключевые слова

DSL, C#, AST, XML, grammar, compilers, IDE, visual studio code, lsp, json, json-rpc, antlr, TypeScript

Если хочется спросить что-то, что не достаточно освещено в описании — приходи на собеседование, на нём можно будет спросить всё что угодно :) 

7. Передача бухгалтерской и налоговой отчетности с согласия клиента в банки 

Ментор: Сафаров Эльдар

Нужен: Аналитик

Описание проекта

У Контура есть продукт “Отчетность в банки”. Через него клиенты Экстерна (сервис по сдаче отчетности) отправляют декларации в различные контролирующие органы. Так же могут отправить и в банки. Сейчас сотрудники банка могут эту отчетность забирать через веб-интерфейс, мы хотим, чтобы банки отчетность с согласия клиентов забирали через API. 

Нужно будет:

  • Разобраться как работает текущий сервис
  • Кто им пользуется, какие пользовательские сценарии 
  • Как эти сценарии изменить и как научиться отдавать данные через API 
  • Спроектировать архитектуру взаимодействия и методы взаимодействия 

Бонусом можно будет придумать как отдавать в банки не только финансовую отчетность, но и результат ее анализа. У Контура есть продукт Эксперт. Это сервис для финансового анализа, у сервиса есть API. 

8. Определение регресса системы (cервиса) между запусками нагрузочного тестирования.

Менторы: Ширман Денис

Нужен: разработчик на С#, который готов в процессе решения задачи применять другие языки

Описание проекта

Наша команда занимается развитием отказоустойчивости вебсервисов, для этого мы разрабатываем специальные инструменты и практики, которые помогают добиться этой цели.
Одной из best-practices является проведение нагрузочного тестирования(НТ) http-сервиса перед его непосредственным релизом. 

Один из вариантов НТ выглядит так:

  1. У вас есть http-сервис. Он развивается, а значит вы добавляете в него новую функциональность. Новая функциональность - новый релиз сервиса.
  2. Вы хотите убедиться, что при релизе ваш сервис не деградирует в производительности.
  3. Вы запускаете нагрузочное тестирование на старом коде.
  4. Затем на новом.
  5. Смотрите на метрики (CPU, RAM, Latency и т.д.) и решаете, есть ли деградация или нет. 

Задача: Создать инструмент, который бы смог сравнивать результаты НТ и определять регрессию.

 

 

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

Остались вопросы?

Пиши на kontur-student@kontur.ru
Я постараюсь ответить как можно быстрее :)