Kurgan-Telecom Ru | Информационные технологии

История развития многослойных конструкций – это наглядная эволюция, которая начиналась с примитивного сочетания природных материалов: глины, соломы, дерева, мха и камня. Наши предки интуитивно понимали, что если между двумя слоями засыпать землю или глину, то в доме становится заметно теплее. Так рождались первые примитивные «слоеные» стены. Шли века, и на смену случайным засыпкам приходили всё более продуманные механизмы. Сегодня же многослойные конструкции превратились в сложные инженерные системы, где каждый слой просчитан, подогнан и выполняет свою функцию.

Без таких конструкций невозможно представить современное проектирование. Поэтому для нашего примера – двухэтажного коттеджа – необходимо было смоделировать многослойные конструкции в nanoCAD BIM Строительство.

В этой статье мы детально рассмотрим многослойные конструкции стен, однако принцип моделирования таких конструкций в nanoCAD BIM Строительство универсален и применим также к другим элементам здания, например к перекрытиям.

Сам проект имеет интересную предысторию. «Коробка» дома уже была возведена на участке, но в процессе строительства возникла необходимость пристроить к дому веранду и гараж. В связи с этим принято решение смоделировать коттедж в новом продукте – nanoCAD BIM Строительство.

Здесь мы столкнулись с ограничением: в текущей версии nanoCAD BIM Строительство отсутствует прямая, «коробочная» возможность создавать многослойные стены как единую интеллектуальную конструкцию (рис. 1). Процесс моделирования сводится к последовательному построению отдельных стен, каждая из которых будет соответствовать одному слою конструкции с заданными характеристиками.

Последний месяц лета закрываем длинным списком релизов для AI-агентов: документация, MCP-сервер, скиллы, навыки, файлы в чате и четыре новые модели в каталоге. Причина простая: каждое третье обращение к нашей документации — от агентов, нужно считаться с новой аудиторией.

Вторая половина выпуска для тех, кто читает сам: три класса хранения в S3, отмена удаления баз, клон приложения в App Platform, домены через Госуслуги и обновленный Kubernetes.

Разворачиваем каждый пункт ниже ↓

В вашей дизайн-системе могут быть особые требования к внешнему виду скроллбаров. К сожалению, нативные возможности стилизации весьма ограничены, поэтому, если вы сталкивались с подобными требованиями, единственный вариант — делать собственный компонент.

Для этого нам нужно решить несколько задач: понять, когда надо показывать ползунок, какого он должен быть размера и где находиться, обновлять положение при прокрутке и тому подобное.

Что, если я скажу вам, что в 2026 году JavaScript для всего этого нам больше не нужен?

Пару недель назад YouTube подкинул мне пятиминутный ролик с небольшого канала, где автор демонстрирует преимущества RAG на графах над обычным RAG поверх корпуса текстов.

Пример довольно простой. LLM должна ответить на вопрос: “Кто должен подписать возврат клиенту на 800 фунтов в марте?”. Ответ, естественно, содержится в предоставленных текстах, но для того, чтобы его добыть, нужно уметь в multi-hop reasoning, т.к. необходимая информация лежит в 3х разных местах:

Модель вернула не все записи, валидатор отбросил пригодные данные, ручная очередь спрятала подходящие вакансии. Разбираю три места, где мой конвейер терял полезные результаты, и проверки, которые помогли это обнаружить.

Прототип в Figma может выглядеть логично для дизайнера и всей продуктовой команды, но первый же пользователь способен за несколько минут обнаружить проблемы, которые никто не заметил на ревью. Неочевидная кнопка, непонятный следующий шаг, неожиданная логика формы — исправить такие вещи в прототипе значительно проще, чем после разработки.

В этой статье разберу, как организовать тестирование прототипов Figma: подготовить сценарии и задания, подобрать участников, собрать обратную связь и превратить результаты в конкретные решения по интерфейсу. Отдельно покажу, как связать работу с прототипом с опросом в Тестографе, чтобы получать не только отдельные комментарии пользователей, но и данные, которые можно сравнивать и анализировать.

