Изначально эта статья была опубликована на Symfony Station.

Из-за недавнего скандала с Reddit и его недальновидным CEO опенсорсные альтернативы сейчас переживают настоящий бум. И kbin — это как раз такая Fediverse-платформа, созданная с применением Symfony, API Platform и Schema Generator 3 Эрнестом Вишневски (Ernest Wiśniewski). Это именно то, на что вам нужно обратить свое внимание в первую очередь, если вы больше не хотите поддерживать самодуров, управляющих Reddit.

Стоит отметить, что еще одна популярная Fediverse-альтернатива, Lemmy, также имеет проблемы с руководством. Конечно, случаи, когда продуктом управляет не кучка идиотов, на платформе все-таки встречаются. Так что если вы решите, что kbin не совсем, то что вы искали, то мы рекомендуем попробовать beehaw.org.

Как упоминалось в моей статье “You say you want a revolution: help the free, fair, and friendly Fediverse destroy Big Social;” kbin — это сервис, очень похожий на Reddit. Это агрегатор контента с открытым исходным кодом плюс микроблогинговая платформа (как Mastodon). Но что самое замечательное — он создан на основе превосходных экосистемных партнеров Symfony!

Вы можете создавать и модерировать сообщества (журналы/Magazines), находить людей со схожими интересами и увлечениям. Лично мы создали  (список действий смотрите ниже) сообщество, которое охватывает Symfony, Drupal и PHP.

Сам kbin характеризует себя так:

Kbin — это модульный децентрализованный агрегатор контента и микроблогинговая платформа, работающий в сети Fediverse. Он может взаимодействовать со многими другими сервисами ActivityPub, такими как Mastodon, Lemmy, Pleroma и Peertube. Эта инициатива направлена ​​на продвижение свободного и открытого интернета.

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

Мобильные приложения создаются с помощью фреймворка Flutter и языка Dart. Это хорошая новость, поскольку это позволяет создавать одновременно Apple, Android и PWA. Они увидят свет ближе к концу этого года.

Опять же, из-за фиаско Reddit API и последующего бойкота модераторов и пользователей, kbin.social (первичный инстанс) вырос с нескольких тысяч пользователей до 123 000 с лишним в этот понедельник. По состоянию на вторник их число превысило отметку в 127 000 пользователей. Вы можете сами посмотреть текущую статистику здесь.

Хочу также упомянуть хороший инстанс, созданный экспертом по информационной безопасности, Fedia.io. Их теперь больше 21 000. Kilioa — это еще один инстанс на более чем 8 000 пользователей. И readit.buzz — еще один хороший инстанс, созданный администратором с хорошей репутацией на Mastodon (около 2000 пользователей).

Но чтобы как следует раскрутиться нам нужно куда больше инстансов (смотрите ниже).

Несмотря на некоторое замедление работы сайта kbin.social из-за невероятной нагрузки на серверы, вызванной самым настоящим цунами трафика, код все-таки справился с понедельником, когда происходила миграция с Reddit. И это неудивительно, если учитывая то, на основе чего был построен kbin. Кроме того, некоторые злонамеренные реддиторы решили помешать его работе с помощью DDOS-атак, поэтому возникла необходимость в услугах Cloudflare.

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

• 1 — присоединиться к kbin.social или другому связанному инстансу.

• 2 — поддержать Эрнеста и проект финансово.

• 3 — подписаться на наш журнал, посвященный Symfony.

• 4 — подписаться на Эрнеста.

• И наконец, подписаться на меня. 😉

Создан на основе экосистемы Symfony

Symfony

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

Вот требования его инстанса, которые касаются экосистемы Symfony:

• Версия PHP: 8.1 или выше

• PHP-расширение GD или Imagemagick

• NGINX/Apache/Caddy

• PostgreSQL

• Redis (опционально)

• Mercure (опционально)

• RabbitMQ (опционально)

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

И вы также имеете возможность просмотреть код на Codeberg.

API Platform

Пакет API Platform позволяет kbin быть частью Fediverse.

Поскольку сам я не являюсь экспертом в этой области, я процитирую сайт API Platform:

API Platform ActivityPub — это пакет для фреймворка API Platform и Symfony, поддерживающий протокол ActivityPub и словарь ActivityStreams.

Протокол ActivityPub — это протокол для создания децентрализованной социальной сети. Он предоставляет клиент-сервер API для создания, обновления и удаления контента, и федеративное сервер-сервер API для доставки уведомлений и контента.

API Platform ActivityPub позволяет легко добавлять поддержку ActivityPub в новые или уже существующие проекты на API Platform, сохраняя при этом преимущества всех фич API Platform (да, речь идет о Mercure, Vulcain и GraphQL!).

Более подробную информацию вы можете найти здесь.

Насколько я помню, Эрнест создал специальную версию для инстанса kbin.social. Но это все так быстро развивается, что я могу ошибаться.

Schema Generator 3

