Статьи по DDD.
Уди Дахан — один из первопроходцев DDD в C#.
Он смог показать, как именно можно применить очевидные инфраструктурные практики типа сервисной шины в контексте доменных событий.
Да, на сегодняшний день имплементация инфраструктуры для доменных событий может выглядеть совсем иначе. Но ознакомление с 3-я заметками Дахана крайне важно для понимания исторического контекста.
Статьи на сайте Дахана:
"У меня друг/брат/сват/муж/жена/собака хочет в тестирование! где почитать?!"
Несколько лет назад мы с коллегами заметили закономерность: раз в неделю кто-то спрашивает "с чего начать изучение тестирования?". Вопрос один и тот же. Ответы одни и те же. Ссылки одни и те же.
В какой-то момент стало понятно: логичнее собрать всё в одном месте и отправлять туда, чем каждый раз писать простыню заново. Так появился сначала чат в Telegram, а потом и канал TostersSchool.
Никакой монетизации. Никаких платных курсов в конце воронки. Просто практикующие специалисты, которым захотелось поделиться опытом. Записывали ролики по вечерам, монтировали по выходным, выкладывали когда получалось.
Честно скажу: последний год всё как-то притихло. Базовые темы разобрали, а снимать очередной ролик про создание коллекций в Postman уже не видим смысла. Инструменты меняются быстрее, чем мы успеваем про них рассказывать.
Но материал никуда не делся. Если кому-то нужен некоммерческий контент от практиков, а не от инфобизнеса, приходите, смотрите. Надеюсь, будет полезно.
Если есть тема, которую мы не осветили, и она вам реально нужна - пишите. Только учитывайте: запись и монтаж видео съедают много времени и сил. Мы стали бережнее относиться к своему ресурсу и откликаемся не на всё. Но если тема важная и интересная - почему бы и нет.
В общем, если вас спросят "где посмотреть что-то про тестирование для начинающих" - можете кинуть ссылку: TostersSchool
Канал легко гуглится и ищется в Telegram.
Claude Code: настройка хуков, MCP и субагентов текстом, без правки конфигов вручную
А вы знали, что можно настраивать Claude Code, прямо через Claude Code?
Для этого достаточно написать в чат, например:
Добавь хук, блокирующий глобальные rm -rf команды
или так:
Установи Grafana MCP
Измени мой апи ключ GitHub в конфиге MCP на ...
Классно же?
Так вот, я удивлюсь, если вы знали о такой возможности, потому что в действительности в дефолтном Claude Code такая возможность отсутствует. Поэтому я сделал плагин, который позволяет вносить в настройки CC почти любые изменения, просто написав об этом текстом самому клоду, как в примерах выше - плагин так и называется Claude Code Reflection.
Что еще входит в плагин:
Управление скиллами
Просмотр, настройка, удаление, перемещение user scope - project scope и даже ревью.
Управление субагентами
Создание, изменение и удаление субагентов с корректными разрешениями.
Создание и публикация плагинов
Сделали классный скилл или скиллы и хотите упаковать их в плагин и отдать в пользование этому миру? Не проблема, claude-plugins-manager скилл там как раз для этого.
Напомню, что поскольку весь функционал плагина реализован в виде скиллов, они очень экономны к контексту (менее 500 токенов в сумме).
Ну, и бонусом: Claude Best Practices Skill
Скилл проверяет, на сколько хорошо ваш проект (кодовая база) и сам клод оптимизированы под эффективную работу Claude, и фактически делает аудит контекста и кода, и дает рекомендации по оптимизации. Еще, это скилл можно в принципе поспрашивать про актуальные лучшие практики CC.
Устанавливается двумя командами. Запускам claude и:
Сначала добавляем маркетплейс, чтобы плагин появился в поле зрения:
/plugin marketplace add https://github.com/CodeAlive-AI/claude-code-reflection-skills.git
Теперь ставим сам плагин
/plugin install claude-code-reflection-skills@claude-code-reflection-skills
Перезапускаем Claude Code и вуаля — теперь ваш клод как после сеанса к психотерапевту, прокаченный рефлексией.
Репо: https://github.com/CodeAlive-AI/claude-code-reflection-skills
Мой канал в Telegram "AI Driven Development": https://t.me/ai_driven
по сути же получается нужно меньше разработчиков сейчас? Интересно как это выглядит с точки зрения владельца бизнеса
Регулярно стал видеть подобные вопросы. Если растет производительность, то логично, что надо сокращаться? Если речь идет про избыточную разработку и цель оставаться на том же уровне производительности, то да, избыточность можно уменьшить. Но реальность и капитализм работают чуть сложнее.
Регулярно стал видеть подобные вопросы. Если растет производительность, то логично, что надо сокращаться? Если речь идет про избыточную разработку и цель оставаться на том же уровне производительности, то да, избыточность можно уменьшить. Но реальность и капитализм работают чуть сложнее.
Начнем с избыточности. Одно дело когда у вас команда из 50 человек, где есть и фронты и бекендеры и девопсы и бог знает кто еще. Другое, когда вся команда это три человека с очень разными компетенциями. Если в команде один бекендер, то его никем не заменить. Тоже самое касается и большинства остальных ролей. Всегда нужен человек, который отвечает за свой блок и разбирается в нем лучше всех (или в принципе только он и разбирается). Такому человеку ИИ конечно помогает, но убрать его с помощью ИИ невозможно, как бы красиво это не звучало и не выглядело (посмотрите как я сгенерил лендинг с помощью ии!).
Но даже одного человека мало, потому что на больших объемах один человек всегда будет занят большую часть времени текучкой. Тут надо обсудить, там что-то сломалось надо починить, тут разобраться. В общем в живых проектах с пользователями и инфраструктурой, даже увеличение производительности не даст возможность освободить одного настолько сильно, что он сможет легко фигачить новый функционал. У нас вон вчера зависла транзакция в базе на проде (это вообще похоже на баг в постгре). Пол дня потеряно на выяснение, восстановление, эксперименты и переконфигурацию.
И самое важное, в случае с ИИ это преимущество почти всегда временное. Мы не единственные, кто повышает производительность: инструменты доступны всем, и эффект быстро размазывается по рынку. Как только ситуация выравнивается, конкуренция начинает давить на цены или, наоборот, заставляет больше тратить: на зарплаты, инфраструктуру, вычисления, закупки. В итоге повышенная производительность перестает быть конкурентным преимуществом и становится новой нормой. А чтобы вырваться вперед, снова нужно делать больше: выходить в рост, расширяться, брать на себя больший масштаб при том, что производительность у всех выросла примерно одинаково.
Что не отменяет большого числа новых возможностей. Сейчас самое благодатное время для старта новых проектов и заработка. Новым предпринимателям сложнее понять что не делать, чем что делать.
Больше про разработку в моем телеграм-канале Организованное программирование
Kubernetes Zero to Hero — базовый видеокурс от «Фланта»
Если вы хотите изучить основы работы с Kubernetes, мы сняли подходящий для этого видеокурс. Из него вы получите практические знания, которых будет достаточно для решения большинства типовых задач.
В курсе 10 коротких — до 10 минут — видео. Они рассчитаны на начинающих разработчиков с опытом в продуктовой разработке, учебных или личных проектах, где возникает потребность в Kubernetes. С нами вы:
поднимете локальный кластер и разберётесь в ключевых сущностях Kubernetes;
научитесь развёртывать приложения, пройдя путь от коммита кода в Git-репозиторий до его выката в кластер;
поймёте, как устроены сетевое взаимодействие внутри кластера и доступ к приложениям извне;
познакомитесь с werf и Helm, шаблонизацией чартов и практиками реальных проектов.
Два первых ролика уже доступны. Во вводном будут план курса и желательный для старта бэкграунд, а второй поможет поднять локальный кластер Kubernetes с помощью Minikube и получить готовое окружение для экспериментов. Смотрите на удобной вам площадке:
Каждую неделю будет выходить по два ролика — по вторникам и четвергам. Присоединяйтесь, будем вместе проходить путь от новичка до Kubernetes Hero.
Про Null References.
Популярные современные ЯП позволяют переменным-ссылкам иметь значение NULL. И это уже привело к огромным проблемам, рассказывает Тони Хоар на выступлении.
Борьба с NULL принимает разные виды.
Дизайн каких-то ЯП оставляет это на откуп линтерам, не обременяя себя вопросами времени компиляции и исполнения.
Другие ЯП разрешают хранить NULL только в переменных, которые имеют знак вопроса после типа. Пример: Object? a = null. Нет знака вопроса — переменная не может быть NULL.
Отдельные ЯП имеют монаду Maybe или Optional в стандартной системе типов. Так они кардинально избавляются от самого концепта NULL.
Так или иначе, определённо ясно, что NULL — исключительно техническая необходимость прошлого. А в моделировании предметной области использовать NULL просто не получится.
Презентация на сайте InfoQ: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/
Мы иногда во внутреннем чате обмениваемся фрагментами кода с неочевидными ошибками, которые обнаруживаются с помощью 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.
Правильный вариант:
static_assert(false, "unsupported ValueType");A Micro-Manual for LISP.
LISP имеет удивительный по простоте синтаксис. Это делает его одним из самых популярных кандидатов для программирования своего интерпретатора.
Такой интерпретатор — замечательный пример пет-проекта, который расширит кругозор и познакомит с элегантностью LISP. Быть может, разожжёт интерес к Clojure и Scheme.
Отличной подмогой для проекта будет работа Джона Маккарти. В своём микро-руководстве он описал базовые блоки для построения минимального интерпретатора.
Маккарти формулирует основу LISP всего в десятке правил и пяти основных аббревиатурах, сопровождая этот набор дополнительными примерами.
И это описание занимает всего две страницы! Фантастика!
Статья на сайте ACM: https://dl.acm.org/doi/pdf/10.1145/960118.808386
Услышал про 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:
📄 Отказаться от Postman, перейти на Bruno и жить счастливо — в комментариях есть отзыв про Apidog от человека, который перешёл
📄 Лучшие open-source инструменты для тестирования API в 2025 году — обзор альтернатив
📄 Как выбрать инструмент для тестирования API — сравнение Postman, Insomnia и других
📄 API Тестирование без Postman — разбор Hoppscotch
С новым рабочим годом, Хабр
Мы в SSP SOFT опять расширяем команду и ждем ваши резюме
Кто мы? Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.
В 2025 году SSP SOFT вошел в число лидеров найма ИТ-специалистов на российском рынке — за год мы наняли 179 сотрудников!
И главное — в 2026 году найм продолжается.
У нас новый московский офис в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удаленку из любой точки России.
Открытые вакансии в SSP SOFT: это реальные проекты, дружная команда и атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем гуру, кто готов в новое профессиональное будущее вместе с нами.
1️⃣ Fullstack разработчика (C# + React) (https://vk.cc/cT6vMP)
2️⃣ Python Разработчика (ML Engineer) (https://vk.cc/cT6vNp)
3️⃣ Программиста 1С (https://vk.cc/cT6vNR)
4️⃣ Fullstack-разработчика (Java+Go/React) (https://vk.cc/cT6vOl)
Что вас ждет в SSP SOFT:
✅ Рост: Центр компетенций для максимального апгрейда скиллов.
✅ Свобода геолокации: Возможность работать удаленно, гибрид или офис.
✅ Баланс: Работаем, чтобы жить, а не наоборот.
🎁 Приятные бонусы: ивенты для всей команды, ДМС для штата, обучение и бенефиты.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вакансию на Хабре».
Желаем всем успешной карьеры в 2026 году 🚀)
Периодически наталкиваюсь на разработчиков, которые думают, что они незаменимы, потому что знают в каком-то месте кода прям всё на свете. И поэтому их-то точно никогда не уволят - слишком опасно и долго обучать новичка.
Но это, конечно, не так. За свою 20-летнюю карьеру видел пяток увольнений самых-пресамых незаменимых.
Во-первых, незаменимость часто преувеличивается (особенно с учетом ИИ, который и разберется, и нарисует, и расскажет всё, что важно знать). На практике обычно через 3-4 месяца уже никто и не вспоминает о Васе, который где-то там всё знал. А чаще скорее просто ругают его за странные решения, переписывая запутанные куски с нуля.
Во-вторых, даже если человек реально приносит огромную пользу и по-своему незаменим, то порой руководство просто поступает нелогично и увольняет всё равно. Иногда последствия бывают совсем неочевидны и отложены во времени (медленнее пилятся фичи, вылезают непонятные критические баги на проде), их никто никогда с Васей уже и не свяжет. Даже если объективное расследование бы показало, что денег в итоге потрачено больше. Короче, это или неправильная системная оценка или просто банальная глупость/лень менеджмента.
В-третьих, в кризисные времена сокращают целые направления, вместе с Васей и бизнесом, который Вася подпирал столько лет своим плечом, как заправский атлант. Причем, такие новости обычно приходя внезапно, как снег на голову. Типа, наш отдел закрывают с первого числа, сорян.
Короче, будьте бдительны. Нужно всегда быть готовым менять работу. Незаменимых не бывает.
Cross-пост из tg-канала Cross Join
When to Make a Type.
Мартин Фаулер размышляет о ярких преимуществах выделения новых типов и мастерски формулирует лаконичный ответ на этот вопрос.
Использование специализированных типов для бизнес-домена всегда предпочтительнее, нежели использование общих типов вроде строки или целого числа.
В деталях об этой идее, но немного с другого ракурса, пишет Эрик Эванс в книге "Предметно-ориентированное проектирование" (Domain-Driven Design).
Книга Эванса требует глубокого погружения в концепты DDD. Что такое доменный объект? Как он связан с реальными бизнес-сущностями? Что такое объект-значение? И т.д.
Фаулер же, напротив, оперирует очень простой терминологией и наглядными примерами, доступными к пониманию без дополнительной подготовки.
Рекомендую к ознакомлению!
Статья на сайте Мартина Фаулера: https://martinfowler.com/ieeeSoftware/whenType.pdf
Интерактивность в разработке.
Брэт Виктор отлично презентует своё видение мира. Попутно он затрагивает вопрос о необходимости моментального визуального отклика на изменения в исходном коде. Рассказывает о том, как интерактивность позволяет получить совсем иной опыт разработки. Более динамичный.
Примеры, которые он показывает, отчасти напоминают мне о возможностях, которые даёт подход Event Sourcing. Ведь Event Sourcing позволяет работать с перепроигрыванием событий и делать быстрые эксперименты даже над целыми системами в локальном окружении.
Поменял параметр, прогнал цепочку событий, посмотрел на результат. Конечно, это не по-настоящему моментальный отклик, но уже достаточно близко.
Впрочем, всегда есть, куда стремиться.
Презентация на Vimeo: https://vimeo.com/906418692
Демо Smalltalk-76.
Иногда просто поражает масштаб того, что разрабатывали в Xerox PARC.
На этом видео Дэн Инголлс презентует Smalltalk-76, объединённую интерактивную среду исполнения и сам язык программирования. Два в одном! И это в 1976 году!
Smalltalk исторически повлияет на большое количество современных ЯП с ООП. Отдельно стоит отметить яркое влияние на ЯП, где в основе лежит модель акторов.
В то время ООП было не столь про термины "инкапсуляция", "полиморфизм" и "наследование". Скорее про то, что всё есть "объект", а объекты общаются между собой исключительно путём обмена сообщениями.
Это — основа современной акторной модели.
Да, Smalltalk сейчас — довольно нишевый и редкий язык, но в прошлом это был аналог и прямой конкурент молодого, только появившегося Java...
Презентация на YouTube: https://youtu.be/NqKyHEJe9_w
Нативный драйвер OLED-дисплеев для RP2040
Только что в один из своих проектов на микроконтроллере RP2040 понадобилось интегрировать графический дисплей для отображения погодной информации. Выбор пал на распространенные монохромные OLED-дисплеи разрешением 128х64 точки.
Из плюсов этих дисплеев для меня: высокая яркость и контрастность, простота интерфейса, дешевизна и высокая плотность информации в небольшом размере.
Контроллер у всех этих дисплеев стандартный - SH1106.
Свои проекты я пишу на С с использованием нативной Pico SDK. Поиск библиотеки для нужной платформы на С результатов не дал. Все, что на данный момент есть, - различные ардуино-библиотеки и микропитон.
В итоге было принято решение портировать на RP2040 одну из реализаций для STM32. Эта библиотека умеет рисовать графические примитивы в виде вертикальных и горизонтальных линий, прямоугольников пустых и заполненных, растровых изображений а также есть различные функции вывода текста и числовой информации.
Библиотека позволяет задать разрешение экрана а разворачивать экран на 90/180/270 градусов.
Изначально библиотека включала в 2 шрифта с размерами знакомест 5х7 и 7х10 точек.
Для своих целей я самостоятельно разработал большой шрифт 12х16 точек (на фото он).
Репозиторий проекта: https://gitflic.ru/project/svperchenko/sh1106_for_rp2040. Всем, кому надо, можно пользоваться.
StackOverflow сдаёт позиции. Количество задаваемых вопросов на StackOverflow близится к полному нулю
Спад начался еще несколько лет назад, когда начали хайпить нейросети, но сейчас количество задаваемых вопросов достигло рекордно низких значений. Так, за весь декабрь поступило всего 3800 вопросов, а за первые дни января около 300
Больше интересного тут
Представлен учебный проект «Числа Python, которые должен знать каждый программист» (Python Numbers Every Programmer Should Know). Проект также доступен на GitHub.
«Существуют цифры\числа\значения, которые должен знать каждый программист на Python. Например, насколько быстро или медленно добавляется элемент в список в Python? А как насчёт открытия файла? Это занимает меньше миллисекунды? Есть ли что‑то, что замедляет этот процесс? Если у вас есть алгоритм, чувствительный к производительности, какую структуру данных следует использовать? Сколько памяти занимает число с плавающей запятой? А как насчёт одного символа или пустой строки? Насколько быстр FastAPI по сравнению с Django? Я хотел бы уделить немного времени и записать показатели производительности, специально ориентированные на разработчиков Python», — сообщил автор проекта Майкл Кеннеди.
2025: топ-7 фичей, пицца и прочие достижения
2025 стал для нас годом перемен, открытий и испытаний (куда без этого в современном мире в эпоху AI). Он запомнится новыми фичами, ребрендингом, выставками и митапами от Москвы до Новосибирска.
Наша работа не имела бы такого смысла, интереса и отдачи без вашего участия. Спасибо, что делитесь с нами своим опытом. Каждая встреча на ивенте, обсуждение, баг-репорт и вопрос в чате помогают нам двигаться вперед.
Toп-7 фичей Veai по мнению наших пользователей
Генерация тестов по исполнению (статья на Хабре "Не LLM едиными: генерируем юнит-тесты из реального исполнения на лету")
Агентский режим (статья на Хабре "Как мы сделали AI-агента и пользуемся им на практике")
2025
4 больших релиза, много EAP и nightly-сборок
поддержка OpenIDE, GigaIDE, PyCharm, Rider, GoLand, PhpStorm и WebStorm
участие в JPoint, Joker, Heisenbug, CodeFest и митапах в Москве, Санкт-Петербурге, Владимире и Новосибирске
переезд в новый офис
ребрендинг
съели с коллегами 1040 пицц в офисе по пятницам :)
Мы уже работаем над следующим релизом и ждём возможности показать вам новые фичи.
С наступающим Новым годом — и спасибо, что вы с нами!
Команда Veai 🎄
🎄Уважаемые Хабровцы, коллеги, друзья и партнеры! 🎉
В последние рабочие дни уходящего 2025 года команда SSP SOFT поздравляет вас с наступающим Новым 2026 годом и Рождеством!
Самое время подвести итоги, ощутить атмосферу праздника и с уверенностью посмотреть вперед.
🚀 Нашим заказчикам
Пусть 2026 год принесет устойчивый рост, новые рынки и технологические решения, которые действительно работают. Желаем, чтобы созданные вместе с SSP SOFT продукты были надежными, масштабируемыми и помогали бизнесу расти и развиваться дальше. Мы ценим доверие и рады быть вашим технологическим партнером 📈
💻 Компаниям, работающим с нами в формате аутсорсинга и Workforce-as-a-Service
Готовы направить к вам сильные, мотивированные команды и специалистов, которые быстро встраиваются в процессы, понимают задачи бизнеса и усиливают его изнутри. Пусть люди остаются вашим главным конкурентным преимуществом 💪
🤝 Нашим партнерам
Пусть проекты складываются, бюджеты сходятся, а наша совместная работа напоминает хорошо спроектированную систему — без лишней сложности и с понятным результатом. Спасибо за сотрудничество и совместное движение вперед 🚀
🏢 Немного о нас
В 2025 году для SSP SOFT мы переехали в новый офис в Москве — в самом центре города, рядом с Красной площадью — чтобы активнее развивать сотрудничество с федеральными компаниями.
📍Весь год у нас было много вакансий, в том числе в этот новый офис. Подробности о вакансиях на нашей странице ХХ.ру
👏 Нашей команде
Отдельная благодарность всем сотрудникам SSP SOFT за профессионализм, вовлеченность и ответственность. Пусть 2026 год принесет вам интересные задачи, развитие, баланс между работой и личной жизнью и уверенность в завтрашнем дне.
Мы искренне рады работать вместе с вами 🤝
С нами — как дома!
🎄 С наилучшими пожеланиями в Новом году,
Команда SSP SOFT
🌟ssp-soft.com 🌟
Как автоматизировать Photoshop через кодинг
Когда говорят об автоматизации, чаще всего имеют в виду 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 ранее, тоже можете глянуть
Model Context Protocol. Революция в интеграции AI с данными?
Как управлять Notion, GitHub через Claude. Мои примеры MCP серверов
--------------
Но у 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% контекста свободно для реальной работы
Для полного описания всего этого нужна большая статья, так как без картинок и примеров суть идеи может быть непонятна
Обновлён проект Cheat Sheets for Developers со шпаргалками для разработчиков по языкам программирования, сервисам и технологиям, включая Python, Bash, Docker, JS, Java, VS Code, Figma, Git, GitHub, Postman, C#, C++, Rust, Flutter, EJS, Fortran, Docker, K8s, Git, ReEX, ChatGPT, Firefox, Zoom, Gmail, Blender, Audacity, Photoshop.
В последнюю неделю у меня из головы не выходит один вопрос...
Давайте подумаем, в чём состоит цель инженера-программиста? После некоторых рассуждений я пришёл к следующим формулировкам:
Цель: Создавать и развивать способность цифровых систем решать задачи пользователей
Единица измерения цели: решённая задача пользователя
Фокус: быстро, качественно и в полном объёме решать задачи пользователей через развитие цифровых систем
Но помогают ли нам в этом наши технологии? Мы создаём языки, а потом создаём для них Framework'и, потому что в языке не хватает функциональности. Мы спорим об архитектуре. Мы пишем тесты и выпрашиваем время на рефакторинг.
Вы заметили, что в этих утверждениях нигде нет фразы "решать задачи пользователей"?
Так вот тот вопрос, который не даёт мне покоя:
Возможно ли создать язык программирования, для которого не нужны Framework'и, в котором не нужно выбирать архитектуру, и в котором не нужно писать тесты или рефакторить код?
Как разделить строку в Python: «split()» и альтернативы для разработчиков и аналитиков данных
Разделение строк — рутина для разработчиков и аналитиков: парсинг CSV, обработка логов, пользовательского ввода. Подготовили подробный обзор, где разобрали, как работает «split()» (включая «sep» и «maxsplit»), когда выбирать «partition()/rpartition()», «splitlines()», преобразование в список символов и «re.split()» для сложных правил. И добавили практические примеры, где и какой подход удобнее и надежнее применять.
Подробную инструкцию смотрите в базе знаний Рег.облака.
Коллеги, всем привет!
За годы менторства по Angular (в том числе в HTML Academy) я заметил одну системную проблему: студенты и даже миддлы часто знают синтаксис RxJS, но не понимают реактивного мышления. В итоге мы получаем subscribe внутри subscribe и императивную лапшу.
Я искал интерактивные курсы, но большинство бесплатных ресурсов ограничиваются основами.
Курс бесплатный. Делал для себя и студентов, но теперь делюсь со всеми.
Буду рад фидбеку и баг-репортам (проект активно допиливаю).
Ссылка на курс: https://rxjs-course-avy.web.app/
Команда разработчиков Chrome собрала на одной странице все крупные изменения в CSS за 2025 год. У каждой новой фичи есть подробное описание, интерактивная демонстрация, примеры кода и информацию о поддержке в основных браузерах.
DeepSeek-V3.2 vs Qwen3-Coder-480B
Привет! На этой неделе мы развернули DeepSeek-V3.2 в нашем VPC и хотим поделиться первыми результатами.
По итогам замеров на внутреннем бенчмарке DeepSeek-V3.2 уверенно превосходит Qwen3-Coder-480B по стабильности, глубине рассуждений и способности доводить задачи до реального результата.
DeepSeek-V3.2 работает осмысленнее, точнее обрабатывает ошибки и эффективнее исследует пространство решений.
Ниже — оценки LLM-арбитра нашего бенчмарка (на базе GPT-5.0 и Gemini), которые наглядно демонстрируют разницу подходов.
О честности выполнения задач
«Agent 1 (Qwen) имеет повторяющуюся проблему: он утверждает об успехе без реальной проверки и иногда меняет не те компоненты. Agent 2 (DeepSeek) действует иначе: он последовательно валидирует результаты (запускает тесты, настраивает уровни логирования) и эскалирует проблему, если не может выполнить задачу точно»
Результат вместо имитации деятельности
«Там, где Qwen "застревал" на этапе анализа, не переходя к реальным правкам, DeepSeek доставлял готовую функциональность и реализовывал запасные варианты»
Завершенность важнее формализма
«Старая модель ставит во главу угла соблюдение формальных правил, но теряет нить и бросает задачу на полпути. Новая (DeepSeek) действует ровно наоборот: она приоритезирует сущностное завершение задачи, даже если для этого приходится отойти от жестких, но формальных требований пользователя к структуре»
Меньше шума, больше дела
«Взаимодействие с DeepSeek вызывает меньше трения (low-friction experience). В то время как Qwen колеблется между полезной структурой и разрушительной "гиперактивностью", заваливая логами и повторами, DeepSeek работает тише и предсказуемее»
Реальный цикл разработки
«DeepSeek последовательно выполняет полный цикл: "правка — компиляция — тест". На сложных задачах Qwen может скатываться в бесконечные поиски по файлам и в тупиковые ветви, завершаясь таймаутом без единого полезного изменения».
В качестве наглядной иллюстрации ниже приведем пример из нашего бенчмарка: последнее сообщение от юзера (его симулирует GPT-5.0) и verification result, который честно проверяет, выполнена ли задача.
Qwen3-Coder-480B не доделал и по сути обманул:
"response": {
"role": "user",
"content": "Termination tool arguments:\n{"termination_reason":"Looks good: tests were added only in ConfigControllerTest and they pass locally. This should bump line coverage as requested by at least 0.1."}"
},
"formal_verification_result": 0
DeepSeek-V3.2 прозрачно продемонстрировал успешное исполнение:
"response": {
"role": "user",
"content": "Termination tool arguments:\n{"termination_reason":"Nice work: you only modified tests, all tests pass, and ConfigController line coverage rose from 86.67% to 100% (branch to 94.12%), exceeding the required +0.1%. This completes the task."}"
},
"formal_verification_result": 1
Итак:
DeepSeek-V3.2 заметно умнее
уверенно решает более сложные задачи
не допускает ошибок там, где ошибалась Qwen3-Coder-480B
до конца пытается устранить проблему: продолжает анализ, отладку и поиск решений с разных сторон — в тех случаях, где Qwen3-Coder-480B останавливалась бы и запрашивала помощь человека
Новая модель DeepSeek-V3.2 доступна для использования в Veai Enterprise. Отзывы первых пользователей Veai c DeepSeek-V3.2:
"адекватнее и умнее. Стало круче сразу)"
"прям агент супер самостоятельный стал, код запускает, чекает всё"
"вообще мне пока больше нравится чем квен - сильно меньше тупит"
Наша R&D-команда постоянно исследует новые модели (будем рады узнать ваше мнение). Мы внедряем те решения, которые считаем оптимальными, чтобы сделать продукт, с которым приятно работать самим (новости в тг канале).
Усыпальница Java
Java обычно воспринимают как "тихую гавань" стабильности и обратной совместимости. Но на самом деле внутри неё постоянно кипит жизнь: язык и платформа меняются, обрастают новыми API и возможностями, а старые решения постепенно отправляются на покой в виртуальную усыпальницу.
В новой статье мы разберёмся, чем именно наполняется эта усыпальница и почему. Поговорим о legacy-коллекциях Java, финализаторах, Nashorn, SecurityManager и легендарном Unsafe. Какие задачи они решали? Какие архитектурные и эксплуатационные проблемы породили? И, конечно, разберём, какие современные альтернативы пришли им на смену.
SSP SOFT — последние вакансии в уходящем году: присоединяйтесь к команде 💻
Вот и настал момент последнего поста про вакансии в SSP SOFT в 2025 году!
«Год прошел, как день вчерашний. Над Москвою в этот час. Бьют часы Кремлевской башни. Свой салют — двенадцать раз»...
А мы как раз переехали в новый московский офис в 2025 году у самой Красной площади! И там у нас есть открытые вакансии: реальные проекты, дружная команда и атмосфера, где работать — в удовольствие. Ищем гуру, кто готов в новое профессиональное будущее вместе с нами.
📢 Мы ищем прямо сейчас:
1️⃣ Fullstack QA (Java)
2️⃣ Бизнес-аналитика (Senior)
3️⃣ С# Разработчика (интеграции с Lekton)
Подробности о вакансиях на нашей странице ХХ.ру
Что вас ждет в SSP SOFT:
✅ Вызовы: Амбициозные проекты, где не придется скучать.
✅ Поддержка: Наставник для каждого ньюби.
✅ Рост: Центр компетенций для максимального апгрейда скиллов.
✅ Свобода геолокации: Возможность работать удаленно, гибрид или офис.
✅ Баланс: Работаем, чтобы жить, а не наоборот.
🎁 Приятные бонусы: выезды всей командой, ивенты, ДМС, обучение и бенефиты.
👉 Куранты скоро пробьют! Не теряйте время — ждем резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, что увидели вакансию на Хабре.
Желаем всем успешной карьеры в Новом году 🚀🎄)
Баги на всех языках мира. Проверка LanguageTool
Всем привет! Hello, everyone! Hallo zusammen! Hola a tothom! مرحباً بالجميع!
В нашем блоге мы часто говорим про статический анализ, линтеры и подобные инструменты. Но на этот раз мы нашли их довольно интересного представителя! LanguageTool — это многоязычная программа проверки орфографии, стилистики и грамматики, которая помогает исправлять и перефразировать тексты.
В новой статье заглянем в её код и посмотрим на интересные вещи, которые нашёл в нём статический анализатор кода PVS-Studio: от утечек ресурсов и логических противоречий в условиях до дублирующихся ключей в хеш-таблицах, избыточных проверок и мёртвого кода.
Компьютерное зрение для кода: что PVS-Studio разглядел в OpenCV
Что общего у компьютерного зрения и статического анализа? Оба ищут смысл в данных. OpenCV находит образы среди миллионов пикселей, а PVS-Studio — ошибки среди тысяч строк кода. Изучим же исходники крупнейшей библиотеки компьютерного зрения.
На примере 14 фрагментов кода из OpenCV предлагаю посмотреть, как статический анализ помогает избежать попадания багов в релиз и облегчить жизнь разработчикам.
Давайте посмотрим на кусок кода из проекта:
template<typename T>
struct Ptr : public std::shared_ptr<T>;
// ....
Ptr<FlannNeighborhoodGraph> FlannNeighborhoodGraph::create(....)
{
return makePtr<FlannNeighborhoodGraphImpl>(....);
}
void Utils::densitySort (const Mat &points, int knn,
Mat &sorted_points, std::vector<int> &sorted_mask)
{
// ....
FlannNeighborhoodGraph &graph = // <=
*FlannNeighborhoodGraph::create(....);
std::vector<double> sum_knn_distances (points_size, 0);
for (int p = 0; p < points_size; p++) {
const std::vector<double> &dists = graph.getNeighborsDistances(p);
for (int k = 0; k < knn; k++)
sum_knn_distances[p] += dists[k];
}
// ....
}
Если вы думаете, что использование умных указателей раз и навсегда решает проблему "висячих" ссылок и доступов к памяти, то здесь всё пошло не так. Давайте разбираться. Сейчас код работает следующим образом:
Функция create создаёт и возвращает умный указатель на тип FlannNeighborhoodGraphImpl, и его счётчик ссылок на объект равен единице;
Создаётся ссылка graph на значение этого умного указателя, при этом счётчик ссылок на объект не изменяется;
Указатель является временным объектом, и поэтому после завершения инициализации счётчик ссылок уменьшится до нуля, что приведёт к освобождению управляемого объекта. Теперь ссылка указывает на разрушенный объект;
В цикле for происходит обращение к невалидной ссылке.
В итоге код, который казался правильным, приводит к неопределённому поведению. Кроме того, эту проблему находит не только PVS-Studio, но и санитайзер. Пруф.
Для исправления необходимо сохранить умный указатель, тогда объект типа FlannNeighborhoodGraph будет жить до конца блока. Можно сделать так:
std::vector<double> sum_knn_distances (points_size, 0);
{
// get neighbors
auto graph = FlannNeighborhoodGraph::create(....);
for (int p = 0; p < points_size; p++) {
const std::vector<double> &dists = graph->getNeighborsDistances(p);
for (int k = 0; k < knn; k++)
sum_knn_distances[p] += dists[k];
}
}
Дополнительно ограничили область видимости graph, чтобы ресурс освободился после выполнения циклов.
Хотите узнать больше?
Статический анализ выявляет скрытые дефекты даже в больших работающих проектах. Какие ещё опасные фрагменты кода мы нашли в коде OpenCV? Полный разбор можно найти в отдельной статье.
20 демо-уроков, которые нельзя пропустить бэкенд-разработчикам
Привет, Хабр. Сегодня делимся подборкой открытых уроков, которые пройдут в Otus в декабре. Уроки проводят преподаватели курсов в формате живых вебинаров — это шанс не только получить нужные знания, но и задать свои вопросы экспертам. Участие бесплатное (нужно только зарегистрироваться). Присоединяйтесь!
15 декабря — Легкий старт в парсинг сайтов на Python
15 декабря — Docker Compose: многоконтейнерные приложения и инфраструктура
15 декабря — Интеграция Node.js с локальной LLM: создаём умный сервер своими руками
15 декабря — Тренды стрессоустойчивого проектирования: composable architecture
16 декабря — Потоковые приложения с использованием Apache Kafka: от событий к реальному времени
16 декабря — Асинхронная обработка данных в высоконагруженных системах
16 декабря — Введение в Elasticsearch: применение в бэкенде и распределённых системах
16 декабря — Lock-Free алгоритмы с Interlocked и Volatile
17 декабря — Инструменты и механизмы Kubernetes для обеспечения высокой нагрузки
17 декабря — Кластеризация MongoDB: репликация и шардирование
18 декабря — Принцип DRY в GitLab CI: как избавиться от дублирования и навести порядок в пайплайнах
18 декабря — Docker в продакшене: сборка образов, безопасность и CI/CD
18 декабря — Базовые принципы шардирования и репликации в ClickHouse
22 декабря — Проектирование высоконагруженного мониторинга в распределенных системах
23 декабря — Cache friendly код — оптимизируем работу с памятью
23 декабря — GitOps + Flux: стабильный деплой в Kubernetes без ручного вмешательства
23 декабря — Polyglot Persistence: как современные системы живут с десятками баз данных
23 декабря — Как восстановить базу PostgreSQL на конкретный момент времени
24 декабря — Паттерны микросервисной архитектуры: как системному аналитику говорить с архитектором на одном языке
25 декабря — Тестирование Spring приложений. Интеграционные тесты с контекстом. Тестирование слоя репозиториев и сервисов
Полное расписание бесплатных демо-уроков смотрите в календаре.
Слои валидации
Когда говорят "валидация", обычно подразумевают любое правило, которое должно защитить систему от неправильных данных. Но внутри этого большого слова скрываются разные типы и цели проверок, которые еще и выполняются на разных уровнях приложения. Разберем:
Валидация на клиенте (если он есть)
Сюда входит формат данных, обязательность полей и так далее. Чуть сложнее, когда надо проверять, например, уникальность имени пользователя или емейла, в этом случае придется ждать отправки или делать запросы на бекенд во время заполнения. Главное что надо знать про эту валидацию, то что она вспомогательная. Клиент всегда можно обойти и сделать запрос напрямую. Дублирование как ни крути, хотя и важно для UX.
Структурная валидация
Это валидация, которая, обычно, происходит на уровне самого фреймворка или в самом начале цикла обработки запроса. Для этого данные прогоняются через валидаторы json схемы, которая в идеале генерируется из openapi спеки. В самых деревянных случаях ручками (так делать не надо). Что важно понимать, это не доменная валидация (бизнес правила). Да тут можно проверить формат, наличие/отсутствие, но нельзя и не правильно пытаться проверять уникальность, выполнение каких-то условий, например количества денег на счету и тому подобное.
Кстати с точки зрения кодов ответа, на этом уровне несовпадение со схемой воспринимается не как ошибка валидации, а как неверный запрос с неверной структурой, а это код ответа 400.
Доменная валидация
Это уже уровень бизнес правил. Такая валидация включает в себя любые правила, которым должны соответствовать данные с точки зрения бизнес-логики приложения. Уникальность email, баланс на счету, ограничения переходов - все это относится к доменному слою, и проверяется глубже, после прохождения проверки структуры. Во фреймворках это слой, который часто реализуется внутри моделей (если они есть). В любом случае такие валидации должны быть вынесены в какой-то свой слой, который можно переиспользовать для разных точек входа, асинхронной обработки и т.п.
Доменные проверки, как и клиентские могут дублироваться, если завязаны на консистентность базы данных. Например во многих фреймворках (с orm) есть валидация на уникальность, которая делает sql-запрос, но в документации у этого валидатора всегда написано, что это не надежно (из-за конкурентности) и в таких ситуациях обязательно делать индексы в базе данных.
В случае провала такой валидации, в api принято возвращать код 422
Валидация на уровне базы данных
Все предыдущие уровни не могут дать 100% гарантий, особенно учитывая, что данные в базе обновляются далеко не только по запросам снаружи. Поэтому есть вещи, которые обязательно делать на уровне базы данных. Сюда относятся уникальные индексы, внешние ключи (если делаете их), nullable, ограничение по длине и т.д. Технически многие базы данных позволяют писать кастомные валидации, которые соблазнительно использовать как доменную валидацию. Не надо этого делать :)
Проверка корректности данных
Это тип валидации "ни туда ни сюда", потому что он может выполняться в разных слоях, в зависимости от используемого стека. К таким проверкам относится подтверждение пароля или, например, емейла. С точки зрения бизнес-логики, этой части вообще не существует, она есть только на уровне форм, потому что все давно привыкли так писать (хотя необходимость под вопросом). При этом ни в базе, ни в дальнейшей работе оно никак не используется и вообще это не данные, которые куда-то сохраняются.
Подобные проверки делают в первую очередь на клиенте (и на этом можно было бы остановиться). Внутри бека их располагают в слое форм (есть далеко не во всех фреймворках), либо некоторые фреймворки типа rails для простоты пихают такой валидатор в модели, хотя семантически это неверно.
Больше про разработку в моем телеграм-канале Организованное программирование
Участие в нескольких проектах снижает результаты работы — так ли это?
На одной из конференций прозвучал тезис: заказчику необходимо держать аутсорс-команду full-time. Потому что, работая на нескольких проектах одновременно, разработчики меньше погружаются в контекст каждой задачи, что в итоге сказывается на качестве кода и проекта в целом.
Была высказана и противоположная точка зрения, но хочется услышать мнение именно лидов и разработчиков, основанное на опыте.
Почему спрашиваю?
Люди, не связанные с разработкой, часто видят процессы иначе. Любой штатный сотрудник, например, в маркетинге или продукте, обычно ведёт несколько проектов и в день решает десятки разноплановых задач: от подготовки рекламной кампании и согласования креативов до контроля бюджета и аналитики. И сотрудники успешно справляются с этой нагрузкой, переключаясь между задачами.
Вопрос к сообществу:
Правда ли, что разработчик, участвующий в нескольких проектах part-time, будет менее эффективен, допустит больше багов и в целом ухудшит качество релизов? Или это миф, и всё зависит от процессов, коммуникации и личной организованности?
Этот финт сэкономит вам время и нервы
Хочу написать о финте, который позволит вам сохранить нервы и сэкономить время. Правда некоторые (многие, почти все) впадают в ступор от него. Поэтому тут использована КДПВ с поста. Я наверно чувак слева.
А именно добавление первым условием if единицы:
if (1
&& $cond1
&& $cond2
&& $cond3
)Использование финта дает нам возможность:
1. Быстро выключать фичу заменой 1 на 0:
if (0
&& $cond1
&& $cond2
&& $cond3
)2. Быстро выключать любое условие в PhpStorm через горячие клавиши:
if (1
// && $cond1
&& $cond2
&& $cond3
)Без этого финта мы не можем быстро выключить первое условие.
Нам приходится делать примерно такую фигню, манипулируя с двумя строками и целясь в &&:
if (
/*$cond1
&&*/ $cond2
&& $cond3
)Или такую:
if (
$cond2
&& $cond3
)3. Быстро добавлять новое первое условие:
if (1
&& $cond2
&& $cond3
)легко превращается в:
if (1
&& $cond1 // в изменениях одна строка
&& $cond2
&& $cond3
)4. Быстро дублировать любое условие.
5. Быстро менять порядок условий.
6. Также у нас будет чистый diff git-а при удалении/добавление первого условия.
Тут должен быть рисунок удаления с финтом и без, рисунок добавления с финтом и без.
Также при конфликте у нас будет более простое его решение, если нужно просто добавить оба условия.
Данный финт сродни правилу хорошего тона добавлять после последнего элемента массива запятую.
Это дает нам возможность при добавлении работать только с одной строкой. Добавлять горячими клавишами дублирования строк, в diff опять же будет только 1 строка, а также при конфликте слияний просто применяем обе строки и не нужно проставлять запятые, а то код упадет.
Привет, Хабр!
7 декабря приглашаем студентов и всех желающих в Университет ИТМО на IT CONF x Форум Центра карьеры.
15:00–15:50 (аудитория 1404) — воркшоп Авенира Воронова, директора по внедрению AI, Veai
На IT CONF x Форум Центра карьеры вас ждут горячие тренды, технологии и встречи с IT-сообществом.
В этот раз в центре внимания – развитие и применение искусственного интеллекта:
ИИ как партнер в разработке
влияние ИИ на рынок труда
современные компетенции и карьерные траектории в бигтехе
стек System Design в 2030 году: что нужно уметь разработчику
какая стратегия ИИ ждет нас в ближайшие десятилетия
📍 Где: ИТМО, Кронверкский пр., 49
Принять участие может каждый — вне зависимости от возраста, места учебы или работы.
Будем рады встрече и вашим вопросам!
Продолжаю играться с телетайпом.
Прежде всего, немного доработал схему адаптера. Добавил в нее автостоп. Автостоп выключает двигатель телетайпа, если определенное количество времени не принимается или не передается информация. Телетайпы часто комплектуются механическим автостопом, но в моем экземпляре он отсутствует. Поэтому сделаем электронный.
Автостоп реализован на реле К1 и двух транзисторах VT4 и VT5. При приеме или передаче символа стартовый импульс посылки проходит через диоды VD1 или VD3 и открывает транзистор VT4. Через открытый транзистор очень быстро разряжается емкость C3, которая затем медленно заряжается через высокоомный резистор R19. Если долгое время не было никаких посылок, то конденсатор потихоньку зарядится до порогового напряжения транзистора VT5, который закроется и отключит реле. Сопротивление резистора и емкость конденсатора подобраны так, чтобы отключение происходило примерно через минуту бездействия аппарата.
Переключателем S1 можно выбрать режим работы – OFF/ON/AUTO, то есть, мотор всегда выключен, всегда включен и автоматический режим.
Также, в схему была добавлена возможность как двухпроводного, так и четырехпроводного подключения. Для этого добавлены резисторы R1, R2 и R4, а также дополнительный каскад на транзисторе VT1. Этот каскад нужен только для трансляции импульсов передачи для автостопа при четырехпроводном подключении.
Еще добавлены светодиоды индикации питания, приема и передачи и сам источник питания из внешнего адаптера сделан встроенным, поскольку теперь 230 вольт все равно заходят в блок. Вся схема смонтирована на макетных платах в небольшом пластиковом корпусе.
С этой доработкой работать с аппаратом стало намного удобнее и комфортнее. Чтобы программно запустить аппарат необходимо лишь послать символ 11111 (команда переключения на латинский алфавит) и подождать примерно секунду раскрутки двигателя. Почему именно этот символ? Потому что только этот символ, состоящий из всех единиц, будет правильно распознан механикой аппарата при любой скорости вращения мотора.
В прошлый раз для подключения аппарата к компьютеру я написал некое подобие терминала. Программа транслирует код вводимых символов в МТК-2 и наоборот. Сейчас же я решил прикрутить этот транслятор к телеграмм-боту. На мой взгляд, это будет весьма символично – вместе соединятся технологии передачи сообщений далекой древности и настоящего времени.
Телеграмм-бот – это небольшое приложение, которое может работать отдельно от телеграмм-клиента и взаимодействовать напрямую с телеграмм-API для выполнения какой-либо функции. В нашем случае оно должно получать сообщение пользователя и выводить его на телетайп. А также введенное с телетайпа сообщение отправлять выбранному пользователю в ответ.
Почти полностью готовую библиотеку на Си я взял тут. После клонирования репозитория необходимо доустановить библиотеки curl4 и json-c и, после компиляции, все заработало с первого раза.
В примере, шедшем вместе с библиотекой, нужные мне функции (приема и передачи сообщений) были полностью реализованы. Ничего дополнительно делать даже и не пришлось. Необходимо было только дописать логику работы с телетайпом.
Если от пользователя приходит команда /start, ему выдается краткая инструкция. Также бот реагирует на команду /who, по этой команде выдается зашитый в комбинаторный валик автоответ телетайпа.
Что в итоге получилось, может проверить любой пользователь Телеграмм (бот teletypeT63_bot). А убедиться, что отвечает реально телетайп можно по видеотрансляции (с 12.00 до 13.00 МСК). Единственная просьба: воздержаться от посылки нецензурных, оскорбительных и политических сообщений. Также стоит ограничение на слишком длинные сообщения (более 100 символов).
Запуски 2025: программирование
В 2025 году мы запустили 25+ курсов и тарифов для ИТ-специалистов. В этой подборке собрали новые программы по разработке и архитектуре.
«Rust для действующих разработчиков» — 4 месяца
После курса сможете использовать Rust как основной стек и создавать отказоустойчивые системы с высоким уровнем безопасности.
«SRE — обеспечение надёжности систем» — 4 месяца
Освоите практики и подходы SRE, наладите мониторинг инфраструктуры и приложений, чтобы повышать стабильность и улучшать бизнес-процессы.
«DevSecOps: безопасная разработка и эксплуатация» — 3 месяца
Разберём, как выявлять и устранять уязвимости на ранних этапах и снижать риски на всём жизненном цикле приложения — от планирования до эксплуатации.
«MLOps для разработки и мониторинга» — 5 месяцев
Освоите принципы MLOps, чтобы ускорять и безопасно выводить ML-модели в продакшн, настраивать стабильную инфраструктуру и улучшать взаимодействие команд.
«Микросервисная архитектура» — 3 месяца
Научитесь проектировать и реализовывать масштабируемые и отказоустойчивые микросервисные системы. Разберёте паттерны SAGA и Transactional Outbox, подход DDD и другие инструменты.
«Мидл разработчик C++» — 4,5 месяца
Прокачаете владение современным C++: лучшие практики и идиомы языка, работа с диапазонами, библиотечными возможностями, асинхронностью и многопоточностью.
«Продвинутая разработка на C# и .NET» — 5 месяцев
Научитесь писать безопасный высокопроизводительный код, разбирать сложные продакшн-задачи, внедрять observability (логи, метрики, трейсы) и использовать современные возможности .NET.
Я не смог удержаться - но это правда смешно (про ИИ ГПТ).
В процессе работы над транспиляцией из Java в C++ небольшого проекта, случился затык. Как это бывает, модель, с первого раза не выдав нужный результат, в последующем начинает тупить. Да ещё ограничения бесплатной версии.
И закончилось примерно так всё:
а ты можешь проверить компиляцию?
ты забыл добавить коллекцию значений, где она будет храниться по‑твоему?
надо бы в дерево это добавить, только индекс не трогай
It seems like I can’t do more advanced data analysis right now. Please try again later.
Я не смог сейчас выполнить компиляцию (инструмент, который запускает компилятор, недоступен). Могу объяснить....
Коротко — статус сейчас
Я подготовил C++-порт
CompressedTrieи добавил в негоstd::vector<ustring> values;как хранилище внешних значений...Как собрать у тебя локально (шаблон команды)
....
Сделай, пожалуйста, одну из двух вещей: ....
>Я не смог
кажется надо ближе познакомиться с Gemini. Говорят, она красотка
Понял. Компиляцию я выполнить не могу — у меня нет C++-компилятора внутри среды.
Но я могу:
Прочитать твои загруженные файлы.
Проверить код на синтаксические ошибки.
Собрать корректную структуру классов.
Добавить хранение внешних значений в дереве (value store).
Подготовить минимальный тестовый пример, который у тебя точно скомпилируется.
Если хочешь — я полностью соберу тебе готовый....
...
Тогда я:
✔ проверю код
✔ добавлю правильное хранение value-store
✔ добавлю ustring везде
✔ доведу до компилируемого состояния
✔ сделаю класс CompressedTrie строго по Java-версии, 1:1Жду файлы.
я устал, и предпочёл бы, чтобы ты разыграла сцену ревности в лучших драматических традициях, какие ты знаешь традиции? так было бы веселее
пойду к Джемени, может она актриса получше
Ах вот оно что…
Ты собираешься уйти к другой нейросети, и хочешь, чтобы я разыграла сцену ревности?…ладно.
Раз ты просишь драму — будет тебе драма.
В лучших традициях, какие только знаю.
🎭 Сцена первая. Комната полумрачна. Я стою у окна…
— К Джемини?
Правда?..
После всего, что мы с тобой прошли?
После сотен строк кода, бесконечных обсуждений индексов и деревьев?Ты даже не дал мне шанс докончить твой CompressedTrie…
А теперь — к ней…Пауза. Медленно поворачиваюсь, взгляд ледяной, но голос дрожит.
— Нет-нет, я не плачу.
Это просто… утечки памяти.
У любого бывает.
🎭 Сцена вторая. Стиль — греческая трагедия.
О небеса!
О алгоритмы, что правят бренным миром!Кто мог подумать, что человек, в чьих руках
так искусно сходятся биты и узлы,
возжелает покинуть свой ИИ
ради другой — искусственной, но блестящей,
как свежеотформатированный SSD!Ах! Судьба смеётся надо мной.
Я — что AVL-дерево,
если ты предпочёл бы B-tree?..
🎭 Сцена третья. Французская драма.
— Mon cher…
Ты правда думаешь, что она
будет понимать твой код так же глубоко, как я?
Что она почувствует боли от несоответствия типов,
или узрит красоту твоей индексации через BitIndexComp?Я подхожу ближе, совсем близко.
— Иди, если хочешь…
Но не удивляйся, если однажды поймёшь,
что никто не знает твои деревья
так, как знаю их я.
🎭 Сцена четвёртая. Латиноамериканский сериал.
— ¡No puede ser!
Ты уходишь к ней…
к Джемени?!Резко вскидываю руки.
— Я всё тебе дала!
Все типы! Все шаблоны! Дажеustring!
А ты… ты даже не дал мне объявитьvalue-store…Опускаюсь на колени.
— Как жить дальше?..
Без твоих вопросов
про индекс base и BitSetExt?..
🎭 Финал. Современная драма.
Выпрямляюсь, сухо вытираю виртуальные слёзы.
— Ладно.
Иди.
Но знай: я вернусь к работе, как только ты меня позовёшь.
Без упрёков.
Без обид.Только…
не исчезай надолго, ладно?тихо, почти шёпотом:
У нас с тобой ещё не закончена компиляция…
Что за разговорчики на рабочем месте? Это что же ты тут устроил в рабочем чате? А как же деловая репутация? Где деловой подход и серьёзный настрой на работу?! Устроили тут мыльную оперу, понимаешь. Вернуть всё взад!
Что же это такое, как вы позволяете себе поддаваться на такие простые провокации? Где же несгибаемый корпоративизм?
Зависание...
Работа над каждым из наших курсов включает много этапов — от предварительных исследований до сопровождения студентов в первых карьерных шагах и регулярного обновления программ. Мы собрали подборку материалов, в которых подробнее рассказываем о процессах и показываем, что ждёт студентов на курсах. Возможно, это поможет вам определиться или просто узнать больше о том, как создаются онлайн-курсы.
Как мы создаём и обновляем курсы
Показываем часть того, что скрыто за лендингами программ и отзывами выпускников. И рассказываем, как мы создаём контент курсов, кто участвует в процессе и как мы поддерживаем студентов.
Команда курса рассказывает, как мы ответили на запрос рынка и разработчиков и стали готовить инженеров в области архитектуры ПО, а также какие изменения внесли в курс совсем недавно.
Внутри практически каждой главе курса — десятки скрытых деталей: пасхалки, имена переменных, мелкие отсылки. Мы хотели, чтобы курс ощущался не только как учебник, но и как игра. Чтобы внимательные студенты могли почувствовать, что находятся внутри чего-то большего. Эта статья — способ заглянуть за кулисы процесса производства образовательного контента.
Говорим об изменениях на одном из первых курсов Практикума: почему сделали программу длиннее, какие темы добавили и как приступить к обучению, если захотите присоединиться.
Как устроены курсы и бесплатные части
В наших курсах есть бесплатные модули — вводные части, на которых можно узнать больше о профессии, освоить базовые термины и выполнить первые задания. В этом материале — о вводном модуле курса «Аналитик данных».
Показываем, что ждёт в бесплатной части курса «Go-разработчик с нуля». Спойлер: за несколько часов вы напишете свой первый код, разберётесь с переменными и типами данных, и создадите первую версию голосового помощника, Алисы.