Разработка

NotCVE-2025-0003 и NotCVE-2025-0004

Продолжаю по мере сил пополнять базу проекта NotCVE информацией о проблемах безопасности, которым разработчики не желают присваивать CVE (делал заметку об этом проекте). В этот раз одна проблема в компиляторе Go привела к регистрации сразу 2-х записей:

• NotCVE-2025-0003

• NotCVE-2025-0004

Т.к. помимо самого компилятора Go, пострадал и Kubernetes:

The Go team has released a fix in Go versions 1.21.11 and 1.22.4 addressing a symlink race condition when using os.RemoveAll. The Kubernetes Security Response Committee received a report that this issue could be abused in Kubernetes to delete arbitrary directories on a Node with root permissions by a local non-root user with the same UID as the user in a Pod.

Из сообщения в гитхабе Kubernetes видно насколько заразительна тенденция вместо регистрации CVE называть фикс проблемы безопасности хардерингом:

The Go team has not issued a CVE for this, as it is considered a hardening issue, and the SRC is following that decision as well.

Собственно, в случае с Docker в этом году было то же самое, для них это тоже хардеринг (моё обращение в MITRE так и не привело к появлению CVE, поэтому я зарегистрировал NotCVE-2025-001).

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

Обучающий вебинар по DLP-системе

Приглашаем на первый вебинар из летней практической серии Академии InfoWatch — «Интенсив по анализу событий в DLP-системе: методика и практика». Он пройдет 8 июля с 11:00 до 12:00.

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

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

Регистрация.

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

Дисклеймер: На этот раз я не использовал никаких AI тулов для помощи:)

Мои принципы работы:

1. Этические принципы.

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

2. Пользовательский и командный опыт.

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

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

3. Ценность через заботу и инновации.

   Верю, что приложение должно быть простым, сфокусированным и стоить времени людей, которые им пользуются. В сочетании с развивающимися технологиями, особенно с AI (облачными или локальными LLM's), думаю, что очень многое можно переосмыслить и фундаментально пересмотреть, сделав пользовательский опыт приоритетом.

4. AI:

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

5. Разработчик, дизайнер и QA как пользователь.

   На мой взгляд, каждый, кто может получить доступ к коду, тоже является пользователем.

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

6. Прототипирование.

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

7. Тайминг.

   Обычно я использую простую формулу, чтобы получить наиболее точное время: Команда + Известные знания + Мой опыт + Мой опыт в кодовой базе | домене.

   Значение: при оценке того, как долго может разрабатываться фича/баг/приложение, мне обычно нужно знать людей, которые работают со мной, затем кодовую базу и затем объединить это со всем, что я знаю.

Надеюсь, этот пост вдохновит и окажется полезным в какой-то степени :-)

Пожалуйста, поделитесь своими мыслями в комментариях :-) это поможет сделать эту ветку видимой для других и станет отличной поддержкой и мотивацией :-)

Спасибо за ваше время и хорошего дня!

Заметки с ИИ-котом v. 1.05, для Windows

Скачать. Бесплатно, установка не требуется.
Кому нужно видеть код приложения - смотрите.
Может ругаться Виндовс антивирус, потому что программа без лицензии. Если кто может с ней помочь - прошу написать.
Ни на что не претендую, если больше нравится Обсидиан - рад за вас, но не искренне.

Новое в "Заметках с котом":

- все ИИ-функции по отдельным заметкам теперь открываются при нажатии по коробке.

- добавлены функции для пакетной обработки содержимого папок (волшебная палочка при наведении на папку)

- теперь можно быстро открывать и большие файлы.

- можно менять цвета папок в Избранном. Рекомендую добавить в Избранное хотя бы одну папку.

Исправлены ошибки:

• неправильное распознавание кодировки. Оставил только utf-8 и windows-1251 - повысил точность их распознавания.

• сбой пути при сохранении новой заметки

• изредка ии-функции выдают ошибки, теперь их видно (раньше были скрыты)

