Road to senior fullstack dev.

Ха, подкаст тот это gift that keeps on giving. Слушаю дальше, они там: > Айдентити, логины, текущее состояние это стыд-позор, количество времени, которые даже образованые, технические подкованные люди тратят каждый день на то, чтобы куда-то залогиниться, это какой-то кошмар, это ненормально. Я такой — ну да. А они дальше: > Но это сложная проблема, над ней работают умные люди, она не решена, потому что сложная, к ней так просто не подойти, многие пробовали, ни у кого не получилось. НА ВСЕ ЕСТЬ ПРИЧИНА. И тут я опять закатил глаза так далеко, что они провернулись на 360 градусов. Ну, да, к проблеме так легко не подойти, но не потому что она сложная, а потому всем похуй, более-менее. Ну еще потому что браузер это худшее что случалось с компьютером, концентрация идиотизма и активно анти-пользовательских решений зашкаливает. Заметьте: постоянные перелогины нужны только в браузере. Во всех остальных местах ты один раз зашел и все. У меня есть CLI логин в npm, который я зарегал лет десять назад, наверное, и раз в несколько лет использую. Я компьютеры меняю чаще, чем в npm логинюсь. И он все это время работает! И в куче других сервисов на CI, там есть токены, которые я прописывал так давно, что не помню уже, что и где я брал. Иногда мне надо что-то там подкрутить, я захожу в Github Actions, смотрю как я делал в прошлый раз и понимаю, что ничего не помню, что и как я генерил. А оно до сих пор работает! Более того, во всех этих программных тулах у тебя даже логина как такового нет, просто токен. Последовательность из 30-40 букв и все, и этого достаточно ДЛЯ ВСЕГО. Также никаких идиотских OAuth, никаких редиректов, никаких JWT, никаких флоу. ТЫ ПРОСТО ПОКАЗЫВАЕШЬ ВО ВРЕМЯ ОПЕРАЦИИ КОД И ДЕЛАЕШЬ ВСЕ ЧТО НУЖНО. И только, блядь, в браузере, у тебя все протухает за две недели, а через полгода ты придешь просто в абсолютно новый браузер, который даже как тебя зовут не будет помнить. И редиректы, и многофакторная аутентификация, и письма с подтверждениями, и чего только не. Также безопасность, как известно, рассадник карго-культов. Помните, как всех заставяли пароли менять регулярно, а потом оказалось, что это приводит к менее безопасным паролям? Я чувствую, что оно все такое, просто по многим пунктам никто пока исследований не провел. Вообще легко может оказаться, что протухающие токены никакого статистически важного влияния ни на что не оказывают, или что идея «passkey нельзя экспортировать» никому ни с чем не помогла. Это индустрия, в которой вещи считаются безопасными, если они звучат безопасно. Индустрия, в которой чем больше ты мучаешь людей, тем спокойнее ты себя чувствуешь. Так что нет. Проблема не сложная. Ситуация сложная. Когда компании, владеющей самым большим браузером на планете, не выгодно, чтобы у нас был простой универсальный логин через браузер, его ни у кого и не будет. Будут только конференции, на которых люди будут махать руками, объясняя, почему вы не должны этого хотеть. Ну или я чего-то не понимаю.

https://www.youtube.com/watch?v=5KyfW79Ld4g