Этот инструмент представляет собой основной костяк, необходимый для организации платформы kbin.

Я не большой эксперт по генерации схем, поэтому я процитирую его идейного вдохновителя, Кевина Дугласа (Kevin Douglas):

“API Platform Schema Generator третьей версии — это инструмент командной строки, часть фреймворка API Platform, который мгновенно создает полную модель данных PHP (классы, перечисления, ORM, правила проверки данных, определения веб-API, PHPDoc…) из словарей RDF и онтологии. Словари RDF обычно используются для определения отношений и представлений о ресурсах в облачных (Schema.org), отраслевых (The NASA Air Traffic Management Ontology, The Automotive Ontology, AddictO Vocab), или организационных (EU Vocabularies, Volkswagen Vehicles Ontology) масштабах.

Среди множества различных словарей RDF на роль основы для этой децентрализованной сети особенно подходит ActivityStreams. Это словарь ActivityPub, поддерживаемый W3C протокол, используемый для создания децентрализованных и федеративных социальных сетей. ActivityPub уже реализован таким популярным программным обеспечением для социальных сетей, как Mastodon, PeerTube, Mobilizon, и WriteFreely. Серверы, реализующие протокол ActivityPub, совместимы и объединены в то, что мы называем Fediverse (Фидеверс)».

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

kbin — треды и микроблогинг

Позвольте мне начать с того, что дизайн и пользовательский интерфейс kbin просто фантастические. Особенно для прототипа. Да и само приложение отличное.

Вы взаимодействуете с kbin как человек (пользователь) и можете отслеживать (follow) людей (других пользователей из kbin и других федеративных платформ, таких как Mastodon) или журналы (аналогичные сабреддитам). Вы также можете следить за группами на Lemmy и других платформах Fediverse.

И другие участники федеверс (Fedizen) также могут отслеживать вашу учетную записью на kbin.

Журналы (Magazines)

Чтобы не утонуть в бурном потоке ленты kbin вам следует подписываться на отдельных пользователей и журналы. Точно так же вы отслеживаете собственную ленту в Mastodon, а не сразу всю федерацию.

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

Треды (Threads)

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

Итак, вы можете лайкать (up) и дизлайкать (downvote), бустить (boost), реплаить (reply) и т.д. и т.п.

Микроблоги (Microblogs)

Я точно не знаю, каков лимит символов для микроблогов, но под микро подразумевается что-то вроде 500, как в том же Mastodon.

Как видно на изображении выше, вы можете добавлять ссылки, стилизовать текст (в отличие от Mastodon), а также изображения и хэштеги.

Пользователи различных Fediverse-платформ могут подписываться на вас как на пользователя kbin и наоборот. Это очень удобно, когда вы хотите ограничится всего одной учетной записью в рамках Fediverse. kbin позволяет вам сделать все это.

Руководство пользователя

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

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

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

В отличие от коммерческих социальных сетей, здесь вам ничего не навязывают.

Вы можете узнать о всех возможностях kbin на их сайте.

Моих любимых можно выделить:

• RSS-каналы

• Статистику

• Несколько типов тредов и элементов управления

• Сообщения и комментарии

• Инструменты модератора

Разработчики, kbin нуждается в вас!

Что касается критической части, нам нужны специалисты для работы над Symfony, Drupal и PHP инстансами. К сожалению, мне как контент- и фронтенд-персоне это не под силу. Но я готов донатить на это деньги.

Если вы способны разработать Symfony или Drupal приложение, то эта задача вам по силам.

Вот как вы можете создать инстанс.

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

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

Заключение

Если вы дочитали до этого момента, то уже поняли, что kbin — это захватывающая новая часть Fediverse. И у него большое будущее впереди, особенно если вы примете в нем участие.

Он надежный, как кирпичный дом, благодаря фантастическим инструментам экосистемы Symfony.

И если вы знакомы с Reddit или другими платформами Fediverse, он подойдет вам как родной.

Итак, если вы еще не сделали этого, выполните пять действий, перечисленных выше, и пошлите Reddit на три буквы. Пришло время отчалить в светлое будущее вместе с kbin!

Полезные ресурсы

1. Официальный сайт kbin

2. Документация kbin

3. kbin-core — Kbin — это децентрализованный агрегатор контента и платформа микроблогинга, работающая в сети Fediverse.

4. API Platform

5. Документация по Kittn API

6. Коммюнике по нашей библиотеке (здесь найдете огромное количество кураторского вечнозеленого контента).

В преддверии старта курса «Symfony Framework» приглашаем на открытый урок, посвященный RabbitMQ. На этой встрече мы реализуем асинхронный поточный процесс обработки и RPC с помощью RabbitMQ. Записаться можно по ссылке.

Если не можешь найти дорогу, иди туда, где её нет, и оставь след.

Ральф Уолдо Эмерсон