Приглашаем на новый бесплатный вебинар «Как не развалить Angular-проект: архитектура, которая работает». 

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

📅 Дата: 11.07.2025

⏰ Время: 17:00-18:30 (Мск)

На вебинаре:

✔️ Разделение ответственности между компонентами и сервисами

✔️ Уменьшение связанности и повышение читаемости

✔️ Паттерны и антипаттерны в архитектуре Angular

✔️ Практический рефакторинг на примере «грязного» компонент

👨‍🎓 Спикер: Погорелов Павел — эксперт в области фронтенд-разработки.

Узнайте, как выстроить архитектуру Angular-приложения, которая выдержит рост команды и кода!

👉 Записаться

🛠 День 10: Разработка полным ходом.

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

📱 Мобильная версия

• Полнофункциональный интерфейс на телефоне- Можно создавать формы и просматривать ответы прямо с телефона

🔧 Конструктор форм

• Drag & Drop

• Автосохранение

• Заголовки (title, description)

• Брендинг: обложка, логотип (картинка, текст или эмодзи)

• 20+ типов полей: текст, email, телефон, рейтинги, файлы, дата, время

• Бизнес-поля: ИНН, ОГРН, КПП, БИК, СНИЛС, паспорт - с валидацией и проверкой хеша

• Рейтинги: 1-5 звёзд, 1-10

🌐 Переводы

• Уже есть RU / EN- Скоро сделаем ещё 48 языков

🗂 Папки и доступы

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

Уровни доступа:

• Владелец - полный контроль

• Администратор - всё, кроме удаления папки

• Редактор - формы и ответы

• Редактор форм - только формы

• Оператор - только просмотр/обновление ответов

• Платежи - доступ только к платежам

📋 Управление формами

• Поиск, фильтрация, сортировка

• Дублирование и удаление

• Шаблоны

🔗 Публикация

• Короткие ссылки (/f/abc1234)

• QR-коды

• Виджет для встраивания в сайт (iframe)

• SEO-метатеги

• Превью формы в соцсетях (OG, Twitter) с картинкой

• SSR-рендеринг форм

📊 Ответы и аналитика

• Фильтрация по дате, форме, IP

• Экспорт ответов в CSV

📎 Файлы

• Поддержка 20+ форматов

• Превью: изображения, PDF, CSV, текст и др.

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

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

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

Так появился проект CoMaps - полностью оффлайновые и бесплатные карты для мобильных устройств с фокусом на приватность: в приложении нет каких-либо трекеров, мы не собираем и не передаем кому-либо каких-либо данных.

А приставка "Co" намекает, что это именно community-driven проект, где ключевые решения принимаются после обсуждения внутри всего сообщества контрибьюторов и при необходимости - после сбора мнений путем голосования за тот или иной вариант.

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

Дальнейшее развитие проекта предполагает как развитие текущих и создание новых фичей на основе сбора обратной связи от самих пользователей, так и формализация самого статуса проекта. Прямо сейчас мы обсуждаем и рассматриваем разные варианты, в том числе создание "нон-профит" организации; или же можем придти под крыло какой-нибудь известной организации вроде SFC или подобной.

Так как сегодня, 3 июля 2025, мы сделали первый публичный релиз приложения в сторах, приложу пачку ссылок на ключевые ресурсы проекта:

• https://comaps.app - сайт проекта (там можно найти всю рабочую внутрянку - матрикс/телеграм/zulip чаты, репозитории, таск-трекинг, инструкции как присоединиться к разработке со своими идеями, и т. д.)

• Google Play Store: https://play.google.com/store/apps/details?id=app.comaps.google

• Apple App Store: https://apps.apple.com/app/comaps/id6747180809

• F-Droid: https://f-droid.org/packages/app.comaps.fdroid/

Такие дела.

Случайна ли случайность? Теория вероятности и личный опыт

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

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

