Сервис clkr. me помогает сделать выступления с презентациями легче и избавляет от необходимости пользоваться кликером — достаточно вашего смартфона. Работает все просто: выбираете Google-презентацию, получаете короткую ссылку на показ слайдов, открываете ее на устройстве и — все готово к выступлению. Слайды можно переключать из мобильной веб-версии, а также из Android-приложения, в которых доступна еще и лазерная указка. Также сервис делает возможным выступление сразу нескольких спикеров с независимыми кликерами.

Проект реализован как монолитное серверное веб-приложение на Typescript и фреймворке Nest. js на основе классических REST API и протокола SSE. Одновременно к серверу подключается множество дисплеев и множество кликеров, а сам сервер играет роль посредника — перенаправляет запросы, тем самым синхронизирует состояния устройств.

Во время работы над этим проектом мы столкнулись с несколькими критическими техническими трудностями. Во-первых, нас подвел Google Drive API на Android, который не позволил реализовать импорт презентаций через системный диалог. Во-вторых, нам пришлось решать проблему с переключением слайдов в iframe с Google-презентацией. Первые два дня мы потратили как раз на все это.

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

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

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

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

Для реализации библиотеки мы решили использовать Kotlin Multiplatform, который позволяет компилировать код на Kotlin под совершенно разные целевые платформы: от web до нативного кода, и от JVM до web assembly. В библиотеке мы не использовали никаких платформо-специфичных зависимостей, что дало нам возможность по полной использовать KMP.

Еще во время первой демонстрации библиотеки, мы решили написать несколько плагинов для IDE, так как это то самое место, где разработчики чаще всего редактируют JSON-документы. Выбор пал на две самые популярные платформы: IntelliJ IDEA и VS Code. Для первой мы написали плагин на Kotlin для JVM, а для второй — на TypeScript. Так мы показали, что библиотека действительно не зависит от платформы, а значит, основная цель проекта достигнута.

Для разработчика взаимодействие с нашей библиотекой выглядит так: реализуется интерфейс DocumentVisitor, в котором нужно описать логику по отрисовке UI на основании нашего внутреннего представления. Именно за счет этого получается скрыть от пользователя библиотеки все сложности по парсингу и обработке JSON-схемы и ему остается сделать только небольшую часть работы. Более того, можно переиспользовать уже написанные классы-реализации DocumentVisitor. Кода получается настолько мало, что у IntelliJ-плагина он составляет всего 160 строк.

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

На осеннем хакатоне я был просто разработчиком, а в этот раз идея моего проекта прошла отбор, и я стал тимлидом. Опыт для меня очень интересный, тем более что этот проект оказался сложнее и потребовал более высокого уровня навыков, как хардов, так и софтов. Задачи удалось разбить на большие блоки, которые не блокировали друг друга, поэтому все смогли работать самостоятельно. Кто-то делал MVP, который генерировал html-формы с минимумом интерактивности, другие писали ядро библиотеки, а кто-то писал базовую реализацию отрисовки UI на swing, что позволило нам потом быстро написать плагин для IntelliJ IDEA. В целом, благодаря такому подходу мы достаточно быстро начали показывать жизнеспособное решение.

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

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

Технически наш продукт — это web-scrapper, который со страницы LMS нашего курса достает ссылки на записи занятий и отправляет их в суммаризатор 300.ya.ru. Затем результат мы сохраняем в две базы данных: postgres для получения текста суммаризации и meilisearch для полнотекстового поиска по темам среди суммаризаций.

Главной трудностью в реализации оказалось то, что у каждого студента индивидуальный набор курсов, поэтому с одного аккаунта мы не могли собрать записи всех занятий. Также много корректив внесла сама API 300.ya.ru: мы могли работать только с лекциями, записанными на нашем направлении и выложенными на YouTube.

Так как в этот раз мою идею отобрали для хакатона, я исполнял роль тимлида. С прошлого хакатона я понял: чем более обособленными будут компоненты, тем легче будет работать параллельно. Основную часть времени мы работали независимо, а в конце соединили части работы, получилось хорошо, да и сэкономило много времени и нервов. Также на осеннем хакатоне я усвоил простую истину: если кто-то уже решил задачу хорошо — переиспользуй его решение. В нашем случае это относится к реализации поиска по суммаризации, где мы воспользовались существующим решением meilisearch, благодаря чему получили поиск практически «из коробки». Но нам нужно было иметь суммаризацию в двух разных баз данных: postgres и meilisearch. Мы нашли проект, который перекачивал данные из одной в другую, но он оказался сырым и так и не запустился у нас, а потратили мы на него достаточно много времени. Так что переиспользовать решения — хорошо, но нужно это делать с осторожностью.

Но несмотря на все сложности, я рад, что удалось поближе поработать с однокурсниками!

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

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

С технической точки зрения проект состоит из двух микросервисов: Telegram-бота, написанного на фреймворке jaicf, и сервиса поиска, представляющего собой API для загрузки мемов, их описания и поиска. Для хранения картинок мы использовали s3, а в качестве поискового движка — elastic search. В планах было добавить какую-нибудь нейронную сеть, чтобы можно было автоматически генерировать описания к мемам, но, к сожалению, мы не успели реализовать эту часть проекта.

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