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, Андрей Минкин

На море на океане есть остров, на том острове дуб стоит, под дубом сундук зарыт, в сундуке — заяц, в зайце — утка, в утке — яйцо, в яйце — игла, — смерть Кощея

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

На прошлой неделе активно ковырял опенсорсные проекты.

1. Kong Gateway. Это API Gateway, который работает на OpenResty, который в свою очередь работает поверх Nginx. Написан на куче Lua кода. В целом его можно использовать, если всё достаточно оптимизировать, но это добавляет еще один уровень абстракции и еще одну зависимость.
2. Ory Oathkeeper. Это тоже еще один реверс прокси сервер, но который умеет проверять аутентификацию. Если его поставить перед всеми незащищенными сервисами и написать пару правил по доступу, то можно не кодить аутентификационные механизмы внутри микросервисов, потому что эту задачу он решит сам за себя
3. Emissary. API Gateway для кубернетиса, который сделан поверх Envoy. Блин, я всё еще не дошел до энвоя, но когда-нибудь дойду обязательно и сравню его с nginx.

Сделал простой пример бекенда на Kong+Oathkeeper+Kratos для того, чтобы получить Hello World Rest API с аутентификацией пользователя по кукам. Может поможет кому-то при построении архитектуры.

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

А царь то ненастоящий! (с) Иван Васильевич меняет профессию.

Программисты и прочие ойтишнеги подвержены синдрому самозванца. Синдром самозванца (англ. Impostor (imposter) syndrome) — психологическое явление (синдром), при котором человек не способен приписать свои достижения собственным качествам, способностям и усилиям. И в последнее время большинство вопросов связаны именно с этой темой. А еще с темой “Где взять мотивацию на постоянное развитие”.

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

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

Или прокастинация и это “где найти время на обучение, я не могу себя заставить, как мне научиться хотеть себя заставлять?” ну и подобные вопросы. Обычно, я отвечаю на вопросы мотивации в лебедевской манере: “Никак. Оставайтесь там где сейчас”.

Основная вещь, что сравнения идут не с теми людьми. Да, конечно можно использовать какие-то ориентиры, но вы не тот человек, с которым вы себя сравниваете. Вот например, у меня был пример программиста, на которого нужно равнятся. Это Брэд Фитцпатрик. Это человек, который написал memcached, gearman, livejournal и был одним из кор контрибуторов в языке Go. У нас с ним разный путь. У него лучше образование, чем у меня, он работал с другими людьми и в других компаниях. Мне его не догнать. Да и зачем? Да, кого-то всегда будут ставить в пример, но единственный человек с кем стоит себя сравнивать — это вы же сами в прошлом

Не пытайтесь быть идеальным кем-то там, вы всё равно не станете, потому что всегда есть человек, который делает что-то лучше. Да и чаще задавайте вопрос себе, а чего хотите лично вы?

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

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

Describe a team experience you found disappointing. What would you have done differently to prevent this?
(с) Любое программерское интервью.

С подготовкой к интервью обычно всё просто. если мы говорим про техническую часть. Поведенческое интервью (на английском behavioral) проходить иногда сложнее и у некоторых могут возникнуть сложности с тем, чтобы придумать ответ на этот вопрос.

Есть хороший видос от jeff H Sipe, который рассказывает про STAR метод, который включает в себя

Situation. Описание ситуации, в которой вы были и что вы решали. Тут важно, что описание должно быть конкретным и понятным.
Task. Какая была цель над которой вы работали?
Action. Какие дейсвия вы предпринимали
Result. К какому результату пришли

Ну и список ситуаций, которые можно обсуждать по этому фреймворку