Доверие как критерий при проектировании систем При разработке ПО мы постоянно работаем с такими понятиями, как требования и риски. Но есть еще один пункт, не менее важный, как мне кажется, доверие. Работая с системами годами, я вынес доверие в отдельную категорию при проектировании. Что я в него вкладываю? Доверие во многом формирует и требования, и риски: чем меньше мы доверяем, тем больше рисков закладываем. И я, честно говоря, скорее склоняюсь к тому, чтобы не доверять, чем доверять. О чем речь. Мы постоянно делаем какие-то интеграции с разными API. Это могут быть интерфейсы крупных компаний вроде Google или Amazon, мелких стартапов, платёжных систем, разных по масштабу. Это могут быть облачные ресурсы, которым мы доверяем или не доверяем в той или иной степени. И в работе со сторонними API и ресурсами я всегда закладываю риски: отказоустойчивость, безопасность, надежность партнера. Под надежностью партнера я понимаю в том числе то, что он будет существовать ещё какое-то время вперёд и его не придется менять на аналог. А ведь даже у гигантов бывают ситуации, когда они закрывают продукты. И если ваш продукт построен на жёсткой связке с чужим, то вероятность головной боли, когда тот закроется, довольно высокая. Поэтому еще на этапе проектирования мы прячем такие вещи на уровне реализации в некие абстракции, чтобы интерфейс провайдера всегда можно было легко заменить на аналогичный. Для этого есть определенные паттерны. Даже интегрируясь с платежными системами, мы находимся в зоне высокого недоверия, пусть это и известная, большая, популярная система уровня банка. Единственное, чему я могу доверять у платежной системы, это информация, которую она возвращает о статусе транзакции. Для меня это финальные, понятные и относительно надёжные данные. Почему относительно? Потому что за свою карьеру я работал в разных компаниях, не раз интегрировался с платёжными системами и сталкивался с тем, что статус транзакции может измениться. Например, с успешного на неуспешный или наоборот. А это довольно критично. Если мы сначала получили финальный статус, а потом оказалось, что транзакция не была оплачена, то мы сработали в минус и отдали товар или услугу покупателю бесплатно. И такое в реальности бывает. Не стоит забывать и про форс-мажоры, которые тоже влияют на наши системы. Я на своей памяти помню, как горел крупный дата-центр в Европе, как падали облака. Да и в последнее время — я уже про это писал — качество интернета и сервисов заметно ухудшилось по сравнению с тем, что было. И это тот самый риск, который мы должны закладывать: косяки бывают у всех, везде работают люди или люди, которые используют что-то во вред или не правильно (например, доверяют результатам AI, не глядя). Не стоит сбрасывать со счетов и физические воздействия. Пожар, как я сказал, никто не отменял. Но бывают еще и землекопы, которые могут перебить магистральный кабель и оставить целый дата-центр без света или без интернета. Понятно, что на этот случай всегда есть резервные каналы и прочее, но я бы об этом не писал, если бы сам не видел, как падают дата-центры. Сейчас рисков еще больше, потому что добавились регуляторы: юрисдикции разных стран давят друг на друга, пытаются что-то заставить сделать и из-за этого в любой момент вам могут просто отказать в услуге. Например, из-за паспорта определённого цвета. Или даже из-за национальности. С таким я тоже сталкивался. Поэтому при проектировании систем я всегда работаю с доверием и по умолчанию не доверяю никому. Я доверяю только своей системе и то с определенной долей недоверия. Именно поэтому существуют разные компенсационные меры, которыми стоит руководствоваться при проектировании. Как правило, именно их мы и пытаемся придумать на уровне системного дизайна, используя определенные паттерны. И не потому, что в первую очередь не доверяем себе, в первую очередь потому, что не доверяем другим. В любой момент может случиться что угодно, и заранее ко всему мы не будем готовы. Поэтому система должна сама компенсировать свое состояние если это, конечно, входит в ее требования.

pognali x2

ну, погнали что ли

если вы тоже близки к промо или собираетесь его обсуждать рекомендую к прочтению этот лист: https://t.me/unsleeping706/1304 https://t.me/unsleeping706/1269