Я занимаюсь анализом данных в Тестографе и консультирую клиентов по методологии опросов, поэтому буду смотреть на тестирование прототипов прежде всего как на исследовательскую задачу. Нас будет интересовать не вопрос «нравится ли пользователю дизайн», а более полезные вещи: смог ли человек выполнить задачу, где он столкнулся с затруднением и какие данные действительно позволяют понять, что стоит изменить в интерфейсе.

За последние полгода вышли сотни материалов об ИИ-агентах. Особенно много говорят про OpenClaw и Hermes. Я изучил, пожалуй, добрую половину из них, протестировал сам и хочу поделиться выводами.

Давайте признаем: полезных кейсов применения сейчас действительно немного, денег вся эта инфраструктура ест прилично, а половину демонстрируемых функций проще вызвать в обычном чате с ИИ. И это вполне валидные претензии к OpenClaw как к готовому продукту. Вот только рассматривать его исключительно как потребительский продукт — ошибка. Когда я это понял, мой взгляд на технологию кардинально изменился. Революция действительно произошла, но не там, где ее привыкли искать.

В этой статье мы подробно разберем, почему OpenClaw стал важной вехой в развитии ИИ, хотя и не предложил ничего принципиально нового, а затем рассмотрим архитектуру автономных агентов и пошагово пройдем процесс создания и деплоя вашего собственного цифрового помощника.

Тестировщик — одна из самых доступных точек входа в IT. Не надо знать сложные алгоритмы и не нужен диплом технического вуза. Но нужно уметь думать нестандартно, находить, что не работает, и точно описывать проблемы. Это делает QA-инженера ценным членом команды.

По данным исследования Хабр Карьеры за первое полугодие 2026 года, зарплаты тестировщиков выросли на 5% — это один из лучших показателей среди IT-специализаций. Для сравнения, з/п разработчиков выросли только на 1%. 

При этом разброс внутри профессии большой: ручное тестирование и автоматизация — разные деньги и разные требования. В статье разберём, кто такой QA-инженер, чем занимается, сколько зарабатывает, где учиться и как получить первую работу.

Привет, Хабр! Была одна вещь, которая давно (примерно 3 дня) не давала мне покоя в Sheeternetes. Весь смысл проекта — «таблица и есть кластер»: Deployments, Nodes, Pods живут во вкладках, таблица — источник истины. Вот только в первых версиях мы покривили душой и шли против истины. Планировщик — та самая часть, что решает, какой под на какую ноду поедет, — был Python-функцией, которая читала таблицу снаружи. То есть таблица хранила состояние, а думал Python.

Это жульничество, и оно меня грызло (на самом деле нет, это клод так придумал). Поэтому я решил убрать последний внешний мозг: переписать планировщик как формулу таблицы. Без Python, без Apps Script, без bash. Одна =LET(…) на под, которая читает вкладку Nodes и решает, куда его поставить, — пользуясь только тем, что встроено в Google Sheets.

И оно работает. Воспроизводит bin-packing, capacity, spread, sticky placement, cordon, affinity и taints — и выдаёт ровно ту же раскладку, что и настоящий Python-планировщик, на всех девяти его юнит-тестах.

На первый взгляд, поиск в сервисе услуг — это довольно типовая задача. Что там может быть особенного? Под капотом лежит каталог услуг, Elasticsearch, нормализация запросов, ранжирование, кеширование. Ничего такого, чего не было бы в других продуктах. Но это только на первый взгляд.

Сейчас расскажу, как устроен поиск в Профи.ру, зачем мы добавили в него LLM и почему языковая модель у нас не заменила классический алгоритм, а стала его дополнительным слоем.

Cursor начал отменять платные подписки пользователей из России: 5 сентября появились сообщения о письмах, в которых сервис ссылается на работу из запрещённого региона. В одном из уведомлений пользователю отменили Pro+ и пообещали вернуть деньги за неиспользованный период. Масштаб отключений пока неясен, но вопрос «а в чём теперь работать?» уже вполне практический.

Сколько ни улучшай PostgreSQL, сколько ни отчитывайся о реальных историях внедрения, архитектурный потолок от этого никуда не исчезает: есть класс задач, где дальнейшее развитие в рамках традиционной архектуры объективно затрудняется. 