— Отсутсвие инженерной культуры
— Люди не писали тесты
— Корп культура не позволяла говорить открыто
— были проблемы с доверием внутри команды и это влияло на перформанс общей команды (см пять пороков команды от Ленсиони)
— Не было поддержки новых идей по стеку или подходам к разработке
— Не писалась документация
— Было много созвонов, что влияло на рабочий климат в команде, хотя можно было заменить на обычный емейл
— Не было понятного фреймворка для разрешения рабочих конфликтов
— Не было понятного и девелопер френдли код ревью
— Не было код ревью в принципе
— Не было сиай сиди для поставки в прод
— Были сложные процессы поставки кода в прод с кучей бюрократии
— Было много техдолга и не уделялось время на его закрытие
— Не транслировалось понимание бизнесовой проблемы, которую нужно было решить и была излишняя технократия в проекте
— Не было развивающей обратной связи
— Не было постоянных 1-1 раз в месяц
— Не было карьерных 1-1
— Не уделялось достаточно времени на сбор требований перед оценкой проекта при оценке проекта
— Тимлид выгорел,потому что овертаймил и не было культуры ворклайф баланса
— Перед релизом ушел чувак и мы обосрались со сроками

А какую ситуацию добавите вы сами?

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

Никто не любит пианистов, все любят барабанщиков!

За последние семь дней было три выступления: в IT-Run, в КГЮА и в аттракторе напишу пару мыслей по этим выступлениям.

IT-RUN

Много прикольных и молодых ребят, которые задают обычные вопросы, на которые я пока еще не устал отвечать. Как устану — напилю пару бложиков и буду кидаться ссылками. Организация мероприятия была приятной, пришел заранее, посидел чуть чуть, ребята не опоздали и пришли тоже вовремя. Побеседовали и разошлись. Даже за выступление заплатили. Наконец-то я пришел к тому, что за выступления платят, хотя в обычную рутину переговоров добавился один вопрос: “Чем платите?”. В итоге, заплатили чуть чуть денег, дали кружку (Она прикольная, кстати. Спасибо большое).

В основном ребята интересовались карьерой и их интересуют всего два вопроса:

— Куда развиваться дальше после курсов
— Как найти первую работу

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

Attractor

Люблю обкатать свои доклады в Аттракторе. Он рядом с домом, там работают ребята, с кем мы сотрудничали или даже бухали вместе. Обкатал свой доклад Identity 101 и вышел со следующими выводами

1. Нужно высыпаться (спасибо, кэп). Так сложилось, что я поспал всего 3 часа в этот день, потому что “А давай зайду и сделаю пару квестиков на часик в WoW The Burning Crusade”. В итоге, мы зачистили пару данжей с ребятами на Firemaw реалме и я апнул аж целый уровень.
2. Нужно применять Zero Knowledge паттерн с некоторыми оговорками. В докладе нашел 4 места, где повествование обрывается. Ну и по структуре доклада он получился слабый. Не выходит рассказывать интересно с мемчиками, шутками на серьезные темы.
3. Говорить целую пару (час двадцать) сложно. Под конец доклада я уже сам думал, когда же он закончится.

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

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

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

English motherfucker! Do you speak it? (c) Pulp Fiction

Let me speak from the bottom of my heart. Today is the unique moment in time 😂

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

Я пошел сначала в English Zone и там начал просто говорить. Местами не грамотно, но начал. Потом взял подписку на ororo.tv и начал пересматривать все сериалы в оригинале. Познакомился с Диваном, начал с ним общаться и открыл для себя целый мир экспатов в Бишкеке. Узнал о паре баров, где можно встретить нейтив спикеров и так в общем-то понеслось.

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

Кратко о грамматике английского.

1. В любом предложении всегда есть глагол. Нет глагола — нет предложения. Когда нет глагола, то всегда есть глагол to be.
2. Вопросов в английском языке всего пять типов и они достаточно просты
2.1 Общий или закрытый вопрос. На него можно ответить коротко, например Do you drink beer?
2.2 Вопросы, начинающиеся со специального слова (wh*). What did you do yesterday?
2.3 Таговые вопросы, которые хороши для сарказма или уточненения. Строятся по формулам -, +? или +, -?. You don’t like beer, do you? или You are always calm in stress situations, don’t you?
2.4 Альтернативные вопросы, где есть слово или. Например: Do you or does she go to school?
2.5 Ну и как костыль, который во-время порефакторили в английском — это исключения из симплов. Если вопрос начинается на Who и у нас время либо презент, либо паст симпл, то можно дропнуть вспомогательный глагол. Who catches the dog?
3. Английский язык достаточно хорошо спроектирован и в нем меньше говнокода, чем в русском и все предложения чаще всего строятся по SVOMPT (Кроме случаев инверсии, но инверсия нужна только магистру Йоде)

