Show must go on (c) Freddie Mercury

#жививкыргызстанеиработайнавесьмир

^^ хороший лозунг от Азиза Абакирова.

Последние лет пять я разговариваю с ребятами, которые покинули нашу страну и им не хватает дешевизны в городе (опросил 10 разработчиков). В Москве или Европе сложно копить или откладывать на свои хотелки, хотя денег получаешь больше. Накопить хотят либо на быстрое закрытие ипотеки (для некоторых 20 лет ипотеки под 0.5-3% годовых может сказаться на ментальном здоровье)

1. Уехать ремоутить на бали, гоа и страны с дешевым уровнем жизни на 2-5 лет, чтобы скопить нужную сумму
2. Вернуться в Кыргызстан, чтобы уменьшить расходы. Тут прям серьезный пункт, потому что если жить скромно, то семьей можно спокойно прожить на 600-700 баксов без детей, особо не напрягаясь и жить вполне себе хорошей жизнью. 1500 — это на семью, которая чуть-чуть оборзела и 3к (ну максимум), это на мажор стайл. Все расходы указаны для семьи без детей.
3. Менять своё отношение к деньгам. Тут, хорошо помогает инвестирование в фондовые рынки или в трейдинг. Просто потихоньку начинаешь относиться к деньгам куда проще.

В Бишкеке просто некуда тратить деньги. Совсем. Ну, тут максимум что можно потратить на компанию за ночь — это 250 баксов, если даже закрыть счёт в баре или где-нибудь еще. В Москве, например, просто посидеть и попить пива в бюджетном формате — это 20к.

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

Например, просто поменяв город на Мюнхен в Линкедине мне стало писать до 8 рекрутеров в сутки (хотя обычно на мой open to work реагировало около 5-6 в неделю).

Хороший подход к поиску работы можно найти у Бугаенко. Он пропагандирует зарабатывать в час от 125 баксов и жить где-нибудь в Тайланде =). В этом плане Кыргызстан не особо отличается, не считая зимнего периода.

PS. Если в Германии получать 90к в год, то налогов нужно будет заплатить на 23к евро, судя по калькулятору, не считая церковных сборов. А это цена хрущевки в Бишкеке :)

А какими способами вы ищете работу? Поделитесь по-брацки

@retired_on_fire, Андрей Минкин

When was the first time you met IRL?
(с) TPB AFK

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

Цитата в эпиграфе не случайная, потому что пару дней назад ФБ напомнил мне о хакатоне GopherGala. Этот хакатон был распределенным и в нем могли принять участие все. Благодаря этому хакатону я познакомился с Максимом и Артёмом. Мы тогда нахакатонили Meshbird, который предоставлял распределённый VPN.

Кодили мы с перерывами на сон и разные таймзоны (+1, +3, +6) были преимуществом, потому как можно было спать, когда другие кодили и наоборот. Мы сделали всё за 48 часов, правда мы готовились, делали прототипы и гоняли бенчмарки за пару недель до хакатона. В итоге за пару недель я узнал и прокачал: DHT (распределенная хеш таблица, что часто используется в торрент клиентах), сети и шифрование.

После хакатона, который был в 16м году мы продолжили общаться с ребятами, обменялись контактами и с Артёмом мы встретились в 17м году на хайлоаде, а с Максом в 18м году на FOSDEM. Общаемся и дружим до сих пор. С Артёмом мы еще пару раз хакатонили и сделали Copybird, а еще думали сделать бесплатным обучение английскому языку благодаря машинному обучению, чтобы преподаватель был цифровым человеком.

Когда хакатонишь, что приходится кодить в самых непредсказуемых местах, вот например мои:

1. Коммитил из троллейбуса, когда мы ехали с Саней Соболевым на одном из хакатонов (вроде это был гараж48)
2. Добавил поддержку tun девайсов в meshbird, из ночного клуба, под очень громкую музыку
3. Был эпизод, когда коммитил код после того, как нам въехали в задницу (не помню мероприятие, но помню, что пушил код с ноута, который стоял на капоте машины где-то в районе Лебединовки)