Именно здесь появляется Tantor Polar — распределенная СУБД с разделением вычислений и хранения и 100% совместимостью с PostgreSQL. На ее основе построена машина баз данных Tantor XData Gen3, объединяющая мощные вычислительные узлы, высокопроизводительное общее хранилище и высокоскоростную сеть c RDMA в единую систему. В этой статье мы покажем, что эта архитектура дает на практике — рассмотрим устройство синергично работающих программных и аппаратных модулей позволяющих достичь высоких показателей в популярных нагрузочных фреймворках, таких как TPC-B (250 тыс. TPS) и TPC-C (2,6 млн NOPM). 

Я пишу эту статью, потому что потратил довольно много времени разбираясь с подключением сервисов Google Workspace к Claude Code CLI и OpenClaw. И хочу чтобы другим было проще. Я постарался объяснить что происходит, чтобы когда вы читали инструкции вашего агента или документацию, понимали что от вас хотят.

В статье нет пошагового гайда по настройке какого-то конкретного клиента. Это набор знаний, как настроить любой клиент (например, написанный вашим агентом)

А подключение агента к календарю и почте - тема полезная. Я уже не представляю как ставить встречи на много человек вручную (хотя вьетнамские флешбеки имеются =))

Всё еще делаете общую таблицу с компонентами и каждый раз рисуете новые компоненты в Altium Designer? Тогда мы идём к вам так сказать. Под катом будет показано как один инструмент позволит создать компонент в альтиуме, зная только JLPCB Part # нужного компонента, либо тыкнув в нужный компонент базы данных KiCAD, в которой есть все стандартные элементы

Представим обычную ситуацию: экспедитор принимает товар на складе, подписывает накладную и фотографирует документ корпоративным смартфоном. Через несколько секунд реквизиты должны оказаться в учетной системе – без ручного ввода данных, офисного сканера и ожидания, пока бумага доедет до бухгалтерии.

Но есть условие: фотография не должна отправляться ни OCR-провайдеру, ни стороннему центру обработки, ни оператору ручной верификации. В идеальном сценарии изображение вообще не покидает мобильное устройство – в корпоративную систему поступают уже извлеченные и проверенные данные.

Возможно ли распознать на смартфоне многостраничный УПД со сложной таблицей, исправить перспективу, прочитать мелкий шрифт и рукописные пометки – и сделать все это без подключения к внешней инфраструктуре? Короткий ответ: да. Однако для безопасной системы распознавания первички недостаточно написать в презентации “работает локально”. Нужно правильно выстроить весь маршрут документа – от камеры смартфона до 1С или ERP.

Всем привет, меня зовут Миша, и я бэкенд‑разработчик в платформе Яндекс Еды. Я уже рассказывал, как мы анализировали наш PHP‑монолит и вынесли из него процессинг заказов, и с тех пор роль этого легаси заметно уменьшилась. Заодно туда стали писать гораздо меньше нового кода, релизы стали реже, и он спокойненько себе работал, не привлекая лишнего внимания. 

Так оно бы и продолжалось, но тут случилась повышенная нагрузка и необходимость зарезервировать побольше мощностей для беспроблемной обработки повышенного спроса. Монолит справился на отлично, но самое интересное случилось потом: возвращая выделение ресурсов к прежним значениям, я случайно обратил внимание, что RPS в пиковые вечерние часы как‑то подозрительно совпадает с количеством ядер CPU, выделенных на весь монолит.

Количество выделенных ядер, конечно, ещё ничего не означает, поэтому я полез смотреть реальное потребление процессорного времени, сложив CPU usage по всем подам. С помощью нехитрой арифметики я обнаружил, что 100% загрузки одного ядра приходятся на 2,5 RPS. Какое‑то время я находился в состоянии глубокого изумления, после чего решил, что это никуда не годится, и отправился в увлекательное приключение на 20 минут. 

Немного спойлеров: дело оказалось далеко не только в PHP. 

У компании могут быть десятки QA-метрик и при этом не быть ответа на вопрос: почему продукт становится все дороже и сложнее менять?

