Kubernetes Zero to Hero — базовый видеокурс от «Фланта»
Если вы хотите изучить основы работы с Kubernetes, мы сняли подходящий для этого видеокурс. Из него вы получите практические знания, которых будет достаточно для решения большинства типовых задач.
В курсе 10 коротких — до 10 минут — видео. Они рассчитаны на начинающих разработчиков с опытом в продуктовой разработке, учебных или личных проектах, где возникает потребность в Kubernetes. С нами вы:
поднимете локальный кластер и разберётесь в ключевых сущностях Kubernetes;
научитесь развёртывать приложения, пройдя путь от коммита кода в Git-репозиторий до его выката в кластер;
поймёте, как устроены сетевое взаимодействие внутри кластера и доступ к приложениям извне;
познакомитесь с werf и Helm, шаблонизацией чартов и практиками реальных проектов.
Два первых ролика уже доступны. Во вводном будут план курса и желательный для старта бэкграунд, а второй поможет поднять локальный кластер Kubernetes с помощью Minikube и получить готовое окружение для экспериментов. Смотрите на удобной вам площадке:
Популярные современные ЯП позволяют переменным-ссылкам иметь значение NULL. И это уже привело к огромным проблемам, рассказывает Тони Хоар на выступлении.
Борьба с NULL принимает разные виды.
Дизайн каких-то ЯП оставляет это на откуп линтерам, не обременяя себя вопросами времени компиляции и исполнения.
Другие ЯП разрешают хранить NULL только в переменных, которые имеют знак вопроса после типа. Пример: Object? a = null. Нет знака вопроса — переменная не может быть NULL.
Отдельные ЯП имеют монаду Maybe или Optional в стандартной системе типов. Так они кардинально избавляются от самого концепта NULL.
Так или иначе, определённо ясно, что NULL — исключительно техническая необходимость прошлого. А в моделировании предметной области использовать NULL просто не получится.
Мы иногда во внутреннем чате обмениваемся фрагментами кода с неочевидными ошибками, которые обнаруживаются с помощью PVS-Studio в каком-нибудь открытом проекте. Мол, кто быстро сообразит, что не так с кодом?
Вчера коллега поделился вот таким фрагментом кода из проекта SereneDB:
template <typename T>
struct NumericParameter : public Parameter {
using ValueType = T;
....
std::string name() const override {
if constexpr (std::is_same_v<ValueType, int16_t>) {
return "int16";
} else if constexpr (std::is_same_v<ValueType, uint16_t>) {
return "uint16";
} else if constexpr (std::is_same_v<ValueType, int32_t>) {
return "int32";
} else if constexpr (std::is_same_v<ValueType, uint32_t>) {
return "uint32";
} else if constexpr (std::is_same_v<ValueType, int64_t>) {
return "int64";
} else if constexpr (std::is_same_v<ValueType, uint64_t>) {
return "uint64";
} else if constexpr (std::is_same_v<ValueType, size_t>) {
return "size";
} else if constexpr (std::is_same_v<ValueType, double>) {
return "double";
} else {
static_assert("unsupported ValueType");
}
}
....
};
Признаюсь честно, я два раза прочитал этот фрагмент, но так и не увидел ошибку. И засчитал себе поражение. Раз так, думаю, это достойно публикации в канал, чтобы и вы могли испытать свою внимательность :)
Попробуйте найти сами
Ответ:
Анализатор PVS-Studio выдаёт предупреждение V591 Non-void function should return a value. parameters.h 222
На первый взгляд предупреждение странное и смахивает на ложное срабатывание, ведь не может быть, что функция закончила работу, не вернув значение с помощью оператора return. Если выбирается ветка else, то там static_assert, и код просто не должен скомпилироваться. Во всех остальных случаях есть return "что-то";.
Но есть нюанс!
Ещё раз посмотрите на эту строчку:
static_assert("unsupported ValueType");
static_assert используется неправильно: пропущен bool-constexpr. Вернее, строковый литерал неявно конвертируется в значение true, и static_assert никогда не прервёт компиляцию. В итоге else-ветка функции ничего не возвращает, и её поведение будет не определено для всех специализаций NumericParameter, кроме указанных ранее в цепочке if constexpr.
LISP имеет удивительный по простоте синтаксис. Это делает его одним из самых популярных кандидатов для программирования своего интерпретатора.
Такой интерпретатор — замечательный пример пет-проекта, который расширит кругозор и познакомит с элегантностью LISP. Быть может, разожжёт интерес к Clojure и Scheme.
Отличной подмогой для проекта будет работа Джона Маккарти. В своём микро-руководстве он описал базовые блоки для построения минимального интерпретатора.
Маккарти формулирует основу LISP всего в десятке правил и пяти основных аббревиатурах, сопровождая этот набор дополнительными примерами.
И это описание занимает всего две страницы! Фантастика!
Услышал про Apidog. Кажется, Postman больше не единственный вариант
Давно понял, что в работе в ИТ очень важно быть открытым к новым знаниям. Технологии меняются быстро, и то, что было стандартом вчера, завтра может оказаться устаревшим подходом.
До недавних пор был уверен, что Postman это непоколебимый промышленный стандарт для работы с API. Все его знают, все используют, коллекции передаются из проекта в проект. Зачем искать что-то ещё?
Вчера разговорился с коллегой из команды, и он упомянул Apidog. Говорит, перешёл полгода назад и не жалеет. Сегодня решил посмотреть сам. Вот первые впечатления.
Что это такое
Apidog позиционируется как all-in-one платформа: дизайн API, документация, mock-сервер, тестирование и дебаг в одном месте. По сути, Postman + Swagger + Mock + автотесты без переключения между инструментами.
Что зацепило
Визуальный редактор для создания спецификаций. Рисуешь схему, она автоматически превращается в OpenAPI. Не нужно писать YAML руками.
Mock из коробки. Создал спецификацию, mock-сервер уже работает. Фронтенд может начинать разработку не дожидаясь бэкенда. Причём mock умный: генерирует данные по типам полей.
Автотесты с визуальными assertions. Можно добавлять проверки без кода, просто кликая. Есть data-driven тестирование, интеграция с CI/CD.
Командная работа в реальном времени. Версионирование API, ветки как в Git, ролевой доступ.
Импорт коллекций из Postman. Миграция не с нуля.
Что смущает
Китайские корни. Для кого-то это плюс (активная разработка, быстрые релизы), для кого-то минус (вопросы безопасности данных).
Ещё один инструмент в зоопарк. Bruno, Insomnia, Hoppscotch, теперь Apidog. Выбор это хорошо, но и головная боль при стандартизации в команде.
Бесплатный тариф щедрый, но всё равно есть ограничения для больших команд.
Пока не тестировал глубоко
Это именно первые впечатления после пары часов изучения. Не готов сказать «бросайте Postman», но точно буду пробовать на реальных задачах.
Интересно послушать тех, кто уже работает с Apidog на постоянной основе. Какие подводные камни? Стоит ли переходить с Postman или это из серии «работает — не трогай»?
Ссылки по теме на Хабре
Коллеги уже делали разборы инструментов для работы с API:
С новым рабочим годом, Хабр Мы в SSP SOFT опять расширяем команду и ждем ваши резюме
Кто мы? Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.
В 2025 году SSP SOFT вошел в число лидеров найма ИТ-специалистов на российском рынке— за год мы наняли 179 сотрудников! И главное — в 2026 году найм продолжается.
У нас новый московский офис в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удаленку из любой точки России.
Открытые вакансии в SSP SOFT: это реальные проекты, дружная команда и атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем гуру, кто готов в новое профессиональное будущее вместе с нами.
Что вас ждет в SSP SOFT: ✅ Рост: Центр компетенций для максимального апгрейда скиллов. ✅ Свобода геолокации: Возможность работать удаленно, гибрид или офис. ✅ Баланс: Работаем, чтобы жить, а не наоборот.
🎁 Приятные бонусы: ивенты для всей команды, ДМС для штата, обучение и бенефиты.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вакансию на Хабре».
Периодически наталкиваюсь на разработчиков, которые думают, что они незаменимы, потому что знают в каком-то месте кода прям всё на свете. И поэтому их-то точно никогда не уволят - слишком опасно и долго обучать новичка.
Но это, конечно, не так. За свою 20-летнюю карьеру видел пяток увольнений самых-пресамых незаменимых.
Во-первых, незаменимость часто преувеличивается (особенно с учетом ИИ, который и разберется, и нарисует, и расскажет всё, что важно знать). На практике обычно через 3-4 месяца уже никто и не вспоминает о Васе, который где-то там всё знал. А чаще скорее просто ругают его за странные решения, переписывая запутанные куски с нуля.
Во-вторых, даже если человек реально приносит огромную пользу и по-своему незаменим, то порой руководство просто поступает нелогично и увольняет всё равно. Иногда последствия бывают совсем неочевидны и отложены во времени (медленнее пилятся фичи, вылезают непонятные критические баги на проде), их никто никогда с Васей уже и не свяжет. Даже если объективное расследование бы показало, что денег в итоге потрачено больше. Короче, это или неправильная системная оценка или просто банальная глупость/лень менеджмента.
В-третьих, в кризисные времена сокращают целые направления, вместе с Васей и бизнесом, который Вася подпирал столько лет своим плечом, как заправский атлант. Причем, такие новости обычно приходя внезапно, как снег на голову. Типа, наш отдел закрывают с первого числа, сорян.
Короче, будьте бдительны. Нужно всегда быть готовым менять работу. Незаменимых не бывает.
Мартин Фаулер размышляет о ярких преимуществах выделения новых типов и мастерски формулирует лаконичный ответ на этот вопрос.
Использование специализированных типов для бизнес-домена всегда предпочтительнее, нежели использование общих типов вроде строки или целого числа.
В деталях об этой идее, но немного с другого ракурса, пишет Эрик Эванс в книге "Предметно-ориентированное проектирование" (Domain-Driven Design).
Книга Эванса требует глубокого погружения в концепты DDD. Что такое доменный объект? Как он связан с реальными бизнес-сущностями? Что такое объект-значение? И т.д.
Фаулер же, напротив, оперирует очень простой терминологией и наглядными примерами, доступными к пониманию без дополнительной подготовки.
Брэт Виктор отлично презентует своё видение мира. Попутно он затрагивает вопрос о необходимости моментального визуального отклика на изменения в исходном коде. Рассказывает о том, как интерактивность позволяет получить совсем иной опыт разработки. Более динамичный.
Примеры, которые он показывает, отчасти напоминают мне о возможностях, которые даёт подход Event Sourcing. Ведь Event Sourcing позволяет работать с перепроигрыванием событий и делать быстрые эксперименты даже над целыми системами в локальном окружении.
Поменял параметр, прогнал цепочку событий, посмотрел на результат. Конечно, это не по-настоящему моментальный отклик, но уже достаточно близко.
Иногда просто поражает масштаб того, что разрабатывали в Xerox PARC.
На этом видео Дэн Инголлс презентует Smalltalk-76, объединённую интерактивную среду исполнения и сам язык программирования. Два в одном! И это в 1976 году!
Smalltalk исторически повлияет на большое количество современных ЯП с ООП. Отдельно стоит отметить яркое влияние на ЯП, где в основе лежит модель акторов.
В то время ООП было не столь про термины "инкапсуляция", "полиморфизм" и "наследование". Скорее про то, что всё есть "объект", а объекты общаются между собой исключительно путём обмена сообщениями.
Это — основа современной акторной модели.
Да, Smalltalk сейчас — довольно нишевый и редкий язык, но в прошлом это был аналог и прямой конкурент молодого, только появившегося Java...
Только что в один из своих проектов на микроконтроллере RP2040 понадобилось интегрировать графический дисплей для отображения погодной информации. Выбор пал на распространенные монохромные OLED-дисплеи разрешением 128х64 точки.
Из плюсов этих дисплеев для меня: высокая яркость и контрастность, простота интерфейса, дешевизна и высокая плотность информации в небольшом размере.
Контроллер у всех этих дисплеев стандартный - SH1106.
Свои проекты я пишу на С с использованием нативной Pico SDK. Поиск библиотеки для нужной платформы на С результатов не дал. Все, что на данный момент есть, - различные ардуино-библиотеки и микропитон.
В итоге было принято решение портировать на RP2040 одну из реализаций для STM32. Эта библиотека умеет рисовать графические примитивы в виде вертикальных и горизонтальных линий, прямоугольников пустых и заполненных, растровых изображений а также есть различные функции вывода текста и числовой информации.
Библиотека позволяет задать разрешение экрана а разворачивать экран на 90/180/270 градусов.
Изначально библиотека включала в 2 шрифта с размерами знакомест 5х7 и 7х10 точек.
Для своих целей я самостоятельно разработал большой шрифт 12х16 точек (на фото он).
StackOverflow сдаёт позиции. Количество задаваемых вопросов на StackOverflow близится к полному нулю
Спад начался еще несколько лет назад, когда начали хайпить нейросети, но сейчас количество задаваемых вопросов достигло рекордно низких значений. Так, за весь декабрь поступило всего 3800 вопросов, а за первые дни января около 300
«Существуют цифры\числа\значения, которые должен знать каждый программист на Python. Например, насколько быстро или медленно добавляется элемент в список в Python? А как насчёт открытия файла? Это занимает меньше миллисекунды? Есть ли что‑то, что замедляет этот процесс? Если у вас есть алгоритм, чувствительный к производительности, какую структуру данных следует использовать? Сколько памяти занимает число с плавающей запятой? А как насчёт одного символа или пустой строки? Насколько быстр FastAPI по сравнению с Django? Я хотел бы уделить немного времени и записать показатели производительности, специально ориентированные на разработчиков Python», — сообщил автор проекта Майкл Кеннеди.
2025 стал для нас годом перемен, открытий и испытаний (куда без этого в современном мире в эпоху AI). Он запомнится новыми фичами, ребрендингом, выставками и митапами от Москвы до Новосибирска.
Наша работа не имела бы такого смысла, интереса и отдачи без вашего участия. Спасибо, что делитесь с нами своим опытом. Каждая встреча на ивенте, обсуждение, баг-репорт и вопрос в чате помогают нам двигаться вперед.
🎄Уважаемые Хабровцы, коллеги, друзья и партнеры! 🎉
В последние рабочие дни уходящего 2025 года команда SSP SOFT поздравляет вас с наступающим Новым 2026 годом и Рождеством! Самое время подвести итоги, ощутить атмосферу праздника и с уверенностью посмотреть вперед.
🚀 Нашим заказчикам Пусть 2026 год принесет устойчивый рост, новые рынки и технологические решения, которые действительно работают. Желаем, чтобы созданные вместе с SSP SOFT продукты были надежными, масштабируемыми и помогали бизнесу расти и развиваться дальше. Мы ценим доверие и рады быть вашим технологическим партнером 📈
💻 Компаниям, работающим с нами в формате аутсорсинга и Workforce-as-a-Service Готовы направить к вам сильные, мотивированные команды и специалистов, которые быстро встраиваются в процессы, понимают задачи бизнеса и усиливают его изнутри. Пусть люди остаются вашим главным конкурентным преимуществом 💪
🤝 Нашим партнерам Пусть проекты складываются, бюджеты сходятся, а наша совместная работа напоминает хорошо спроектированную систему — без лишней сложности и с понятным результатом. Спасибо за сотрудничество и совместное движение вперед 🚀
🏢 Немного о нас В 2025 году для SSP SOFT мы переехали в новый офис в Москве — в самом центре города, рядом с Красной площадью — чтобы активнее развивать сотрудничество с федеральными компаниями. 📍Весь год у нас было много вакансий, в том числе в этот новый офис. Подробности о вакансиях на нашей странице ХХ.ру
👏 Нашей команде Отдельная благодарность всем сотрудникам SSP SOFT за профессионализм, вовлеченность и ответственность. Пусть 2026 год принесет вам интересные задачи, развитие, баланс между работой и личной жизнью и уверенность в завтрашнем дне. Мы искренне рады работать вместе с вами 🤝
С нами — как дома!
🎄 С наилучшими пожеланиями в Новом году, Команда SSP SOFT 🌟ssp-soft.com 🌟
Когда говорят об автоматизации, чаще всего имеют в виду Python. Но важно понимать: Photoshop не выполняет Python-код напрямую.
Зато у него есть встроенная поддержка скриптов — Photoshop умеет исполнять код на JavaScript (ExtendScript).
Это не «JS как в браузере» и не замена Python. Это родной язык автоматизации Photoshop, с прямым доступом к:
слоям
тексту
смарт-объектам
экспорту файлов
истории документа
Если задача — управлять самим Photoshop, то скрипты внутри Photoshop — самый надёжный путь.
Что это даёт на практике
Через код можно:
массово менять текст в PSD
генерировать сотни изображений из одного шаблона
автоматизировать экспорт
исключить Actions и Variables с их ограничениями
По сути, мы описываем действия, которые дизайнер делает руками, но в виде кода.
Пример задачи
Есть:
один PSD
текстовый слой
значения 1 м → 100 м
Нужно:
автоматически подставить значения
сохранить 100 PNG-файлов
вернуть PSD в исходное состояние
Пример скрипта для Photoshop (JSX)
#target photoshop
var doc = app.activeDocument;
var layerName = "1 м"; // имя текстового слоя
var outputFolder = Folder.selectDialog("Выбери папку для сохранения");
if (!outputFolder) {
alert("Папка не выбрана");
exit();
}
function findTextLayer(layerSet) {
for (var i = 0; i < layerSet.layers.length; i++) {
var layer = layerSet.layers[i];
if (layer.kind == LayerKind.TEXT && layer.name == layerName) {
return layer;
}
if (layer.typename == "LayerSet") {
var found = findTextLayer(layer);
if (found) return found;
}
}
return null;
}
var textLayer = findTextLayer(doc);
if (!textLayer) {
alert("Текстовый слой не найден");
exit();
}
for (var i = 1; i <= 100; i++) {
textLayer.textItem.contents = i + " м";
var file = new File(outputFolder + "/pkabel_4x2_5_" + i + "m.png");
var opts = new PNGSaveOptions();
opts.compression = 9;
doc.saveAs(file, opts, true, Extension.LOWERCASE);
}
// откат без сохранения
doc.activeHistoryState = doc.historyStates[0];
alert("Готово!");
Неделю назад выступал с темой MCP сервера и как можно решить проблему с забиванием контекста как при старте диалога, так и при последующем общении через MCP сервера
Это больше походит на исследовательскую работу, а не на мой каждодневный сценарий использования. Мне было интересно, до скольки токенов можно сжать диалог без ухудшения качества
Вот, можете ознакомиться ⤵️⤵️⤵️
Давайте для начала о том, что такое MCP
MCP — протокол, который позволяет LLM подключаться к внешним сервисам: Notion, GitHub, Jira, Google Analytics, любой сервис с API. Один стандартный разъём вместо зоопарка интеграций — как USB для AI.
Протокол создали в Anthropic в ноябре 2024, в декабре 2025 передали в Linux Foundation с поддержкой OpenAI, Google, Microsoft и AWS. Де-факто стандарт индустрии. Вот тут есть каталог серверов, можете глянуть
Но у MCP есть две неочевидные проблемы, на которые я наткнулся после нескольких месяцев активного использования.
🛸 Проблема №1: Tools съедают контекст до старта
Предзагруженные MCP Tools занимают Context Window ещё до первого сообщения. Как системный промпт — уже там, когда вы только открыли чат.
Конкретные цифры из моих замеров:
Apify MCP — 7 инструментов, ~11.8k токенов
GitHub Official MCP — 40 инструментов, ~25-30k токенов
Несколько серверов вместе — легко съедают 40-70k токенов
При контексте в 200k это уже 20-35% бюджета — и вы ещё ничего не спросили.
🛸 Проблема №2: JSON забивает контекст в процессе
MCP-сервер — это переброска JSON-запросов между LLM и сервисом. Каждый вызов инструмента генерирует запрос и ответ, которые остаются в истории чата. Эти JSON часто громоздкие — особенно ответы с данными. Контекст забивается не на старте, а по ходу общения.
Почему это важно
Популярные модели имеют Context Window 128-200k токенов. Это весь бюджет чата: системные промпты, знания о вас, файлы, коннекторы. Что не влезает — забывается.
Хуже того: чем больше загружено в контекст, тем чаще модель теряет детали. В тестах на поиск 8 фактов GPT-5.1 падает с 65% до 30% при заполнении до 100k токенов. Даже более мощная GPT-5.2 проседает с 95% до 70%.
То есть проблема не только в лимите, но и в качестве работы модели при забитом контексте.
Решение для проблемы №1: Dynamic MCP
Docker Dynamic MCP — подключаем серверы не заранее, а динамически, во время разговора.
Например, вместо 40+ инструментов GitHub в контексте постоянно — лёгкий шлюз с базовыми командами:
mcp-find — найти сервер в каталоге
mcp-add — подключить к текущей сессии
mcp-exec — выполнить инструмент
mcp-remove — отключить сервер
Базовая нагрузка: ~4k токенов вместо 40-70k. Серверы подключаются по требованию и удаляются, когда больше не нужны. Работает с каталогом Docker MCP, где уже 300+ верифицированных серверов.
Нужно установить Desktop Client и в настройках Beta Features включить Enable Docker MCP Toolkit
Решение проблемы №2: запускать MCP сервера в SubAgents
SubAgents из Claude Code выполняют запрос в изолированном контексте, возвращая только результат.
Вся грязная работа — поиск серверов, подключение, вызовы инструментов, парсинг JSON-ответов — происходит в отдельном контексте подагента. В основной контекст попадает только чистый финальный ответ.
Claude Code (основной контекст)
│
▼ Запрос
┌─────────────┐
│ SubAgent │ ← вся работа с MCP
└─────────────┘
│
▼ Только результат
Claude Code (чистый контекст)
Итог: ~70k токенов экономии = 35% контекста свободно для реальной работы
Для полного описания всего этого нужна большая статья, так как без картинок и примеров суть идеи может быть непонятна
В последнюю неделю у меня из головы не выходит один вопрос...
Давайте подумаем, в чём состоит цель инженера-программиста? После некоторых рассуждений я пришёл к следующим формулировкам:
Цель: Создавать и развивать способность цифровых систем решать задачи пользователей
Единица измерения цели: решённая задача пользователя
Фокус: быстро, качественно и в полном объёме решать задачи пользователей через развитие цифровых систем
Но помогают ли нам в этом наши технологии? Мы создаём языки, а потом создаём для них Framework'и, потому что в языке не хватает функциональности. Мы спорим об архитектуре. Мы пишем тесты и выпрашиваем время на рефакторинг.
Вы заметили, что в этих утверждениях нигде нет фразы "решать задачи пользователей"?
Так вот тот вопрос, который не даёт мне покоя:
Возможно ли создать язык программирования, для которого не нужны Framework'и, в котором не нужно выбирать архитектуру, и в котором не нужно писать тесты или рефакторить код?
Как разделить строку в Python: «split()» и альтернативы для разработчиков и аналитиков данных
Разделение строк — рутина для разработчиков и аналитиков: парсинг CSV, обработка логов, пользовательского ввода. Подготовили подробный обзор, где разобрали, как работает «split()» (включая «sep» и «maxsplit»), когда выбирать «partition()/rpartition()», «splitlines()», преобразование в список символов и «re.split()» для сложных правил. И добавили практические примеры, где и какой подход удобнее и надежнее применять.
