В продолжение темы про удаленку.

Хорошо, когда ты не ограничен выбором работы в определенной стране. Условно говоря, работать на Европу, находясь в Азии 🏖️

Сейчас же, если говорить про РФ,  с этим есть некоторые сложности: компании которые находятся за пределами РФ хотят, чтобы ты тоже физически находился вне РФ. И наоборот также работает 😒

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

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

Конечно, сейчас интернет зацензурен или просто говоря сломан. Но так или иначе до сих пор можно работать из любой точки. Так зачем же ограничивать людей физическим местонахождением? Ни одна компания мне не смогла ответить на такой достаточно простой вопрос. Были отговорки вроде: "у нас такая политика безопасности". А почему у вас такая политика безопасности? Какая логика в этом? 🙃

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

➡️ Для работы на международном уровне нужен английский язык. По моему опыту достаточно уверенного B2 для разговора и B1 для чтения документации и общения в чате.

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

👉 https://t.me/english_practice_lisa_bot - разговорная практика с американцем (уровень A1/A2)
👉 https://t.me/english_practice_bart_bot - разговорная практика с американцем (уровень B1/B2)
👉 https://t.me/english_practice_tech_bot - деловая разговорная практика с уклоном в IT (уровень B1/B2)
👉 https://t.me/english_words_practice_bot - разговорная тренировка вашего набора английских слов
Управляйте списком и запоминайте слова через единственный надежный способ - применение на практике!

Попробуйте - вам обязательно понравится 🛍

DevopsTrain

О недавнем падении Яндекс.Облака

30 марта сервис Яндекс.Облако простаивал примерно 12 часов 😊. К счастью, он был недоступен не полностью, а лишь на треть. Однако, если вам не повезло размещать свои ресурсы в зоне B, то для вас этот день стал настоящим испытанием. По классике, это произошло в воскресенье. С одной стороны, это хорошо, так как клиенты многих бизнесов активнее работают в будни, и это могло снизить масштабы катастрофы. С другой стороны, это плохо, потому что уже отдыхающих системных администраторов и SRE/DevOps-специалистов не так просто вернуть за компьютеры.

➡️ В нашей компании всё завязано на Яндекс.Облако, но в этот раз нам повезло: основные ресурсы размещены в зоне A, а те, что упали в воскресенье, никому не были нужны. К понедельнику всё уже восстановилось.

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

Без исключений.

Даже Amazon (AWS) иногда сталкивается с подобными проблемами, хотя, по моим ощущениям, это происходит реже. Обычно у Яндекса сроки восстановления значительно короче, но в этот раз случился двойной сбой: отключилась городская сеть, а генераторы не смогли запуститься. Поэтому питать иллюзий насчёт абсолютной надёжности уже невозможно. Мы знаем, что подобное повторится — скоро, а может быть, даже быстрее, чем мы думаем.

🖇️ Но с этим надо как-то жить: минимизировать ущерб от простоев и стараться их избегать. У каждой компании своя стратегия "выживания".

Либо ждать, пока всё "само" починится, рассказывая клиентам, какой плохой Яндекс, либо заранее резервировать ресурсы.

➡️ Это действительно большая и сложная тема, где существует множество подходов. Например, можно распределить ресурсы по зонам доступности внутри одного облачного провайдера (как это постепенно делаем мы), либо построить мультиклаудное решение. В любом случае это значительно увеличивает расходы, и компании приходится выбирать, какой путь ей подходит: смириться с несколькими часами простоя и связанными с этим репутационными и финансовыми рисками или вкладывать значительные силы и средства в отказоустойчивое решение.

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

Какой бы подход вы ни выбрали, важно продумать планы B и C на случай, если вся ваша отказоустойчивость пойдёт по бороде 🙂. Лучше сделать это заранее, чтобы хотя бы примерно представлять, как действовать. Про бекапы я уже молчу — это must have.

DevopsTrain

День глюков

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

Недавно череда странных багов случилась со мной в один день.

▶️Глюк №1
Кластер Kubernetes на OVH не запускался. Я решил обновить в своих курсах версию кластера по умолчанию, ведь пора бы уже, старая скоро просто не будет поддерживаться. Увеличил версию, и проверил — выдалась ошибка. На OVH ошибки очень скудные, деталей нет вообще. Первая мысль — именно данная версия не работает, ведь пару дней назад же все было ок. Но потом оказалось, что и старая версия в этот день тоже не работала. Чтож, ок, тут только ждать пока починят.

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