Команда знает, сколько дефектов нашла за спринт, сколько ошибок дошло до продакшена, сколько времени занимает регрессия, какой процент сценариев автоматизирован. После каждого релиза появляются новые цифры, графики и отчеты.

А теперь представим продукт, который выпускает релизы раз в две недели. Серьезных дефектов больше не становится, автоматизация развивается, команда укладывается в релизный цикл. На первый взгляд все в порядке.

Но за последний год регрессия заметно выросла. Изменение одного сервиса все чаще требует проверки нескольких соседних. Одни и те же компоненты регулярно всплывают в инцидентах и срочных исправлениях после релиза.

Для QA это дополнительные проверки и знакомые проблемные модули. Для CTO — возможный сигнал, что растет стоимость изменений.

Через несколько кварталов эта история может проявиться уже в сроках разработки. Новые функции станут выходить дольше, оценки начнут расти, а для сохранения прежней скорости понадобится больше людей.

Первые признаки проблемы при этом уже были в данных QA.

Примерно вокруг этой идеи и строится Quality Intelligence.

Что вообще такое Quality Intelligence

За термином Quality Intelligence скрывается практичная идея: данные о качестве могут рассказать о продукте гораздо больше, чем просто показать, насколько хорошо он протестирован перед очередным релизом.

История тестирования, дефекты, изменения компонентов, продакшн-инциденты, обращения пользователей, продуктовые показатели — все это следы того, как система развивается и как она реагирует на изменения. Если смотреть на них вместе и в динамике, можно заметить проблемы задолго до того, как они станут очевидны на уровне сроков, бюджетов или пользовательских жалоб.

Под моей первой статьёй о блокчейне как append-only базе данных самые интересные вопросы были не про базу. Всплывали другие вопросы, примерно следующего содержания. А что будет, если валидаторы сговорятся? Кто мешает большинству переписать историю? Почему я вообще должен верить блокчейну?

Ответ достаточно развернутый и занимает больше, чем один адекватный комментарий. Поэтому публикую его отдельной статьей.

Организация Объединённых Наций проголосовала за принятие резолюции, призывающей официально отказаться от традиционной карты мира в проекции Меркатора в пользу карты, которая точнее передаёт размеры Африки.

На заседании в штаб‑квартире ООН в Нью‑Йорке Генеральная Ассамблея официально отказалась от проекции Меркатора XVI века в пользу карты, основанной на более точной равновеликой проекции Equal Earth, разработанной в 2018 году. За резолюцию проголосовали 164 страны. Против выступили только США, представитель которых назвал резолюцию «излишней». Шесть стран воздержались.

Резолюции ООН не имеют обязательной силы, поэтому страны и организации не будут обязаны использовать только новую проекцию, а старая не окажется под запретом. Однако ожидается, что решение приведёт к изменениям в школьных программах и повседневных технологиях, учитывая широкое распространение проекции Меркатора в образовании, технологиях и государственном управлении.

Того, возглавившее кампанию за принятие резолюции от имени Африканского союза, заявило, что страна «признаёт и подтверждает, что непропорциональные картографические изображения, особенно возникающие при использовании проекции Меркатора, имели долгосрочные когнитивные, образовательные, культурные, геополитические и социально‑экономические последствия, способствуя резкому уменьшению воспринимаемых размеров Африки и других регионов мира в глобальном коллективном сознании».

Перед принятием резолюции министр иностранных дел Того Робер Дюссе заявил: «Это не политическая, а научная дискуссия, поскольку существуют научные доказательства, и поэтому мы все должны принять реальность».

Промышленная автоматизация десятилетиями жила с четким разделением: на верхних уровнях управления царил Ethernet, а на нижнем — полевые шины и аналоговые интерфейсы 4–20 мА. Этот рубеж долгое время казался непреодолимым: Ethernet требовал четырех пар проводов, имел ограничения по дальности и не мог использоваться во взрывоопасных зонах.

Сегодня ситуация кардинально меняется. Две технологии — Single Pair Ethernet (SPE) и Ethernet-APL — делают возможным то, о чем раньше можно было только мечтать: единую IP-сеть от центра управления до самого простого датчика. В этой статье мы рассмотрим обе эти технологии подробнее.