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

Но то что кто-то может назвать когнитивным искажением, можно назвать и способом взгляда на те или иные явления. И вот один из таких способов восприятия реальности - это смотреть на все как на список. Список дел, список строк в файле, список записей в БД и так далее. А если по списку можно проходить и что-то делать с тем что в нем находится то он является перебираемым или на английском языке iterable.

Собственно под восприятия мира данных того что большая часть структур данных, форматов дата файлов и тд - это перебираемые списки я когда-то создал, а недавно обновил библиотеку iterabledata для Python.

Изначально она создавалась для того чтобы реализовать для JSON/JSON lines файлов логику перебора содержимого по принципу csv.DictReader, стандартной библиотеки в Python в которой перебираемые объекты возвращаются как словари. Заодно добавив к этому что чаще всего эти файлы с данными сжаты чем-то Gzip, LZMA, Zstandard и тд.

А в этот раз я обновил эту библиотеку для большей универсальности и поддержки десятков новых форматов данных DBF, JSON-LD, KML, GML, CSVW, Annotated CSV, MessagePack и еще много, полный список.

Включая некоторые экзотические форматы такие как WARC для веб-архивации, которые тоже можно рассматривать как объекты со списками для перебора.

А в качестве наглядного примера, преобразование дампа Википедии из сжатого XML в Parquet.

Особенность Iterable Data именно в универсальности инструмента, но не в скорости обработки данных. Для супербыстрой обработки, например, CSV файлов есть и другие инструменты, но CSV лишь один из десятков встречающихся форматов данных.

Так что инструмент полезный и обновлялся мной сейчас в контенте задач в Dateno, в открытые репозитории которого я и перенес его из личных пэт проектов.

#opensource #dateno #datatools #dataengineering

Рассеянные мысли про разное:
1. В продолжение когнитивных искажений или искажений восприятия в наблюдениях последнего времени часто встречаю ещё два случая:
- декларативизация всего что возможно, иногда в форме YAML'ификации, когда декларативное описание (в сформе структурированного описания конфигурации) кажется панацеей для всего. Панацеей оно, конечно, не является и даже вызывает раздражение у многих разработчиков, но становится удобным при использовании ИИ агентов которые как раз такое декларативное описание понимают очень неплохо.
- маркдаунизация всего и вся, ловлю себя на том что стало неудобно писать тексты в Word'е, совсем неудобно, все время хочется использовать синтаксис маркдауна. Кроме того для скармливания объектов ИИ также часто преобразование в Markdown кажется более логичным чем во что-то другое.
2. По прежнему жизненно не хватает продвинутых инструментов управления контактами, такое ощущение что они вымирают и ни один из крупнейших сервисов не дает удобного API для их обогащения. Например, для управления контактами в Google нужно оттанцевать много с бубном чтобы добавить/изменить контакт автоматически. Когда у тебя пара сотен контактов - это не проблема, когда несколько тысяч - уже ощутимо.

#thoughts

Полезное чтение про данные, технологии и не только

AI
- Introduction to AI Agents хорошо написанный четко изложенный документ от Google. Полезно для быстрого погружения в тему
- State of Agent Engineering обзор от LangChain состояния разработки ИИ агентов через опрос 1300 специалистов
- 2025 LLM Year in Review обзор 2025 года с точки зрения LLM, с погружением в технологии, от Андрея Карпатого
- AI Scraping and the Open Web о том что владельцы контента перешли к юридической защите от ИИ скрейперов после того как технические меры перестали работать

Облачная инфраструктура
- Let’s talk about GitHub Actions в блоге Github о том как они переделали Github Actions. Важное для всех что Github Actions использует. Важное тем что для многие GA стали заменой собственных ETL/ELT инструментов и многие конвееры работы с данными и другими действиями живут на Github.

Инструменты
- headson инструмент для выполнения команд типа head/tail для JSON и YAML файлов. Бывает полезно, но как-то узковато, больший универсализм был бы полезнее
- AGENTS.md спецификация для управления кодирующими ИИ агентами через специальный Markdown файл
- chandra модель для OCR с обещанием поддержки сложных структур и таблиц. Надо пробовать, правда ли так работает.
- Mistral OCR 3 свежая ИИ модель от Mistral для OCR, тоже обещают работу со сложными таблицами

