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

- undatum - многофункциональная утилита для обработки данных изначально в формате JSON lines, делалась как xsv для JSON/JSON lines, я её лично активно и везде применяю.
- docx2csv - утилита по извлечению таблиц из файлов MS Word (.docx), настолько простая что надо её с чем-то объединить
- mongo2md - инструмент автоматизации документирования коллекций в MongoDB было полезно когда MongoDB была в основе технологического стека разных проектов, сейчас скорее буду переводить в статус легаси, но полезно как пример автодокументирования.
- metawarc утилита по извлечению метаданных из файлов WARC, умеет собирать данные из pdf, doc, docx, pdf, png, jpg, xls, xlsx и других файлов документов и изображений. Полезна для разного рода OSINT задач и для автоматизированного анализа WARC файлов
- apibackuper утилита для сбора данных из API через декларативно заданные правила. Использую её повсеместно и всё время хочу переписать чтобы вместо cfg файлов использовать yaml/toml, заменить zip контейнеры на базу duckdb и в целом сделать удобнее. Но и так работает
- wparc архиватор API и данных из Wordpress и файлов заодно. Одна из утилит для архивации сайтов для RuArxive
- lazyscraper скрейпер сайтов для лентяев, когда хочется извлечь данные минимальными усилиями и без программирования. Я её чуть-чуть не доделал чтобы даже xpath не использовать, но в остальном вполне рабочий инструмент
- metacrafter мой любимый инструмент идентификации структуры таблиц в файлах и таблицах с данными. Надо объединить с undatum её конечно же
- apicrafter утилита по быстрому созданию API поверх коллекций в MongoDB. Когда-то использовалась в проектах где основной стек был на MongoDB, сейчас всё по другому я бы делал

#opensource #data #datatools

Подборка ссылок про данные, технологии и не только:
- transferia инструмент для переноса данных между разными базами данных причем поддерживает не только SQL, но и выгрузку и загрузку данных в MongoDB, OpenSearch, Elasticsearch. Судя по именам разработчиков и поддержке YTSaurus создатели продукта русскоязычные. Сам продукт пока не очень популярен, но лично у меня под такое задачки есть, надо тестировать
- Affine набирающая популярность замена Notion с открытым кодом. Делает его сингапурский стартап которые создают на его базе облачный сервис с подпиской и они же распространяют версию с открытым кодом. Выглядит симпатично и лозунг у них Write, Draw, Plan. Пиши, рисуй, планируй. ПРП в общем
#opensource #data #tools

Полезные ссылки про данные, технологии и не только:
- A Deep Dive into DuckDB for Data Scientists о том как дата сайентистам использовать DuckDB. Если коротко, то всё довольно просто и понятно.
- ClickHouse welcomes LibreChat: Introducing the open-source Agentic Data Stack Clickhouse поглотил LibreChat, инструмент с открытым кодом для создания ИИ чатботов. Инструмент был хороший, надеюсь таким и останется.
- Hannes Mühleisen - Data Architecture Turned Upside Down отличное выступление Hannes Mühleisen про ключевые изменения в архитектуре данных последних лет. Полезно и по смыслу и по визуальному представлению хорошо
- agor: Next-gen agent orchestration for AI coding ИИ агент для управления ИИ кодированием, автор его создатель Superset и позиционирует этот проект как думай об асситентах для кодирования как о Figma. С открытым. кодом. Любопытно, но ИМХО автор плохо объясняет преимущества, как подхода, так и интерфейса.

#opensource #data #datatools #dataengineering #ai

Ещё одна совсем-совсем свежая спецификация PLOON для отправки данных в ИИ агенты с максимальной экономией токенов. Экономит до 60% в сравнении с JSON и до 14.1% в сравнении с TOON. Автор написал бенчмарк показывающий что PLOON сильно экономнее других форматов. Уже прям любопытно что дальше, когда наступит момент что ИИ агенты смогут нормально употреблять бинарные данные и тогда все эти оптимизации будет очень легко заменить.

#ai #data #dataengineering #specifications

После экспериментов с простым кодом, я постепенно добрался до тех инструментов которые используются внутри Dateno для сбора данных. Один из них это утилита apibackuper которая помогает вытащить данные публикуемые через API и сохранять их в виде датасета. Фактически это инструмент скрейпинга API через декларативное описание параметров скрейпинга (да, я люблю декларативные описания). У инструмента был ряд недостатков которые я исправлял и думаю что исправил, вот перечень изменений:
- переход от декларативного описания скрейперов с INI (.cfg) файлов на YAML, читать легче, синтаксис приятнее
- валидация YAML описаний через JSON схему
- поддержка ограченичений и таймаутов на число запросов в минуту (Rate Limiting)
- поддержка аутентификации к API
- экспорт данных не только в JSONL, но и в Parquet
- автоопределение формата экспорта данных по расширению файла
- массовое обработка исключений и понятные сообщения об ошибках везде где возможно
- тесты для покрытия большей части кода
- подробная документация
- и всякое по мелочи

