Все потоки

Работа в Сибири – это суровый климат, гигантские расстояния и сложные промышленные объекты, которые требуют технологий, способных «видеть» и фиксировать реальность с ювелирной точностью. Для инженерного центра «СибИАЦ», более 20 лет обеспечивающего теплом и энергией населенные пункты региона, лазерное сканирование давно стало и глазами, и средством получения точной информации.

Введение санкций и уход с российского рынка западных компаний, занимающихся разработкой и поставкой специализированного программного обеспечения, сделали актуальным вопрос оперативного перехода на отечественное решение. Совместный с компанией «Макссофт-24» проект по внедрению программного решения nanoCAD Облака точек позволил не только бесшовно заместить ПО для обработки данных лазерного сканирования, но и выстроить более эффективный и технологичный рабочий процесс – от сканирования объекта SLAM-сканером до передачи готовой трассировки в BIM-модель.

Когда овчинка стоит выделки: сложности внедрения окупились многократно...

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

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

Журналистка Ребекка Иган Маккарти опубликовала на сайте Grist репортаж, посвящённый ситуации с центрами обработки данных в США. В нём рассказывается о проблемах энергетики, экологии и отношении местного населения к развитию подобной инфраструктуры.

В первой статье мы остановились на том месте, где классический RAG начинает буксовать. Он умеет находить близкие по смыслу фрагменты текста, но не умеет по-настоящему "жить" внутри структуры знаний. До определённого масштаба это почти незаметно. Но как только данных становится очень много, а вопросы требуют не буквального извлечения фраз, а работы со связями, векторный поиск начинает всё чаще давать не то чтобы неправильный, а недостаточно глубокий результат. Он вытаскивает похожее. Но похожее — не всегда значит связанное.

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

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

Художники открыли эту логику первыми, когда наносили на холст сетку, пытались управлять светом через темную комнату – она же камера-обскура, а позднее превратили дискретность в художественный принцип. Затем пришла цифровая революция: пиксель стал матрицей чисел, стандартом тестирования и языком видеоигр. А сегодня пиксель вернулся туда, откуда появился, – в материальный мир, но уже как культурный феномен. Теперь пиксель можно держать в руках: это кубик Рубика или кирпичик LEGO. В этой статье мы пройдём путь от аналоговой сетки к цифровому пикселю и обратно… к кубику Рубика.

В последние два года у многих возникло ощущение, что большие языковые модели почти решили проблему доступа к знаниям. Достаточно взять ChatGPT или любую другую сильную LLM, добавить к ней документы компании, подключить поиск по базе знаний, и вот уже кажется, что мы получили универсального цифрового аналитика. Он читает инструкции, отвечает по регламентам, пишет письма, пересказывает договоры, собирает отчёты и даже объясняет табличные данные на человеческом языке. На этом фоне Retrieval‑Augmented Generation, или просто RAG, стал восприниматься как практически универсальный рецепт: если модель чего‑то не знает, надо просто «подложить» ей нужные данные...

Пятничное, давно я что-то не писал про приключения ездового кота, но недавно наткнулся на  очередной пост про нейросети и искусственный интеллект, который теперь умеет диагностировать болезни, предсказывать поломки оборудования и вообще решать задачи, для которых раньше требовались годы человеческого опыта. Автор распинался про триллионы параметров, петабайты данных и революцию в промышленности, а я читал, усмехался и вспоминал, что в начале нулевых был свой “ии” для диагностики неисправностей, только работал он не на GPU-кластерах и обучался не на размеченных датасетах, а на похвале старого инженера, с которым был на дежурствах и не мешал делать выводы.

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

Наверняка вы уже слышали о том, что рынок видеокарт в 2026 году переживает не лучшие времена. Дефицит DRAM, взлетевшие цены на память, производственные линии TSMC, забитые заказами на ИИ-ускорители — все это превратило покупку новой видеокарты в квест с непредсказуемым финалом. И вот на этом фоне NVIDIA принимает решение, которое еще пару лет назад показалось бы абсурдным — перезапустить производство GeForce RTX 3060. Да, той самой карточки 2021 года на архитектуре Ampere. Наверное, об этом вы тоже слышали, но давайте обсудим, надо ли этому радоваться. 

Привет, Хабр! Я Маша Митрофанова, проджект исследования IT-брендов работодателей в ЭКОПСИ. Совместно с Хабром мы с 2020 года ежегодно замеряем привлекательность IT-компаний среди соискателей и сотрудников, а сейчас стартовал уже седьмой цикл нашего исследования. Под катом делюсь аналитикой о том, чем живёт российский рынок IT-кадров и на что на самом деле смотрят специалисты при выборе работы.

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

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