▶️Глюк №3
На основной работе ко мне пришли из разработки и сообщил, что нашли в инфре стейджингого окружения страшный и ужасный баг, который если повториться в проде, будет *опа. Вкратце: у нас несколько инстансов redis запущено в одной неймспейсе k8s, и каждый микросервис работает со своим. А тут по какой-то неведомой причине один микросервис подключился к redis другого микросервиса. Сначала грешили на съехавшие env переменные, хотя ничего не меняли тут, и как выяснилось дело не в них. Они установлены верно. Но по ошибкам в Sentry проблема определенно была. После долгих раскопок логов, нашли попытки самого редиса подключиться к другому, что насторожило. Выяснилось, что не так уж давно был внедрен механизм Sential для кластеризации Redis, и он умеет делать autodiscovery, и находил в качестве источника не своего мастера.

▶️Глюк №4
Он связан с попыткой решить №3, а именно запустить Managed Redis cluster в облаке. Запускаем мы сервисы через Terraform, но почему-то именно с этим ресурсом возникли проблемы, после создания ресурс не добавлялся в стейт. Тут похоже мы наткнулись на какой-то пограничный случай, т.к. воспроизводится только на нашем стейте. Если вынести его отдельно, то проблем нет.

Вывод, который можно сделать: 🙄

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

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

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

DevopsTrain

Реально последний шанс НЕ пойти работать таксистом

Кажется, что вся шумиха вокруг нейросетей и AI это просто очередная веха в развитии айтишечки. Действительно, не первый же раз мы видим инновации в этой сфере. Хотя, если честно, то реально значимых открытий и изобретений можно пересчитать по пальцам одной руки:

🔵 Создание ЭВМ и сетей
🔵 Создание интернета и связанных с ним протоколов (TCP, HTTP, smtp, dns, ...)
🔵 Отдельно можно выделить протокол Bittorrent
🔵 Ладно, эти ваши смартфоны тоже существенный скачок в развитии, хотя большинство людей их использует достаточно примитивно
🔵 Создание Bitcoin (сюда же и прочие криптовалюты)
🔵 Машинное обучение и в частности генеративные модели вроде GPT

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

Так вот, получается, что

не так уж часто происходят революционные события

, чтобы каждое из них не рассмотреть всерьез. Я в целом отслеживаю ситуацию и замечаю и гораздо более нишевые тренды, которые мне интересны по долгу службы. То есть еще в 16 году я сделал ставку на Kubernetes, хотя он был еще в зачатке и в облаках его не было вовсе. А в 15 году мне уже было очевидно, что Golang прочно займет свою нишу и даже потеснит прочее легаси вроде Python/Ruby/Java на многих проектах.

🤖 Конечно же и мимо гпт пройти не смог, использовать его начал еще в 22 году, и несмотря на некоторую глючность моделей тех времен, сразу стало понятно что это game changer. Но то, что мы видим сейчас в плане развития как самих моделей, так и инструментов на их основе - это нечто за гранью добра и зла. Причем я бы сказал, что инструментарий не менее важен, чем качество моделей.

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

Речь о тотальном переходе на эти инструменты и как следствие повышение эффективности интеллектуального труда.

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

Хорошая новость в том, что ручной труд пока заменить не удается и курьеры, таксисты еще пока пользуются спросом 😂

❗️Если такие перспективы не воодушевляют, то по сути в ИТ вариантов не так уж много. Остается возглавить ИИ революцию выбрав работу инженера по машинному обучению. Но как понимаете, выбрать не достаточно, нужно уметь что-то делать, а конкуренция там будь здоров. Поэтому другой более реальный и не менее выгодный вариант - инженер Devops, который, в том числе, и модельки эти будет запускать. Приходите учиться в мою программу наставничества, пока не поздно.

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

DevopsTrain

Опа, что это тут? Новый курс!

➡️ 12 Factor App: от теории к практике в Cloud Native мире

Рад поделиться долгожданным обновлением платформы! Сегодня стартует уникальный курс, посвящённый созданию cloud native приложений на основе 12 Factor App.

💡 Почему этот курс особенный?
Мы не просто разбираем теорию, а шаг за шагом реализуем микросервисное приложение, используя Go — язык, который стал незаменимым инструментом для DevOps.

❔Что будет в курсе?

✅ Понимание принципов 12 Factor App и их применение.
✅ Создание приложения с помощью вайб-кодинга — промптов для ИИ (это реально круто и будущее уже здесь!).
✅ Работа с Kubernetes и GitHub Actions, включая настройку собственных раннеров.
✅ Интеграция с БД и Telegram API для полного цикла разработки.
✅ Бонусные 2 фактора от меня

🤩 Этот курс — не просто обучение, а взгляд в будущее разработки, где ИИ и облачные технологии становятся неотъемлемой частью процесса. Если вы хотите быть на волне технологий и понимать, как создаются современные приложения, — welcome!

Помимо этого, до 15 июня действует 5% скидка на программу наставничества.
И до этой же даты действует акция: 1 курс + еще 1 курс = 3 курса (самый дешевый в подарок)

Хотели прокачаться в Devops? - самое время начать (пока не поздно 🐶)