Я этот инструмент изначально разрабатывал для для архивации данных публикуемых через API, но сейчас он используется в части кода Dateno для выгрузки метаданных из каталогов данных. Может его даже пора уже перенести из ruarxive в dateno на Github'е, ещё не решил.

На скриншоте то как это выглядит на примере реестра лекарственных средств ЕСКЛП

Для сбора данных достаточно выполнить две команды
- apibackuper run
- apibackuper export current.parquet

Первая выгрузит все данные постранично, вторая сохранит выгруженные данные в parquet файл.

#opensource #datatools #data #dataengineering

В рубрике полезных инструментов для сбора данных tdl (Telegram Downloader) инструмент командной строки,написан на Go, под лицензией AGPL-3.0, позволяет выгружать списки сообщений, сами сообщения и файлы и проводить другие манипуляции по выгрузке списков чатов, их участников и другой информации.

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

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

Мне лично нравится как сделан этот инструмент по архитектуре, логике команд, набору опций (выкачивать только сообщения, скачивать медиа) и так далее. Хотелось бы такой же, но универсальный для разных платформ и соцсетей или даже отдельные для других платформ сделанные по схожей логике. Для РФ скоро будет актуален инструмент для выгрузки чатов и каналов в MAX потому что у MAX'а нет открытой веб версии без авторизации как это есть у телеграм'а (пример - https://t.me/s/begtin) и все что создается внутри платформы не архивируется. Но это уже отдельная тема.

Пока же tdl полезный инструмент для телеграма и хорошая референсная реализация подобных инструментов для других задач.

#opendata #opensource #digitalpreservation #data #tools

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

Есть три основных категории пользователей и у каждой из них свой набор ожиданий :
1. Аналитики
- максимальная оперативность данных
- доступность данных в форматах привычных для работы (CSV, XLSX)
- возможность доступа к данным аналитическими и No code/Low code инструментами
- наличие данных по ключевым наиболее значимым темам (официальная и ведомственная статистика, например)

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

3. Разработчики и дата инженеры
- доступность данных через API
- доступность данных для массовой выгрузки (bulk download)
- доступность схем и структур данных
- наличие данных в современных форматах для выгрузки: сжатые CSV, Parquet и др.
- наличие предсказуемой инфраструктуры для интеграции с ETL/ELT системами получения данных
———
У этих 3-х групп есть ряд подгрупп которые имеют свою специфику:
- журналисты. Имеют те же требования что и аналитики, с меньшим погружением в технологии, с большим погружением в доступность данных.
- AI/ML инженеры. Помимо ожиданий разработчиков и дата инженеров у них еще присутствует потребность именно в данных большого объема для обучения, интегрируемость в стеки данных и интегрируемость в продуктами вроде Hugging Face
- статистики. Это не только сотрудники статслужб, но и профессиональные пользователи их данных. Они могут быть аналитиками и исследователями и тут важным становится наличие значимых метаданных и специальных стандартов и форматов SDMX, DDI и тд.
- геоаналитики и георазработчики. Подгруппы аналитиков и разработчиков с упором на геоданные, ключевое здесь это наличие возможности поиска данных по геопривязке, получению их в форме стандартизированных API ArcGIS/OGC и возможность выгрузки в наиболее востребованных форматах геоданных
—
Пользователь может быть в одной роли или хоть сразу в нескольких, важно то что любые публикуемые данные и создаваемые дата каталоги можно четко разметить по их потенциальным пользователям.

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

К примеру, когда я ругаюсь в адрес российского портала data.gov.ru, то могу объяснить это довольно просто. Можно посмотреть на него глазами любой из перечисленных ролей/групп пользователей и убедиться что для их задач он непригоден.

#opendata #users #thoughts #data

В рубрике интересных каталогов данных сеть порталов для публикации онтологий:
- https://biodivportal.gfbio.org/ - портал по онтологиям по биоразнообразию
- https://bioportal.bioontology.org/ - портал биомедицинским онтологиям
- https://technoportal.hevs.ch/ - репозиторий онтологий по технологиям и инженерии
- https://earthportal.eu/ - портал онтологий по наукам о Земле.
- ... и многие другие

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

Их можно относить к каталогам данных, я их также вношу в реестр каталогов данных Dateno и их также можно индексировать в поисковой системе, хотя объём проиндексированного будет невелик, но полезен для некоторых категорий пользователей.

#opendata #datasets #data #datacatalogs #ontologies #linkeddata

Полезное чтение про данные, технологии и не только:
- Compute Is the New Oil статья в FA о том что чипы для ИИ стали основной для дипломатии США и стран Персидского залива и о том что вычислительные мощности - это новая нефть. Ну вы меня поняли, теперь если кто-то ляпнет что "данные - это новая нефть", то можно записывать его в древние ретрограды, потому что теперь чипы-чипы-чипы. По крайней мере на уровне глобальной дипломатии
- The Nation’s Data at Risk: 2025 Report доклад американской ассоциации статистиков о кризисе статистики в США, много критики, много рекомендаций в центре которого восполнение дефицита сотрудников, но еще много всего. Хочется тут конечно понять что если в США в статистике кризис, то что в России, апокалипсис? Армагеддон? Все познается в сравнении
- Personal Data Architectures in the BRICS Countries книга о персональных данных в странах БРИКС в Oxford Press, ещё не читал, но любопытно по некоторым странам. Есть правда подозрение что авторы могут недостаточно понимать внутреннюю кухню и смотрят на это глазами кабинетных исследователей

#readings #privacy #statistics #data

В рубрике полезного чтения про данные, технологии и не только:
- Saloni's guide to data visualization гайд по визуализации данных с акцентом на наглядность научных данных, хорошие примеры, понятные советы
- Useful patterns for building HTML tools обзор HTML инструментов, в том числе созданных с помощью LLM.Немного за пределами моих интересов, но взгляд на эти инструменты который я лично упускал.
- Economics of Orbital vs Terrestrial Data Centers про обоснованность и возможность создания дата центров на орбите Земли. Любопытно, хотя и не кажется практичным в ближайшие годы
- Cloudflare Radar 2025 Year обзор трендов 2025 года от Cloudflare, обзор большой, в том числе страновой и есть что посмотреть по разным странам. Тянет на отдельную заметку, а пока просто закладка на чтение

#readings #data #dataviz

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

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

#opendata #data #digitalpreservation

В продолжение истории про документы выложенные Минюстом США и в которых замазанный текст легко распознается я скажу вам что совершенно не удивлен и косяков госорганов и корпоратов в работе с документами и данными я знаю много, хотя и рассказывать про большую часть не могу и не хочу потому что не чувствую своей принадлежности к рынкам инфобеза и OSINT. Расскажу лишь некоторые примеры не называя имен

1. Скрытые, но доступные данные в недокументированном API
Госорган создает общедоступный портал с некоторой информацией и портал построен по уже классической трехзвенной структуре: База данных -> Слой API -> Веб интерфейс. При этом все ограничения в доступе к данным делаются только на уровне веб интерфейса, а через API вполне можно собирать записи имеющие статус "удаленные" или "черновики". Ситуация вообще не редкая и возникает от недостатка квалификации постановщика задачи, разработчиков и недостаточного тестирования

2. Скрытые данные в общедоступных материалах
Многие форматы публикации текстов, таблиц и изображений имеют свои особенности позволяющие как скрывать часть содержания так и "раскрывать" его. Пример с закрашиванием PDF файлов всем хорошо известен, а есть, к примеру, случаи когда публикуются Excel файлы со скрытыми вкладками, частенько когда публикуют статистику ее рассчитывают на более детальных первичных данных в другой вкладке, а потом эту вкладку скрывают, а не удаляют. Так чувствительные данные внутри Excel файлов становятся общедоступными. Есть и другие случаи когда одни файлы MS Office погружают в другие, а когда запускают процесс удаления метаданных он вырезает метаданные из основного контейнера, но не удаляет их из внедренных файлов. И так далее, это только то что совсем на поверхности

3. Доступное API стандартизированного ПО
Организация выбирает стандартизированное ПО для сайта, а у этого стандартизированного ПО (CMS) есть какое-то количество опять же стандартно общедоступных API о которых они могут и не подозревать. Я привожу часто в пример WordPress у которого есть открытые эндпоинты дающие возможность находить документы ссылок на которые может не быть на сайте, но сами файлы остаются. Например, если кто-то загружает документ в WordPress и потом делиться на него с кем-то по прямой ссылке, то даже если на страницах сайта этого документа нет, то в API он доступен. WordPress - это пример, кроме него есть немало других CMS и веб фреймворков имеющих такую особенность
—
Насмотревшись всего этого в больших количествах я совершенно не удивляюсь когда вижу как в очередной раз кто-то попадается на такой лаже как "затереть текст в PDF файле", думаю что еще не раз такое будет.

А я про такое пишу пореже потому что лично мне открытые данные и дата инженерия куда интереснее, кроме того рассказывая какой-либо кейс с такими утечками данных всегда велика вероятность что канал утечки исчезнет;)

#thoughts #osint #data #privacy

Полезное чтение про данные, технологии и не только:
- How to Stay Ahead of AI as an Early-Career Engineer в IEEE Spectrum о том как меняются требования к джуниорам в ИТ на фоне применения ИИ. Если вкратце то требования к кандидатам растут, хуже всего тем кто умеет не начальном уровне кодить и не вкладывался в собственное развитие многие годы. Ключевой вопрос в том как должно меняться образование?
- Congress: Protect NCAR and Climate Research союзе обеспокоенных ученых в США призывает остановить закрытие Национального центра атмосферных исследований (NCAR) США которое недавно было анонсировано администрацией Трампа
- The Hidden Price of Data статья в журнале IMF про то как измерять стоимость данных в экономике и экономическими методами, автор статьи написала книгу на эту тему, тоже полезную для понимания того как экономика данных устроена.
- Instagram CLI для тех кто любит текстовые терминалы и серьезное намерен бороться с "гниеним мозга" (brainrot) утилита для работы с инстаграмом с командной строки. Я бы пошел дальше и вместо отображения изображения сразу бы давал текстовое описание извлеченное из него с помощью LLM

#ai #instagram #data #careers #it