Полезные ссылки про данные, технологии и не только:
- 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

Полезные ссылки про данные, технологии и не только:
- quackstore расширение для DuckDB для кеширования облачных дата файлов, позволяет сильно ускорить выполнение запросов к облачным файлам благодаря их частичному сохранению. Полезная штука, её можно бы и сразу внутрь DuckDB ибо логично
- Catalog of Patterns of Distributed Systems для тех разработчиков кто хотят не только кодировать, но и двигаться в сторону архитектуры ПО.
- The Data Engineering Agent is now in preview Гугл запустили ИИ агента для дата инженеров внутри BigQuery, конечно же на базе Gemini. Дайте мне такой же только с открытым кодом и без инфраструктуры Google и с поддержкой всех основных инструментов и СУБД!
- Diseño del V Plan de Gobierno Abierto 2025-2029 5-й план по открытости гос-ва опубликовали власти Испании. Сейчас проходят публичные консультации и далее он будет утвержден. Открытые данные там, конечно же, присутствуют

#opendata #opensource #rdbms #datatools #dataengineering #ai

Часто встречающаяся задача когда необходимо быстро создать API над какими-то данными и предоставить его внутренним и/или внешним пользователям. API, как правило, нужно для одной или нескольких из перечисленных причин:
1. Данные обновляются слишком часто чтобы делать дампы или предоставлять к ним прямой доступ
2. Необходимо предоставить данные недоверенным пользователям и поэтому прямой доступ к данным невозможен
3. Данные предоставляются на каких либо условиях предусматривающих ограничения, например, за деньги и ограничением числа записей за раз
4. API необходимо для интеграции с каким-либо существующим ПО которое умеет в API, но плохо или совсем не умеет работать с дампами и выгрузками данных
5. Нужна возможность ссылаться постоянными ссылками на конкретные записи в машиночитаемом виде.
6. API нужно, например, для быстрого написания фронтэнда или иного интерфейса которое бы через это API работало

Ситуации когда нужно сделать API достаточно частые и я лично за эти годы перебрал немало инструментов с помощью которых это можно делать и написал несколько своих.

Эти инструменты можно поделить на условно 3 типа:
- преобразующие данные в API
- создающие API поверх SQL и других баз данных
- позволяющие загрузить данные и сразу получить API на выходе

Для превращения данных несколько инструментов существовало относительно давно, например, csv-to-api и csv2api, они работали с CSV файлами и в общем-то довольно просты

Для баз данных есть инструменты вроде:
- gosql относительно свежий, работает поверх условно любой SQL базы данных
- Express REST API Generator - для MongoDB, давно не обновлялся
- RestHEART аналогично для MongoDB, но вроде как живой
- DataBeam код 12-летней давности от GSA (орган пр-ва США) с поддержкой преимущественно тяжелых корпоративных баз данных

И, наконец, есть какое-то число low-code инструментов вроде Retool, Baserow, Directus и тд. которые позволяют загружать туда таблицы и генерируют интерфейс для их редактирования и API заодно.

В своё время я сделал два похожих инструмента. Первый, самый простой, apiready грузил данные в MongoDB (в основном это были csv или tsv) файлы, анализировал их и создавал API поверх них. Я этот инструмент довольно быстро забросил и писал его оочень давно.

Более продвинутый инструмент был apicrafter вместо загрузки данных, он строился поверх базы MongoDB и создавл интерфейсы с помощью Python Eve довольно удобного инструмента, но статического. А apicrafter анализировал данные и собирал схему для работы Python Eve.

Когда-то я думал сделать этот инструмент поумнее и автоматически генерировать не только точки к API, но и документацию, примеры и тд., но со временем я начал убеждаться что MongoDB - это, конечно, неплохая штука, но с несколькими системными изъянами главные из которых низкая производительность и серьёзная неэффективность в хранении данных. В общем-то DuckDB или Polars или другие датафреймовые инструменты дают качественно лучший опыт в работе с данными, но переписывать под них не так то просто и главное нужно применение.

Тем не менее если решать не общую задачу, а конкретную по организации доступа к данным со всеми ограничениями, то может оказаться что схема данных + FastAPI + ИИ агент помогут собрать REST API гораздо быстрее. А могут и не собрать😂

В любом случае полезно знать про альтернативы и инструменты.

#api #opensource #datatools

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