В продолжение последнего пункта, предложения всегда строятся по следующей формуле

1. Подлежашее
2. Сказуемое
3. Дополнение
4. Временные ключевые слова

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

1. Are you dead yet?
2. Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo
3. James while John had had had had had had had had had had had a better effect on the teacher

Так что в любом языке есть свои приколы.

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

Хорошо помогают в изучении английского

— Duolingo и LinguaLeo. По 10-15 минут можно потратить на поддержание формы в том или ином языке. Кстати, перед поездкой во Францию я французский учил по Duolingo, однако когда попал во Францию, то понял, что произношение в приложении и в жизни — два разных понятия. Например досвидания au revoir (о ревуа) часто произносится как оэуа.
— Сказки. Читать и слушать. Обычно там простой язык и можно хорошо натренировать мозг. Можно смотреть с субтитрами, но если мы занимаемся и прокачиваем Listening, то желательно выключать субтитры, записывать что услышал и потом проверять с тем, что написано в субтитрах. А еще хорошо читать Хемингуэя в оригинале. Он прост. Он краток. Он быстро погружает в контекст рассказа.
— Изучать разные диалекты. Есть ньюансы в диалектах и часто даже нейтивы друг друга не понимают. Ну или вот тоже хороший прикольный пример

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

Надо больше контента богу контента

Чем больше англоязычного контента вы будете поглощать, тем лучше.

— У Джеймса с Engvid куча полезного контента с хорошими советами по грамматике и оборотам.
— Хорошей идеей может быть приобретение подписки на netflix и смотреть все сериалы в оригинале. Обычно это два разных сериала в зависимости от озвучки.
— Акцент — это последнее о чем нужно переживать. Весь мир говорит коряво. Чтобы убедиться в этом, достаточно просто поговорить с жителями индии, хотя у нас в команде есть SRE с очень понятным произношением.
— Диалекты. Чем больше диалектов вы узнаете, тем лучше. Иногда смотрю канал Спик изи и он мне помогает в общении с людьми из разных регионов.
— Писать на английском. Если нет постоянной разговорной практики английского языка, то можно заменить сочинительством. Можно пилить или блогпосты, или писать какие-то рассказы, главное писать. Особенно гуглдоки или граммарли хорошо помогают в написании контента и расширении словарного запаса.

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

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

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

1. Чтобы сделать аутентификацию есть Ory Cloud или Auth0. Просто подключил и даже особо настраивать не нужно
2. Для того, чтобы сделать API на Graphql, которая будет удобной и безопасной есть hasura.io
3. СМСки отправлять можно через twilio, также как и делать звонки.
4. Любое облако позволяет делать хостинг эффективным с помощью их облачных функций. Например Cloud Functions от Google Cloud Platform или AWS Lambda от AWS.
5. Для лендосов есть тильда или WiX. Или связка Hugo+github pages.
6. Для платежей есть stripe

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

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

Convey. Don’t convince.

Вот эта фраза максимально продуктивно работает в моем случае. Если перевести дословно, то “Сообщай, передавай, но не убеждай”.

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

Разговор с первым чуваком был примерно следующий

— Привет, мы такой-то продукт, делаем вот это и это
— ОК, а чем можете быть полезны?
— Вот у вас какое среднее время ответа от ваших API?
— 20мс
— Мы можем это улучшить.


Второй чувак напротив вел следующий диалог
— Привет, а что вы делаете?
— Тоже, что и они
— А чем вы лучше?
— Да ничем почти
— А как вы можете нам помочь?
— У вас какое среднее время ответа от ваших API?
— 20 мс
— Улучшать нужно?
— Неа
— Мы вам не нужны

Я не помню какие были компании, но помню второго чувака. В этом случае он продал лучше продукт, потому что он не впаривал, а узнавал решит ли это мою проблему или нет?

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

Я же айтишник. Зачем мне изучать законы?

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

