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

Проблема — копируют интерфейс, а код переписывают. Регистрация ПО не поможет, потому что она защищает бэк, а фронт так и остается беззащитным. 

Представьте: вы делаете мобильное приложение год, создали уникальный плиточный интерфейс с плавными переходами. Конкурент скриншотит каждый экран, переписывает и выпускает клон. Ваша регистрация программы для ЭВМ поможет? Нет, она бессильна, код-то разный. 

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

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

Современное проектирование – это постоянный поиск баланса между детализацией и производительностью. Чем точнее модель, тем тяжелее с ней работать. Именно здесь на помощь приходит концепция многовидовых представлений (Multiview) – способ организации данных, при котором один физический объект, будь то колонна или стена, может иметь несколько графических вариантов отображения.

Долгое время эти задачи решались последовательно или разными программами, что приводило к ошибкам передачи данных и разрыву информационной целостности. Решение этой проблемы в nanoCAD BIM Строительство реализовано на основе концепции многовидовых представлений.

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

Многовидовое представление также влияет на отображение материалов: например, для кирпичных стен в 3D-представлении мы видим реалистичную текстуру, а на 2D-плане – условную штриховку по ГОСТ, которая автоматически обновляется при смене материала.

В этой статье мы подробно разберем каждое из четырех представлений...

Device Plugin в Kubernetes сводит GPU к счётчику на узле: планировщик видит только количество устройств, но не их профиль, объём памяти или режим шаринга. Для ML-задач это быстро становится ограничением. Обучению нужны выделенные карточки целиком, инференсу — управляемые доли, а CI хватит и четвертинки NVIDIA H100 на пять минут. 

Dynamic Resource Allocation полностью меняет модель управления устройствами. GPU становятся сущностью с инвентарём, атрибутами и правилами выбора. В статье я разбираю устройство DRA и показываю миграцию с device plugin на примере кластера из 8 узлов × 8 NVIDIA H100 без полного переписывания манифестов. А ещё объясняю, почему мы в Deckhouse пишем свой DRA-драйвер.

Привет! Меня зовут Ксюша, я продуктовый дизайнер в MAGNIT TECH, и уже больше года работаю над карьерными сайтами. Я присоединилась к продуктовой команде, в которой были продакт-менеджер, продуктовый аналитик, исследователь и разработчики, но не хватало меня –  дизайнера :)

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

«Вы не потеряете работу из-за ИИ. Скорее всего, вы потеряете её из-за человека, который использует ИИ». Так глава Nvidia Дженсен Хуанг объясняет новую логику рынка труда: нейросети не просто автоматизируют задачи, а меняют норму производительности внутри команды.

Сотрудник с агентом быстрее ищет информацию, пишет код, готовит отчёты, отвечает клиентам и меньше тратит время на рутину. Сотрудник без агента выглядит как человек с блокнотом рядом с коллегой в CRM.

Для бизнеса это уже не вопрос «заменит ли ИИ людей». Более практичный вопрос звучит иначе: какие KPI можно поднять, если дать сотрудникам ИИ-агентов и встроить их в рабочие процессы?

Сергей Тищенко, аналитик студии визуализации данных AkademiaDev, рассказывает, как данные перестали быть сугубо аналитическим инструментом и превратились в полноценный язык, на котором сегодня говорят медиа, бизнес, цифровые сервисы и дизайнеры: от доступного визуального сторителлинга в Flourish и Datawrapper до повседневной работы с данными в Superset, Metabase, Power BI и DataLens. Почему данные давно вышли за пределы таблиц и отчетов, как визуализация помогает превращать сложные массивы информации в понятные истории.

Привет, Хабр! На связи «Исходный Код». Сегодня разбираем инструмент, который мы все запускаем по сто раз на дню, но часто воспринимаем как черный ящик. Без него мы бы до сих пор собирали проекты руками, писали скрипты на bash и страдали от вечного «у меня собирается, а у тебя нет».

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

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

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

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

В нише внедрения CRM принято публиковать только истории успеха. У всех на сайте «выручка выросла на 47%», «время цикла сделки сократилось в 2,3 раза», «менеджеры довольны, дашборды красивые». Это создаёт у рынка ложное впечатление, что внедрение CRM — почти всегда удачное.

Это не так. По нашим внутренним наблюдениям, 15–20% проектов заканчиваются провалом разной степени: от тихого саботажа со стороны команды до полного отказа клиента от системы через 3–6 месяцев после запуска. Системные причины этих провалов одинаковые, и о них почти никто не пишет.

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

Все детали обезличены, цифры реальные.

В некоторых браузерах есть код, проверяющий, какой домен посещает пользователь, и меняющий способ рендеринга страницы.

Да, вы всё поняли верно. If site == X, do Y.

Особого обращения заслужили TikTok, Netflix, Instagram* и даже SeatGuru.