Сейчас, с одной стороны хочется снять какой-то офис, но с другой стороны вполне себе комфортно работается в некоторых барах и кофейнях.

1. Созвоны, стримы, запись контента идёт дома
2. Генерация контента, разработка с любого другого места (иногда хорошо кодится где-нибудь в горах, сидя в машине)

А кто как ремоутит из подписчиков? Какие были необычные места, откуда вы коммитили код?

@retired_on_fire, Андрей Минкин

Надо больше ивентов, богу ивентов

Вчера было два выступления. Один в IT Attractor, где я обкатывал доклад и восстанавливал форму публичных выступлений, к которым нужно готовиться. А хорошая практика обкатать слайды — это дать доклад перед маленькой аудиторией. Доклад получился живым, пообщался с будущими коллегами и обсудили типичные вопросы:

1. Сколько джун получает
2. Нормально ли выбирать язык %LANGUAGE_NAME% для старта?
3. Как проходить интервью

Также, хорошо поговорили в кулуарах. Было живенько, весело и отлично. Спасибо, что пригласили. А тема была про “Мой путь в айти”, мораль там такая, что ты почти всегда что-то изучаешь и пробуешь. А еще “мне 32 и я не знаю, кем я стану, когда вырасту”.

Также провел слаконар у Хекслета. Слаконар — это текстовый вебинар в слаке. Тема была технической, обсуждали аутентификацию, авторизацию, идентификацию и современные тренды. FIDO2, WebauthN, OAuth, OpenID Connect и так далее. Получилось чуть чуть сложно для неподготовленной аудитории, но стало понятнее, как делать их вовлеченнее.

Я тут в репо ссылочки и материалы собираю по теме Identity stack.

Сегодня буду на GoViral говорить про киберспорт и айтишечку. Приходите =)

@retired_on_fire, Андрей Минкин

It’s Friday. Friiday. FUN FUN FUN (c) Мемчик из 2010.

С пятницей вас всех. Развлекательно-познавательного контента вам в ленту.

1. IT Crowd. Или “Вы пробовали выключить и снова включить?”. Один из самых ржачных сериалов про айтишников(Это те, кто тыжпрограммисты в СНГ)
2. Halt & Catch Fire. Отличный сериал про зарождение кремниевой долины
3. Silicon Valley — лучше Дудёвого, сериал с кучей мемасов и вообще там много полезного про стартаперскую тусу

Что я узнал за неделю и что я нашел:

1. Supabase опенсорсный аналог Firebase
2. Developer Relations - это область.

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

Developer Relations может быть подотчетна либо отделу маркетинга и привет CBDO (Chief Business Development Officer), BDSM (Business Development Sales & Marketing). Ну или может быть подотчетна CTO.

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

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

PS. Завтра готовлюсь к записи подкаста DevZen. Это будет мой первый раз в таком хорошем подкасте

@retired_on_fire, Андрей Минкин

If debugging is the process of removing software bugs, then programming must be the process of putting them in.
(с) Edsger Dijkstra

Дейкстра — датский учёный в области Computer Science. На его исследованиях в современном мире много чего работает. В своё время он хорошо набрасывал на технологии и вот несколько высказываний от него, которые зашли:

— Programming in Basic causes brain damage.
— Teaching COBOL ought to be regarded as a criminal act.
— Mathematicians are like managers - they want improvement without change.

Из современных мемчиков есть:

— Использование любой другой кодировки, кроме как UTF-8 нужно считать актом экстримизма и карать по всей строгости УК (это было популярно, когда было множество кодировок и UTF-8 не зашел как стандарт де-факто. где-то до 12 года) (c) Башорг, вроде как
— Node.js нужен для того, чтобы делать SSR, чтобы экономить пользователю батарейку на телефоне. Использование ноды для чего-то более сложным считать экстримизмом и карать по всей строгости УК (с) Макс Лапшин.
— Лучше вляпаться в PHP, чем в Node.js. Ну и в крестах лучше сидеть, чем кодить на них. (Это про C++. Жаргонные названия плюсы или кресты)