Попользовавшись множеством приложений вида «калькулятор калорий» и «трекер тренировок», пришел к выводу, что функционал подобных приложений не так широк, как этого бы хотелось, а доступ к более‑менее продвинутому функционалу стоит несоразмерно много для российского кошелька. Философия популярных приложений часто такова: вот, отслеживай съеденные калории, но чтобы контролировать соотношение БЖУ, отслеживать потребление воды и т. д. — плати деньгу. С вас 20 баксов в месяц, но только сегодня всего за 199$ можешь получить доступ на год. Ну что, пробиваем? (*утрированно*)

Касательно скудного функционала: есть прекрасные калькуляторы калорий (дневники питания), которые хоть и за дорого, но справляются со своей основной задачей — калькулировать эти самые калории + БЖУ. Про микроэлементы или хотя бы клетчатку как-нибудь промолчим. Но что касается физической активности, то она в подобных приложениях идет, как кажется, в небольшой довесок к основному функционалу, без какой-либо глубокой проработанности. Еще один пример: есть список видов физической активности — можешь их добавить, указав продолжительность, мы примерно рассчитаем, сколько калорий ты потратил и запишем в дневник тренировок. (Хотя такие расчеты очень примерны и мало отражают действительность, в принципе, как и расчет калорий, который потребил организм, но сейчас не об этом). Хочешь программу тренировок? Отслеживать каждый подход? Получить подробную статистику и рекомендации? — сори, у вас документов нету, такого функционала не подвезли.

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

Почему так, Обэме?

— Почему чат‑бот?

Я не замечал чат-ботов схожего функционала, поэтому пришла идея сделать свой (может быть, плохо искал). Встречал боты со всякими калькуляторами для расчета КБЖУ и всего такого, однако такой скудный функционал нам неинтересен. Мне было нужно что-то единое, где в одной «пачке» — дневники питания и тренировок.

Также здесь мы сразу обрубаем на корню проблему с кроссплатформенностью, так как приложение Telegram можно открыть на телефоне, компьютере или же использовать веб-версию в браузере.

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

А вот весомый плюс — легкость и быстрота разработки. Есть готовый интерфейс, а тебе остается только определить кнопки, команды и сообщения, который будет слать и принимать бот. Быстро, дешево и сердито.

— Почему Telegram?

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

Цели и мечты

Перед тем как начать писать код, давайте ответим на вопрос: «А что же мы собираемся сделать?»

GPT-3.5

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

Что касается монетизации, то было решено сделать классическую систему подписок по периодам: неделя, месяц и т. д. Но перед тем как её купить, юзер может получить бесплатные 7 дней, а потом уже решать — надо это ему или нет. Цены решено было выбрать достаточно демократичные, чтобы стоимость подписки была не более той, которую пользователь привык тратить на другие сервисы для просмотра фильмов или прослушивания музыки. То есть должна получиться эдакая «бытовая» трата, которую человеку не жалко отдать за полезный продукт — 200-300 рублей в месяц.

Для реализации данного функционала решено было выбрать API ЮMoney (бывшие Яндекс. Деньги), взаимодействие с которым велось посредством библиотеки yoomoney от Алексея Коршука.

БД нет, но вы держитесь

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

Чтобы юзер смог занести какую-либо физическую активность, нужно где-то достать список ее видов, а это оказалось не так просто, так как нормальных готовых баз на русском языке, по всей видимости, просто нет. Поэтому пришлось строить ее самостоятельно, а так как делать это очень долго, нужно процесс автоматизировать. При этом в сети куча сайтов с каталогами физических упражнений, а это значит — заводим свой Selenium и начинаем парсить. В качестве цели был выбран не топовый, но более-менее популярный сервис DailyFit, где страницы упражнений сжатые, без воды и лишь с основной информацией, которая нам нужна на этапе создания МЖП:

• Название

• Целевая группа мышц

• Дополнительные группы мышц

• Вид упражнения (силовое, кардио, растяжка или плиометрическое)

• Тип упражнения (базовое, изолирующее) — только для силовых упражнений

• Необходимое оборудование (штанга, гиря и т. д.)

• Уровень сложности

Также на каждой странице есть симпотишные фото выполнения каждого упражнения, при этом в 2 вариантах: мужское исполнение и женское. Все фото мы парсим тоже, и оба вида — потом будем показывать фото соответственно полу пользователя. При этом нам не нужно никуда сохранять каждое фото, достаточно только ссылки на него.

Всего на момент парсинга каталог упражнений содержал 594 позиции, что довольно прилично и охватывает, наверное, почти все возможные виды, которые может искать пользователь. Теперь наша БД (в моем случае на SQLite ) заполнена кучей упражнений, да еще и по несколько фото к каждому (целых 2582 штуки). Все ссылки на фото хранятся в отдельной таблице и каждое из них имеет колонку с идентификатором пола (male или female) и ID упражнения, к которому оно относится. Ниже можете просмотреть, какие у нас получились таблицы:

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

https://github.com/Molot999/dailyfit_parser

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

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

Чем больше выбор, тем сложнее попасть в цель