Так поступают Safari и Firefox. Но не Chrome.

И это говорит нам кое о чём любопытном.

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

Представьте внутреннего AI-агента, который помогает компании искать общие документы и управлять ими. Он работает. До тех пор, пока 12–15% запросов не начинают падать. Агент возвращает не тот документ, редактирует не тот файл, молча падает или уверенно ссылается на файл, которого не существует. Поиск по фото отказывает с той же частотой. Ошибки размазаны равномерно по пользователям, фичам и запросам.

Первое инстинктивное действие — поменять модель. Opus 4.5, GPT 5.5 или что там сейчас в топе лидерборда. Меняете. Счет за инференс растет в 4–5 раз, а общая доля ошибок снижается с 12% до 9%. Пользователи пишут о тех же проблемах. Бюджет следующего квартала сгорает за пару недель ради улучшения в 3 процентных пункта — и вы по-прежнему не понимаете, что именно было не так в системе и как улучшать ее дальше.

Эта статья — о том, почему смена модели обычно разочаровывает и куда стоит смотреть в первую очередь. Большинство сбоев AI-систем живет в слое обвязки — orchestration, retrieval, tool definitions, retries, context management, — а не в самой модели. Дальше — метод, как отличить проблемы обвязки от проблем модели, кейс, в котором одно исправление в обвязке подняло completion rate с 26% до 88% без смены модели, и чек-лист, который помогает находить такие сбои в вашей собственной системе. Если вы никогда не делали подобной диагностики — ожидайте найти хотя бы один пункт, который стоит починить.

Обзор будущего продукта. Distributed Occupancy Intelligence Platform - это распределённая система мониторинга и аналитики присутствия людей в зданиях и инфраструктурных объектах без использования камер и сбора персональных данных.

Джира в России осталась, но в очень нелегальном состоянии. 4 года назад Атлассиан ушёл из РФ, а 30 марта закрыли продажи on-premise версий для дата-центров. В 2029 году снимаются с поддержки все локальные версии.

При этом 70% компаний всё ещё сидят на неподдерживаемых версиях Jira, Confluence и Trello.

Это не малый бизнес, который не захотел успел разобраться, а гиганты с выручкой от 2 млрд рублей. Люди, которые управляют этими компаниями, прекрасно понимают ситуацию. И всё равно не уходят.

Потому что это годами настроенные рабочие процессы, тысячи задач в системе и команды, которые не хотят переучиваться. Больше половины бизнесов оценивают срок миграции в 1—2 года. С таким горизонтом легче решить, что «всё равно пока не горит».

А уже горит.

С 15 февраля 2024 Jira Server перестала поддерживаться — больше никаких апдейтов безопасности. Если вы пускаете снаружи людей без дополнительной прослойки типа корпоративного тоннеля или NGFW — остаётся спорить, создаёт ли Джира дыру в системе или ей является. Крякнутые версии тоже под вопросом относительно бэкдоров.

Atlassian Marketplace заблокирован для РФ — плагины и интеграции с другим софтом отваливаются все эти годы.

Для госкомпаний, компаний с госучастием, субъектов КИИ (Критическая информационная инфраструктура) и банков законодательно были чёткие сроки перехода на отечественное ПО. Jira прямо нарушает директивы ФСТЭК, Минцифры и указы Президента РФ.

Есть сложности с аудитами и проверками — если планируется сделка или сертификация, проверку получится пройти только с серьёзными замечаниями.

Админов по Джире всё меньше, а поддержка по мере разваливания стека всё нужнее.

Вы можете вычислять зависимые реактивные состояния как можно раньше, так и как можно позже, вплоть до отказа от вычислений, если это возможно. Далее разберём, как делать это правильно.

В практике инженера АСУ ТП диагностика интерфейса RS-485/422 обыденное дело. Но что делать, если удаленный опрос приборов учета лег, линии прозвонены, сеть работает а связи все равно нет? Рассказываю реальный кейс о том, как из-за невнимательности при первичной проверке мы перепутали подключение COM-портов, и что в итоге получилось.

DOOM известен тем, что запускается где угодно – благодаря портам, которые появляются с 1993 года. Мем «It Runs Doom» («Он запускает DOOM») живёт в интернете уже больше десяти лет. Люди запускали DOOM на тостерах, на тачбарах макбуков, на умных холодильниках. И, кажется, я – первый человек, который уместил DOOM в QR-код.

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

В статье разбираем, почему инвалидация кэша — это архитектурная проблема, как TTL, события, CDC и lease‑подходы влияют на консистентность и когда кэш лучше вообще не использовать.

В.А.Притула, «Электрическая защита от коррозии подземных металлических сооружений»

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

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

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

Однако, как выясняется, даже такие сплавы не могут устоять перед негативным явлением, которое носит название «щелевая коррозия»…