📎 И не забывайте про DevOps Roadmap

Немного про DevSecOps

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

🔵Раньше:
Отдельная security-команда (если она есть, кхе-кхе) периодически проводит свои тесты на предмет известных уязвимостей тестового стенда, а иногда сразу и прода. Даже возможно смотрит в код приложения, но это не точно. Далее дает обратную связь разработчикам, если есть что исправить. 

🔵Сейчас:
Статические (код) и динамические (запущенное приложение) проверки встроены в CI-пайплайн, и разработчики постоянно получают обратную связь от инструментов-анализаторов. Безопасность становится общей ответственностью, а не только службы безопасности. 

📎 Что касается самих инструментов, то ярким примером являются SonarQube, Checkmarx. 

Безопасность — это не только код, это еще инфраструктура, которая архитектурно должна быть безопасной. А также и организационно. 

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


📍Devops Roadmap
👉 Наставничество
👉 Курсы

💬 Такой отзыв пришел вчера на мою программу наставничества. Максим устроился на работу в финтех с хорошей зарплатой.

Меня часто спрашивают:

Смогу ли я устроиться на работу после вашей программы ❔❔

Конечно, при должном упорстве и уровне знаний можно получить работу с зарплатой от 250-300к и окупить наставничество за неделю-две. В обучении вся нужная информация и вопросы собеседований, которые часто задают работодатели ✔️

Жду вас на своем обучении, с сентября планирую повышение цены 🙃

Startup, Mid-size, Enterprise

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

Startup

⏩Работа в стартапах (до 50 человек) — весело, задорно, хаотично, иногда аврально, но сильно заметна очевидная связь между тем, что ты сделал и эффектом для компании. Возможно потому, что когда ты роняешь прод, это действительно трудно не заметить)) Или оптимизировал расходы на сервера, чтобы оставить больше бюджета на рекламу. А уж если ты еще бэкенд пишешь, то там еще больше можешь влиять на результат. Из минусов можно выделить необходимость выстраивать различные процессы, а код и инфраструктура еще не имеют жестких гайдлайнов. Как правило, даже нет infra-as-a-code. Тем не менее мне до сих пор нравится работать в таких компаниях, люблю приводить все в порядок.

Mid-size

⏩В компании среднего размера (порядка 100+ человек) от тебя зависит чуть меньше, т.к. по идее твоя роль должна быть задублирована вторым и может быть третьим человеком.
Однако несмотря на большее число сотрудников, ты все еще напрямую влияешь на работоспособность продуктов компании. К плюсам можно отнести выстроенный подход к разработке и релизам, а также широкое использование инструментов вроде terraform, helm, ansible для работы с инфрой.

Enterprise

⏩В корпорациях (1000+ сотрудников) твоя роль становится более узкоспециализированной, и твое влияние на конечный результат заметно снижается. Процессы строго регламентированы, каждый шаг требует согласований, а решения принимаются на верхнем уровне. Из плюсов — стабильность, четкая структура и возможность работать с масштабными системами. Однако, бюрократия и медленное принятие решений могут раздражать. Инфраструктурные решения уже выстроены годами, и внесение изменений требует тщательного обоснования. Тем не менее это отличная возможность набраться опыта работы в крупных проектах и понять, как функционируют сложные системы.

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

✌️Devops Roadmap
✅Наставничество
✅Курсы

Middle или Junior ❔

Если вы не вчера начали свой путь в IT, и тем более если в смежной DevOps области вроде сисадминства имели опыт, то вероятно вам всерьез стоит задуматься о позиционировании себя как Middle.

➡️ Поясню почему.
Допустим, вы хотите перейти в devops, но вам кажется, что ваших навыков достаточно только для джун позиции. Это нормально и вероятно вы адекватно оцениваете свой уровень. Однако, возможно что вы уже не джун, хотя еще и не мидл.

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

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

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

Кстати, по зарплате между джуном и мидлом тоже разница существенная.

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

💡💡На лето осталось немного свободных мест 🙂

NixOS спустя год

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

Сказать, что я доволен - ничего не сказать.

После debian based дистров, да, впрочем, и не только их, этот отвечает моим требованиям на 100%. Все настройки лежат у меня в git репе, для каждой из моих машин. Конфигурация несколько отличается, но не сильно, конфиг используется общий, но, например, photoprism на младшей машинке мне не нужен, поэтому там сделано исключение. Добавление пакетов - это новая строчка в конфиге и запуск одной команды, что создает новый снепшот всей системы и я могу, если что, откатиться. Но это ни разу не потребовалось.

🔖 К слову, пакетная база настолько большая, что 99,9% пакетов я нашел в ней. И, пожалуй, буквально несколько приложений пришлось скачивать отдельно. Кстати, из-за особенностей системы (там своя иерархия файлов), ты не можешь просто так взять и запустить тот же appimage. Но как обычно есть проблема - есть решение: appimage-run

