MCP — это язык, на котором AI учится общаться с инструментами. Но если дать ему слишком много «слов», получится хаос. В статье можно узнать, почему MCP нужно курировать, где начинаются риски безопасности и как этот протокол помогает сделать взаимодействие с AI осмысленным и надёжным.
Всё началось с желания автономно заниматься исследованиями в области искусственного интеллекта и запускать свои эксперименты без ограничений облачных сервисов или недостаточных ресурсов рабочих кластеров. Наука и исследования давно стали для меня не только профессией, но и хобби: запускать эксперименты, сравнивать модели, тестировать свежие идеи - всё это требует собственной инфраструктуры. Именно поэтому я решил собрать домашний GPU‑сервер «под себя» для полноценного AI‑ресёрча
При разработке автотестов нередко приходится сталкиваться проверками POJO, которые могут вернуться в ответах от API или быть сущностями в базе данных. Если вы также используете библиотеку Hamcrest, то наверняка сталкивались с проблемой, как лучше и оптимально использовать мэтчеры с POJO? Посмотрим, что предлагает Hamcrest из коробки, и познакомимся с тремя библиотеками, которые используют разные подходы.
🌀 Конкурентность в Go: горутины и каналы — просто о сложном
Go изначально создавался для высоконагруженных и сетевых систем, где параллелизм и конкурентность — ключевые факторы производительности. Его философия проста: «не делись памятью для общения, общайся, чтобы делиться памятью».
В статье разберём:
✅ Что такое горутины и как Go управляет миллионами их одновременно.
✅ Как работают каналы и зачем они нужны для безопасного обмена данными.
✅ Как планировщик Go (GMP-модель) распределяет нагрузку между потоками.
✅ Типичные ошибки: deadlock, race condition, блокировки и как их избегать.
✅ Практические примеры — от простых пайплайнов до паттернов Fan-in/Fan-out.
Небольшой ориентир для начинающих программистов.
Если ты только делаешь первые шаги в backend-разработке — этот материал поможет сориентироваться, сэкономить время и прийти к делу с правильным настроем.
Алгоритм двухфазной блокировки (Two-Phase Locking, 2PL) — один из старейших механизмов управления параллелизмом, используемых реляционными СУБД для обеспечения целостности данных. В этой статье я расскажу, как работает алгоритм 2PL и как его можно реализовать на любом языке программирования.
Как перестать тащить всё на силе воли и начать делать важные вещи с такой же лёгкостью, как играть в компьютерные игры?
Стопроцентный способ облажаться в любом начинании — это делать через не хочу и никак иначе.
Всем наверняка попадались эти видосы:
Парень с покерфейсом выключает будильник — на экране айфона 4 утра.
Потом идёт в душ с холодной водой и на следующем кадре одинокий волк вышел на пробежку в пустой парк.
И, как мы слышим, фоном ко всему этому играет затасканная музыка из рилсов.
Всем привет! Меня зовут Леонид, я разработчик компании DD Planet.
Как мы все прекрасно понимаем, ни один бизнес‑проект немыслим без разного рода отчетов. Быстрота и удобство их создания зачастую критично важны.
В нашей компании мы долгое время использовали инструмент DevExpress Reports. Однако после ухода DX с отечественного рынка остро встал вопрос о пересмотре архитектуры формирования отчетов — особенно тех, что создавались с помощью визуального дизайнера форм.
Раньше, при использовании компонентов DevExpress, такие отчеты можно было создать в несколько кликов и практически без знания кода — за счет мощного и удобного дизайнера:
Тем кто собирает что-то под windows и задумался о версионировании сборочного окружения.
Как ведь бывает, прилетает баг, нужно пересобрать старый релиз, а сборочный агент уже с другим окружением. И даже если вы каким-то образом сохраните нужное окружение, как защитить от его от самих сборок? Делать снапшоты, откатываться, или разворачивать агенты с некого золотого образа и прочее.
Версии окружения поднимаются, само окружение усложняется, требование команд к окружению растут и расходятся. Как тут всем угодить?
Исторически так сложилось, что в linux docker заехал как родной, а вот в windows вроде бы есть, но про него не слышно, на Хабре так уж точно. Поэтому если вы решили это попробовать, то эта статья для вас.
огда человек слышит новое предложение — купить продукт, подписаться на услугу, внедрить решение — его мозг почти всегда реагирует одинаково: торможением.
Это не лень и не недоверие. Это защитный механизм.
Все больше ребят говорят о том, что сейчас на рынке труда в тестировании непростая ситуация. Давайте попробуем разобраться в чем дело и как с этим жить.
Возникало ли у вас когда-нибудь желание посмотреть на свою жизнь в цифрах?
Сколько дней в году вы проводите не в одиночестве? Действительно ли вы выпиваете раз в две недели, или это уже давно самообман? Сколько часов сна вам нужно, чтобы чувствовать бодрость? И что сильнее влияет на настроение — прогулка или занятие любимым хобби?
Короче, вот что я поняла за годы работы: в крупных цифровых продуктах UX‑исследования — это уже не «было бы круто», а must‑have. Без них ты просто не выживешь в конкурентной среде. Но вот между тем, чтобы сказать «ой, исследования важны 🤓» и реально построить работающую исследовательскую функцию — пропасть. Причём пропасть, полная организационных косяков, процессных дыр и культурных вызовов.
Как превратить разрозненные исследования в системную практику, которая реально приносит ценность бизнесу? Как выстроить команду, процессы и метрики так, чтобы исследования не просто проводились для галочки, но влияли на качество продукта и счастье пользователей? Об этом и поговорим.
Это не теоретическая статья — я делюсь реальным опытом разработки стратегии исследовательской лабы в крупной продуктовой IT‑компании. Разберём ключевые элементы: от формулирования миссии до внедрения конкретных процессов и метрик.
Как систематизировать работу с техническим долгом
Техдолг растёт, пока его никто не контролирует. Мы решили это так: выделили отдельную доску в Jira, разделили процесс на Backlog → To Discuss → Ready for Development → В работе, проводим регулярный груминг, оцениваем и приоритизируем задачи, сделали быстрые фильтры и дашборд для контроля времени.
Результат: прозрачность и приоритетность задач, техдолг перестал копиться «в стол», стало проще брать задачи без хаоса, улучшилось качество кода, выросла инициативность команды.
Более 50 тысяч информационных систем на российских предприятиях ― объекты критической инфраструктуры. Объясня., что это означает.
Еще в июле 2024 года Госдума приняла в первом чтении законопроект о переходе объектов критической информационной инфраструктуры на использование российского ПО.
Выполнение требований закона влечет рост расходов компаний, в том числе операторов связи, ведь все они ― субъекты КИИ. Как соответствовать требованиям и справляться с дополнительной нагрузкой на бизнес?
Claw Engine: как студенты из НИУ ВШЭ релизнули MVP игрового движка
Всем привет! На связи Bear Head Studio, команда Claw Engine. Мы рады сообщить об открытом релизе нашего игрового движка :)
Рынок рекламы пережил свой взрывной рост в 2023-м: прибавил 30%, в 2024-м — на 24%, по итогам 2025 будет 20%, то есть рынок рекламы постепенно входит в стагнацию. Это нормально, вся экономика циклична.
Влияние оказывает и то, что рынок перестраивается – традиционные каналы рекламы, такие как СМИ, уже который год видят снижение спроса, выручают долгосрочные контракты и дружеские личные отношения собственников, деньги на рекламу уходят в соцсети, поисковые системы, мессенджеры, маркетплейсы и доски объявлений.
Интернет занимает 52% рынка, это 488 миллиардов рублей в 2024 году, но мест для размещения рекламы не хватает, а цены выросли на 15–25%.
То есть реклама там, где люди, а люди выбирают интернет-площадки. Но на них проявился перегрев – рекламы стало очень много, и потребители уже на неё не реагируют, баннерная слепота теперь проявляется явственнее, чем какая-либо реклама. Брендам приходит изощряться. Реклама перестаёт быть двигателем торговли.
Привет! Я — Лёша, принципал дизайнер, решаю бизнес-задачи с помощью дизайна уже больше 15-ти лет. Это моя первая статья из небольшой, но насыщенной серии, и она полностью посвящена дизайн-процессам и взрослому, результативному подходу к работе. Я постараюсь рассказать все очень кратко, насколько это возможно чтобы не потерять суть, но емко. Сделаю это так, чтобы все процессы стали понятны даже новичку.
Думаю большинство читателей уже знакомы с известной системой «Double diamond» (двойной ромб), разработанной Британским Советом по дизайну еще в далеком 2005-м году. Называть его в русском варианте «Двойной алмаз» некорректно. Алмаз многогранен, а суть подхода именно в двух, при необходимости бесконечно повторяющихся этапах дивергенции и конвергенции внутри каждого ромба.
Если говорить простыми словами, то суть заключается в том, что сначала мы расширяем наш поиск во все возможные стороны, и только потом приступаем к поиску решений, объединяя все полученные знания, при этом сужая фокус внимания. Мы делаем какие-то выводы из полученных данных и оставляем только самое важное из того что мы смогли выяснить. У каждого ромба в этой системе есть два этапа (расширение и последующее объединение):
Пятьдесят лет он создавал искусственный интеллект. Теперь говорит, что машины могут уничтожить человечество. Безработица, кибератаки, подтасовка выборов, вирусы, роботы-убийцы — далеко не полный список, что нас ждет. Что делать людям в таком мире? Учиться на сантехника. Пока... пока не появятся гуманоиды.
Привет! Я — Павел, фронтенд-разработчик, и это мой первый пост на Хабре. На момент публикации мне 34 года, а за плечами — 5 лет опыта в профессии. Уже чуть больше года я работаю в бигтех-компании: делаю новый функционал на React, пишу тесты, провожу код-ревью и периодически тушу рабочие пожары. А в качестве разминки для мозгов разгребаю легаси на смежном проекте и постоянно что-нибудь изучаю. У меня классные коллеги, конкурентная зарплата, ДМС для всей семьи, приятные премии и ощущение каких-то перспектив. Но так было не всегда.