Разное
- On the Immortality of Microsoft Word о бессмертии MS Word и почему Markdown не может заменить его, например, в работе юристов с документами

#opensource #ai #readings

В продолжение рефлексии про применение ИИ агентов в разработке. Мои личные ощущения от применения для различных задач.

Документирование. Почти на 100% закрывается с помощью ИИ агентов, при условии что сам код ясно написан и в коде документация присутствует (в Python это обязательные docstrings). Как простая документация так и сложная генерируется без излишних сложностей, но как и код её необходимо тестировать промптами в условном стиле "проверь что все примеры упомянутые в документации являются рабочими" (в реальной работе немного сложнее, но и так можно).

Тестирование. Около 90-100% тестов кода могут генерироваться автоматически, остальное с некоторой помощью. Закрывает практически все общепонятные ошибки связанные с особенностью языка и его стилистики. не закрывают какую-либо сложную логику работы с не самыми очевидными продуктами, устройствами, интеграцией и тд.

Исправление ошибок. По ощущениям эффективности уже в районе 50-80% (до 8 из 10 задач выполняются сразу правильно, без необходимости корректироки). Практически все задачи линтинга кода и большая часть задач исправления ошибок по итогам неудачных тестов. Наиболее часто несрабатывающие исправления касаются взаимодействия с другими сервисами, серверами, параллельно разрабатываемыми продуктами.

Генерация кода. Варьируется от 40% до 70% эффективности, чем более комплексная задача тем хуже результат в виде кода. Простые задачи умеют хорошо делать уже почти все ИИ агенты, сложные часто приводят к переусложненному коду. Например, в качестве теста я делал REST API поверх написанного на Python SDK. Cursor при его реализации начал ваять сложный промежуточный код для обработки данных и преобразования типов хотя все то же самое можно было бы сделать значительно проще простыми исправлениями в оригинальном SDK. Вот эта вот контекстность в решении проблем это особенность ИИ агентов. Они пока не предполагают что решения проблем могут быть за пределами рассматриваемой ими кодовой базы.

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

Разработка дата продуктов (декларативное создание баз данных). Это то что я рассказывал ранее про то что справочные данные можно создавать в виде множества YAML файлов которые расширять и собирать в наборы данных с помощью ИИ агентов. Здесь эффективность весьма вариативна. Чем больше гранулярности в задаче, тем она выше, но исправлять результаты и расширять их нужно практически всего. Однако и это снижает трудоемкость создания датасетов в десяток раз, не меньше.

#thoughts #ai

Суверенное импортозамещение по французски La Suite numerique (Цифровой комплект) в виде набора приложений с открытым кодом включающий:
- Tchap - мессенжер
- France Transfer - сервис передачи больших файлов
- Docs - совместная работа над документами
- Grist - управление проектами
- Visio - видеоконференции
- Messagerie - электронная почта
- Fichiers - управление общими файлами.

Все это в варианте, либо локального развертывания, либо на федеральном портале ProConnect

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

#opensource #france #government

В рубрике как это устроено у них (наверное) портал открытых данных ЕАЭС opendata.eaeunion.org

Содержит реестры и ресурсы ЕАЭС в части разрешительной работы и совместной деятельности.

Предоставляет отраслевые данные через REST API и по стандарту API OData.

Плюсы:
- данные общедоступны декларируемые явным образом как открытые
- хорошо документированное стандартизированное API
- много разных отраслевых данных

Минусы:
- свободные лицензии не указаны явным образом
- нет возможности массовой выгрузки (сразу все), у API ограничение по выгрузке до 5000 записей за раз
- данные рассеяны по множеству отраслевых подсайтов что неудоьно при желании скачать все

#opendata #datacatalogs

В рубрике как это устроено у них открытые данные в Австрии собраны на национальном портале data.gv.at где опубликовано 63 тысячи с небольшим наборов данных по самым разным тематикам. Портал работает на базе ПО CKAN, к нему доступно REST API, а данные экспортируются в форматах связанных данных и почти у всех наборов данных есть привязанная свободная лицензия. В целом портал и все инициативы по открытым данным в Австрии напрямую взаимосвязаны и ссылаются на политики Евросоюза и, в частности, сейчас имеют фокус на публикацию данных особой ценности (HVD) и переход к публикации данных необходимых для обучения ИИ.

