Облекаем данные в красивую оболочку
В последнее продолжительное время занимаюсь разработкой ПО и алгоритмов по русистике. Иногда ищу обсуждение, задачки из комментариев и на Хабре. Попался на глаза занятный коммент:
Ключевой вехой в таймлайне электронных таблиц считается изобретение инженеров Рене Пардо и Реми Ландау «процесса и устройства (программы-компилятора), выполняемых на цифровом компьютере для преобразования исходной программы в объектную». Оба они были канадцами, детьми эмигрантов из Европы, оба получили магистерскую степень, то есть законченное высшее образование в Гарвардском университете в 1969 году и, вернувшись домой и устроившись там на работу в Bell Canada (дочка Bell System, а по сути — AT&T Corporation), разработали в том же году (по словам Пардо, за 6 недель) алгоритм автоматического вычисления естественного порядка в электронных таблицах, как это сейчас называют. Судя по дальнейшим событиям, главным в их дуэте, во всяком случае в администрировании их изобретением, был Рене Пардо. В 1970 году он учредил компанию LANPAR Ltd. (в дальнейшем LANPAR Technologies Inc.), и в августе того же 1970 года Пардо и Ландау подали заявку на свое изобретение в Ведомство США по патентам и товарным знакам, но как физические лица.
Честный рассказ команды Modus , которая только что завела Storybook поверх большой легаси-базы: зачем стартуем, чего ждём и как через полгода проверим, окупился ли он.
Представьте, что разработчику нужно поправить одну кнопку — отступ или состояние наведения. Работы на минуту, но для этого нужно поднять всё приложение, залогиниться и прокликать половину интерфейса до нужного экрана. И так — каждый раз. К третьему заходу проще остановиться на «вроде норм», чем повторять этот цикл ради мелочи.
Нам это надоело и мы решили попробовать Storybook. А заодно — поставить над собой небольшой эксперимент.
Если вы сейчас решаете, тащить ли Storybook в уже живой проект, и хотите увидеть честный старт, а не сухой результат — этот материал для вас.
Привет, Хабр! Меня зовут Павел, я ML-инженер и исследователь в области ИИ. Недавно наткнулся на исследование, посвященное проблеме понимания графиков визуально-языковыми моделями (Vision-Language Model, VLM), и решил подробнее разобраться в этой теме.
В наши дни большое количество научных, деловых и политических данных представляется в формате графиков, однако современные VLM решают задачу их анализа лишь частично. Одна из главных причин этого — отсутствие масштабных и разнообразных наборов данных для обучения и тестирования.
Исследователи из MIT и IBM Research предложили оригинальное решение — ChartNet, мультимодальный датасет для обучения моделей анализу и интерпретации графиков. Разберемся, как он устроен и насколько эффективен.
Как с помощью бесплатных инструментов Google создать систему анализа данных: от сбора ответов в форме до визуализации на сайте. В качестве примера разберем исследование туристических предпочтений и настроим автоматическую отправку письма при достижении цели.
В начале этого века сотрудниками лаборатории С.Э.Шноля (ИТЭБ РАН) совместно с Арктическим и антарктическим НИИ РАН на станции Новолазаревская в Антарктиде была организована посекундная регистрация альфа-распада плутония-239. Получаемые с 2001 по 2010 год кремниевыми счётчиками данные записывались в файлы, суммарный объём которых составил около 1 Гб. Задачей этого продолжительного эксперимента было доказательство влияния космофизических факторов на альфа-распад, которое могло проявляться в виде суточных, месячных и годовых циклов. Подобная цикличность противоречит давно устоявшимся воззрениям на случайный характер радиоактивности, поэтому антарктические данные не помогли С.Э.Шнолю (1930 - 2021) поколебать эти воззрения. Но он искал (и находил) закономерности в повторении формы поминутных гистограмм альфа-распада, а это не самый наглядный способ их демонстрации. Намного проще просто понаблюдать за интенсивностью альфа-распада. Причём иногда изменения этой интенсивности имеют довольно странный характер, который невозможно объяснить колебаниями температуры, атмосферного давления, сетевого напряжения, грозовыми разрядами и наводками от ближайших научных приборов и бытовой техники.
На данном этапе развития строительная отрасль в России проходит процесс цифровизации. Выпускаются национальные стандарты, например, предназначенные для облегчения совместимости программных средств, используемых на всех этапах жизненного цикла здания. Ключевой проблемой этого процесса является низкий уровень подготовки проектировщиков для работы с ЦИМ и, как следствие, низкое качество подготавливаемых моделей. Из-за этого происходит большой разрыв между графической частью проектной документации и моделями, на основании которых чертежи должны формироваться.
В данной статье я разберу принцип работы разработанного нашей командой инструмента для верификации чертежей с цифровой информационной моделью зданий.
Какие существуют подходы к верификации чертежей и ЦИМ и программные продукты для этого?
Сверка 2D-чертежей с ЦИМ критически важна для точности ведомостей объемов работ. Сегодня эту задачу решают двумя способами, оба из которых имеют ограничения:
1. Ручная верификация: визуальное сравнение модели и чертежей.
Плюсы: не требует ПО и спец. навыков.
Минусы: крайне трудоемка, подвержена человеческому фактору, данные невозможно систематизировать.
2. Верификация через САПР: проверка внутри системы проектирования.
Плюсы: высокая точность и прозрачность.
Минусы: нужны дорогие лицензии и глубокие знания ПО. Кроме того, госсектор ограничен в использовании иностранного софта.
Единственный существующий продукт с элементами автоматизации — швейцарская платформа Revizto. Но это инструмент для общей визуализации и координации, а не узкоспециализированный модуль прямой алгоритмической сверки чертежа с моделью.
Скормил новому встроенному скиллу Claude Code датасет на 76 лет — только ранги, без чисел. Модель сама выбрала перевёрнутую лог-ось, проверила палитру математикой и починила наезжающие подписи. Разбираю, как /dataviz устроен изнутри и почему из всех решений кодом проверяется только цвет
Что такое электронная таблица, объяснять не надо. Все знают Excel, и многие хоть раз им пользовались. История создания электронных таблиц тоже, на первый взгляд, незамысловатая и сравнительно недолгая: как только появились первые ПК, сразу началась разработка ПО для выведения на экран их монитора интерактивной таблицы, которая сильно облегчила бы работу бухгалтеров и менеджеров. IT-инженеры уложились в 15 лет, с конца 60-х до середины 80-х, чтобы создать электронную таблицу от начала и до конца – от разработки самого принципа ее программирования до появления первых электронных таблиц (от VisiCalc до Excel) на экране ПК, сильно порадовав тем самым белых воротничков (и не только их). Дальше шло лишь усовершенствование электронных таблиц.
С чего вдруг IT-инженеры и изобретатели озаботились бухгалтерскими проблемами, тоже понятно. Люди старшего поколения помнят, что можно было делать на первых ПК 70-х и 80-х годов, еще до эпохи интернета. Если оставить в стороне возможность самостоятельно заняться программированием и обмениваться файлами с такими же энтузиастами, что сейчас часто ставят в заслугу первым ПК (для этого все-таки надо было в душе быть айтишником), то на этих ПК можно было играть в интерактивные игры (правда, на игровых приставках к телевизору это обходилось дешевле) и можно было использовать ПК как пишущую машинку, при пользовании которой не надо было замазывать белилами ошибки и ждать, когда те высохнут, чтобы напечатать поверх правильную букву. Сказать, что это сильно порадовало писателей и редакторов бумажных СМИ значит ничего не сказать, это была настоящая революция в писательском и издательском деле, сравнимая разве что с изобретением печатного станка Гутенбергом в XV веке. А когда к этому добавились еще электронные таблицы для сведения дебета с кредетом в интерактивном режиме, это была еще одна революция в бухгалтерии того же масштаба, если не большего.
Недавно мы выкатили новость (кейс) о совместном проекте с компаниями «Полиэкс» и PIX BI о построении аналитической платформы (почитать можно тут). Все чинно-благородно (новостной язык суров): сроки, интеграции, архитектура. Но у нас с коллегами родилась идея – сделать перевод с делового языка на человеческий. И мы записали интервью с участниками проекта. Команда PIX BI задавала вопросы, а GlowByte и «Полиэкс» говорили как есть: от GlowByte – руководитель проектов Роман Прохоров, со стороны АО «Полиэкс» – ведущий аналитик службы стратегического развития Арина Бортникова.
Все знают авто-электриков и диагностов. Я IT-автоэлектрик объединяю знание физики автомобильных цепей и низкоуровневого программирования на С для создания инструментов анализа и изучения j1939.
CAN шина это мост между двумя мирами авто-электриков и IT специалиста. Но для многих этот мост, увы кажется непреодолимой пропастью. Ребята попробуйте программировать на Си и вы пойдёте по этому мосту. Я начинал программировать в телефоне termux. То есть для этого нужно только желание.
Я себя не считаю самым умным. Я просто нашел для себя мощную точку пересечения этих профессий и стал называть этот подход IT-автоэлектрик. Писать свои собственные утилиты на С чтоб заглянуть под капот CAN шины. Под капотом ДВС менее интересно.
Размер моих логов на сегодняшний день 1 - 3 мегабайта. Если вес лога гигабайты то по идее данные нужно положить в голову страницы и процессор полетит как пуля. Размер скомпилированного файла map_id_j1939.c и viz_j1939.c по 16.5 КБ.
Знаете это чувство, когда правишь JSON и ищешь, где же ты забыл запятую? Я устал и сделал редактор, где JSON — это таблица. А теперь он ещё и открывает папку проекта целиком: дерево файлов, Ctrl+S прямо в файл, drag & drop. Как в VS Code, только заточено под данные.
Искусственный интеллект постепенно становится частью BI-систем. Не остался в стороне и Yandex DataLens, где около года назад появился Нейроаналитик — встроенный AI-помощник для работы с данными. Недавно Яндекс представил Нейроаналитик 2.0, который получил новые возможности и стал работать как AI-агент.
Здесь хочу разобрать возможности Нейроаналитика, чем отличается Нейроаналитик 2.0 и какие ограничения стоит учитывать при работе с инструментом.
Краткая история внешней памяти и пять функций листа бумаги
Не претендуя на гениальность задался простым, на первый взгляд, вопросом: "На моем столе в 2026г всегда лежит лист черновика и пара карандашей?" Ответ оказался не таким коротким, как ожидал. Приглашаю к прочтению!
Всем привет!
Очень долгое время разработчики Telegram-ботов довольствовались двумя способами форматирования сообщений: HTML и Markdown. Оба этих способа делали одно и то же: добавляли простое форматирование в обычный текст.
Для большинства задач этого было достаточно, но в какой-то момент обычного HTML и Markdown может не хватать.
В недавнем обновлении Telegram Bot API 10.1 эту проблему решили, добавив Rich Messages. Обзор которого я и сделаю в статье.
Полгода назад я так устал вручную ковыряться в JSON, что написал свой редактор — просто чтобы не сойти с ума. Выложил статью на Хабр, не ожидая ничего особенного. А в итоге получил 54 звезды, 4 форка и десятки комментариев с болью, очень похожей на мою: у кого-то конфиги для Unity, у кого-то — прошивки, у кого-то — просто ненависть к блокноту как JSON-редактору. Рассказываю, как усталость от рутины превратилась в проект, который теперь развивает не только один человек, а целое небольшое комьюнити.
Наша третья статья на пути к созданию системе круглосуточной ситуационной осведомленности. Данный материл является подготовительным этапом перед созданием такой системы.
Меня зовут Александр Ларин, я руковожу центром обучения и технической поддержки в GlowByte. Мы постоянно внедряем FineBI у клиентов и регулярно слышим один и тот же вопрос: «а где почитать или посмотреть, чтобы разобраться самому?» Решил собрать ответ в одном месте.
Расскажу, как и почему я в какой-то момент решил написать собственный pivot grid — без сторонних библиотек, на чистом JavaScript и DOM. И что из этого получилось: от первой версии с обычным GROUP BY до кэширования больших выборок и цепочки связанных гридов.
Если зададите «закупщику» вопрос о проблемах, которые ему приходится решать на каждодневной основе, то «пустая рюмка и взгляд полный грусти будет вам ответом». Дальше последует уходящий в бесконечность список с описанием того, что болит, и достается в нем и нашим и вашим. Вспоминают и ненадежных поставщиков, и задержки поставок, и перерасход по контрактам, но в большинстве таких списков фигурирует проблема, настигающая «закупки» еще в самом начале цикла: идентификации потребности и формирования заявки на закупку.
Сегодня разберем один из подходов, помогающий снизить градус проблемы с формированием потребностей: внедрение в регламент закупок чек-листа на фазе формирования потребности. Покажем на живых примерах, как ИИ-аналитик Raft AI4BI может помочь в имплементации подхода.