База данных готова, осталось определить, как пользователь будет искать то самое упражнение из общей кучи. Самое простое, что можно сделать — это реализовать механизм поиска по названию. Ввел пользователь запрос «жим», а мы ему:

И еще 70 видов физических упражнений из нашей БД, в которой есть слово «жим». Сделать такую выборку очень просто, используя простейший функционал нашей СУБД SQLite3, а именно при помощи оператора LIKE:

 SELECT * FROM available_exercises WHERE title LIKE '%жим%';

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

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

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

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

• Перед тем как что-то искать, необходимо удостовериться в том, что юзер написал запрос корректно и без ошибок («жим», а не «жым»). Для этого воспользуемся сервисом Яндекс.Спеллер, который исправляет в тексте орфографические ошибки. Для взаимодействия с API данного сервиса нам поможет библиотека pyaspeller.

• Теперь решаем проблему с окончаниями, о которой говорилось выше. Что для этого нужно сделать? Правильно — попросту убрать окончания, получив основу слова (или же нескольких слов), то есть провести стемминг. В этом нам поможет библиотека nltk. Теперь, если юзер ввел «разгибание гантелей», то в запросе будет «разгибан гантел».

• Теперь можно начать сам поиск по БД. Здесь без изменений — используем тот же оператор LIKE. Если в запросе несколько слов, используем оператор AND, тогда в выдаче получим только те упражнения, где в названии есть сразу обе подстроки (и «разгибан» и «гантел» сразу).

• Теперь в ход идут метрики, по которым мы поднимаем наверх те упражнения, которые с большей вероятностью интересны пользователю. Первый из них — это коэффициент Жаккара (насколько название упражнения приближено к запросу пользователя). К примеру, юзер ввел «жим штанги лежа» и благодаря использованию этого коэффициента список упражнений будет таким:

  1. Жим штанги лежа

  2. Жим штанги лежа узким хватом

  3. Жим штанги лежа широким хватом

• Следующая метрика — «популярность» упражнения, которая складывается из количества просмотров и количества фактических выполнений упражнения другими пользователями. Как можно полагать, количество выполнений является более приоритетной цифрой, поэтому число просмотров и число выполнений должны иметь разный вес. В качестве теста было распределить его так: просмотры — 0.3, а выполнения — 0.7.

• Теперь осталось провести сортировку списка упражнений по 2 метрикам:

search_results.sort(key=lambda ex: (ex.popularity, ex.similarity), reverse=True)

• На заключительном этапе нужно проверить, что длина сообщения с упражнением не будет выходить за допустимые пределы. В моем случае каждая строка с упражнением состоит из id упражнения в БД с косой чертой (чтобы можно было нажать на него и выбрать упражнение, а не вводить вручную) и его названия. Соответственно, нам нужно получить длину каждой строки упражнения по следующей формуле: длина id + длина названия + 2 (косая черта и пробел между ID и названием). Далее складываем длину всех строк и проверяем, будет ли длина сообщения выше допустимого предела (4 096 символов) и если больше — убираем последнюю строку и далее по кругу, пока длина не впишется в лимит. Если в сообщении помимо списка есть еще текст — учитываем и его длину.

  На этом все, осталось только послать сообщение со списком упражнений пользователю. Например, такое:

Косые черты рядом с ID упражнения в данном случае помогают сделать команду, которая при нажатии автоматически отправляется боту. Далее, получив ID упражнения в БД, мы можем вывести его подробную информацию. К примеру, такую:

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

Структура дневника тренировок

Здесь все относительно просто: пользователь начинает тренировку, выбирает упражнения и вносит подходы по каждому упражнению. Соответственно, нам нужно создать 3 таблицы в нашей базе данных: Тренировки, Упражнения и Подходы. При этом упражнение хранит ID тренировки, а подход — ID упражнения в ее рамках.

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

А в сводке по всей тренировке выводим все упражнения, количество подходов и время выполнения всего упражнения (немного поинтереснее):

По окончании тренировки можем просмотреть краткую сводку по ее длительности объему, интенсивности и количеству упражнений:

И щепотка статистики

Не так интересно отслеживать отдельную тренировку, как просмотреть статистику по всем и оценить общий прогресс.

На первое время было решено сделать статистику по 3 метрикам, которые как раз и есть в сводке по окончании тренировки: объем, интенсивность и длительность.

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

Конец

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

Можете затестить функционал чат-бота совершенно бесплатно, подписка не нужна.

В следующей статье рассмотрим организацию дневника питания и его интересные фишки. Например, такие:

Raspberry Pi — это универсальный компьютер, который можно использовать как угодно. Есть тысячи вариантов, где его применить. Поэтому не совсем понятно: что считать стандартным, а что — нестандартным вариантом использования? Например, управление станками или умный дом — вполне логичное применение «малинки», тем более что Home Assistant отлично работает на RPi OS. Блокировка рекламы/соцсетей из домашней сети на общем файрволе Pi-Hole или простейший piVPN — тоже очевидная и общепринятая практика.