Вот, после посещения одной из конференций по C++ Роб Пайк со своими корешами Кеном Томпсоном и Робертом Гризмаером посидели, подумали и появился Go.

Go, как язык достаточно прост в виду синтаксиса и его хорошо использовать при написании:

- Сетевых сервисов
- Чего-то, где нужна производительность
- Там, где нужна асинхронность (все скриптовые языки курят в сторонке, потому что написать что-то асинхронное на питоне иногда ломает мозг)

Ну и закончить пост хочется несколькими дедами:

— Лесли Лампорт. Автор Paxos. У него достаточно хороший блог по распределенным системам. А еще у него есть отличный доклад Thinking above the code, одна из самых интересных мыслей для меня была “If you are thinking without writing you are only pretending to think”. Поэтому, писать спецификации и обсуждать их с рабочей группой в тексте — один из самых продуктивных для меня способов принятия решения
— Доклад дяди Боба Expecting Proffesionalism

@retired_on_fire, Андрей Минкин

Now for the economic need. Nowadays one often encounters the opinion that in the sixties programming has been an overpaid profession, and that in the coming years programmer salaries may be expected to go down.
(c) Edsger W. Dijkstra

Вот эта цитата была написана Дейкстрой в далекий 1972й год. Так что программисты overpaid с 60х годов. Пока еще не упали и программистов как всегда не хватает. Правда мы ушли от перфокарт и нормального программирования во что-то непонятное, жрущее кучу памяти.

Например, есть занятный баг на Mac Os Monterey, где windowserver начинает отжирать много оперативы, когда ты смотришь видосики на ютюбе или сериальчики на нетфликсе. Как один из костылей решения этой неприятной досады (у меня он отжирал до 74 гигов мозгов) - это выставить Refresh Rate в 60 герц, вместо модного ProMotion. Windowserver перестал отжирать много памяти и теперь, как обычно жрут память Node.js, Chrome, Slack.

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

Продам своего Pajero Sport 2012 года. Прошу $14500. Машина в идеальном состоянии, подробности в личке 😂

@retired_on_fire, Андрей Минкин

Программисты рядом, они настолько рядом, что некоторые даже вы.

Неделю пробовал попользоваться джинни. Вердикт: ну такое…

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

Hello.

Thank you for organizing the interview. I am writing to let you know that you have not been selected to be my employer.

I recognize this may be a disappointment to you. On this occasion, I received a significant number of applications from the companies that more closely fit my requirements for the next job.

Thank you for your time. Good luck and let’s keep connected.

Этот ответ я шлю всем рекрутерам именно на джинни, по нескольким причинам:

1. Слишком сложный процесс найма. Из самых интересных вариантов: три технических интервью (3, КАРЛ!). Два — это решать алгоритмические задачи (имхо, это надо приравнивать к программированию на доске). И еще нужно будет сделать тестовое на два часа времени, за выполнение которого хотя бы заплатят $100. Я понимаю, что в FAANG и подобных компаниях это работает и достаточно хорошо. К этому даже готовятся, но в том же самом FB процесс построен куда проще и кодить алгоритмы нужно всего час.
2. Долгий ответ от рекрутера, сложности с фоллоуапами, сложности с назначением времени для интервью, нет митинг-ноутсов. Некоторых рекрутеров приходилось подпинывать, чтобы просто с ними созвониться.
3. Нет интро о проекте и компании. Некоторые просто задают интересующие их вопросы и отпадает желание вообще с ними продолжать диалог.

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

Воронка:

1. Заинтересованных во мне рекрутеров: 25
2. С 20 из них я решил поговорить
3. 4 написали в телеграм, остальные остались на джинни
4. 4 сделали интрокол, чтобы сделать свой обычный фаст чек
5. Только одна девушка рекрутер всё-таки сделала нормальные фоллоуапы и достаточно серьезно относится к своей работе. Остальные как-то забили на коммуникацию.

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

@retired_on_fire, Андрей Минкин

Не хочу на фронт
(с) мемчик из интернета

Но, видимо придется.

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