На старших курсах ВУЗа проходил практику в школе своего города, который расположен ровно в 1 000 км от Москвы. Преподавал естественные дисциплины школьникам 5-9-х классов. Не суть, что там было по учёбе, главное, что в одном из 9-х классов учился юноша, который в следующем учебном году, т.е., уже осенью, должен был уехать с родителями в Москву. Юноша упомянул как-то про это, и мы даже разговорились с ним, потому что я сам через несколько месяцев собирался уехать в Москву на стажировку. Для нас обоих это был совершенно новый, неизведанный мир. Одно слово - столица!

Наступила осень. Приехала в гости к молодому стажёру мама и я повёл её в театр. И вот садимся мы на свои места, а рядом, на соседнем месте оказывается… тот самый юноша, уже московский десятиклассник, с которым мы полгода назад болтали непринуждённо про столицу нашей Родины.

В пекло теорию вероятности! В соответствии с ней описанное выше событие не могло произойти со мною в принципе. А оно было. И это реальный факт, который до сих пор помню.

Вот так я выиграл свой «джекпот», за несколько сотен рублей, которые стоил билет в театр в далёком 1992-м году. Правда, выигрыш в том «джекпоте» достался мне небольшой, точнее сказать, ничего не досталось, кроме улыбки и взаимного удивления невероятному стечению обстоятельств. Но, надеюсь, что для одного небольшого поста на Хабр этого хватит.

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

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

Открыта регистрация на Kubernetes Community Day — главную сходку K8s-сообщества

31 июля в Москве состоится первая независимая конференция Kubernetes Community Day для открытого сообщества профи по куберу и тех, кто только начинает. Два пространства с техническими докладами, дискуссиями и хардкорными воркшопами, интерактивы и IT StandUp. Никаких HR-стендов и дорогих билетов — только бесплатное участие, сообщество, живое общение.

Цель мероприятия — создать площадку для объединения сообщества, обмена опытом и нетворкинга. В программе — актуальные выступления от коллег из различных компаний, которые дышат контейнерами: Yandex Cloud, ecom.tеch, VK, Luntry, МКБ, «Лаборатория Числитель», Lamoda Tech, Rebrain, Cloud ru и др.

Среди заявленных тем:

• «Legacy-кубы и как нежно увезти с них продукты»

• «Ретроспектива уязвимостей системных компонентов Kubernetes»

• «Блеск и нищета Cluster API Kubernetes»

• «Почему K8s — плохой продукт и он вам не нужен?»

• «Как мы переизобрели UI для Kubernetes: динамический фронт на основе OpenAPI и CRD».

Полная программа будет объявлена позже.

Зачем идти?

• Послушать истории коллег про реальные кейсы, факапы и «боли». 

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

• Встретиться со старыми друзьями и найти новых.

• Внести свой вклад в сообщество.

Формат: офлайн и онлайн.

Участие бесплатное. Количество мест на офлайн ограничено площадкой — успейте зарегистрироваться!

Следите за анонсами мероприятия в Telegram-канале генерального партнера конференции — платформы «Штурвал».

Информационные партнеры: Computerra, ICT Online, Cybermedia, Global Digital Space, AM Live, ict2go, Kubernetes_ru, DevOps For Love, IT STAND.

Как роботы стали частью культуры — и почему это важно сегодня

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

Что изменилось с тех пор? Почему человечество так настойчиво мечтало о разумных машинах? И как художники, философы, писатели и инженеры вместе формировали наш образ «искусственного человека»? Ответы на эти вопросы — в лекциях YADRO Lectorium от экспертов Сколтеха, «Иннополиса» и Музея криптографии.

«Спросите любого робототехника, как он пришел в профессию — он вспомнит не тему своего диплома, а первую игру, первый конструктор, первый мультик про роботов», — Егор Ефремов, культуролог, историк техники, исследователь в Музее криптографии.

В статье собраны лекции YADRO Lectorium — о культурной эволюции образа робота, текущем состоянии и трендах в мировой робототехнике, а также о том, как физический дизайн влияет на функциональность и взаимодействие человека с машиной.

Хотите стать мастером регулярных выражений?

Тогда новый бесплатный курс — для вас!

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

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