Промо в начале мая получил промо, шел я к этому не сказать что долго, но целился. Собирал историю хороших задач, в них входила таблица, писал про нее много постов тут, линедж (собрали движок с коллегой, я руководил всем фронтом, а потом еще сделал систему откатов ходов и сохранении сессии с чем выступил недавно (ссылка)). Затем произшeл Hybrid Deployment, на котором я очень отличился, получал хорошие комментарии что это первый в истории деплоя здесь распределенный сервис где все прошло гладко, и в целом его на меня сгрузили и я справился самостоятельно (ЛЛМ творит чудеса) с достаточно объемным и сложным сервисом, и вот надо было как-то выравниваться с рыночной зп, возвращать себе сеньора, а то взяли меня на обычную позицию так как я был сеньором фронта (теперь придется закрывать целых два канала, путь же окончен). в общем решил я не ждать чуда и намекнуть самостоятельно на 1:1 встрече с CEO что скоро как бы и год близко и проекты у меня серьезные тут. CEO конечно же расстроился, сказал что он сам любит приходить с такими известиями, а тут я с такими запросами (расчет был на приходящую годовщину + пока все еще помнили успешный успех и надо было фиксировать момент пока послевкусие еще не ушло). Цель была выровнять вилку на рыночную ЗП (брал чуть меньше, чтобы выделиться между кандидатами, так как первая не РФ работа была, другой менталитет, + это нормальная тема здесь), и попробовать вернуть тайтл сеньора. Удовлетворили оба требования, обрадовался и ждал около месяца публичного анонса. Самое смешное что в день анонса я был настолько забит задачами что забыл про встречу (а я живу без нотификаций), сижу, никого не трогаю и тут летят десятки сообщений congrats... Сначала не понял что происходит, а потом даже засмущался. В общем запись запросил и посмотрел после самой встречи, но конфуз вышел веселым

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

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

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

https://www.youtube.com/watch?v=gHIs0Mdow8M

я очень много думал о том, как мы можем предупредить ошибки перед релизом, я старался построить хорошие цепочки прокидывания ошибок на границы внутри каждой системы с одним централизованным обработчиков (чтобы не было лишних логов, лишних оберток из try/catch), следил чтобы не везде из catch блока мы перекидывали (rethrow) ошибку дальше так как это могло положить agent-gateway при неудачном коннекте и закрыть его для других подключений, минимизируя случаи unhandled rejections/exceptions мы чуть улучшили секьюрность коммуникаций, у нас есть https/wss (TLS) + encryption/decryption. агент при подключении генерирует пару ключей in-memory, которые нужны для кодирования на стороне agent-gateway с помощью публичного ключа и декодирования приходящих сообщений на стороне агента с помощью приватного чтобы избежать man-in-the-middle перехватов. до этого у нас секреты поставлялись от бекенда в докер/воркер через argv процесса, можно было проинспектить контейнер и найти там все ключи. и когда это живет на твоей инфре и в одном месте это не так страшно. сейчас же у нас распределенная система и мы сделали OTT (one time token) генерацию временных токенов, по которым агент получая сообщения с бекенда после декодирования приватным ключом генерирует под эту полезную нагрузку некоторый временный одноразовый токен, по которому воркер запрашивает данные уже внутри процесса, тем самым мы убираем просвет лишних секретов через docker inspect и все живет in-memory в процессе получил много опыта с winston логером, с ротацией файлов, лимитами, поигрался с разными DI в NestJS, посмотрел на transient/scope, когда внедряемые сущности получают знание о том, в какой класс они встраиваются (в логах это критично, так как мы хотим понимать из какого компонента системы нам пришел лог). логи пишутся в файл с ротацией, по запросу мы их сможем запросить от клиента для дебага. критичные логи с агента у нас идут в облако чтобы мы видели и мониторили ситуацию без зависимости от предоставления логов. так же пришлось попотеть чтобы решить циклическую зависимость нормально, так как сам логер "умный" и помимо записи логов он умеет коммуницировать через вебсокет с agent-gateway (в самом вебсокете тоже есть сущность этого логера)