1. Terraform/Cloudformation или что там сейчас трендовое для того, чтобы была Infrastructure as a Code. Благо, сейчас слак выпустил events-api и ботов стало делать куда проще и дешевле. Особенно, если они не нагружены вообще никак. Просто пишем лямбда функцию, подключаем API гейтвей и несколько ботов могут работать бесплатно в рамках AWS Free Tier.
2. EKS/K8s и прочее трендовое по облакам, благо, что я оформил подписку на acloudguru.com. Забавная, кстати ситуация. Они выкупили linux academy а теперь Cloud guru выкупили Pluralsight.
3. React/Vue/Typescript и верстку (опять).

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

Поковырял Gatsby. Может быть хорошей альтернативой для Prismic и хорошо деплоится в Netlify.

Еще, что прикольного в Developer Advocate позиции — это нужно кодить кучу мелких проектов/демок. Кругозор расширяется будь здоров. Сейчас, потихоньку расковыриваю Supabase, это опенсорсный аналог Firebase. Нужно подружить их с чем-нибудь из нашего стека. Пока первый кандидат - это Kratos. А еще в планах пощупать FerretDB и Yugabute

PS. Если есть хорошие материалы по современному фронту (Vue/React/TypeScript), Накидайте плиз в комментариях.

@retired_on_fire, Андрей Минкин

Friday sees more smiles than any other day of the workweek!
—Kate Summers

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

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

Остальные компании в портфеле потихоньку тоже показывают рост. Это ROKU, NIO, SPLK.

В прошлую субботу поговорили с ребятами из DevZen на тему ранней пенсии и интересно вот что:

1. Работа в публичных компаниях и покупка акций со скидкой для сотрудника (порядка 15%). Вот это хороший бонус к плюхам компании, а не эти ваши печеньки в офис и дружный коллектив
2. Проблема с финансовой граммотностью стоит во всём мире, правда в странах с большей социальной защищенностью государство пушит вас к тому, чтобы вы ивестировали и откладывали себе на пенсию.
3. Есть отрицательная ставка по депозиту по превышению лимита

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

Что я узнал эа эту неделю

1. Если вы используете транзакции, то вы наверное знаете о связке BEGIN; COMMIT; ROLLBACK, которые предоставляют обновление данных по ACID. Иногда в тестах забавно использовать ROLLBACK, просто чтобы узнать, что твои запросы работают. Кстати, использование ORM должно идти после того, как человек напишет хоть какой-то запрос.
2. В техническом писательстве, как и в блоггерстве просто важна дисциплина. Хороший пост ‘How To Write Better Technical Content’. С русскоязычными постами у меня нет особых проблем (иногда с фантазией если только). а вот с английским всё куда сложнее.
3. Grammarly пользуются не только на СНГ. У нас половина команды пользуется этим продуктом, чтобы быть грамотнее. Но у нас команда мультикультурная и мы говорим на 13 языках. Там даже есть флаг КР.
4. Винцент нашел отличную замену граммарли, которую я попробую поюзать в ближайшее время. Она для девелоперов, консольная и наверное даже в вим можно будет затащить. Можно пробовать поюзать

Развлекаловка

1. Медитация для девопсов
2. Что нужно знать разработчику про Web3
3. Почему не нужно использовать MMAP, если вы кодите базу данных
4. Как я слушал новый релиз от Мешуги
5. Пассивно-Агрессивный фидбек о вашем пароле

До понедельника!

@retired_on_fire, Андрей Минкин

Keep calm and pretend it’s not Monday

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

Так как компания пилилась разработчиками, то для всех использовать mdx или md файлы кажется достаточно простой историей. Gatsby в этом плане предоставляет кучу интеграций и компонентов, которые можно вставлять в md файлы. Получается эдакая смесь из md и веб компонентов. У нас есть компонент, который делает оформление для кода и можно вставить ссылочку на файл на гитхабе и он будет постоянно обновлен.

Еще мы запустили в нашем слак сообществе поддержку на двух языках: русском и немецком.

