Открытый код Beeline: Hacktoberfest в Казахстане

Благодаря ей несколько десятков отечественных программистов впервые попробовали написать программное обеспечение с открытым исходным кодом.

Мероприятие проходит уже несколько лет, его инициировала американская компания DigitalOcean и с каждым годом число участников по всему миру становится все больше. Суть в том, что с 1 по 31 октября надо сделать минимум четыре пул-реквеста в любом проекте на GitHub — и получить за это уникальную футболку с логотипом. Программисты, которые хотели, но никак не могли собраться с силами, чтобы начать кодить open source, наконец, находят таким образом для себя повод сдвинуться с мертвой точки. А затем вовлекаются в процесс и зачастую уже не могут остановиться. Чем-то это напоминает массовый ИТ-марафон. Причем, чтобы старт прошел еще более гладко, по всему миру корпорации и небольшие фирмы, у которых есть собственный штат разработки, предоставляют помещение, покупают пиццу и приглашают выступить перед новичками людей, которые уже опубликовали какую-то библиотеку, софт на GitHub. Кодеры делятся своим опытом, рассказывают, что им дало участие в глобальном сообществе разработчиков — и тем самым мотивируют неофитов. В этом году по всему миру пройдет больше семи сотен подобных «хакерских» сходок. Одна из них состоялась в Алматы благодаря Beeline Казахстан.

Субботним утром заинтересовавшиеся предложением собрались в одном из коворкингов, чтобы попробовать свои силы. «Тут всего три человека из Beeline, — говорит Марат Жунусов, Руководитель Службы по Agile трансформации. — Остальные ребята со стороны. И это здорово!» Александр Пузеев, Руководитель службы разработки цифровых продуктов, представился собравшимся и сделал предположение: «Раз вы здесь, то уже задавались вопросом: „А зачем мне тратить свое личное время и бесплатно заниматься разработкой софта с открытым кодом?“ Самый короткий ответ — затем, что так вы прокачиваете свои скилы разработчика. Если обычно вы имеете дело с командами из 5-6 человек, то в проекте на GitHub может быть задействованы сотни людей. Самый известный проект с открытым кодом — это, разумеется, Linux. Это целая вселенная, которая создана тысячами энтузиастов со всего мира. Код, который вы пишите, обсуждается, вам дают массу советов. Таким образом вы растете над собой. Кроме того, к тому, у кого прокачанный профиль на GitHub, совершенно другое отношение при найме. Обычный подход для человека, который приходит с улицы и где-то писал неоткрытый код — дать тестовые задания. Но даже если тесты пройдены, затем тимлид еще довольно долго присматривается к программисту. На GitHub всегда можно посмотреть, насколько хороший код человек пишет, что думает о его стиле сообщество. Многие программисты получают предложение о работе после того, как руководитель разработки корпорации посмотрит код какой-то open source библиотеки».

Дальше, как и принято на подобных мероприятиях, выступили программисты, которые уже что-то публиковали на GitHub. Малик Жарыков рассказал о своем опыте создания серверного приложение NCANode для работы с ЭЦП РК, способного подписывать данные. «Такой софт мне нужен был самому для одного проекта. Я ничего подобного не нашел, официальная документация по работе с ключами была довольно скудная. Поэтому я решил написать код сам. Смысла пытаться продавать такое ПО я не видел, поэтому просто выложил все на GitHub. После этого мне стали сыпаться благодарности одна за другой. Мне писали и продолжают писать, что я сэкономил вагон времени. Это очень вдохновляет. Пошли предложения прикрутить тот или иной функционал — докер, Rabbit и так далее. Как реализовать многие из этих вещей я на тот момент не знал, но мне подсказывали, как это лучше сделать. Мне поступило несколько предложений о работе… В общем, очень рекомендую публиковать свое ПО на GitHub — это во всех смыслах хорошо для программиста».

Вторым выступил Алихан Аршабеков, автор логгера, который он назвал KEK, для языка Go — быстрый и симпатичный. «Для одного из проектов мне понадобился логгер. Те, что я нашел, были или очень медленные, или совсем страшные и со слабым функционалом. Понятно, что были логгеры на других языках, но если ты весь проект делаешь на Go, то разумно, чтобы и эта часть без костылей была на Golang». Алихан также получил массу благодарностей от программистов со всего мира и в будущем намерен больше времени посвящать софту с открытым кодом.

В беседе с Profit.kz Александр Пузеев пояснил, почему у нас в стране именно Beeline Казахстан поддержал инициативу Hacktoberfest: «Раньше мы весь софт заказывали на стороне. Но с какого-то момента было принято стратегическое решение развивать разработку внутри компании. На самом деле это связано с теми изменениями, которые происходят на телеком-рынке. Beeline Казахстан — теперь тоже немного софтверная компания. Да, в общем, не немного — у нас уже сто разработчиков в команде, и она продолжает расти. Большинство софта с лого Beeline Казахстан теперь создается внутри. Мы переписали портал beeline.kz. Мы сделали ПО, которое помогает нашему персоналу работать с клиентами в офисах — его использование полностью изменило подходы к обслуживанию клиентов. В общем, у нас хватает работы. И очень часто мы используем библиотеки с открытым исходным кодом. Мы видим, сколько человекочасов они нам экономят. И трудно представить, сколько времени они экономят в глобальном масштабе. Поэтому мы и поддержали эту инициативу. Кроме того, нам очень важно, чтобы отечественные программисты развивались, росли. Потому что чем выше будет уровень профессионализма сообщества, тем проще будет нам как работодателю».

Выслушав доклады коллег, программисты занялись поиском проектов, где они могли бы оказаться полезны. Задача для мероприятия ставилась простая — за два часа сделать какой-нибудь один пул-реквест. «Самое сложное — выбрать для себя первый проект. Дальше — легче», — поясняет Александр. В действительности от участников Hacktoberfest никто не ждет подвигов, публикации какой-то новой библиотеки. Достаточно исправить три бага в большом проекте, написать документацию к какому-нибудь функционалу в другом — и жди майку, которая придет по почте. Но подчищенный баг может оказаться началом большого пути, который вполне способен привести к участию в написании ядра Linux. Почему нет?