После изучения материалов вы сможете:

• моментально извлекать данные из гигабайтов текста;

• валидировать формы любой сложности;

• правильно обрабатывать тексты на русском (никаких сломанных \b);

• решать сложные задачи с помощью lookarounds и именованных групп;

• повысить свой уровень в работе со скриптами и редакторами.

Все материалы бесплатные. Не требуется даже регистрация.

Начать обучение в Академии Selectel →

Основа Kotlin K2 компилятора — это FIR‑дерево (Frontend Intermediate Representation).

Вкратце: FIR — это AST (абстрактное синтаксическое дерево), обогащённое семантической (смысловой) информацией. Оказывается, что у этой основополагающей технологии есть своя небольшая документация: fir‑basics.md и в той части, где написано про контракты указано (в моём вольном переводе), что:

Компилятор разрешает использовать контракты в свойствах, функциях и конструкторах классов

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

А где находится то самое ограничение на использование контрактов вне функций описал Android‑разработчик Виталий Перятин в новой статье о Kotlin Contracts, где он поделился любопытными моментами, которые удалось накопать самостоятельно, потому что как парсится список эффектов, как работает новый Contracts API изнутри, и почему, чёрт возьми, на уровне компилятора можно использовать контракты не только на уровне функций, в доках не пишут.

Совершенный assert() для всех языков программирования

...как ни смешно, но пострадали стоматологи: стало меньше зубовного скрежета!

Когда C/C++ разработчики переключаются на другие языки, им очень не хватает привычного механизма assert()/NDEBUG. Он, в некотором смысле, позволяет получить "идеальный" метод управления Debug/Release конфигурациями:

Как вы правильно поняли, в Release конфигурации строки кода между #ifndef NDEBUG и #endif полностью исчезают, и мы получаем идеальный билд. Но идентичного результата можно добиться и с помощью комментариев... ^{(здесь должна была быть картинка, но вставить не получается)}

Гмм.. Значит будет лишь краткий конспект статьи.

ОК, как ни странно, но это правда: я создал утилиту DebRel, полезную ВСЕМ языкам программирования! Комментарии специального вида (D0 - D9 и R0 - R9) позволяют минимальными усилиями добиться "идеального" управления Debug/Release конфигурациями:

• Debug конфигурация дает нам всю необходимую диагностику! С различной глубиной.

• В Release конфигурации нет никаких следов Debug-а! Ни байта.

А именно:

• Конфигурация RN отменяет все остальные. Релиз -- эгоист!

• Конфигурация DN оставляет лишь строки от D0 до DN. Вы задаете глубину отладки.

В общем, сразу читайте https://ders.by/arch/debrel/debrel.html Там есть подробности, исходники и сам debrel.exe.

Контур проводит исследование о том, как живёт .NET-сообщество в России. Анкета активна до 15 июля.

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

Об итогах напишем на Хабре.

Смотреть можно, трогать нельзя: режим read-only в балансировщиках ☝️

Раньше в тикетах часто встречали:

«Я немного поменял настройки балансировщика для Кубика, и у меня все полетело».

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

✅ Закрыли возможность управления балансировщиками, созданными для Kubernetes (из панели и через API). Теперь все настраивается только через манифесты.

✅ Добавили режим read-only для новых и уже созданных балансировщиков. В панели они помечены тегом + есть подсказки.

✅ И самое важное — критическая конфигурация кластера теперь защищена от случайных изменений и возможных сбоев.

Проверить на своем балансировщике →

Как я случайно сделал ферму в Telegram с помощью ИИ

— История одного бота, картошки и чёртовой тыквы

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

Но началось всё, как ни странно, с Таро. Да-да, карт Таро. Тех самых.

Первая попытка: гадать и страдать

Где-то в начале года я решил сделать Telegram-бота, который бы умел раскладывать карты Таро, делать натальные карты и выдавать предсказания на день. Казалось бы, звучит просто. Особенно если рядом есть ChatGPT, который может на ходу генерировать описания карт и писать код на Node.js.