Спустя месяц (Хотя на самом деле несколько недель всего прошло) я влился в работу, стал лучше разбираться в продукте и процессах и всё встало на свои места. Процесс оплаты достаточно простой и понятный. Попробую его в следующем месяце. Правила просты. Шаг первый — отправляешь инвойс, шаг второй получаешь деньги. Написать инвойс помогают (я потратил несколько часов, чтобы найти шаблон для инвойса, который мне понравился бы)

Разобрался в области Developer Relations и завтра расскажу какие там есть позиции. А еще, FB упал на 26% из-за отчёта (Там часть пользователей упала у продуктов, потому что ушла в тикток). Жду, когда тикток начнет выходить на IPO, чтобы прикупить чутка.

Как началась ваша рабочая неделя?

@retired_on_fire, Андрей Минкин

Есть что по докладам? А если найду?

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

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

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

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

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

Поэтому — хорошо, когда компании вкладываются в DevRel Активности. Плохо, когда они этого не делают. А за прошлый месяц я сделал слайды для 4х докладов на разные целевые аудитории. Самый сложный доклад, который я до сих пор делаю — это Authentication & Authorization 101. Пока покрыл тему с Аутентификацией. Буду рад рассказать в какой-нибудь для какой-нибудь аудитории.

@retired_on_fire, Андрей Минкин

Про Деврел. Деврел — это область, которая включает в себя следующие дисциплины:

— Developer Marketing
— Developer Avangelism
— Developer Advocacy
— Developer Experience
— Community Management

Developer Marketing

Мало чем отличается от традиционного цифрового маркетинга.

Основная цель — создать Go-to-developer стратегию. Почти тоже самое что и go-to-market, только для разработчиков.

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

Развивать придется следующие скиллы: знания о разработчиках, стеке, трендах. Умение ресерчить и писать, аналитическое и стратегическое мышление, умение планировать.

Работать придется с продуктовыми менеджерами, маркетологами в компании, Developer Evangelism.

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

Developer Evangelism

Основная цель — рассказывать о продукте.

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

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

Сотрудничать придется с Developer Marketing и Developer Advocacy

Developer Advocacy

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

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

Развивать придется скиллы программирования, писательства и иногда публичных выступлений. А еще придется много ресерчить и изучать тулы для разработчиков

Сотрудничать придется с Developer Experience, Developer Evangelism, Developer Marketing и Community

Developer Experience

Основная цель — улучшать пользовательский опыт (почти тоже самое что и UX, только для разработчиков)

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

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

Community Management

Основная цель взращивать сообщество разработчиков.

Заниматься придется тем, что нужно будет строить сообщество онлайновое и оффлайновое. Организовывать и фасилитировать ивенты в сообществе, постить всякое в новостях и социальных сетях. Запускать разные программы (например Hacktoberfest)

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

Работать придется чаще всего с Developer Advocacy и Developer Experience.

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

@retired_on_fire, Андрей Минкин

API design is stuck in the past

Слак красавчики. С одной стороны они сначала выкатили свою RTM API (Я с нее начинал проект Comedian для сбора стендапов внутри команды). Потом они выкатили интеграцию по веб сокетам и сейчас они выкатили Events API.

Пилить ботов стало в разы проще и дешевле. В чем минусы использования их RTM API:

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

В итоге если пилим бота, то это либо дорого, либо геморно.

Events API позволяет делать простые схемы, типа API Gateway + AWS Lambda. Ну и достаточно долго можно жить в рамках Free Tier от AWS (Вообще, очень много своих пет проектов можно хостить на облаках типа гугла или AWS просто используя их сервисы).

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

Схема работы простая. Если новый человек добавился к нам в сообщество, то слак отправляет ивент на API Gateway от AWS, тот триггерит функцию, которая обрабатывает ивент и шлёт запрос в API слака. Лениво, дешево, классно.

В последнее время пилю разные интеграции с разными сервисами и supabase нравится для некоторых проектов (очень небольших с минимальной нагрузкой). Пилю Proof of concept. Из технологий:

