Полезные ссылки про технологии, данные и не только:
- Top Programming Languages 2024 [1] от IEEE Spectrum, для интриги не назову языки лидеры. Но всё очевидно:)
- GCSE results 2024: The main trends in grades and entries [2] лонгрид про данные результатов британского экзамена GCSE от Education Datalab.
- New Washington Post AI tool sifts massive data sets [3] в Axios о том что у Washington Post новый ИИ инструмент для просеивания данных, через него уже прогнали базу видеороликов кандидатов в президенты [4].
- Using Perplexity to prepare to job interview [5] автор описывает инструкции и шаблон промпт по подготовке к интервью компании на основании описания вакансии. Эта идея имеет больше глубины чем кажется на первый взгляд. Применимо не только к подготовке к интервью, но и в принятии решения откликаться ли на вакансию.
- Benchmarking energy usage and performance of Polars and pandas [6] сравнение энергопотребления при использовании Polars и Pandas. Интересен сам факт сравнения, но объекты сравнения подобраны плохо. Сравнивать надо с теми же движками что применялись в 1 billion rows challenge, а не вот так. Pandas уже какое-то время рассматривается как референсный продукт, хуже которого быть нельзя в части скорости работы с данными.
- No, 80% of data isn’t spatial (and why that is a good thing) [7] автор опровергает, вернее, пытается опровергнуть тот факт что 80% датасетов это геоданные. Нууу, вот тут то можно и поспорить. Количественно точно не 80%. А вот качественно, вернее объёмно по хранению... До того как объёмы геномных данных не начали накапливаться десятками петабайтов, а это где-то лет 5 назад началось, геоданные, с учётом данных наук о Земле, могли по объёму быть и более 80%. Сейчас я думаю что геномные данные составляют не менее 50%: данных.

Ссылки:
[1] https://spectrum.ieee.org/top-programming-languages-2024
[2] https://ffteducationdatalab.org.uk/2024/08/gcse-results-2024-the-main-trends-in-grades-and-entries/
[3] https://www.axios.com/2024/08/20/washington-post-ai-tool-data
[4] https://www.washingtonpost.com/elections/interactive/2024/republican-campaign-ads-immigration-border-security/
[5] https://www.linkedin.com/posts/patleomi_i-just-unlocked-a-really-cool-new-use-case-activity-7232456130281549825-onDm
[6] https://pola.rs/posts/benchmark-energy-performance/
[7] https://www.spatialstack.ai/blog/no-80-of-data-isn-t-spatial-and-why-that-is-a-good-thing

#data #ai #geodata #readings

Если ты знаешь один трюк, рассказывать его нельзя. Если ты знаешь сто трюков, то можно рассказать хоть про три (с)

Недокументированные API - это те API веб сайтов которые существуют и дают доступ к данным/сервисами, но по какой-либо причине явно не документированы владельцем сайта. Это то о чём я раньше читал лекции и недавно упоминал их в контексте презентации Paul Bradshow для дата-журналистов [1]. Журналисты расследователи и дата журналисты используют их достаточно часто. Я лично регулярно сталкиваюсь с этим в задачах архивации сайтов, создания датасетов "из ничего" и в Dateno при индексировании каталогов данных.

Есть несколько трюков в их поиске которые, как оказывается, широкой публике малоизвестны:
1. Многие сайты разрабатываются так что возвращают разный контент на передаваемые заголовки "Accept". Достаточно делать запросы с заголовком "Accept: application/json" чтобы обнаружить что веб страница может быть и JSON документом. Например, сайты на базе движка Blacklight используемого в архивном деле и для ведения цифровых коллекций материалов.
2. У стандартизированных CMS множество стандартизированных интерфейсов о которых владельцы сайтов могут ничего не подозревать. Не совсем "недокументированное API", скорее плохо документированное API по умолчанию. Оно есть пока владелец сайта явным образом не найдёт где его отключить или не предпримет специальных мер по его сокрытию. Явный пример, /wp-json/ у Wordpress, а также множество других примеров в менее известных CMS. На многих порталах открытых данных каталог данных доступен по ссылке /data.json даже если на сайте ссылки на него нет.
3. Разработчики API тоже люди и думают шаблонами и даже на проде оставляют доступ к API через стандартизированные интерфейсы во внутренних ссылках или поддоменах вроде префиксов документов вроде api и api-dev и в виде внутренних ссылок /api, /api-dev, /rest и ещё с десяток других.

Когда надо найти API конкретного сайта то трюков гораздо больше. Главное чтобы такое API реально существовало😉

Ссылки:
[1] https://t.me/begtin/5662

#opendata #data #tricks #readings

На днях я накатывал очередной обновление реестра каталогов данных, Dateno registry [1] тот самый который раньше был Common Data Index, а потом стал ядром поисковика по данным.

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

Некоторые цифры реестра видны на сайте, а некоторые можно подсчитать поработав в этим датасетом напрямую. Такие цифры на сегодня.

По типам каталогов данных
- 10 099 каталогов данных всего, из них:
— 5944 каталога геоданных
— 2732 портала открытых данных
— 871 репозиторий научных данных
— 276 каталогов индикаторов
— 276 всех остальных каталогов данных

По точкам подключения к API
- 35 404 точек подключения к API 99 различных типов API

По внешним идентификаторам:
- 777 идентификаторов каталогов данных в других источниках таких как re3data, datacatalogs.org, roar, wikidata и других

По используемому ПО:
- 119 типов ПО каталогов зарегистрировано
- 89% каталогов внесены с идентификацией типа ПО и только 11 процентов как отдельная разработка