Зарядка с утра: — GPT, напиши функцию для расчёта Луны в Скорпионе. — GPT, как сделать inline-кнопки в grammY? — GPT, почему Heroku опять всё уронил?

И вот бот заработал. Люди заходят, тянут карту дня, шлют благодарности… и уходят. На следующий день — снова тяни карту. Через неделю — всё. Надоело.

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

А потом я вспомнил старую ферму

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

И вот я подумал: а что, если скрестить эту старую добрую механику с Telegram-ботом?

Чтобы всё было просто:

• Никаких установок

• Играть можно прямо в чате

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

Начало новой жизни

Запустил первого бота. Добавил регистрацию, посадку капусты и сбор. Подключил базу PostgreSQL. Всё это — руками и с подсказками ИИ (да здравствует Cursor AI, GPT и граммY).

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

Так появилась Веселая Ферма — ферма прямо в Telegram, которая сейчас уже живёт своей жизнью, где игроки сажают растения, разводят скот, воруют другу у друга лимоны и спорят в чате, почему мед дешевле мотыги.

Что дальше?

Это только начало. Я хочу рассказать:

• Как ИИ помогает не сойти с ума, когда у тебя 500+ игроков и баг в 3 ночи

• Как запускались тыквенные фестивали и почему это был трэш

• Как устроен баланс в экономике фермы

• И как создать клановую систему, когда никто не читает туториал

Если интересно — подписывайся на продолжение. А если хочешь сам потыкать бот — вот: 👉 Веселая Ферма

Следующая часть будет про то, как я балансировал экономику в игре, используя google sheet, интуицию и крик в подушку, почему Доярка Жанна названа в честь жадной хозяйки квартиры, и откуда взялся Председатель СНТ в образе Якубовича.

Представлен обновлённый проект Awesome Black Hat Tools, где собраны все инструменты, которые когда-либо были представлены на ИБ-конференциях Black Hat. Инструменты аккуратно структурированы по странам, где проходила конференция, по годам и категориям Red Teaming, Blue Teaming, OSINT & Recon, Exploit Development, Malware Analysis, DFIR & Forensics, Threat Intelligence, ICS/IoT/SCADA и Application Security (AppSec).

Также все презентации с выступлений Black Hat, начиная с 2023 года, собраны на отдельной странице GitHub.

Теперь за специалистов по искусственному интеллекту платят больше, чем за футболистов.

Новая версия Gramax!

• Сравнение ревизий. Можно сравнить текущую версию каталога с одной из предыдущих.

• Экспорт в корпоративных шаблонах DOCX. Добавили возможность загрузить корпоративный шаблон DOCX и экспортировать статьи и каталоги в этом шаблоне.

• Избранное. Каталоги и статьи можно пометить как Избранные для быстрой навигации. Это доступно как в приложении, так и на портале документации.

• Связанные статьи. В меню статьи можно просмотреть: куда ссылается статья и какие статьи ссылаются на нее.

Об этих и других изменениях читайте в Release Notes 🔥

Привет Хабр! Это мой первый пост, и я просто хотелось спросить, стоит ли уходить в Go? У меня есть небольшая база в программировании, делал сайты на реакт и ларавел, реализовывал бэкенд с Солид и паттернами, писал на нативном пхп файловые обменники и апи. Не много знаю базы данных соответственно, гит, докер. Сейчас засматриваюсь на Go, где то вычитал что мол крутая штука для бигтехов в России, а сам я студент и пока сижу на шее у родителей, но в следующем году я окончу к курс, и хочу где то месяца за 4-5 изучить все нужное в го и во всех других сопутствующих технологиях для разработки высоконагруженных приложений и микросервисов и всякого подобного. Стоит ли сворачивать на этот путь, или добить стек ларавел плюс вью? Немного боюсь, так как слышал что в го нужны уже 25 летние синьоры со стажем работы минимум в 20 лет, но и не хочется проторчать всю жизнь в челябинской галере на фуллстеке за 70 деревянных на руки.