Но есть гораздо более странные примеры.

▍ Второй разъём HDMI для ноутбука

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

Французский разработчик Пьер Куи (Pierre Couy) не хотел мириться с таким неудобством и придумал интересный хак: второй виртуальный HDMI через Raspberry Pi.

Если подключить второй монитор по HDMI к «малинке», то есть несколько вариантов, как передать картинку на ноутбук. Сначала автор выбрал самый логичный способ по Ethernet с использованием медиаплееров типа VNC, Steam Remote Play и всяких VNC-оболочек, разработанных для этой цели. Но его не удовлетворяло общее качество видео: фреймрейт, скорость сети, нагрузка на CPU, обязательный запуск десктопной сессии на стареньком RPi 3.

Поэтому он решил оптимизировать установку — и вместо готового видеоплеера использовать для трансляции видео по сети утилиту командной строки ffmpeg, о богатых возможностях которой уже рассказывали на Хабре.

Этот универсальный инструмент берёт на себя захват видео, транскодирование, инкапсуляцию в сетевой трафик, передачу по сети, обеспечивая тонкий контроль над каждым шагом. На стороне приёма можно выбрать любой из ffmpeg-совместимых плееров c поддержкой Direct Rendering Manager, включая mpv, vlc и ffplay.

В общем виде передача потока выглядит примерно так.

На стороне отправителя (ноутбук):

$ ffmpeg -video_size 1920x1080 -framerate 5 -f x11grab -i :0.0+0x0 -f mpegts tcp://10.0.0.1:1234

На стороне получателя (RPi + второй монитор):

$ mpv -vo=gpu --gpu-context=drm --input-cursor=no --input-vo-keyboard=no --input-default-bindings=no --hwdec=drm --untimed --no-cache --profile=low-latency --opengl-glfinish=yes --opengl-swapinterval=0 --gpu-hwdec-interop=drmprime-drm --drm-draw-plane=overlay --drm-drmprime-video-plane=primary --framedrop=no --speed=1.01 --video-latency-hacks=yes --opengl-glfinish=yes --opengl-swapinterval=0 tcp://10.0.0.1:1234\?listen

Или родной для ffmpeg плеер ffplay:

$ ffplay -autoexit -flags low_delay -framedrop -strict experimental -vf setpts=0 -tcp_nodelay 1 "tcp://10.0.0.1:1234\?listen"

Для оптимизации кодировщика и объяснения команд см. отчёт с описанием всех подводных камней.

В итоге получается «виртуальный HDMI» для подключения второго монитора, если вы хотите избежать установки проприетарных драйверов и адаптера DisplayLink, а интерфейс USB-С на ноутбуке не поддерживает работу в режиме «HDMI over USB-C».

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

▍ Дешёвый NAS

Недорогой файл-сервер на SSD — практически стандартное применение RPi. Блогер Джефф Гирлинг собирает такие пачками в разных конфигурациях, а по производительности они не уступают специализированным NAS нижнего ценового сегмента (на ARM-процессорах).

Правда, его последняя поделка базируется на более мощном одноплатнике Rock 5 с 8-ядерным процессором Rockchip RK3588 SoC (четыре A76, четыре A55, по системе big.LITTLE), но принцип тот же. Внешний разъём PCIe Gen 3 x4 M.2 используется для подключения шести SSD-накопителей в компактной конфигурации.

Главное — не забыть о вентиляторе.

Примерно такую же конструкцию можно соорудить на базе RPi+SSD. Если подключать HDD, получится дешевле, но компактность потеряется, вот примеры:

Хотя цена такого элегантного решения может оказаться дороже самого дешёвого NAS, собранного из бэушных старых деталей.

▍ Карманный компьютер

На одноплатнике можно собрать оригинальный карманный компьютер.

Комплект для сборки включает Raspbery Pi CM4, плату расширения BTT Pad 5, дисплей 800×480, сменный аккумулятор (ячейки US18650VTC6), порт зарядки USB-C на 10 Вт и Bluetooth-клавиатура (полный список компонентов). Всё это размещается в специальном корпусе, напечатанном на 3D-принтере (чертёж корпуса):

Карманный компьютер Decktility на основе RPi сделан по образцу Yarh.io Micro 2, uConsole и других любительских ретро-КПК на базе RPi.

Ещё фото

Пошаговую инструкцию по сборке см. здесь.

▍ Высококачественная кинокамера

Довольно экзотическая штука — видеокамера CinePI с прицелом на профессиональную киносъёмку.

Её уникальная функция: съёмка видео в несжатом формате 2K RAW Cinema DNG с частотой кадров до 50 fps и 12-битным цветом. Хоть это не 4K, а всего 1080p, но профессиональные видеокамеры такого класса стоят многие тысячи долларов.

Четырёхдюймовый дисплей высокого разрешения HyperPixel 4.0 Square, плата управления питанием и все остальные компоненты видеокамеры подключены к Raspberry Pi по единой шине.

