DevDays Fall 2021:
от идеи до прототипа
от идеи до прототипа
Каждые полгода на нашей магистерской программе проходит хакатон – DevDays. Это 4 дня, в течение которых команды студентов разрабатывают свои собственные проекты: от идеи до прототипа. Помимо отработки навыков реализации реальных проектов, хакатон помогает научиться работать в команде, а некоторым студентам еще и попробовать себя в роли тимлидов.
На DevDays Fall 2021, который проходил в первую неделю декабря 2021, было представлено девять проектов. Руководители некоторых из них поделились своими впечатлениями и рассказали о том, что им удалось сделать.
На DevDays Fall 2021, который проходил в первую неделю декабря 2021, было представлено девять проектов. Руководители некоторых из них поделились своими впечатлениями и рассказали о том, что им удалось сделать.
Арсен Нагдалян
team lead проекта REPL ++
Я делал проект в команде с Юрой Каменевым и Кириллом Карташевым. Он заключается в реализации механизма REPL (интерактивного интерпретатора) для языка C++. Идея для проекта возникла, когда я делал домашнее задание по плюсам, и мне захотелось иметь такой механизм, который позволил бы что-то проверить, над чем-то поэкспериментировать.
Как известно, C++ – компилируемый язык. А это означает, что разработчикам необходимо писать целые готовые программы, чтобы их запустить. То есть сначала будет происходить процесс компиляции, а только потом исполнения. С другой стороны, часто в разработке возникает необходимость провести какой-то эксперимент, оценку параметров, проверить, как работает тот или иной метод стандартной библиотеки, просто провести локальный дебаг. Для этого очень удобным оказывается механизм REPL, который реализован в интерпретируемых языках, например, на Python. Но в тех языках это происходит более-менее естественным образом. А в случае C++ есть определенные вызовы и сложности – как минимум, изначальная его компилируемая природа.
У нас были задачи минимум и те, что стали для нас значительными челенджами. Задача минимум – заставить наш механизм работать так, чтобы при получении каждой новой строчки кода от пользователя, он просто его исполнял. Наивное решение этой задачи может привести к повторению на каждом шаге уже произведенных вычислений. Этого, конечно же, хочется избежать из-за возможных сайд эффектов, например, повторной записи в файл. В идеале, хотелось также позволять пользователю переопределять уже объявленные сущности, такие как функции, переменные, классы и структуры.
В итоге нам удалось добиться того, чтобы каждая новая строка кода от пользователя выполнялась отдельно, не повторяя предыдущих вычислений. Таким образом мы получаем отсутствие сайд-эффектов. Также мы поддержали переопределение сущностей. Например, можно заново написать уже объявленную функцию, и ее прежняя реализация будет обновлена. Такой же механизм работает и для классов, но для них существуют ограничения, в частности, связанные с наследованием. Самой нетривиальной задачей оказалось сохранение состояния памяти между шагами исполнения. Мы решили это, работая с памятью из динамических библиотек, однако такой подход не поддерживает указателей. Нам известны альтернативные способы работы с состоянием памяти, которые можно будет реализовать в будущем.
Конечно, на рынке существуют аналогичные решения для C++, в частности, от ЦЕРН. Но я посчитал, что ничего плохого не будет, если мы предложим альтернативу. Мы не пытались создать заявку на конкуренцию за четыре дня, но какой-то свой прототип всегда сделать неплохо.
Видео с демонстрацией работы
Ссылка на GitHub
Как известно, C++ – компилируемый язык. А это означает, что разработчикам необходимо писать целые готовые программы, чтобы их запустить. То есть сначала будет происходить процесс компиляции, а только потом исполнения. С другой стороны, часто в разработке возникает необходимость провести какой-то эксперимент, оценку параметров, проверить, как работает тот или иной метод стандартной библиотеки, просто провести локальный дебаг. Для этого очень удобным оказывается механизм REPL, который реализован в интерпретируемых языках, например, на Python. Но в тех языках это происходит более-менее естественным образом. А в случае C++ есть определенные вызовы и сложности – как минимум, изначальная его компилируемая природа.
У нас были задачи минимум и те, что стали для нас значительными челенджами. Задача минимум – заставить наш механизм работать так, чтобы при получении каждой новой строчки кода от пользователя, он просто его исполнял. Наивное решение этой задачи может привести к повторению на каждом шаге уже произведенных вычислений. Этого, конечно же, хочется избежать из-за возможных сайд эффектов, например, повторной записи в файл. В идеале, хотелось также позволять пользователю переопределять уже объявленные сущности, такие как функции, переменные, классы и структуры.
В итоге нам удалось добиться того, чтобы каждая новая строка кода от пользователя выполнялась отдельно, не повторяя предыдущих вычислений. Таким образом мы получаем отсутствие сайд-эффектов. Также мы поддержали переопределение сущностей. Например, можно заново написать уже объявленную функцию, и ее прежняя реализация будет обновлена. Такой же механизм работает и для классов, но для них существуют ограничения, в частности, связанные с наследованием. Самой нетривиальной задачей оказалось сохранение состояния памяти между шагами исполнения. Мы решили это, работая с памятью из динамических библиотек, однако такой подход не поддерживает указателей. Нам известны альтернативные способы работы с состоянием памяти, которые можно будет реализовать в будущем.
Конечно, на рынке существуют аналогичные решения для C++, в частности, от ЦЕРН. Но я посчитал, что ничего плохого не будет, если мы предложим альтернативу. Мы не пытались создать заявку на конкуренцию за четыре дня, но какой-то свой прототип всегда сделать неплохо.
Видео с демонстрацией работы
Ссылка на GitHub
Андрей Стоян
team lead проекта «Конспекты»
Для Хакатона я предложил четыре проекта, два из которых были реализованы. Плагин для компилятора Kotlin отпал на этапе голосования. Также, к сожалению, на приложение для Angelina Braille Reader – сайта, который преобразует в обычный текст символы шрифта Брайля с фото, не хватило людей. В итоге на Хакатоне осталось два моих проекта: Study Center и Конспекты, тимлидом последнего я выступаю.
Предлагая проекты, я думал скорее не о популярности того или иного решения, а исходил из того, что мне самому очень нужно. Например, обучаясь в бакалавриате, я обычно писал конспекты на бумаге. Поскольку в таком формате оставить гиперссылку на источник не получается, приходилось многое переписывать вручную, даже чтобы добавить строчку поясняющего комментария. Имеющиеся сейчас варианты приложений для электронных конспектов также не слишком далеко уходят от обычной бумаги. Если приложение заточено под рукописный ввод, там скорее всего нет хорошей системы ссылок и оглавлений. В приложениях, подразумевающих ввод с помощью какого-то языка разметки, обычно не предусмотрен рукописный ввод. А главное – нигде нет развитой работы с источниками, PDF документ учебника не становится частью конспекта, на конкретное место в нём нельзя сослаться. Но в этом же и суть конспектирования – упорядочение и преобразование уже имеющихся материалов. В итоге я решил попробовать разработать свое идеальное приложение для ведения конспектов. Этот проект у меня зрел давно, и сразу было понимание, как его делать. Нам быстро удалось набросать общий шаблон, а дальше уже погружаться в конкретные детали. Мы взяли Kotlin и Compose и для простоты разрабатывали решение под десктоп. Конечно, не весь функционал мы успели проработать за 4 дня. Так, наше приложение позволяет писать конспект, организованный из набора ячеек (текстовых и рукописного ввода), читать PDF и делать гиперссылки.
Проект я делал вместе с Григорием Райкиным и Артемом Горбачевым. В начале у меня был период отдыха от тимлидства, пока ребята разбирались в Kotlin. Я за это время написал общий шаблон проекта и выделил задачи в виде 20-ти с лишним Issues на GitHub, которые мы затем распределяли по интересам и делали. С начала учебы мы с ребятами успели подружиться и, не смотря на очень большой объём и сложность работы, мы получали от нее удовольствие.
Видео с демонстрацией работы
Ссылка на GitHub
Предлагая проекты, я думал скорее не о популярности того или иного решения, а исходил из того, что мне самому очень нужно. Например, обучаясь в бакалавриате, я обычно писал конспекты на бумаге. Поскольку в таком формате оставить гиперссылку на источник не получается, приходилось многое переписывать вручную, даже чтобы добавить строчку поясняющего комментария. Имеющиеся сейчас варианты приложений для электронных конспектов также не слишком далеко уходят от обычной бумаги. Если приложение заточено под рукописный ввод, там скорее всего нет хорошей системы ссылок и оглавлений. В приложениях, подразумевающих ввод с помощью какого-то языка разметки, обычно не предусмотрен рукописный ввод. А главное – нигде нет развитой работы с источниками, PDF документ учебника не становится частью конспекта, на конкретное место в нём нельзя сослаться. Но в этом же и суть конспектирования – упорядочение и преобразование уже имеющихся материалов. В итоге я решил попробовать разработать свое идеальное приложение для ведения конспектов. Этот проект у меня зрел давно, и сразу было понимание, как его делать. Нам быстро удалось набросать общий шаблон, а дальше уже погружаться в конкретные детали. Мы взяли Kotlin и Compose и для простоты разрабатывали решение под десктоп. Конечно, не весь функционал мы успели проработать за 4 дня. Так, наше приложение позволяет писать конспект, организованный из набора ячеек (текстовых и рукописного ввода), читать PDF и делать гиперссылки.
Проект я делал вместе с Григорием Райкиным и Артемом Горбачевым. В начале у меня был период отдыха от тимлидства, пока ребята разбирались в Kotlin. Я за это время написал общий шаблон проекта и выделил задачи в виде 20-ти с лишним Issues на GitHub, которые мы затем распределяли по интересам и делали. С начала учебы мы с ребятами успели подружиться и, не смотря на очень большой объём и сложность работы, мы получали от нее удовольствие.
Видео с демонстрацией работы
Ссылка на GitHub
Илья Колегов
team lead проекта Study Center
Моя команда – Иванцов Илья, Сорокин Семен, Галяминский Роман и я – разрабатывала приложение, которое сделает коммуникацию с преподавателями и одногруппниками проще.
Есть такое выражение «Не будь самым умным студентом в аудитории, а будь самым глупым – задавай вопросы». Это прекрасный совет, но признать, что ты чего-то не понял перед всей аудиторией, не каждый решится. Конечно, можно подойти к преподавателю и задать вопрос лично, но такая возможность не всегда есть. Пример -– онлайн-курсы. Если обучение достаточно интенсивное, тогда нам, студентам, часто хочется спросить помощи у одногруппников или предложить вместе позаниматься и сделать домашнее задание. На хакатоне мы как раз разрабатывали платформу, которая могла бы комфортно объединять преподавателей и одногруппников между собой.
Приложение основано на экономической игре. Важно отметить, что все пользователи в приложении действуют анонимно, таким образом мы нивелируем напряжение в общении. Изначально всем участникам выдается одинаковое количество ресурса – времени. Если мы просим помощи, то отдаем ресурс, если помогаем – получаем. Также предполагается вознаграждение за пользование сервисом. Это может быть как мерч для обучающихся, так и оплата дополнительных занятий преподавателям. Таким образом мы создаем ценность от пользования сервисом. Что касается непосредственной разработки, то мы использовали PostgreSQL, Flask, ReactJS для построения web-приложения.
В нашей команде получилось так, что каждый хорош в своей области. Это позволило нам достаточно быстро распределить обязанности. К тому же мы доверяем друг другу, все проблемы и вопросы мы обсуждали и решали вместе.
Видео с демонстрацией работы приложения
Ссылка на GitHub
Есть такое выражение «Не будь самым умным студентом в аудитории, а будь самым глупым – задавай вопросы». Это прекрасный совет, но признать, что ты чего-то не понял перед всей аудиторией, не каждый решится. Конечно, можно подойти к преподавателю и задать вопрос лично, но такая возможность не всегда есть. Пример -– онлайн-курсы. Если обучение достаточно интенсивное, тогда нам, студентам, часто хочется спросить помощи у одногруппников или предложить вместе позаниматься и сделать домашнее задание. На хакатоне мы как раз разрабатывали платформу, которая могла бы комфортно объединять преподавателей и одногруппников между собой.
Приложение основано на экономической игре. Важно отметить, что все пользователи в приложении действуют анонимно, таким образом мы нивелируем напряжение в общении. Изначально всем участникам выдается одинаковое количество ресурса – времени. Если мы просим помощи, то отдаем ресурс, если помогаем – получаем. Также предполагается вознаграждение за пользование сервисом. Это может быть как мерч для обучающихся, так и оплата дополнительных занятий преподавателям. Таким образом мы создаем ценность от пользования сервисом. Что касается непосредственной разработки, то мы использовали PostgreSQL, Flask, ReactJS для построения web-приложения.
В нашей команде получилось так, что каждый хорош в своей области. Это позволило нам достаточно быстро распределить обязанности. К тому же мы доверяем друг другу, все проблемы и вопросы мы обсуждали и решали вместе.
Видео с демонстрацией работы приложения
Ссылка на GitHub
Шумаф Ловпаче
team lead проекта Doc comments REPL
Моя команда разрабатывала плагин для IntelliJ IDEA, который позволяет выполнять сниппеты кода из комментариев. Зачем это нужно? Часто бывает, что вы пишете какой-то код и не до конца уверены, что он правильно работает или, наоборот, хотите предоставить какие-то примеры, которые будут сохранены как часть документации. Для этого вы можете написать код в комментарии и нажать кнопку, которая появится слева от сниппета кода. Происходит некоторая магия, и результат выполнения сниппета будет выведен в то же место, откуда вы запускали сниппет.
Такой функционал есть у плагина для Haskell, но он работает только для Visual Studio Code, а нам хотелось добавить поддержку более популярных языков – Python и Kotlin – и реализовать это для платформы IntelliJ. Для проекта мы перелопатили много кода из IntelliJ IDEA Community и плагинов для языков, чтобы разобраться, как происходит работа с REPL, взаимодействие с процессами и как расширять пользовательский интерфейс через плагины. Сначала мы набросали прототип, а дальше перешли к более зрелым решениям отдельно для каждого языка. У нас возникло некоторое количество трудностей: языки довольно сильно отличаются по своей природе, у них разные плагины и в каждом исполнение реализовано своему. Но нам очень помогли ребята из JetBrains: Семен Прошев (команда PyCharm) и Дмитрий Новожилов (команда компилятора Kotlin), они подсказали, в какую сторону нам стоит копать.
В Хакатонах я до этого участвовал номинально. Обычно дальше презентации бизнес-идеи не заходило. А тут нужно сделать рабочий прототип. Чем хорош этот Хакатон – тут больше важна техническая часть, а не бизнесовая, можно поуправлять проектами, если ты тимлид, попробовать новую технологию.
Лично я не очень хороший руководитель, поэтому для меня это некого рода стресс, я старался держать себя в руках, чтобы волнение не передавалось Леше Полюсову, с которым мы и работали над проектом. Особого деления у нас в команде не было, мы выбирали задачи по интересам. Например, Леша занимался ядром раннера для Kotlin, я – интерфейсом и Python. Плюс небольшой команды – не надо тратить много времени на взаимодействие и синхронизацию.
Видео с демонстрацией работы
Ссылка на GitHub
Такой функционал есть у плагина для Haskell, но он работает только для Visual Studio Code, а нам хотелось добавить поддержку более популярных языков – Python и Kotlin – и реализовать это для платформы IntelliJ. Для проекта мы перелопатили много кода из IntelliJ IDEA Community и плагинов для языков, чтобы разобраться, как происходит работа с REPL, взаимодействие с процессами и как расширять пользовательский интерфейс через плагины. Сначала мы набросали прототип, а дальше перешли к более зрелым решениям отдельно для каждого языка. У нас возникло некоторое количество трудностей: языки довольно сильно отличаются по своей природе, у них разные плагины и в каждом исполнение реализовано своему. Но нам очень помогли ребята из JetBrains: Семен Прошев (команда PyCharm) и Дмитрий Новожилов (команда компилятора Kotlin), они подсказали, в какую сторону нам стоит копать.
В Хакатонах я до этого участвовал номинально. Обычно дальше презентации бизнес-идеи не заходило. А тут нужно сделать рабочий прототип. Чем хорош этот Хакатон – тут больше важна техническая часть, а не бизнесовая, можно поуправлять проектами, если ты тимлид, попробовать новую технологию.
Лично я не очень хороший руководитель, поэтому для меня это некого рода стресс, я старался держать себя в руках, чтобы волнение не передавалось Леше Полюсову, с которым мы и работали над проектом. Особого деления у нас в команде не было, мы выбирали задачи по интересам. Например, Леша занимался ядром раннера для Kotlin, я – интерфейсом и Python. Плюс небольшой команды – не надо тратить много времени на взаимодействие и синхронизацию.
Видео с демонстрацией работы
Ссылка на GitHub