По предметным областям
- 2158 каталогов имеют тематическую привязку в виде хотя бы одной темы, это около 21% всех каталогов данных

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

А наибольшие ограничения у реестра сейчас в том что у 66% каталогов данных не указан тип владельца и у 15% не идентифицирована страна к которой каталог относится. Если страну ещё можно идентифицировать по доменной зоне, то тип владельца каталога определяется, пока, только вручную. А приоритет ручной проверки проставлен от числа наборов данных в каталоге. Если в поисковый индекс Dateno попадает источник где есть более 1000 наборов данных то он становится кандидатом для ручной проверки и обновления метаданных.

И это, напомню, цифры именно по реестру каталогов данных. Потому что по индексируемым датасетам статистика совсем другая.

Ссылки:
[1] https://dateno.io/registry

#opendata #data #datasets #datacatalogs

В качестве мини-хобби, очень мини, я время от времени систематизирую ссылки по темам в жанре awesome list на Github с некоторой надеждой что над этими списками не я один буду работать. Надежды, как правило, не оправдываются, за редким исключением.

Список Awesome Digital Preservation, за время существования всего 14 лайков. У цифровой архивации мало фанатов, увы.

Или, например, у меня есть список Awesome Open Data software с ПО и стандартами по работе с открытыми данными. Почти всё ПО из реестра каталогов данных в Dateno, плюс ссылки на форматы файлов и стандарты обмена данными. Звездочек маловато, всего 24, не самая популярная тема.😜

Или вот Awesome Data Takeout со ссылками на сервисы получения всех своих данных из онлайн сервисов. 54 звезды, тоже, очень мало.

Для дата журналистов Awesome data journalism со списками инструментов для визуализации и не только. Набрало, 178 звезд, давно не обновлялось.

Russian Awesome Open data каталог источников открытых данных по РФ. Составлялся очень давно, как-то собрал 200 звездочек, уже практически не пополняется. Вместо него развивали datacatalogs.ru

Побольше в Awesome Forensic Tools с подборкой ресурсов в задачах цифрового дознания. Набрало 472 лайка при том что я почти не прилагал усилий по его пополнению, только один раз собрал всё вместе.

И, наконец, Awesome Status Pages собравшее 2738 лайков. Активное настолько что утомляет, сплошным потоком разработчики создают очередные сервисы проверки и публикации статусов сервисов и используют всякую маркетинговую мишуру чтобы их продвинуть. Дважды предлагали выкупить у меня эту страницу. Чувствую зря я её не продал;)

В общем-то по настоящему выстрелило только последнее, хотя списки составлять я лично люблю. Списки это же частный вид таблицы, можно ещё жанр завести. Awesome table of <something>, но в форматы Github'а или Telegram'а они плохо укладываются. Но может найдется близкий интересный формат

#opendata #datajournalism #data #digitalforensics #readings #thoughts

Для тех кто интересуется международной повесткой регулирования данных International Decade for Data (2025-2035) under G20 sponsorship [1] доклад одной из рабочих группы при G20 с предложением по продвижению десятилетия данных под эгидой G20 и основных направлениях.

Удивительно что там ни слова об открытых данных, но много про управление данными в международном аспекте.

Ссылки:
[1] https://www.t20brasil.org/media/documentos/arquivos/TF05_ST_06_Advocating_an_Inter66cf6ad8f1a90.pdf

#opendata #data #policy #readings

Свежий любопытный BI(?) проект MotherDuck Data App Generator [1] который позволяет на основе датасета в DuckDB генерировать дата приложение. Приложение с открытым кодом, но зависит от инфраструктуры MotherDuck.

Хотя они и называют его Data App Generator, тут надо быть честными, это такой недо-BI, по крайней мере в текущей форме и примерах по генерации дашбордов.

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

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

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

Ссылки:
[1] https://motherduck.com/blog/data-app-generator/

#opensource #duckdb #data #dataapps #startups

Неплохая подборка примеров проектов в том что называют Rewrite Bigdata in Rust (RBiR) [1], а то есть по переписыванию функциональности и отдельных продуктов с открытым кодом на Rust, вместо Python или Java.

Подборка хорошая и примеры там все как один вполне применимые к инфраструктуре практически любого дата-продукта.

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

Ссылки:
[1] https://xuanwo.io/2024/07-rewrite-bigdata-in-rust/

#opensource #rust #bigdata #datatools #data

Симпатичный продукт для тетрадок работы с данными Briefer [1], обещают поддержку Python и SQL, генерацию Data apps, ИИ помощника и построение дашбордов.

Поддерживаются Y Combinator и даже с открытым кодом и ещё интереснее их рассказ о том почему они с открытым кодом и каково это открывать код когда тебя финансируют венчурный фонд [3]. Ожидаемо там про выбор AGPL лицензии.

Ссылки:
[1] https://briefer.cloud/
[2] https://github.com/briefercloud
[3] https://briefer.cloud/blog/posts/launching-briefer-oss/

#opensource #datatools #data

А помните я писал о том что хорошо бы многим продуктам иметь SQL интерфейс для продвинутых пользователей? Вместо API, в дополнение API Так вот всё больше такого появляется. К примеру? Hugging Face совсем недавно добавили SQL консоль.

Внутри там всё на базе DuckDB WASM и выглядит как весьма полезная фича.

К каким сервисам ещё бы очень хотелось иметь SQL консоли?
1. Всё что касается веб аналитики. Чтобы не тягать всё время из API и чтобы не испытывать мучения с их веб интерфейсами.
2. К почте, вот просто к корпоративной почте.
3. К любым другим массовым онлайн сервисам (?)


#sql #datatools #data