🔖 Причем, часть пакетов у меня висит на стабильной ветке, а часть в unstable, чтобы получать самый свежий софт, такой как k9s, terraform, kubectl, cursor, firefox, telegram и прочее.
Это очень удобно и работает пока стабильно. Также, в своих проектах я использую shell.nix файл с конфигурацией нужных для данного приложения зависимостей причем нужной версии.
Ближайший аналог в мире python - virtualenv, хоть и достаточно грубое сравнение.

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

Однозначно рекомендую! 🙂

🙃Devops Roadmap
✔️Наставничество
✔️Курсы

В чем прикол моей платформы

Не все сразу понимают как формат курсов devopstrain продвигает вас в обучении. Позвольте рассказать немного истории...)

Давным давно у меня возникла идея создания универсальной платформы для IT курсов. Предполагалось, что там будут курсы по разным темам, в том числе и по разработке. Но надо было с чего то начинать. Первый релиз платформы случился еще в 2020 году с одним единственным курсом "Kubernetes на практике". Именно кубер на тот момент выглядел наиболее подходящим вариантом для такого формата. И это оказалось действительно так, кубер с тех пор остается бестселлером на моей платформе.

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

❔Почему такой формат работает?

Секрет в том, что курсы такого формата оптимально сбалансированы по следующим характеристикам:

💜глубина подачи теоретического материала
тут можно уйти в дебри, где будет очень интересно, но ничего не понятно. А можно пробежаться по верхам, и этого будет недостаточно даже для тех. собеседования, не говоря уже о реальной работе. Истина где-то посередине.

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

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

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

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

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

Подытожу: платформа devopstrain - это не всеобъемлющий справочник, а скорее продуманный roadmap со встроенной практикой, который выведет вас куда надо 😕

Без плана никуда

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

И не всегда есть возможность сделать плавное переключение на новую схему, что означает отсутствие права на ошибку, а время процедуры обычно очень лимитировано 🤷‍♂️🤷‍♂️🤷‍♂️

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

Сам план должен быть понятным даже спустя месяц, поэтому важно правильно его составить.

Т.к. сроки выполнения процедуры сжаты, то два тома инструкций расписывать не надо.

➡️ Далее, когда есть план, можно еще разок полностью по нему пройти, выполняя шаг за шагом, и измерить время, в которое можно уложиться. А дальше осталось запланировать мероприятие, уведомить нужных лиц и в назначенный момент сделать дело. Я обычно планирую такие вещи на раннее утро, чтобы пока все спят все завершить. Ну люблю я запах паленых серверов по утрам, что поделаешь)

Иметь план всегда полезно,

поэтому в своей менторской программе мы начинаем обучение с проработки индивидуального плана, в котором также есть некоторые ориентиры по срокам, чтобы эффективнее прошло обучение ✔️

▶️Наставничество
▶️Курсы
🔥DevOps Roadmap

Рынок найма

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

😕 Дело в том, что на некоторые позиции поток соискателей настолько большой, что кадровики легко могут себе позволить отсеивать кандидатов за любой вопрос, ответ на который не отвечает текущим политикам компании. Раньше я не задумываясь отвечал на такие вопросы как: "А почему ищете работу?", "Как относитесь к переработкам?", "На какую зарплату рассчитываете?" и тд.

➡️ Сегодня я понимаю, что в текущих реалиях я бы даже не дошел до технического интервью, отвечай я также. Это полная дичь, и многие это понимают, но почему-то ничего не меняется.

Хочется быть честным и отвечать в стиле "speak from my heart", однако это пустая трата времени, если цель устроиться на работу.

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

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

✅ На все эти детали мы обращаем пристальное внимание в моей программе менторства (🤫 мест на осень осталось мало):

🔥даю рекомендации по общению на разных уровнях найма,
🔥 оформляем резюме,
🔥проводим mock интервью,
🔥 формируем позиционирование и улучшаем самопрезентацию

Devops как прогрессивная и консервативная тема

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

*️⃣Возьмем для сравнения разработку, а точнее ее довольно популярную часть — фронтенд. Выглядит так, что туда вкатиться не так уж сложно и долго, но тут кроется подвох. Да, для работы в конкретный момент времени и на определенном проекте тебе надо знать основы языка, и особенности фреймворка.

Это намного проще, чем тот же devops, где нужно разбираться во многих вещах.

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

В devops все иначе:

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

К тому же всегда в цене фундаментальные знания: Linux, сети, контейнеры, IaC, CI/CD.

Мне регулярно поступают вопросы вида:

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

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

🙂 Впрочем, это не значит, что все стоит на месте и не меняется годами, изменения происходят, это неизбежно и прекрасно.

Мы просто наблюдаем за ними и применяем лучшие подходы в нашей работе.

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