Видеозапись без сжатия в 12-битном цвете обеспечивает высочайшую цветопередачу, особенно в сравнении с дефолтным кодеком H.264, который Raspberry Pi поддерживает на аппаратном уровне.

Некоторые кадры подводной видеосъёмки для оценки цветопередачи:

Ещё фото

▍ Сервер на плате mini ITX

Интересный вариант моддинга — установка Compute Module 4 на плате формата Mini-ITX, которая подходит для настольных компьютеров, а особенно — серверов. Она моментально превращает CM4 в полноценный сервер.

В 2021 году проект по созданию такой платы Over:Board не собрал достаточного финансирования на платформе краудфандинга Indiegogo. Хотя выглядел красиво:

Больше прототипов

Аналогичную плату Seaberry Mini ITX тоже сняли с производства. Опять же, идея материнской платы для Raspberry Pi CM4 с 11 разъёмами mini PCIe, M.2 и проч. была великолепной. Только представьте, сколько SSD-накопителей можно подключить к одному модулю:

Seaberry Mini ITX

Но идею подхватили — и платы Mini ITX всё-таки появились, пусть и в другом виде. Например, модель Turing Pi 2. Это мини-кластер с четырьмя разъёмами для установки вычислительных модулей Raspberry Pi CM4, Turing RK1 или Nvidia Jetson в любой комбинации.

Фото

▍ Лучшие аксессуары для Raspberry Pi

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

Ещё фото

Там можно найти очень экзотические штуки, которые расширяют функциональность «малинки» и позволяют использовать её очень нестандартным способом. Тут большой выбор плат расширения для вывода контактной панели (HATs), моторов, сенсоров и проч.

▍ Планы на будущее

По мнению экспертов, у Raspberry Pi отличные перспективы в промышленных компьютерах. Особенно большие планы связываются с линейкой CM4.

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

▍ Когда исчезнет дефицит?

Люди заказывают дешёвые компьютеры оптом, россыпью и про запас, так что с 2021 года на рынке наблюдался постоянный дефицит «малинок».

По словам исполнительного директора Raspberry Pi Ltd. Эбена Аптона, по итогам июля 2023 года подрядчики должны выйти на объём производства 1 миллион плат в месяц. Это почти вчетверо больше, чем в начале года, когда за весь квартал произвели всего 800 000 плат, т. е. по 267 000 в месяц. Это был худший квартал с 2015 года из-за дефицита компонентов (в первую очередь, речь о SoC Broadcom BCM2835).

В 2022−2023 гг. практически полностью остановилось производство RPi Zero, Zero 2 W, 3 и 3B+, официальные реселлеры постоянно обозначали статус «Out of stock». В продажу пускали только модели 3А+ и 4. Что касается CM4, он только периодически появляется в продаже.

Но сейчас ситуация с запасами стала полегче, а Sony как контрактный производитель начал помогать с запасами других компонентов (конденсаторы и проч.), так что в июле 2023 года объём производства увеличился в несколько раз.

Все Raspberry Pi традиционно выпускаются Британским технологическим центром Sony в Пенкоеде (Южный Уэльс), см. экскурсию по заводу. Интересно, что некоторые машины на заводе по производству Raspberry Pi сами работает под управлением Raspberry Pi (например, камера охлаждения после пайки и 64 автоматических тестировочных стенда).

Кадры с экскурсии

Катушки с компонентами Raspberry Pi на конвейере

Катушка с кристаллами Broadcom — главный дефицит на производстве

Конвейер по упаковке RPi 3

В день экскурсии с конвейера сходила такая коробка на 150 плат примерно каждые пять минут. Это соответствует максимальной пропускной способности конвейера 43 200 плат в сутки, т. е. 1,3 млн в месяц

К сожалению, из-за увеличения стоимости компонентов пришлось увеличить розничную цену ряда продуктов, включая Raspberry Pi 4 (2GB), Compute Module 4 и Raspberry Pi Zero.

Raspberry Pi — это уже не только игрушка для энтузиастов, а коммерческий продукт, который используется и в промышленном секторе, и в бизнесе. Поэтому и вырос спрос. Очевидно, что компания Raspberry Pi Ltd. в первую очередь обслуживает оптовых клиентов, перед которыми у неё контрактные обязательства. Так что на розничный рынок попадают только остатки продукции (или ничего).

Возможно, запас компонентов поможет роботам ABB на конвейере Sony увеличить производство и наконец-то устранить глобальный дефицит Raspberry Pi.

Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх 🕹️

Привет! Это Виталий Чесноков, сооснователь TEAMLY. Мы делаем нашу альтернативу Confluence и Notion, а ещё собираем успешные кейсы управления знаниями в российских компаниях. Сегодня с нами поделился опытом Антон Елисеев – начальник отдела управления знаниями ОКБ Сухого ПАО «ОАК». В этой статье мы поэтапно рассмотрим, как формировалась система управления знаниями в огромном авиационном холдинге. Сейчас ей пользуются больше половины сотрудников.