Привет, Хабр! Я Виктория Левена, руководитель отдела аналитики в AGIMA. По моему опыту редизайн часто начинается с ощущения, что что-то не так. Кажется, наш сайт выглядит устаревшим. Кажется, технологии и пользовательские привычки меняются — и нам тоже надо. Кажется, никому в команде не нравится сайт, но никто не может объяснить, почему. С такими ощущениями сложно работать: непонятно, что менять, и главное, как потом доказать, что стало лучше, а не просто по-другому.

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

Появление операционного усилителя как отдельного класса электронных схем произошло благодаря развитию аналоговых вычислителей. Так, прообраз ОУ — суммирующий усилитель Карла Сварцеля из Bell Labs — в начале 1940-х годов стал основой электронной системы управления огнем зенитного орудия M9 gun director. А сам термин «операционный усилитель» впервые сформулировал Джон Рагаццини из Колумбийского университета в своей знаменитой статье «Анализ динамических задач с помощью электронных схем» 1947 года, прямо ссылаясь на работы Bell Labs по этому проекту. Но мало кто задумывается о том, что вычислительная техника оказала значительно больший вклад — без цифровых микросхем мы еще долго могли бы не увидеть первый интегральный ОУ.

Моя текущая скорость примерно в 3 раза выше, чем у среднего Senior 1С-разработчика. Потенциальный потолок при полной автоматизации цикла — 100 задач в неделю (эквивалент 6 синьоров).

Это не теория. Ниже — цифры, архитектура и честный разбор того, что работает, а что нет.

Я использую подписку Claude code Pro MAX 200 USD в месяц и этого полностью хватает.
Работа вся построена через Claude code CLI на выделенном сервере.

Пайплайн разработки строится на команде
/task НазваниеЗадачи - далее промт - что нужно сделать на 2-3 предложения.

Команда /task обёртка - вызывает полный пайплайн.

После стажировки в КОРУСе я довольно быстро оказался на реальных проектах. И, как это часто бывает, проекты были далеко не учебные — крупные клиенты, сложные процессы и живая система, от которой зависит работа бизнеса.

Иногда со стороны кажется, что такие проекты — территория только для мидлов и сеньоров. Но на практике команды почти всегда состоят из специалистов разных грейдов. И это нормально.

За время работы я убедился: младший аналитик на проекте — это не ученик, который просто наблюдает. Это полноценный участник команды, который закрывает целый пласт прикладных задач. Особенно хорошо это видно на проектах внедрения и поддержки Битрикс24.

Меня зовут Семен Курганов, младший аналитик в департаменте CRM&BPM в «КОРУС Консалтинг», и в этой статье я поделюсь своим опытом работы младшим системным аналитиком на проектах Битрикс24.

Коротко для ленивых

В MariaDB 12.3 binlog можно хранить внутри InnoDB через binlog_storage_engine=innodb.

Главный эффект: вместо двух fsync() на commit остаётся один, поэтому на write-heavy нагрузке резко растут TPS и снижается tail latency.

В тестах из статьи прирост на полном durability-профиле составил примерно 2.4x–3.3x.

Backup, restore и ресинк реплик становятся проще, потому что binlog и данные теперь консистентны на уровне одного механизма хранения.

Цена за это: обязателен GTID, Galera пока не поддерживается, а innodb_log_file_size нужно подбирать внимательнее из-за роста объёма redo.

Если у вас обычная схема primary + async replica на InnoDB, эту возможность точно стоит хотя бы протестировать.

В мире медицинского Machine Learning сейчас доминируют англоязычные открытые решения (базирующиеся в основном на датасетах вроде MIMIC-CXR или CheXpert). Если вы хотите развернуть локальную мультимодальную (Vision-Language) модель, которая будет генерировать медицинские репорты по рентгену на русском языке, вы столкнетесь с полным вакуумом.

В этой статье я расскажу о своем пет-проекте: как я с нуля собрал и обучил архитектуру VisionEncoderDecoder, используя "глаза" от Google и "мозг" от Сбера, как решал проблемы с датасетами на Kaggle и почему Seq2SeqTrainer от Hugging Face крашится при сохранении чекпоинтов.

Расскажем, как на наш взгляд не стоит писать функциональные требования для Технического Задания.

Напомним, что функциональные требования – это не 50% от общего объема всех требований к Системе, которые определяют 100+ % успеха разработки и реализации.

Итак, что точно не нужно делать.

В этой статье мы рассмотрим, как при помощи искусственного интеллекта отрефакторить множественные файлы на Java. Действуем по такому сценарию:

Есть компания, которая при работе с микросервисами на Java использует собственную библиотеку, управляющую флагами для переключения фич. Теперь решено мигрировать на  Unleash, где работа с флагами переключения фич организована удобнее, а также предусмотрено поэтапное включение фич.

В 1997 году акции Apple стоили 4 доллара. Компания теряла сотни миллионов и была в шаге от банкротства.

Одной из причин катастрофы оказалось решение, которое за три года до этого казалось спасением: Apple разрешила другим компаниям выпускать Mac по лицензии. Десятки клонов наводнили рынок — дешевле, быстрее, доступнее оригинала.

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