Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Эта статья —продолжение предыдущей: Мой справочник по Feature-Sliced Design. На этот раз я рассмотрю, как по моему субъективному мнению улучшить файловую структуру проекта, нарушая рекомендации FSD.
Привет, Хаброжители! Машинное обучение может ускорить выполнение повседневных бизнес-задач, таких как сверка счетов, прогнозирование спроса или автоматизация обслуживания клиентов, не говоря уже о более сложных задачах, например выявление мошенничества, прогнозное техническое обслуживание и персонализированный маркетинг. Извлекайте важную информацию из электронных таблиц, реестров, баз данных и других источников, используя градиентный бустинг, глубокое обучение и генеративный ИИ.
В микросервисной архитектуре ошибка — это не просто баг в отдельном сервисе. Это сорванный релиз, нестабильные интеграции, потерянные заказы и часы дорогой ручной проверки. Когда сервисов десятки, а релизы идут постоянно, цена отсутствия системной автоматизации становится слишком высокой.
Уже больше полутора лет я пишу автотесты на Go. За это время мы прошли путь от «зачем вообще тестировать на Go?» до «почему мы не сделали это раньше?».
В этой статье я покажу, как внедрить автоматизацию тестирования на Go с нуля — так, чтобы она решала реальные бизнес‑проблемы, а не просто увеличивала количество тестов в репозитории.
Hola, Amigos! На связи Павел Гершевич, Mobile Team Lead агентства продуктовой разработки Amiga и соавтор книги «Основы Flutter». Иногда нужно реализовать поиск по данным без участия бэкенда. Самый простой вариант — обычное вхождение строки — не прощает опечаток. Одна лишняя буква, и поиск выдает пустоту.
В статье разберем, как усовершенствовать этот процесс: научим поиск обрабатывать ошибки и сортировать результаты по степени совпадения.
В Go легко написать код, который компилируется, но раздражает при чтении: слишком длинные receiver’ы, странные имена пакетов, лишние повторы в вызовах, хаотичный регистр и utils, который постепенно превращается в свалку. Для начинающего Go-разработчика соглашения по именованию могут выглядеть как набор мелких вкусовых правил, хотя на практике они влияют на навигацию по проекту, читаемость API и стоимость будущего рефакторинга.
В статье разберем основные правила и идиомы именования в Go – от идентификаторов и пакетов до методов, интерфейсов и геттеров – с примерами удачных и неудачных решений.
Привет всем, на связи снова Дарья Борисова, системный аналитик из ПСБ. Продолжаю развеивать мифы о REST API. Если вы пропустили первую и вторую часть, то советую заглянуть туда: ведь мы уже разобрали некоторые заблуждения о природе REST. Сегодня мы разберем нюансы транспортных и бизнес-ошибок, погрузимся в кеширование и узнаем, действительно ли REST должен быть прокси для базы данных.
Переходите под кат, начинаем!
Привет, Хабр. Меня зовут Алексей, я C#-разработчик. В этой статье хочу рассказать о своём дипломном проекте очень запавшем мне в душу, который я делал на тему обработки изображений, GIS и дистанционного зондирования Земли. Даже спустя годы мне интересна данная тема и она по-прежнему остаётся очень перспективной в различных отраслях.
Идея была в том, чтобы собрать небольшое настольное приложение, которое умеет работать с реальными спутниковыми данными: Landsat 8, Sentinel-2 и AVIRIS. То есть открывать не готовую RGB-картинку, а набор спектральных каналов, собирать из них естественные и псевдоцветные изображения, считать растровые индексы, выделять эталоны прямо на снимке, классифицировать пиксели, сегментировать изображение и пробовать более исследовательские вещи вроде EMD-разложения.
В итоге получилась учебно-исследовательская программа, но с полным рабочим циклом: от чтения спутникового архива до сохранения информативного результата обработки. Ниже расскажу, зачем вообще нужны такие снимки, какие особенности есть у разных спутниковых данных, что делает приложение и какие алгоритмы оказались самыми интересными.
Фирма «1С» опубликовала тестовый релиз технологической платформы «1С:Предприятие 8.5.4». Версия предназначена для ознакомления и тестирования, но уже позволяет оценить изменения, которые могут быть важны для администраторов, разработчиков и команд сопровождения.
Одно из заметных обновлений - новый инструмент «1С:Предприятие — менеджер лицензий». Он унифицирует работу с программными и аппаратными лицензиями и позволяет управлять их распределением между информационными базами, продуктами и пространствами лицензирования. Также менеджер поддерживает работу с HASP License Manager, при этом поддержка HASP License Manager в клиентских и серверных приложениях прекращена...
Инвентаризация устаревает в момент, когда вы её заканчиваете. Разбираем, почему разовый подсчёт активов не работает, откуда берутся призрачные ноутбуки на балансе и что с этим делать.
Приветствую всех, продолжаю отчет о своих мучениях с выбором и установкой робота-пылесоса, с минимизацией вопросов по его обслуживанию. В предыдущих статьях я рассказывал про возможность подключения станции робота с помощью комплектов RAW4 (L30) и RAW7 (Х50), но итоговым решением стала модель X60 Master с прямым подключением к водопроводу и канализации, а также с уменьшенными габаритами самой станции.
Изучите принципы информационного моделирования на практике.
Разбираем возможности с помощью демонстрационного архитектурного проекта в nanoCAD BIM Строительство: двухэтажного загородного дома «с нуля».
В девяти уроках последовательно представлено создание архитектурного раздела: фундамент, стены, перекрытия, кровля, параметрические объекты, документация и экспорт в IFC.
Всем привет! Меня зовут Яков, и я разработчик игр. Возможно, вы играли в мои предыдущие проекты: Dom Rusalok, Loretta и Anoxia Station.
Пока команда одна — всё логично: бэклог, доска, понятный поток. Но когда команд становится пятнадцать и все работают над одним продуктом — Jira начинает вести себя странно. Product Owner открывает утро с обхода четырёх проектов, задачи дублируются, а зависимости живут в комментариях. Разбираемся, почему это не про «плохую Jira», а про конфликт моделей.
29 апреля 2026 года Митчелл Хашимото объявил, что уводит свой Ghostty с GitHub. Цитата ушла на главную Hacker News через статью в The Register: «GitHub больше не место для серьёзной работы, если он каждый день блокирует тебя на часы».
Сам по себе уход одного человека, даже такого, как Хашимото, ещё не новость. Новость в другом: на главной HN на той же неделе оказалось ещё четыре истории про GitHub. Эссе Армина Ронахера про то, как мы жили до GitHub. Манифест команды Tangled про федеративные форджи. Тихий запуск голландской госплатформы для опенсорса на Forgejo. И жёсткий аудит безопасности того же Forgejo от Жюльена Вуазана. Если посмотреть на эти пять текстов вместе, складывается одна история.
Хашимото — не случайный пользователь GitHub. Сооснователь HashiCorp, после ухода оттуда автор Ghostty. И, по его собственным словам, «пользователь GitHub номер 1299, зарегистрирован в феврале 2008-го». Он же говорит про себя как про человека, который «листает задачи на GitHub с тех пор, когда у такого поведения ещё не было названия». Если GitHub для кого-то и был домом, то для него.
Необычным его пост делает разбор последнего месяца. Хашимото вёл журнал дат и ставил «X» против каждого дня, когда GitHub упал и помешал ему работать. «Почти каждый день стоит отметка X», пишет он. «В день, когда я пишу этот пост, я уже два часа не могу сделать ни одного ревью пулл-реквестов, потому что лежат GitHub Actions». The Register заметил, что пост вышел прямо перед инцидентом 28 апреля, когда пулл-реквесты перестали завершаться из-за падения Elasticsearch.
Статья о том, как читать kubectl describe pod не как длинный вывод, а как историю жизни Pod«а: кто его создал, куда его пытались поставить, скачался ли image, стартовали ли init containers, что случилось с probes, volumes, restarts и Events.»
Постарался сделать материал дружелюбным для джунов и мидлов, но без упрощения до «введите команду и посмотрите статус». Тут много реальной эксплуатации: Pending, CrashLoopBackOff, ImagePullBackOff, OOMKilled, FailedMount, CreateContainerConfigError, Evicted и любимое «Pod Running, но сервис не работает».
Если вам нужна не вся теория, а быстрая шпаргалка для инцидента — в конце статьи есть компактная схема: что смотреть в kubectl describe pod при Pending, CrashLoopBackOff, ImagePullBackOff, OOMKilled, FailedMount и других типовых состояниях. Можно сразу перейти к ней, сохранить и использовать как чек‑лист. А если хочется понять не только «куда смотреть», но и почему Kubernetes ведёт себя именно так — дальше разберём describe вместе по шагам.
Одиннадцать тысяч рублей — именно столько денег было на всех счетах эмитента биржевых облигаций ООО «СибАвтоТранс» 31 декабря 2025 года. На семи счетах в шести банках — Сбербанке, Газпромбанке, Совкомбанке, Росдорбанке, Евромосбанке и АБ «Россия» — суммарно 10 956 рублей 94 копейки.
У компании, которая за три предыдущих года вышла на Московскую биржу с программой облигаций объёмом 1 миллиард 750 миллионов рублей под 19–26% годовых.
Через три недели после того, как директор Коршунов Владимир Анатольевич подписал годовой баланс за 2025 год, эмитент не нашёл четырёх миллионов девятисот тысяч, чтобы заплатить купон.
Если вы за последние полгода хоть раз заходили в интернет, то наверняка натыкались на посты в духе: «За выходные навайбкодил B2B SAAS ULTRA SUPER AI APP». Как-то незаметно мы оказались в мире, где сидишь и смотришь, как ИИ-агент сам ползает по папкам на диске, запускает тесты, падает с ошибкой, ругается на свои же логи (или тебя) и молча открывает пулреквест.
Предлагаю отмотать время немного назад и посмотреть, как мы вообще докатились до жизни такой. Под катом краткая историческая ретроспектива того, как ИИ-кодинг прошёл путь от умного T9 до мультиагентных систем, и иллюстрация того, почему главный навык синьора сегодня — это умение вовремя написать: «Я ЖЕ СКАЗАЛ, НЕ ДОПУСКАЙ ОШИБОК, ПОДУМАЙ ЕЩЁ РАЗ И СДЕЛАЙ НОРМАЛЬНО».
Прежде чем начать свой рассказ, представлюсь. Я Сергей Чекмарёв, AI Product Manager и программный автор курса по вайбкодингу в Практикуме. Специализируюсь на автоматизации процессов и создании продуктов на базе искусственного интеллекта.
Привет, меня зовут Николай, я 23 года в DevOps, последние пару-тройку месяцев копаюсь в архитектуре AI-агента (Hermes Agent)
В предыдущих двух статьях я разбирал, почему AI-агенты сходят с ума на длинных сессиях (сжатие контекста) и почему Chain-of-Thought это пост-хок нарратив, а не трассировка мышления. Статьи неплохо зашли, но в комментариях меня справедливо пропесочили: "нейрослоп с характерными эпитетами, очередной набор запросов к ИИ". Ну и по делу в принципе. Пишем руками, нудное это дело если честно, все равно вычитку в агента отдал в итоге.
И сегодня я расскажу про два инструмента, которые использую постоянно: Premortem и Prism. Не в теории, а на моём собственном опыте.
Prism это не моё изобретение. Это форк из Cranot/super-hermes, доработанный под мои задачи. В оригинале — пять независимых скилов структурного анализа. Premortem — вообще классика, из книги Klein «The Power of Intuition» и военной аналитики. Но я их доработал так, что это не просто "очередная методология для митапов", а работающий pipeline, который находит баги архитектуры.
using в C# выглядит как универсальная страховка от утечек ресурсов, пока объект живёт строго внутри одного метода. Но стоит вернуть его наружу, передать в фоновую задачу, положить в коллекцию или доверить DI‑контейнеру — и привычное правило начинает работать против вас.
В статье разберём типичные сценарии, где IDisposable превращается в источник нестабильных багов: закрытые раньше времени соединения, гонки с Task.Run, утечки обработчиков и тот самый HttpClient, который лучше не создавать на каждый запрос.
В пентест часто пытаются войти через список инструментов: выучить Burp, погонять Nmap, пройти пару лабораторий и ждать первой боевой задачи. В 2026 году такой вход всё хуже работает: часть рутины уже забирают AI‑ассистенты и автоматические сканеры, а от специалиста ждут понимания атакующей логики, бизнес‑рисков и умения проверять гипотезы руками.
Разбираемся, кому сегодня действительно стоит идти в пентест, какие направления растут быстрее всего и как учиться так, чтобы не конкурировать с автоматизацией за самые простые задачи.