Как стажёр не стал ИТ-разрабом. Наш опыт

Что: c7e63aec647725b80611c735b34f39474888c6cc

Когда: 2024-05-31 10:29:58+03:00

Темы: bgp bsd crypto djb git go ipv6 mail redo systemd zsh

https://habr.com/en/companies/ozontech/articles/817737/
Тема стажировки для меня совершенно новая. В нашей компании никого ниже
junior-разрабов ещё не приходило. А тут так вышло, что я с коллегами с
двумя стажёрами будем вот заниматься. В других отделах тоже появились
стажёры, но им откровенно скучно и наверное задерживаться не будут, судя
по всему.

У нас же появится стажёр который ничего кроме Windows даже не трогал. Но
хочет быть программистом. Вот за всю свою жизнь я никогда не встречал из
(потенциальных) коллег кого-либо, кто не работал в Unix-like системах.
Благо, эту тему с ним будет закрывать другой коллега. Я прям тут даже не
знаю как подступаться к такому человеку и вообще сколько занимает время
погружения в уверенную работу в Unix ОС.

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

Но мы решили дать задачу на написание IM-а. Очень люблю её, ибо ты и
сетевое взаимодействие между клиентом-сервером потрогаешь, и СУБД и
криптографию для защиты протокола и с форматами данных можно поиграться
и чуть поадминистрировать для разворачивания. Возможно коллеги что-то
подправят, но я предложил сделать JSON-RPC over TCP для взаимодействия
клиента и сервера. Потом JSON заменить например на protocol buffers,
чтобы потрогать не-schemaless форматы. Для защиты канала связи сверху
потом прикрутить Noise. Интерфейсом на клиенте для начала может быть
WebUI какой-нибудь: так ещё и HTTP+HTML можно будет потрогать. Ну и
соответственно всё это хотя бы интеграционно тестировать, писать
документацию в каждых коммитах.

Плюс ещё уже приступил к работе другой стажёр, который хочет стать в
идеале devops-ом. А вот для него задачи исключительно я напридумывал. У
нас есть неиспользуемая маленькая стойка со старыми серверами и
коммутатором. Вот организовать в ней IPv6-only сеть, развернуть на всех
машинах с разными ОС (в идеале и одну на FreeBSD бы иметь) BASS
(d6a10bd448599b7fcdb4222e3d03810bd0cebec9) CI систему. До этой сети
предполагается поднять VPN (WireGuard), а то ещё и OSPF/Babel например
приделать, чтобы подключаясь, получать маршруты до машин в этой
изолированной сети. Только одна машина будет иметь доступ в Интернет, на
которой и GoProxy и подобные другие демоны будут. А для BASS нужно будет
как-раз множество daemontools service-ов написать, что-то с zsh на POSIX
shell перевести, кое какие утилиты на Go написать и всё в таком духе. Не
знаю как там пойдёт всё это дело, но надеюсь что перед свободным релизом
BASS-а многое полезное будет написано как-раз. Придётся и в сетях
поковыряться, в VPN, в маршрутизации, в POSIX shell, zsh увидеть (и
сравнить насколько в нём проще), Go потрогать, понять daemontools и тему
про запуск процессов, поднять почтовый сервер (для отправки
уведомлений), писать как минимум уже с дюжину BASS skel-ов, являющиеся
redo-целями.

Пока коллеги решили что лучше ставить Debian. Пока один Debian на master
и одной slave ноде. Ну наверное не помешает человеку начать трогать
systemdOS, а то вдруг в основном ей и придётся заниматься. Но, кроме
FreeBSD, я думаю стоит и GNU/Linux (не systemdOS) какой-нибудь
поставить на другом slave, просто для саморазвития (Alpine, CRUX?
что-нибудь из этого).

Все задачи мы кстати заводим в schwabrak-е
(bd94115b066472316ea03e85d611f732785f8b7c,
42b3d1b739b5f0cef40f349cdc7044a785dc604a). Пока ещё не ясно смогут ли
стажёры это сдюжить. Никто не знает что такое merge vs rebase. То бишь в
Git нулевые знания.

В текстовых редакторах ещё никто из них не работал (всё что не Vi(m) или
Emacs, естественно нельзя воспринимать всерьёз). Но мы решили не
настаивать на их освоении. Просто порекомендовали задуматься об этом.

оставить комментарий

Сгенерирован: SGBlog 0.34.0