Сама утилита эта работа как обертка вокруг множества приложений в операционной системе: pngquant, jpegoptim, 7z, zip и тд, но вот одна беда что она устарела и её надо было переписать.

Так что я её использовал как второй полигон для проверки кодирования с помощью ИИ (первый был с библиотекой iterabledata).

Итого:
- утилита filesrepack полностью переписана и теперь умеет две команды: repack - сжимать одиночные файлы, bulk - сжимать файлы внутри папки, рекурсивно
- добавлена поддержка множества новых форматов файлов: tiff, parquet, avi, avf, svg, gif, rtb, pages, numbers, key и других
- 90% кода написано с помощью ИИ агента Cursor'а (2-я версия Cursor, режим автовыбора моделей)
- существенные ошибки были лишь пару раз, достаточно легко они исправлялись
- у ИИ агента очень неплохое понимание контекста и того для чего сделано приложение и очень хорошие ответы на вопросы вроде "проанализируй приложение и предложи какие опции были бы полезны для его пользователей" или "предложи форматы файлов которые можно было бы оптимизировать и которые пока не поддерживаются"
- наибольшая польза, по прежнему, в автоматическом написании документации что очень удобно для всякого рода утилит и программных библиотек где не надо скриншотов и сложных сценариев.
- для такого простого практического применения ИИ агенты, действительно, прекрасно подходят и ускоряют работы многократно, а также помогают закрыть дыры в документировании, тестировании и тд.
- по ощущениям можно уже применять ИИ агенты и для промышленного применения в сложных системах, но, конечно, с существенно большей осторожностью и дополнительными мерами по верификации кода
- все в совокупности, конечно, огромный прогресс за последний год. Ранее когда я пытался применять ИИ агенты, было ощущение что галлюцинаций существенно больше чем результата.
- в любом случае джуниорам я категорически не рекомендую начинать изучение программирования через ИИ ассистенты. Что бы понимать насколько созданный код хорош и адекватен нужно уметь создавать его самостоятельно иначе можно наделать серьёзных ошибок

Далее я уже расскажу про практическое применение ИИ для работы с кодом и создания индекса в Dateno, но этим кодом поделиться уже можно только в отдельных отчуждаемых компонентах.

#opensource #tools #ai #coding #thoughts

В контексте премии по открытому доступу в гуманитарных науках (humawards.ru) о том как предоставлять материалы в открытом доступе.

1. В основе открытости данных исследователей лежат принципы FAIR (Findability, Accessibility, Interoperability, Reuse). Описание на русском языке есть в русскоязычной википедии и многих онлайн ресурсах, их легко найти по ключевым словам "принципы FAIR".
2. Ключевое в этих принципах в публикации данных результатов исследований таким образом чтобы их могли использовать другие и в использовании данных другими опубликованные. Использование включает юридические права (свободные лицензии), техническую возможность (удобные форматы и документация) и находимость (возможность найти эти данные).
3. Для публикации данных исследователи в мире чаще всего используют такие порталы как Zenodo, Figshare, Dataverse, институциональные репозитории и специализированные репозитории данных по своим дисциплинам.
4. Альтернативно часто данные публикуются на открытых платформах для публикации исходного кода таких как Github и Gitlab или же через развертывание собственных порталов для данных, к примеру Инфокультура поддерживает портал hubofdata.ru в России.
5. Кроме публикации данных к открытому доступу можно отнести и публикацию открытого кода, как правило, также публикуемого на платформах вроде Github или Gitlab, реже на других сайтах.
6. Конечно, кроме этого существует многие материалы по открытому доступу которые не являются данными или кодом, это могут быть курсы, лекции, просветительские материалы, для которых, впрочем, хорошей практикой является их публикация под свободными лицензиями такими как CC0, CC-BY и им подобные.

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

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

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

#opendata #openaccess #contest #humanitarian #opensource

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

#opensource #ai #privacy #llm #tools #datatools

После экспериментов с простым кодом, я постепенно добрался до тех инструментов которые используются внутри 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

Короткий текст The fate of “small” open source где автор рассказывает о будущей печальной судьбе программных библиотек на примере свой библиотеки blob-util и того что ИИ агенты не предлагают использовать её, а автоматически генерируют код.

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

Итоговые изменения пока малопредсказуемы, но вероятность того что многие библиотеки кода будут быстро устаревать весьма вероятно.

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

Похоже на реалистичный сценарий?

#opensource #ai #llm