Что полезного будет в тексте:

• Вы узнаете, на какие этапы на практике можно разбить процесс создания системы управления знаниями. Никаких абстрактных рассуждений вроде «Нужно создать особую атмосферу в профессиональном сообществе экспертов»

• Полезные ссылки на кейсы крупных компаний

• Простой шаблон для оценки знаниевых процессов у себя

Дисклеймер

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

Второй момент. Идеального алгоритма для создания системы управления знаниями в любой компании не существует. Эти советы актуальны для «ОАК», но в чистом виде они могут вам не подойти. Всегда надо тестировать на практике.

Третий момент. Это дисклеймер от команды TEAMLY, но мы будем описывать не свой личный опыт, а кейс «ОАК». Поэтому дальше рассказ пойдет от лица Антона Елисеева.

Для контекста: с какой целью вообще была нужна система?

«ОАК» объединяет более 30 предприятий в разных городах России. Информация и экспертиза в таких условиях оказывается разрозненной. Нужна была электронная среда, которая бы объединяла все документы и экспертов в едином пространстве. Кроме того, эта среда должна быть органично вплетена в рабочие процессы.

Пилотным подразделением выступало крупнейшее подразделение ПАО «ОАК» – ОКБ Сухого. Сейчас в нем уже более половины сотрудников пользуются системой.

Как она влияет на работу компании

Раз в два года в «ОАК» проводится анализ кадрово-квалификационного потенциала. Руководители должны оценить своих сотрудников по ряду параметров: владение компетенциями, активность, склонность к наставничеству и др. А затем отправить эти оценки в Корпоративный университет.

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

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

С чего начать строить систему управления знаниями

Изучить опыт других экспертов

Сегодня в России есть профессиональная ассоциация специалистов в менеджменте знаний – KM-Alliance. Кроме того, проводятся открытые конференции, на которых выступают практики, например, «Конференция TEAMLY: управление знаниями и эффективная совместная работа». Возможно, там вы найдете решения для компании, похожей на вашу.

Проанализировать, какие практики управления знаниями уже прижились

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

Отдельно стоит сказать про программу подготовки студентов. Взять готового конструктора со стороны сложно, поэтому в «ОАК» начинают готовить специалистов под себя, начиная с института. Параллельно с учебой в вузе, студенты изучают реальные инструменты и задачи. Таким образом, на работу приходят люди, уже способные воспринимать знания, которыми обладает компания.

Чтобы оценить, насколько эффективно работают практики управления знаниями в «ОАК», мы придумали простой и универсальный шаблон. Он поможет оценить, как работают инструменты управления знаниями в вашей компании.

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

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

Объединить все разрозненные источники информации в единой цифровой среде

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

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

Встроить ПО в рабочие процессы

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

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

Человек находит в электронной экспертной среде нужный документ в Excel. Открывает его в привычном формате, вносит изменения. А перед тем, как закрыть файл, плагин спрашивает: «Сохранить ли изменения в экспертной среде?». Достаточно ответить да.

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

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

Учитывать корпоративную культуру

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

Мы пробовали разные инструменты: от приказов до вовлечения. И эти две крайности на самом деле не действовали на причины проблем.

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

Вовлечение тоже отлично работает. Но его трудно формировать и поддерживать. Нам таким образом удалось привлечь лишь 5-10% сотрудников. И часть из них остыла к этой идее до того, как внедрение было завершено.

“На практике мы нашли третий вариант, который условно назвали «сделка». Вспомните случай с корпоративным университетом. Была проблема с подготовкой отчета. Мы помогли её решить с помощью автоматизации и незаметно внедрили элементы управления знаниями”, – рассказывает Антон.

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

Полезные ссылки, о которых мы упоминали:

✔️ TEAMLY – платформа для совместной работы и управления знаниями. Сюда переехали знания «ОАК» после всем известных событий. Есть бесплатная версия в облаке, можно протестировать

✔️ Дайджесты премии «Преображение» – здесь собраны лучшие кейсы из российской практики управления знаниями. Их выбирают профессиональные knowelege-менеджеры. Очень рекомендуем. Возможно среди этих решений вы найдете компанию, похожую на вашу.

✔️Записи докладов с конференции TEAMLY об управлении знаниями. Там тоже много докладов об управлении знаниями. Это ссылка на YouTube, так что будет удобно слушать в машине на x2, у кого дефицит времени.

✔️  Телеграм-канал TEAMLY.  Обсуждаем базы знаний, фреймворки по организации командной работы в ИТ и осмысляем теорию управления знаниями.  А ещё мы проводим много открытых мероприятий, и в первую очередь публикуем анонсы там. Подписывайтесь, чтобы ничего не пропустить.

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

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

Кого ищем в Ситидрайве