из последних апдейтов что хотел занести по Hybrid Deployment мы впервые занесли атомик транзакции в MongoDB, странно что их никто до этого не юзал, но мы занесли. посеем зерно, посмотрим как прорастет. пришлось убить стандалон инстанс монги локально и поднять атлас, так как транзакции на стандалоне не работали до бинаря (так как код мы будем передавать клиентам, важно чтобы ничего серьезного там не засветилось) мы так и не дошли, зато нашли интересный обфускатор, и в силу того, что это не так секьюрно (учитывая что могут нейронки сейчас), решил его попробовать восстановить нейронками без контекста, как много он сможет оттуда достать и восстановить логики. из этого исследования вышло, что через barrel импорты shared модулей заходило кучу деталей бизнес логики, о которых on-premise агент не должен был знать и все это попадало в бандл. настроили restrictive import в eslint чтобы гарантировать что никто не сломает это в будущем + закопипастили часть утилок сделав их опять же "мало знающими". Реверс инжинирингом занимались авто модели курсора + гпт5.3. Суммарно уже слил на это около 20$ судя по дашборду использований, но лучше уж слить токены, чем потом найти дыру. Он смог восстановить скелетон, даже где-то проставить константы которые были очень идентично похожи на те что у нас в проекте. но это я еще пока не открыл что там гпт5.3 написал, так что тут может быть будет продолжение. у меня примерно с 2022 года лежит куча докладов про rxjs, я даже немного смотрел и пробовал читать про реактивщину, но так и не накопил себе нормально хардов на эту тему. здесь удалось поиграться с утилитами для таймаутов, ретраев - система все-таки распределенная, иногда есть смысл попробовать еще раз или упасть по таймауту, если ответ был не получен: кто его знает как оно будет вести себя в реальном окружении когда это все на разных машинах. кстати, одна гипотеза очень сильно сыграла тут, я когда-то перед стартом процессинга данных на удаленном агенте решил сделать пинг из бекенда на agent-gateway, для проверки состояния перед отправкой с ретраями, мне потом лид сказал что особо нет в этом смысла так как agent-gateway будет жить на EKS с автоматическими ретраями если упадет, но как только мы это выложили на окружение для тестов, увидели что иногда ретрай помогает и не кладет процесс на старте, было приятно! так как хотелось понимать статус агентов, которых может быть сколь угодно много у сколь угодно большого кол-ва клиентов, хотелось бы сделать какой-то мониторинг централизованный, который будет по хелз-чекам понимать где у нас есть подвисшие агенты чтобы их тушить и закрывать сокеты по ним (если открытые). и для этого нам пришлось немного запариться и унести все статусы агентов, их lastHeartbeat и айдишники сокетов в отдельную коллекцию отключив от multi-tenancy плагина. поставили крон джобу которая проверяет всех онлайн агентов и смотрит на их cutoffTime относительно их lastHeartbeat. из-за того что проверять это локально сложно, решил покрыть это интеграционными тестами, где и база поднимается, и сокет реальный включается для того чтобы зафиксировать бизнес логику при разных состояниях подключенных агентов в сети. кстати это и послужило отправной точкой для внедрения транзакций в монгу, так как мы унесли данные подключения от метаданных агента, которые до этого лежали в одной коллекции. К счастью мы еще не успели зарелизить старую версию и избежали кучу миграций (на локалке мы просто дропали коллекцию и пересоздавали агентов) сделал я два zod декоратора под tcp payload + ws message body, чтобы можно было прокинуть схему ожидаемых входящих нагрузок и получать прокаченные детальными описаниями проблемы случающиеся в рантайме

спустя ровно месяц работы над проектом наша распределенная система (monolith backend + hybrid worker in EKS + agent-gateway in EKS + agent on premise) поехала в прод сегодня колоссальный опыт был получен мной, это такой первый мой бекенд проект (серьезный бекенд проект), получил лестные комментарии от лида и верхушки - приятно! сейчас опубликую последние апдейты

спонтанно сегодня позвал тимлид настроить инфру под наш проект который делаем до этого локально все протестировали и все работало в рамках монолита, пошли деплоить на тестовый стенд и настраивать распределенное окружение тимлид написал хочу ли я присоединиться посмотреть (было уже после рабочего времени). ну мне палец в рот не клади, лишь покажи чего-нибудь интересного на чем можно харды прокачать посидели два часа с ним вместе, показал, рассказал, поэтому делюсь сегодняшним бинго. не то чтобы я стал больше понимать после этой встречи, но теперь хотя бы есть верхнеуровневое понимание (зачатки) alb - application load balancer ec2 ECR EKS route 53 secret manager target group helm chart Cloudfront ArgoCD

https://github.com/rohitg00/DevOps_Books

https://piechowski.io/post/how-i-audit-a-legacy-rails-codebase/