1. gRPC
2. gRPC Gateway для предоставления рест апи для совместимости с браузерами
3. buf.build. Это прям находка. Отлично расширяет экосистему gRPC и протокол буфферов. Этот тул решает проблему километровых простыней запуска protoc для генерации кода, документации и всего остального

Пока еще не пощупал Graphql и не особо представляю для каких задач он мне потребуется. Потому как для большинства задач хватает gRPC+Rest

А вы что для апи используете и на чем их кодите?)

@retired_on_fire, Андрей Минкин

Почему я люблю gRPC?

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

В итоге, мы приходим к тому, что RPC стиль удобнее, ведь

- CreateTodo Звучит понятнее для всех (включая джунов)
- POST /todos может как обновлять, так и создавать задачу.

До выхода HTTP/2 было несколько вариантов делать API, но REST был куда популярнее, чем SOAP, JSONRPC, XMLRPC. Использование XML в современном мире для любых задач стоит считать жестоким обращением с людьми и карать по всей строгости УК

С выходом HTTP/2, которые частично начали вытеснять вебсокеты с рынка гугл и сделал gRPC, которые работают поверх HTTP/2 и используют protocol buffers в качестве сериализатора данных. Из очевидных плюсов:

1. Protobuf куда быстрее и меньше чем JSON. (JSON — текст, парсить его по CPU куда затратнее, чем использовать бинарные протокол буффера)
2. Protobuf со статической типизацией, что доставляет удобств в разработке
3. HTTP/2 сам по себе бинарнее и быстрее
4. Все эти преимущества понижают количество трафика гоняемого между клиентом и сервером.

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

За время использования в разных сервисах единственная проблема это балансировка HTTP/2. Равномерно разбалансировать HTTP/2 сложнее, потому что балансировать приходится на L7, а не на L4, как обычно балансируется HTTP/1. Вот в этом абзаце мог обмануть, но суть такая, что если у нас есть пул серверов на нашем балансере (nginx, ingress, istio, envoy) то HTTP/1.x можно спокойно балансировать раундробином за счет того, что не держится постоянный коннект, но если мы используем gRPC стримы, то тут постоянные подключения сложнее балансировать.

Хотя, современный веб идет в социальное дистанцирование и уменьшение рукопожатий и HTTP/3 (который основан больше на QUIC, который в свою очередь работает на UDP, а не на TCP).

Но основная проблема сейчас, что люди не умеют использовать нормально HTTP/1.1, не говоря уже о HTTP/2 но хотят использовать HTTP/3.

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

@retired_on_fire, Андрей Минкин

Очень интересно, ничерта непонятно.

Это символ моих постов на эту неделю.

Мыркосервисы. Мыркосервисы — это не очень хорошо спроектированные микросервисы. В некоторых проектах выбор технологий вызывает вопросы. Например зачем втаскивать Кафку, или асинхронный тип коммуникации между микросервисами, если сервисов всего два или три и там можно было обойтись либо rest, либо grpc, либо любой другой синхронной API.

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

Проектирование микросервисов:

1. Начать пилить монолит. Монолит обычно почти всегда подходит и если мы не можем определить зоны ответственности для тех или иных сервисов
2. Подумать, какие есть ограничения при проектировании, которые ну никак не обойти (требования законодательства, требования тех или иных комплайнсов, требования инженерной культуры).
3. Где мы собираемся хостить наши сервисы. На каком провайдере и какие подходы мы будем использовать
4. Какие есть скиллы в команде
5. Ресерч стека и тулов для проекта. Выбор асинхронной или синхронной коммуникации микросервисов (очень часто используют микс в больших проектах)
6. Дизайн API и взаимодействия между сервисами. Это по крайней мере поможет распаралелить работу между отделами.
7. Чем меньше зависимостей, тем лучше.

А что добавите вы?

@retired_on_fire, Андрей Минкин

А кто вообще читает лицензионные соглашения?
(с) Кайл. Саус Парк, эпизод про человекайпадоножка

Обложился техникой эппл по-максимуму. Теперь у меня есть еще айпад с эпл карандашом. Взял айпад для того, чтобы разнообразить свой контент на ютюбе, потому что текущих инструментов не хватает и очень не хватает цифровой доски на которой можно рисовать рукой. В итоге, купив айпад (Pro на 128 гигов 2021 года), эта проблема решилась.