1. Безопасность.
2. Доступность
3. Цена поддержки
4. Производительность
5. Легкость эксплуатации.

Однако, очень часто накладываются дополнительные ограничения в виде правовых актов (например закон о хранении персональных данных) и требования дополнительных коплайнсов: PCI-DSS, HIPAA, GDPR

Знать комплайнсы хорошо, потому что они добавляют множество ограничений на наш продукт и могут сэкономить нам время и деньги. К сожалению, многие команды упускают очень важный этап сбора требований и ресерча вокруг архитектуры. Достаточно найти пару подходящих решений и этого хватает для старта проекта. А дальше всё приводит к тому, что проект обрастает, становится монструозным и приводит к тому, что “а давай всё с нуля перепишем”.

в Modern Application Framework есть шесть вопросов, которые хороши для того, чтобы ограничить себя в выборе инструментов

- What are your business priorities? Этот вопрос хорош хотя бы тем, что получив ответ в двух-трех предложениях становится понятно что делает продукт.
- What is the worst possible scenario? Помогает минимизировать риски утечек данных и понять что на самом деле важно
- What are your immovable constraints? Этот вопрос обычно как раз про комплайнсы и Legal часть. Я надеюсь все знают, что данные банковских карт нельзя хранить в незимененном виде
- What data is this solution storing/processing? Помогает при проектировании систем контроля доступа
- What skills does your team have? Важный вопрос, потому что в любом случае нужно будет тратить время либо на обучение команды, либо убирать сложные решения
- What is the timeline for the project? Ну, без дедлайнов никуда.

Эти шесть вопросов заставляют искать оптимальные решения для проектов.

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

Советы для тех, кто хочет стать программистом.

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

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

Следующим пунктом нужно прокачивать дисциплину. Дисциплина это важный столп, который помогает воспитать в себе самостоятельность и находчивость. По этой теме лучше всего подойдет почитать книгу Jocko Willink - Discipline Equals Freedom.

Любознательность. Основа любого обучения — это интерес к теме. Без любознательности никуда. Особенно в программировании, где множество пересечений разных сфер и технологий. У нас есть и e-commerce, и fintech, и edtech, и еще куча всяких *tech.

Самостоятельность. После 18 лет вас никто не обязан учить. Вы сами по себе и вы взрослый человек. А значит за всё, что происходит в вашей жизни нужно будет отвечать только вам и никому больше. Эту простую вещь мало кто понимает и почему-то до сих пор встречаются еще “А за что я деньги плачу?” при обучении. А еще хуже, когда это в работе. Была поставлена задача, тобой был озвучен срок. Значит нужно уложиться в этот срок, либо передвинуть его предложив план Б. Детский сад разводить не стоит и говорить что “Это вообще-то менеджер делать должен”. Так вот, в интернете действительно есть много информации и задавать вопросы нужно уметь, также как и находить решение проблемы самостоятельно.

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

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

Небольшая история аутентификации (это часть моего доклада Identity 101)

— В начале 60х годов не было паролей вообще. Потому что нужды не было
— Хотя в начале 60х придумали пароли для Compatible Time Sharing Machine. Они хранились в открытом виде
— В конце 60х придумали хоть какое-то шифрование паролей.
— В начале 70х придумали ассиметричное шифрование, которое повышало безопасность и криптостойкость паролей
— В середине 80х придумали алгоритмы для TIme Based One Time Password (Это генерация одноразового пароля в приложениях типа Google Authenticator), который был сделан поверх HOTP (HMAC based one time password). Разница в том, что HMAC использовала обычный счетчик, а TOTP использует системное время для генерации паролей
— В конце 90х годов была придумана инфраструктура для обмена публичными ключами
— В середине 90х придумали капчу
— В начале нулевых придумали MultiFactor authentication и Single Sign-on
— В начале 10х стала популярна биометрия для аутентификации (Фейс айди, тач айди и так далее)

Сейчас же лучшей практикой является использование MFA везде, причем по приложениям типа Google Authenticator, потому что SMS не так безопасно.

SMS передается обычным текстом без шифрования и его можно легко перехватить.

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