Несмотря на кризисную ситуацию на рынке, Ситидрайв продолжает расти, и за последний год к нам присоединилось более 70 новых сотрудников уровня Middle, Middle+ и Senior. 

Сильнее всего вырос штат бекэнд-разработчиков на Golang, а также программистов для мобильных устройств на iOS и Android. Отдел аналитики не отстаёт — чаще всего мы искали людей на позиции Data Analyst и Аналитика.

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

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

Мы не ставим задачу как можно быстрее закрыть вакансию, а выбираем человека, который будет полностью подходить нам, а мы — ему. 

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

Этапы подбора кандидатов: от открытой вакансии до найма

Расскажу поэтапно, как происходит подбор специалистов на открытые вакансии. И конечно, дам несколько советов соискателям.

Этап 1. Первый контакт. Сбор базы потенциальных сотрудников.

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

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

Совет 1. Вежливость — must have. Хоть многие HR питаются поддерживать френдли-атмосферу и сразу перейти на «ты», не стоит общаться слишком фамильярно.

А если первое сообщение пишете сами, то постарайтесь вместить в него всю необходимую информацию: кто вы, на какую должность претендуете, какой опыт, каким стеком технологий владеете. 

Нам слишком часто пишут короткие сообщения «Хочу работать у вас». Без приветствия, без желаемой должности, вообще без какой-либо информации. Не надо так. 

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

Этап 2. Работа с резюме. Читаем очень внимательно.

Резюме всё ещё остаётся главным способом узнать максимум информации о кандидате. Грамотно составленное CV даст вам сто очков форы перед остальными соискателями. 

Если рекрутер не знает о каких-нибудь ваших компетенциях, значит, их нет. 

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

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

Совет 2. Прикрепите в резюме не только ссылки в LinkedIn и Facebook, но и ник в Telegram. Обычно общение через Telegram занимает на порядок меньше времени, чем в LinkedIn или Facebook.

Этап 3. Созвон с рекрутером. Первое личное впечатление.

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

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

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

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

Совет 3. На первом интервью не спрашивайте о зарплате. Рекрутер просто не знает, что ответить, потому что финансовый вопрос зависит от скилов спеца и решается уже после технического интервью.

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

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

Этап 4. Техническое интервью. Оценка хард-скилов.

Техническое интервью у нас тоже проходит онлайн. По времени оно длится в среднем 1,5 часа, и его ведёт уже тимлид или руководитель направления. 

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

И кульминация интервью — лайфкодинг. Спецу дают одну конкретную задачу, которую ему нужно решить в прямом эфире. 

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

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

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

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

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

Следующим этапом кандидат выбирает список технологий, аргументируя свой выбор. Кто-то выбирает Android Navigation Component, кто-то Hilt, кто-то Glide и так далее. Уже благодаря этому можно понять, с каким опытом пришёл разработчик, в каких технологиях он силён, сходятся ли наши решения с его бэкграундом, как он размышляет.

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

Следующее, на что я смотрю — опыт разработчика в построении приложения и сложных многомодульных проектов. Тут рассматриваем опыт деления проекта на модули, их взаимосвязь, как её оптимизировать, как ускорить время сборки проекта. Вполне нормально для junior — рассказать про модули в целом, а для senior — рассказать, как делить по модулям Dagger или Room.

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

Проваливаясь дальше, рассматриваем зависимости между слоями приложения, как правильно их выстраивать, где какие условия должны храниться, где и как мы пишем unit-тесты.

На этом этапе я уже рассказываю, как архитектура выстроена в нашем приложении, как мы работаем с БД, какие есть особенности работы с картой и так далее.

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

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

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

Вернусь к своему рассказу. Уровня кандидата либо достаточно — тогда он переходит на финальное собеседование, либо нет — тогда мы просто с его согласия добавляем соискателя в базу на будущее.

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

Этап 5. Финальное интервью. Принятие решения о найме. 

Финальное собеседование проводит CTO или CDO компании, в зависимости от направления вакансии, а также ведущий менеджер по подбору персонала. На нём мы более детально обсуждаем какие-то кейсы, задаём дополнительные вопросы, обсуждаем возможные страхи и риски как со стороны кандидата, так и с нашей, проверяем софт-скиллы.

Иногда руководитель задаёт вопрос на логику, чтобы понять, как мыслит соискатель. Но главное — никаких стресс-тестов. Когда-то это была очень модная тема, но выводить потенциального сотрудника из себя — плохая идея. Он ведь нас тоже выбирает.

Также на финальном интервью обсуждаем финансовую мотивацию специалиста — как она складывается, какая система мотивации существует в компании и так далее. 

По результатам финального собеседования топы от каждого направления составляют своё мнение о кандидате. Далее команда, которая нанимает специалиста и рекрутер решают, кто нам подходит. В большинстве случаев мысли сходятся — «нашего» кандидата рекрутеры видят уже на самом первом интервью.

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

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

Навыки общения и такта очень важны, когда работаешь в команде. 

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

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

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

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

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