Из дополнительных и удобных фичей:

1. Можно использовать как дополнительный монитор (скорее всего не буду этого делать, либо буду использовать как дополнение к стримам)
2. Появилась поверхность, на которой можно рисовать. ExplainEverything предоставляет вполне удобное приложение, которое эмулирует бесконечную доску

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

1. Аутентификация и факторы аутентификации. OTP/TOTP и еще много разных вещей для реализации многофактороной аутентификации
2. Аутентификация без пароля. аутентификация по токенам, в чем разница токенов и сессий
3. Почему логин через социальные сети не заменяет аутентификацию полного цикла
4. Контроль доступа с разбором RBAC/ABAC
5. Zero Trust/Federation

Хочу рассказать на тестовую аудиторию в оффлайне и кому это будет интересно — пишите в личку и приглашайте. Формат гостевой лекции канает.

Еще из дополнительных девайсов жду микрофон со звуковой картой. Микрофон взял Shure SM7B и к нему звуковую карту. Думаю уйти от стримов в сторону генерации контента и монтирования его. Благо, что сейчас в эпловой экосистеме это получится сделать вполне себе просто. Пока еще не решил что использовать для монтажа видосов: Premiere или Final Cut.

@retired_on_fire, Андрей Минкин

Муки выбора.

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

1. The fall of man в жанре мелодик дез метал. Звучит немного безлико и это прям совсем не бенгер, но можно использовать как нейтральную заглушку
2. Frostbite в хз каком жанре, но звучит интереснее и на мой взгляд жирнее.

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

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

Кстати, о стоках. Для музыки я нашел варианты типа ютюба или audiojungle. Буду рад рекомендациям стоков для видео эффектов.

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

@retired_on_fire, Андрей Минкин

Люблю дудки, люблю бас, люблю я долю слабую
Ебашу как в последний раз, а остальное похую!
(c) Пневмослон

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

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

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

1. Knowledge management. Документация должна писаться и поддерживаться. Если этот процесс есть, то уже хорошо. Если нет, то можно без него, но по крайней мере должны быть описаны основные договоренности по коммуникации между сотрудниками: больничные, когда мы созваниваемся, как ревьюим код, как вообще пишем код и какими стайлгайдами пользуемся, архитектура (это один из важных пунктов в проектах)
2. Запрещено коммитить в основную ветку напрямую
3. Есть настроенный CI/CD, что подразумевает написание тестов. Я сейчас вообще не представляю как можно что-то выкатывать в прод без хорошего тестирования.
4. У разработчиков нет доступа к проду и к данным. Это хорошо в больших компаниях, но не когда вы стартап вам к этому нужно стремиться
5. Schema First дизайн. Это когда мы сначала договариваемся о коммуникации между сервисами (если у вас раздельно работает бекенд и фронтенд)

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

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

@retired_on_fire, Андрей Минкин

Ебашу как в последний раз, а остальное похую
(с) Пневмослон

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

А полный список выглядит примерно так

1. Ок, не пишем документацию, фиг с ним, будем жить без нее
2. В принципе можно и тесты не писать, всё равно у нас тут говна самовар
3. Да в целом я не вижу смысла развиваться, поэтому пока посмотрю котиков на ютюбе
4. А смысл что-то предлагать, если всё равно зарубят?

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

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

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

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

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

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

@retired_on_fire, Андрей Минкин

Изменения наступают естественно, без усилий, если есть обратная связь и поступает качественная информация.
(с) Джон Уитмор, “Внутренняя сила лидера”

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

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

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

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

К большинству криптостартапам я отношусь примерно также, как в этом отрывке South Park, однако, есть один, который мне понравился, потому что люди умеют нанимать людей.

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

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

1. Повышается лояльность к компании
2. Компанию соискатель будет рекомендовать своим друзьям, даже если ему отказали
3. Это в целом говорит о хороших процессах внутри компании

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

@retired_on_fire, Андрей Минкин