Некоторые особенности австрийского портала данных в том что, как и во многих других странах, создатели портала используют искусственное дробление наборов данных для демонстрации их количества. так из 63 тысяч наборов данных 52 тысячи наборов данных - это файлы муниципальных бюджетов страны (1692 муниципалитета) разбитые по годам примерно за 20 лет и по нескольким вида бюджетной отчетности с другого официального портала www.offenerhaushalt.at

Все эти 52 тысячи наборов данных можно свести от 1 до 1692 (единая база или дробление только по территориям), а все остальное это очень искусственное разделение не имеющее отношения к сценариям использования пользователями.

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

В целом же в Австрии 58 порталов данных и это скорее всего не все из них подсчитаны, реально может быть и больше. Многие данные публикуются в исследовательских репозиториях данных или в каталогах геоданных, которые лишь частично собираются на национальном портале.

#opendata #austria #datacatalogs

У меня есть довольно давняя отложенная нерабочая задача - это извлечь с каталога музейного фонда РФ (goskatalog.ru) материалы по армянскому культурному наследию для чего я когда-то выгружал с портала данных Минкультуры РФ битый датасет этого реестра и преобразовывал 88ГБ текстовый файл в 2.7ГБ файл Parquet с 31.7 записями о культурных объектах. А также есть примерно 100 регулярных выражений позволяющих найти записи в которых есть прямое или косвенное упоминание Армении или армянской культуры.

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

А теперь о подходах как такую задачу можно решить.

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

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

Неэкономное продвинутое программирование. Обращаешь внимание что записи в данных не зависят друг от друга и находишь компьютер с большим объемом памяти и множеством ядер или арендуешь дорогой облачный сервер, разрезаешь оригинальный файл с данными на 100 по 370 тысяч записей каждый и запускаешь их обработку параллельно по числу доступных ядер

Экономное хардкорное программирование. Обращаешь внимание что регулярные выражения - это медленно почти всегда и на то что не все поля в оригинальных данных нужны. Оптимизируешь и пересобираешь оригинальный файл с данными так чтобы он содержал только id записи и поля с нужными текстами, переписываешь регулярные выражения на pyparsing или разворачиваешь их в текст для полного мэтчинга и, конечно, тоже разрезаешь файл с данными на 100 (или сколько нужно) и параллельно запускаешь обработку не обязательно на продвинутом железе. Думаешь о том не переписать ли все это на Rust

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

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

Вайб-кодирование. Описываешь эту задачу ИИ агенту и он за тебя генерирует код (скорее всего не самый высокопроизводительный) и дальше уже по аналогии с ленивым программированием

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

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

#thoughts #programming #dataengineering

В рубрике как это устроено у них Fairstack 1.0 комплект продуктов и сервисов от Китайской академии наук (СAS) по организации инфраструктуры работы с данными для исследователей. Включает множество инструментов с открытым кодом и разработанных в компьютерном центре CAS для организации работы исследователей.

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

#opendata #datacatalogs #china

Ещё в рубрике как это устроено у них FranceArchives официальный архивный портал Франции. Включает более 29 миллионов записей из которых более 5 миллионов - это оцифрованные документы, фотографии, карты и иные цифровые артефакты агрегированные из сотен музеев и архивов страны.

Предоставляют открытое API в виде интерфейса SPARQL, у каждой записи есть RDF, JSON-LD и N3 карточки с описанием со всеми метаданными в структурированой форме и есть возможность получить карточку записи в виде CSV файла.

#opendata #data #digitalpreservation

Любопытные граждане нашли в выложенных документах по делу Эпштейна что текст там замарывали в виде слоя к PDF файлу и содержание под слоем читается даже без спецсредств, просто выделением текста

Думаю что в ближайшее время Минюст США эти документы начнет снимать и заменять на реально вымаранные, но как же они умудряются в одну и ту же лужу вступать неоднократно. Я помню как много лет назад в США сотрудники Пентагона выкладывали вымаранные документы, тоже через PDF слой, а считывали его через комбинацию: Ctrl+A, Ctrl+C, Ctrl+V.

Все это приводит к нескольким тезисам:
1. Некомпетентность свойственна не только сотрудникам госорганов небогатых стран, но и богатых.
2. Если что-то рассекречено, надо сразу делать копию, потому что уже завтра могут начать править, удалять и исправлять.

#privacy #usa #documents