Кто мы? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке— за прошлый год мы наняли 179 сотрудников! Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.
У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удалёнку из любой точки России.
Команда в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем гуру, кто готов в новое профессиональное будущее вместе с нами.
Что вас ждет в SSP SOFT: ✅ Рост: Центр компетенций для максимального апгрейда скиллов. ✅ Свобода геолокации: Возможность работать удаленно, гибрид или офис. ✅ Баланс work-life: Работаем, чтобы жить, а не наоборот.
🎁 Приятные бонусы: ивенты для всей команды, ДМС для штата, обучение и бенефиты.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀)
При работе с Git я почти не пользуюсь отдельными программами. В корпоративной разработке у меня под рукой есть IntelliJ с достаточно удобной панелькой Git. А для своих проектов я привык пользоваться Git CLI.
И всё же, время от времени, нужно посмотреть изменения в разрезе нескольких коммитов. Делать тучу git diff не очень удобно, особенно когда нужно дать хэш конкретного коммита.
И тут на помощь приходит Lazygit. Этот TUI позволяет удобно шастать по дереву Git стрелками. Окна в программе настраиваются, мышка поддерживается, темы оформления есть.
Можно делать stage для кусков кода, а не целых файлов. Можно делать commit, fixup, revert, amend… В общем, все (или почти все) функции Git в наличии.
Благодаря тому, что это TUI инструмент, им можно пользоваться на удалённых машинах по SSH. Очень удобно и практично.
Я подумал, что самое время, пока он не стал слишком умным и не взял все мои данные, чтобы составить обо мне мнение когда наступит господство роботов и он вспомнит все чаты когда я не написал “спасибо”.
Но прежде чем нажать Удалить все, я нажал другую кнопку, Экспорт данных
В течение часа мне на почту пришла ссылка со всеми моими данными в архиве, и вот что внутри:
Аудио, все записи диалогов мои с ЧатомГПТ, в формате wav, по папкам, сначала мой вопрос в wav, потом его ответ в wav
Фото/Изображение, просто в корневой папке около 1000 изображений
Изображения, которые чатГПТ сгенерирован для меня, в отдельной папке
Системные файлы, где содержится моя почта, год рождения, телефон, id в системе
Отдельный файл shopping, если бы я что-то покупал через новую функциональность оператора, это было бы тоже там
Отдельный файл диалоги которые поделился, в отдельном файле
Отдельный файл информация о групповых чатах
Отдельный файл всех диалогов в формате conversations.json 320 мб текста
Отдельный файл всех диалогов в формате .html 320 мб текста
Конечно открыть файл html такого размера может только человек без СДВГ.
В итоге я открыл эту папку в Gemini CLI (в последнее время мне нравится он) / можно использовать Claude Code
и попросил создать мне отдельную папку Sorted, где он распарсит все в “.md” файлы и разложит по папкам диалога, а Projects, которые были с инструкциями положить отдельно в Projects (у меня это типа Work, Money, Health и тд.)
я не использовал никакой специальный промпт, просто по английски по просил это сделать
Here is an extracted folder from ChatGPT. Is it possible to generate .md files for all extracted chats and organize them into topic-based folders, with everything placed under a main Sorted directory? Some chats may contain information related to specific projects, with or without explicit instructions. If so, can we create separate sections for these projects inside the Sorted folder. Additionally, let’s try to identify project instructions by searching for the following marker: ТУТ МОЯ ИНСТРУКЦИЯ КАК ПРИМЕР
В итоге у меня теперь локальная копия всех диалогов из ChatGPT
далее я положу все по папочкам и темам в Obsidian, пока что буду лазить по ним и продолжать общение с помощью Gemini CLI, но как только локальные модели станут более умные и менее прожорливые возможно перейду на офлайн (статья об этом на хабре)
Теперь когда у меня есть все мои .md которые очень хорошо обрабатываются любой LLM (AI моделью), можно менять Gemini, Claude, ChatGPT и новые другие тд как перчатки, не теряя все свои диалоги и контекст или перейти в свой приватный офлайн
Павел Варнавский, руководитель группы разработки «ДАР» (Корус Консалтинг), рассказал, как их команда использует BI Magic в своих проектах для создания мощных аналитических решений.
Как внедрять CI/CD для дэшбордов и масштабировать решения под конкретные процессы, там, где стандартных «коробочных» решений не хватает
Два практических кейса, где кастомная разработка на Luxms BI решила нетипичные задачи
Будет интересно всем, кто работает с нестандартной аналитикой, сложными требованиями бизнеса и хочет понимать, как кастомная BI-разработка может быть управляемой и удобной
На неделе вспомнил про wchar_t в Си, пока в очередной раз работал с Unicode, но в Windows. Штука… Неоднозначная.
Часть WinAPI жёстко завязана на WCHAR (wchar_t). Но в Windows он до сих пор определён размером в 16 бит. Тот же GCC на Debian мне говорит, что у него wchar_t — все 32 бита.
Т.е. перевод строки из char в wchar_t генерирует валидный UTF-16 в Windows, но UTF-32 в Linux…
Кажется, char32_t должен решить эту чехарду в будущем… Хотя бы с точки зрения размерности… Пусть это и не исправит проблемы WinAPI…
Но действительно ли так часто нужно работать с полноценным code point в Unicode? Зачем? Только чтобы посчитать общее количество символов? Это же просто сделать и на основе char!
Авторы UTF-8 Everywhere дают развёрнутый ответ на этот и многие другие вопросы. Идея хорошо проработана, есть даже прекрасный FAQ для любопытных.
На этой веб-странице собрали самые веские доводы для использования исключительно UTF-8. Везде. Всегда.
Ответьте мне на один простой вопрос: зачем в наше время вообще нужны HR?
Ни для кого не секрет, что найм сегодня сломан. Бесконечные этапы собеседований, которые якобы должны отсекать «вкатунов в IT», по факту отсеивают и нормальных разработчиков.
Причём даже в эффективности этого «фильтра» есть серьёзные сомнения: по сети уже гуляют AI-оверлеи, которые в реальном времени анализируют вопросы интервьюеров и подсказывают ответы. Так о каком объективном отборе вообще идёт речь?
При этом у HR — бесконечный поток, условно говоря, «подопытных кроликов», на которых можно тестировать гипотезы, улучшать процессы и действительно чинить найм. Но вместо этого они просто копируют чужие, далеко не самые успешные практики.
Почему HR не выполняют своё прямое предназначение, а действуют по шаблону?
И главный вопрос: каким образом лайв-кодинг должен подтверждать или опровергать мои навыки, если:
могут дать абсолютно любую задачу и в штатном порядке, я залезу гуглить документацию, а на собесе я это сделать не могу?
Легендарное письмо Эдсгера Дейкстры обсуждалось учёными и программистами довольно долго. Даже сейчас встречаются разные взгляды на присутствие GOTO в программе.
Краткое содержание (парафразирую): GOTO нарушает простую навигацию по коду и, самое главное, возможность сопоставить код с тем, что мы имеем как состояние процесса в определённый момент времени.
Сам Дейкстра пишет, что ничего нового не говорит, о том же уже выступали Тони Хоар, Никлаус Вирт и ряд других учёных.
Дейкста и его коллеги в 1970-х дадут старт “структурному программированию”. В основу ляжет теорема Бёма-Якопини.
Оригинал статьи есть в свободном доступе библиотеки ACM.
Что интересно, этот вариант вырезки содержит и другие письма от 1968 года в редакцию журнала ACM.
К примеру, одно из них про то, что ЯП и их среды не должны быть защищены торговыми марками. Другое про дихотомию килобайты-кибибайты. Ещё одно про необходимость включения пост-мортем дампов (stacktrace или coredump) как обязательную часть высокоуровневых ЯП…
Иногда кажется, что мы застряли в каком-то странном лимбо, где всё уже было придумано или обдумано за нас. Нам же надо только иногда почитывать работы прошлого…
При написании интеграционных тестов для Spring Boot приложения часто возникает проблема, что разработчики бездумно добавляют аннотации @MockBean, @SpyBean, @DirtiesContext или переопределяют прямо в тестовом классе различные property. Всё это приводит к изменению Spring Context, невозможности использовать закэшированный контекст и следовательно созданию нового. Часто создание нового контекста это длительная операция.
Существуют инструменты по отслеживанию этих процессов. Самым простым способом увидеть количество контекстов и количество попаданий в кэш является добавление логирования либо через свойство logging.level.org.springframework.test.context.cache=DEBUG либо настройкой вашего логгера.
Один известный автор статей про тестирование на Java / Spring Boot, Philip Riecks (со товарищи), создал инструмент с открытым исходным кодом Spring Test Profiler при помощи которого можно получить html отчёт о поднимаемых контекстах во время тестов, о количестве и типе бинов в этих контекстах. На Хабре есть перевод его статьи в сообществе Spring АйО.
У нас на проекте стал вопрос, как нам показать разработчикам, что их тест порождает новый Спринг Контекст. Мы решили считать контексты в тестах и при превышении ожидаемого количества падать. Это "руинит" сборку и CI/CD пайплайн. Для этого мы добавили реализацию интерфейса ContextCustomizer
class LimitingSpringContextCustomizer implements ContextCustomizer {
private static final AtomicInteger CONTEXT_COUNTER = new AtomicInteger();
private static final int EXPECTED_SPRING_TEST_CONTEXT_COUNT = 16;
@Override
public void customizeContext(ConfigurableApplicationContext context, MergedContextConfiguration mergedConfig) {
int numberOfContexts = CONTEXT_COUNTER.incrementAndGet();
log.info("Number of Spring Test Contexts: {}/{}", numberOfContexts, EXPECTED_SPRING_TEST_CONTEXT_COUNT);
Assert.state(numberOfContexts <= EXPECTED_SPRING_TEST_CONTEXT_COUNT,
() -> "Number of test contexts exceeds configured maximum: " + EXPECTED_SPRING_TEST_CONTEXT_COUNT);
}
@Override
public boolean equals(Object obj) {
return (obj != null) && (getClass() == obj.getClass());
}
@Override
public int hashCode() {
return getClass().hashCode();
}
}
Здесь, согласно документации интерфейса ContextCustomizer необходимо корректно переопределить методы equals и hashCode.
WARNING: implementations must implement correct equals and hashCode methods since customizers form part of the MergedContextConfiguration which is used as a cache key.
Далее добавляем фабрику.
class LimitingSpringContextCustomizerFactory implements ContextCustomizerFactory {
@Override
public ContextCustomizer createContextCustomizer(Class<?> testClass,
List<ContextConfigurationAttributes> configAttributes) {
return new LimitingSpringContextCustomizer();
}
}
Затем регистрируем эту фабрику при помощи spring.factories чтобы она применялась ко всем тестам. Для этого создаём в тестовых ресурсах файл по пути src/test/resources/META-INF/spring.factories со следующим содержимым
Теперь, если во время выполнения тестов будет превышено количество инициализированных тестовых контекстов, то мы увидим ошибку в тестах и сборка завершится неудачей.
Возможно, это пример поможет кому-нибудь повысить скорость прохождения своих тестов путём отслеживания количества запускаемых тестовых Спринг контекстов.
Сама идея мелькает в НФ-литературе уже не первый год. То, что я могу вспомнить сейчас, - это Вернор Виндж, «Глубина в небе». В этой книге люди, чей мозг был искусственно изменён для решения узких задач (в книге так делали очень плохие люди), вырабатывали свой, никому не понятный язык, специфичный задаче.
В теории, если делаю какую-то большую систему с помощью ИИ-агентов будущего, в каком-то 2035 году, - можно предположить, что сначала ИИ-агент разработает доменно-специфический язык для конкретной задачи, конкретной платформы и т.п. Просто один специальный язык для ИИ-агентов не имеет смысла. Раз уж у нас есть «мозг», который может писать много кода, - пусть он делает язык под задачу. В чём смысл иметь всего один язык?
В целом, в каком-то смысле, какие-то «нечеловеческие» языки уже есть - это разного рода P-код, байткод и т.д. Такое промежуточное звено между машинным кодом и языком, на котором пишет программы человек. Они, конечно, создавались для другого, но вот вопрос - а для чего именно должен быть создан ИИ-язык? См. пункт ниже.
Следующее соображение - если вернуться из великолепного (или не очень, если судить по трендам) 2035-го года в год 2026, то один из важнейших факторов успешности кодирования с помощью ИИ-агентов - это способность человека читать сгенерированный код и исправлять накосяченное. Ну вот ни разу не похоже, что тот код, который ИИ генерирует, можно пускать в продакшн без ревью и правок. Оговорюсь - для сколько-нибудь сложных / больших приложений.
Из этого автоматически следуют следующие качества используемого языка:
Легко читаем человеком, простые вещи делаются просто.
Мало или вообще нет неочевидных сайд-эффектов.
Распространённые вещи, такие как работа с БД или JWT-авторизация запросов, делаются при помощи библиотеки / фреймворка, а не «с нуля».
Из этих пунктов мы легко получаем на выходе тройку языков: Java / C# / TypeScript с фреймворками Spring Boot / NestJS / ASP.NET Core.
Драйвером развития всех трёх были именно пункты выше: легко читается, простые вещи делаются просто, минимизация неочевидных эффектов.
Да, все три не идеальны, но это лучшее, что у нас есть в этой области. Сможет ли ИИ придумать лучше? Точнее - люди для ИИ. В теории - да, но это десятки лет работы. Быстро не получится.
И последнее. ИИ не пишет код «сам», он по факту подбирает похожие кусочки из той базы, на которой он был обучен. Т.е. чтобы ИИ начал писать сколько-то адекватный код на каком-либо языке, ему нужно «скормить» миллионы (скорее всего - много больше) строк кода на этом языке, и писать этот код должен не ИИ.
На самом деле, даже живые программисты обучаются так же. Когда ты берёшь в руки книгу по совершенно незнакомому тебе языку, то первая реакция - «блин, как на этом код-то писать», потом ты начинаешь писать небольшие кусочки, понимаешь, что получается плохо, правишь, смотришь на чужой код, говоришь себе «Ага! Вот как надо!» - и как-то так понемногу двигаешься вперёд.
Подводя итог. В целом, идея специального языка витает в воздухе не первый десяток лет.
Скорее всего, это будут специальные языки под задачу.
Мы пока не там. ИИ-агенты, с одной стороны, заметно ускоряют разработку, но с другой стороны - программирование с помощью ИИ-агентов это гонка на костылях от ямы к яме. Требует очень высокого внимания и навыка со стороны человека.
В текущей ИИ-индустрии всё крутится вокруг обучения, и если нет хорошего датасета для обучения, то результат будет очень грустным. Какие-то опыты по самообучению ведутся, но мы пока не там. Например, Google сделал бота для игры в StarCraft, который обыгрывает большинство противников. Но бот изначально обучался на записях игр реальных людей и делает безумное количество бессмысленных вещей. Где взять датасет для обучения программированию на специальном ИИ-языке - непонятно.
Попалась на глаза картинка. Интересная идея, я так или иначе кручу её в голове уже не первый месяц. Несколько соображений на этот счёт.
Сама идея мелькает в НФ-литературе уже не первый год. То, что я могу вспомнить сейчас, - это Вернор Виндж, «Глубина в небе». В этой книге люди, чей мозг был искусственно изменён для решения узких задач (в книге так делали очень плохие люди), вырабатывали свой, никому не понятный язык, специфичный задаче.
В теории, если делаю какую-то большую систему с помощью ИИ-агентов будущего, в каком-то 2035 году, - можно предположить, что сначала ИИ-агент разработает доменно-специфический язык для конкретной задачи, конкретной платформы и т.п. Просто один специальный язык для ИИ-агентов не имеет смысла. Раз уж у нас есть «мозг», который может писать много кода, - пусть он делает язык под задачу. В чём смысл иметь всего один язык?
В целом, в каком-то смысле, какие-то «нечеловеческие» языки уже есть - это разного рода P-код, байткод и т.д. Такое промежуточное звено между машинным кодом и языком, на котором пишет программы человек. Они, конечно, создавались для другого, но вот вопрос - а для чего именно должен быть создан ИИ-язык? См. пункт ниже.
Следующее соображение - если вернуться из великолепного (или не очень, если судить по трендам) 2035-го года в год 2026, то один из важнейших факторов успешности кодирования с помощью ИИ-агентов - это способность человека читать сгенерированный код и исправлять накосяченное. Ну вот ни разу не похоже, что тот код, который ИИ генерирует, можно пускать в продакшн без ревью и правок. Оговорюсь - для сколько-нибудь сложных / больших приложений.
Из этого автоматически следуют следующие качества используемого языка:
Легко читаем человеком, простые вещи делаются просто.
Мало или вообще нет неочевидных сайд-эффектов.
Распространённые вещи, такие как работа с БД или JWT-авторизация запросов, делаются при помощи библиотеки / фреймворка, а не «с нуля».
Из этих пунктов мы легко получаем на выходе тройку языков: Java / C# / TypeScript с фреймворками Spring Boot / NestJS / ASP.NET Core.
Драйвером развития всех трёх были именно пункты выше: легко читается, простые вещи делаются просто, минимизация неочевидных эффектов.
Да, все три не идеальны, но это лучшее, что у нас есть в этой области. Сможет ли ИИ придумать лучше? Точнее - люди для ИИ. В теории - да, но это десятки лет работы. Быстро не получится.
И последнее. ИИ не пишет код «сам», он по факту подбирает похожие кусочки из той базы, на которой он был обучен. Т.е. чтобы ИИ начал писать сколько-то адекватный код на каком-либо языке, ему нужно «скормить» миллионы (скорее всего - много больше) строк кода на этом языке, и писать этот код должен не ИИ.
На самом деле, даже живые программисты обучаются так же. Когда ты берёшь в руки книгу по совершенно незнакомому тебе языку, то первая реакция - «блин, как на этом код-то писать», потом ты начинаешь писать небольшие кусочки, понимаешь, что получается плохо, правишь, смотришь на чужой код, говоришь себе «Ага! Вот как надо!» - и как-то так понемногу двигаешься вперёд.
Подводя итог. В целом, идея специального языка витает в воздухе не первый десяток лет.
Скорее всего, это будут специальные языки под задачу.
Мы пока не там. ИИ-агенты, с одной стороны, заметно ускоряют разработку, но с другой стороны - программирование с помощью ИИ-агентов это гонка на костылях от ямы к яме. Требует очень высокого внимания и навыка со стороны человека.
В текущей ИИ-индустрии всё крутится вокруг обучения, и если нет хорошего датасета для обучения, то результат будет очень грустным. Какие-то опыты по самообучению ведутся, но мы пока не там. Например, Google сделал бота для игры в StarCraft, который обыгрывает большинство противников. Но бот изначально обучался на записях игр реальных людей и делает безумное количество бессмысленных вещей. Где взять датасет для обучения программированию на специальном ИИ-языке - непонятно.
Подборка инструкций по Python для начинающих специалистов
Привет, Хабр! Вот и наступила пятница, а значит, пришло время очередной подборки материалов для тех, кто решился взяться за изучение Python. Сегодня у нас несколько базовых инструкций, бесплатный курс и небольшой квиз.
Как работать с PostgreSQL в Python. Эта статья-шпаргалка научит работать с модулем psycopg2, чтобы немного упростить себе жизнь при администрировании PostgreSQL.
Как создать голосового помощника на Python. С помощью простых инструментов и библиотек разработаем голосового помощника на Python, сделав его полезным и удобным в повседневной жизни.
Изучаем Python: теория, практика, настройка инструментов. Да, это подборка в подборке. Внутри несколько материалов, все доступно бесплатно. Для тех, кто хочет научиться не только писать код, но и запускать его в облаке, внутри курса спрятан промо-код на услуги Selectel.
Эпоха расцвета больших языковых моделей (БЯМ) резко усложнила проверку знаний соискателей. Удалёнщики при прохождении собеседований часто читерят и копируют вопросы в ChatGPT или любой другой мощный чат-бот.
Своим простым методом отсева слабых кандидатов поделился Хосе Сарасуа́, бывший CTO компании MonetizeMore. На собственном сайте Хосе рекомендует себя как профессионала от мира найма, через которого прошли 50 тыс. соискателей, и предлагает услуги консультанта.
Сарасуа выложил следующую задачку, которая якобы отсеивает половину неквалифицированных кандидатов. Такую задачку он включал в форму отклика на вакансию.
Какое значение примет result? Задачка на выбор варианта, их четыре: 1, 0, −11, −10. Правильный — 1, но если соискатель пользовался ИИ, он выберет −11.
Суть приёма передать скриншотом невозможно. Дело в том, что в статье в блоге Сарасуа в проверке x > 3 есть знак равенства, скрытый с помощью <span aria-hidden="true" style="font-size: 0px; opacity: 0; user-select: text;">. Для глаза человека будет знак >, «больше», а если выделить и скопировать, то в буфере обмена на этом месте останется =>, «больше или равно».
Замысел в том, что человек даже с минимальным опытом не будет ничего куда копировать и решит всё в уме, а вот живущий в режиме копипейста не пройдёт этот базовый скрининг.
Как утверждает Хосе, эти ухищрения с CSS очень эффективны. Этот приём он применял при работе в MonetizeMore, и 50 % кандидатов выбирали вариант как от БЯМ. Из оставшихся: 47 % отвечали правильно, 3 % выбирали один из двух других неправильных вариантов.
Важно, что сам Хосе предупреждает: ставить крест на людях не нужно. Некоторые поначалу демонстрировали использование ИИ, но затем, без уведомления от компании, самостоятельно повторно заполняли форму отклика и с правильным ответом. Один из таких соискателей в итоге прошёл все этапы и оказался отличным сотрудником.
На самом деле для таких уловок не нужен даже кастомный код CSS. Хосе — канадец мексиканского происхождения, поэтому он наверняка не слышал про похожесть кириллической х и английской x. Впрочем, в случае мешанины из схожих символов БЯМ может обратить внимание на неладное и разразиться замечанием.
Наконец, такая ловушка точно не сработает против Interview Coder и Cheating Daddy: эти инструменты для мошенничества на собесах снимают скриншоты экрана и отправляют в мультимодальные языковые модели, а не копируют текст из браузера. И вообще, что если соискатель слабовидящий, и текст на веб-странице зачитывается вслух его операционной системой?
Никто так говорить, кроме менеджеров, не любит. А я вдруг внезапно полюбил такой подход в работе. Стал бить себя по рукам и делать дешево.
Оказывается, мозгу легче уйти в кроличью нору, чем просто делать задачу. Через час потной работы начинаешь зарываться в тонны документации, смотреть примеры кода на форумах или в репах на работе, переписывать свои модули по десять раз. Ощущение, будто стек собираешь, и он никак не схлопнется. Это обычная прокрастинация через усложнение.
MVP-подход тут мне стал очень помогать на моем, локальном уровне. Суть очень простая: делаю минимум и быстро. А потом добавляю на кости мяса. Надо сделать сохранение строк файла в БД? Пока сделаю построчно и поставлю # TODO. Потом сделаю батчем. Нужна отправка сотен объектов из БД в API? Пока тоже построчно. Нужна еще одна очередь Redis для этапа в обработке файла — потом. Пока и с одной очередью и воркером справимся.
MVP-подход требует некоей выдержки, особенно на пет-проектах. Код пишешь ты сам с собой. Выступаешь внутренним критиком и, зачастую, самым строгим. Но делать все дешево и сердито стало помогать мне лично держать фокус на цели: дать максимум ценности за минимум усилий. И при этом не сгореть от объема, быть в тонусе.
Риски, конечно тоже есть. У TODO нет хозяев, кроме нас. Дешевое Г становится иногда продом. Техдолг это вообще бесконечная тема и, пожалуй, не для этого поста. Пост про эффективность.
MVP-промтинг работает и с нейронками таким же образом. Берем чистый контекст, делаем простой прототип. А дальше по кускам его обтесываем, заменяем, улучшаем. Может, у нас есть с ними что-то общее?
У каждого человека есть свое определение голого минимума. Поэтому примеры выше могут кому-то показаться тривиальными. Очевидно, и сам подход не для всех. Но мне лично он развязал немного руки и помог выдохнуть на одной из недавних душных задач. Может быть такой ход мысли поможет и вам.
Райан Даль, создатель Node.js, одной из ключевых технологий современного веба: времена, когда код писали люди, всё.
Даль сформулировал свою позицию в посте в X: «Это говорили уже тысячу раз, но я тоже вставлю слово: времена, когда код писали люди, закончилась. Это тревожно для тех из нас, кто называет себя инженерами ПО, но от этого не менее верно. Это не значит, что у инженеров больше не будет работы, но про написание синтаксиса напрямую она больше не будет».
Конечно, говоря про Clean Architecture, нельзя обойти стороной книгу Роберта Мартина “Чистая Архитектура”.
Это замечательная книга. В ней можно найти большое количество исторического контекста, с помощью которого Мартин наглядно демонстрирует необходимость введения новых абстракций.
Но не менее полезной можно считать дистиллированную версию в блоге Clean Coder. Автор заметки — тот же Роберт Мартин. Если Вы не знакомы с Clean Architecture, то статья станет хорошей отправной точкой.
Он смог показать, как именно можно применить очевидные инфраструктурные практики типа сервисной шины в контексте доменных событий.
Да, на сегодняшний день имплементация инфраструктуры для доменных событий может выглядеть совсем иначе. Но ознакомление с 3-я заметками Дахана крайне важно для понимания исторического контекста.
"У меня друг/брат/сват/муж/жена/собака хочет в тестирование! где почитать?!"
TostersSchool
Несколько лет назад мы с коллегами заметили закономерность: раз в неделю кто-то спрашивает "с чего начать изучение тестирования?". Вопрос один и тот же. Ответы одни и те же. Ссылки одни и те же.
В какой-то момент стало понятно: логичнее собрать всё в одном месте и отправлять туда, чем каждый раз писать простыню заново. Так появился сначала чат в Telegram, а потом и канал TostersSchool.
Никакой монетизации. Никаких платных курсов в конце воронки. Просто практикующие специалисты, которым захотелось поделиться опытом. Записывали ролики по вечерам, монтировали по выходным, выкладывали когда получалось.
Честно скажу: последний год всё как-то притихло. Базовые темы разобрали, а снимать очередной ролик про создание коллекций в Postman уже не видим смысла. Инструменты меняются быстрее, чем мы успеваем про них рассказывать.
Но материал никуда не делся. Если кому-то нужен некоммерческий контент от практиков, а не от инфобизнеса, приходите, смотрите. Надеюсь, будет полезно.
Если есть тема, которую мы не осветили, и она вам реально нужна - пишите. Только учитывайте: запись и монтаж видео съедают много времени и сил. Мы стали бережнее относиться к своему ресурсу и откликаемся не на всё. Но если тема важная и интересная - почему бы и нет.
В общем, если вас спросят "где посмотреть что-то про тестирование для начинающих" - можете кинуть ссылку: TostersSchool
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 install claude-code-reflection-skills@claude-code-reflection-skills Перезапускаем Claude Code и вуаля — теперь ваш клод как после сеанса к психотерапевту, прокаченный рефлексией.
по сути же получается нужно меньше разработчиков сейчас? Интересно как это выглядит с точки зрения владельца бизнеса
Регулярно стал видеть подобные вопросы. Если растет производительность, то логично, что надо сокращаться? Если речь идет про избыточную разработку и цель оставаться на том же уровне производительности, то да, избыточность можно уменьшить. Но реальность и капитализм работают чуть сложнее.
Регулярно стал видеть подобные вопросы. Если растет производительность, то логично, что надо сокращаться? Если речь идет про избыточную разработку и цель оставаться на том же уровне производительности, то да, избыточность можно уменьшить. Но реальность и капитализм работают чуть сложнее.
Начнем с избыточности. Одно дело когда у вас команда из 50 человек, где есть и фронты и бекендеры и девопсы и бог знает кто еще. Другое, когда вся команда это три человека с очень разными компетенциями. Если в команде один бекендер, то его никем не заменить. Тоже самое касается и большинства остальных ролей. Всегда нужен человек, который отвечает за свой блок и разбирается в нем лучше всех (или в принципе только он и разбирается). Такому человеку ИИ конечно помогает, но убрать его с помощью ИИ невозможно, как бы красиво это не звучало и не выглядело (посмотрите как я сгенерил лендинг с помощью ии!).
Но даже одного человека мало, потому что на больших объемах один человек всегда будет занят большую часть времени текучкой. Тут надо обсудить, там что-то сломалось надо починить, тут разобраться. В общем в живых проектах с пользователями и инфраструктурой, даже увеличение производительности не даст возможность освободить одного настолько сильно, что он сможет легко фигачить новый функционал. У нас вон вчера зависла транзакция в базе на проде (это вообще похоже на баг в постгре). Пол дня потеряно на выяснение, восстановление, эксперименты и переконфигурацию.
И самое важное, в случае с ИИ это преимущество почти всегда временное. Мы не единственные, кто повышает производительность: инструменты доступны всем, и эффект быстро размазывается по рынку. Как только ситуация выравнивается, конкуренция начинает давить на цены или, наоборот, заставляет больше тратить: на зарплаты, инфраструктуру, вычисления, закупки. В итоге повышенная производительность перестает быть конкурентным преимуществом и становится новой нормой. А чтобы вырваться вперед, снова нужно делать больше: выходить в рост, расширяться, брать на себя больший масштаб при том, что производительность у всех выросла примерно одинаково.
Что не отменяет большого числа новых возможностей. Сейчас самое благодатное время для старта новых проектов и заработка. Новым предпринимателям сложнее понять что не делать, чем что делать.
