Интересный текст Silicon Valley’s Civil War [1] от Nadia Asparouhova о контрэлите из Кремниевой долине. Контрэлита, в данном случае, это совокупный образ сверхбогатых техно-олигархов вроде Маска или Цукерберга провопоставляемых условно "классической элите", а в данном случае автор ещё и сопоставляет их с Давосским форумом, как совокупное представление элиты.
В тексте хорошие примеры очень быстрой реакции именно контрэлиты в лице Ryan Petersen из Flexport по личному анализу проблем с доставкой во время COVID-19 и про Patrick Collison, сооснователя Stripe, который в течение недели собрал и раздал грантов на $50 миллионов учёным исследующим COVID-19 и долго ожидающим начала финансирования от National Institute of Health в США.
Текст, кстати, во многом объясняющий столь контрастную реакцию на деятельность Элона Маска, он довольно яркий представитель контр-элиты. В статье есть также противопоставление поколенческое и, возможно, им же можно объяснить этот термин контр элит, но важное отличие именно представителей контр элиты в индивидуализме, собственном восприятии мира и готовностью менять мир.
В итоге текст интересный, как минимум дающий дополнительный взгляд на происходящее
Ссылки:
[1] https://www.tabletmag.com/sections/news/articles/silicon-valley-civil-war
#readings #tech
В тексте хорошие примеры очень быстрой реакции именно контрэлиты в лице Ryan Petersen из Flexport по личному анализу проблем с доставкой во время COVID-19 и про Patrick Collison, сооснователя Stripe, который в течение недели собрал и раздал грантов на $50 миллионов учёным исследующим COVID-19 и долго ожидающим начала финансирования от National Institute of Health в США.
Текст, кстати, во многом объясняющий столь контрастную реакцию на деятельность Элона Маска, он довольно яркий представитель контр-элиты. В статье есть также противопоставление поколенческое и, возможно, им же можно объяснить этот термин контр элит, но важное отличие именно представителей контр элиты в индивидуализме, собственном восприятии мира и готовностью менять мир.
В итоге текст интересный, как минимум дающий дополнительный взгляд на происходящее
Ссылки:
[1] https://www.tabletmag.com/sections/news/articles/silicon-valley-civil-war
#readings #tech
Tablet
Silicon Valley’s Civil War
Tech’s leadership is splitting into two elites—and the battle between them will shape America’s future
Но есть и хорошие новости, крипто-пузырь сдувается в ноль [1] и, лично я считаю, что это только к лучшему. Удивительно даже как долго этот хайп длился и что у него до сих пор так много фанатов.
Ссылки:
[1] https://www.brookings.edu/articles/crypto-crashes-and-job-slashes-lessons-for-local-leaders-on-building-an-innovation-ecosystem/
#crypto #tech #readings
Ссылки:
[1] https://www.brookings.edu/articles/crypto-crashes-and-job-slashes-lessons-for-local-leaders-on-building-an-innovation-ecosystem/
#crypto #tech #readings
По поводу глобального синего экрана смерти из-за ошибки в антивирусе CrowdStrike [1] который поразил авиакомпании и тысячи критических инфраструктурных и просто компаний.
Ключевое тут - это хрупкость человечества и расширение списка мест этой хрупкости.
Но что пока радует так то что рукожопы пока лидируют в угрозе человечеству далеко обгоняя хакеров.
Ссылки:
[1] https://www.forbes.com/sites/kateoflahertyuk/2024/07/19/crowdstrike-windows-outage-what-happened-and-what-to-do-next/
#it #tech #thoughts
Ключевое тут - это хрупкость человечества и расширение списка мест этой хрупкости.
Но что пока радует так то что рукожопы пока лидируют в угрозе человечеству далеко обгоняя хакеров.
Ссылки:
[1] https://www.forbes.com/sites/kateoflahertyuk/2024/07/19/crowdstrike-windows-outage-what-happened-and-what-to-do-next/
#it #tech #thoughts
Ещё немного про всякое сугубо техническое, сейчас в Dateno постепенно идёт переход от индексирования тысяч маленьких порталов с общедоступными данными и метаданными, к охвату крупных каталогов. Ключевое отличие таких крупных каталогов данных в том что необходимо писать скрейперы под каждый индивидуально, а это хоть и несложно, но означает увеличение кода скрейпинга многократно что постепенно будет усложнять сопровождение кода и так далее. Но это не проблема, это вполне измеримая техническая задача.
Что сложнее так то что многие из таких крупных каталогов данных - это базы индикаторов. Часть из них написаны на типовом ПО, большая часть на нетиповом, но что характерно для большей части таких каталогов так то что сбор метаданных и данных (значений) индикаторов по трудоёмкости почти не различаются
Это сильно отличает такие порталы от порталов открытых или научных данных, где выкачать метаданные можно быстро и они имеют относительно разумные размеры, а вот данных могут быть там сотни гигабайт и терабайт, их сбор и обработка уже сложнее.
А в случае индикаторов, хорошие владельцы таких баз данных всё чаще дают возможность выкачать их целиком в режиме bulk download. Как минимум это ECB, Eurostat, FAO, Ilostat и ещё многие. Данные там почти всегда CSV или сжатые CSV и вот тут то срабатывает магия инструментов вроде duckdb. Во всех ситуациях когда CSVшки в кодировке utf8 и имеют предсказуемые схемы данных, с помощью duckdb можно многократно ускорять их обработку заменяя обработку через датафреймы на прямые SQL запросы к CSV, даже без копирования данных в БД и не строя ни одного индекса.
В общем могу сказать что в роли "дешёвого ETL инструмента для бедных" duckdb работает прекрасно. К примеру DISTINCT по разреженному полю по CSV файлу в 15GB и 22 миллиона записей без индекса отрабатывается на 19.8 секунд. Это в режиме когда совсем без оптимизаций, без преобразований в parquet. А если в parquet преобразовать то, ожидаемо, DISTINCT отрабатывает за 0.5 секунд. Выбор очевиден 🛠 надо использовать!
Например, про данные из другого проекта, если кто-то надумает использовать данные по госконтрактам [1], то они вполне себе читаются с помощью duckdb особенно после преобразований в parquet. Например, jsonl файл с госзаказчиками вполне себе легко преобразуется в parquet после всего операции по преобразованиям занимают сотые доли секунд. В этом смысле единственный недостаток открытых данных из Госзатрат только в том что они сжаты в zip, а если сжать их в gz или публиковать в parquet, то можно ещё и ускорить подготовку данных.
Таких примеров много, главный вывод в том что можно удешевить ресурсные требования во многих задачах и многие R&D задачи решать без дополнительных серверных ресурсов, экспериментируя локально.
Ссылки:
[1] https://clearspending.ru/opendata/
#duckdb #tech #dataengineering #etl
Что сложнее так то что многие из таких крупных каталогов данных - это базы индикаторов. Часть из них написаны на типовом ПО, большая часть на нетиповом, но что характерно для большей части таких каталогов так то что сбор метаданных и данных (значений) индикаторов по трудоёмкости почти не различаются
Это сильно отличает такие порталы от порталов открытых или научных данных, где выкачать метаданные можно быстро и они имеют относительно разумные размеры, а вот данных могут быть там сотни гигабайт и терабайт, их сбор и обработка уже сложнее.
А в случае индикаторов, хорошие владельцы таких баз данных всё чаще дают возможность выкачать их целиком в режиме bulk download. Как минимум это ECB, Eurostat, FAO, Ilostat и ещё многие. Данные там почти всегда CSV или сжатые CSV и вот тут то срабатывает магия инструментов вроде duckdb. Во всех ситуациях когда CSVшки в кодировке utf8 и имеют предсказуемые схемы данных, с помощью duckdb можно многократно ускорять их обработку заменяя обработку через датафреймы на прямые SQL запросы к CSV, даже без копирования данных в БД и не строя ни одного индекса.
В общем могу сказать что в роли "дешёвого ETL инструмента для бедных" duckdb работает прекрасно. К примеру DISTINCT по разреженному полю по CSV файлу в 15GB и 22 миллиона записей без индекса отрабатывается на 19.8 секунд. Это в режиме когда совсем без оптимизаций, без преобразований в parquet. А если в parquet преобразовать то, ожидаемо, DISTINCT отрабатывает за 0.5 секунд. Выбор очевиден 🛠 надо использовать!
Например, про данные из другого проекта, если кто-то надумает использовать данные по госконтрактам [1], то они вполне себе читаются с помощью duckdb особенно после преобразований в parquet. Например, jsonl файл с госзаказчиками вполне себе легко преобразуется в parquet после всего операции по преобразованиям занимают сотые доли секунд. В этом смысле единственный недостаток открытых данных из Госзатрат только в том что они сжаты в zip, а если сжать их в gz или публиковать в parquet, то можно ещё и ускорить подготовку данных.
Таких примеров много, главный вывод в том что можно удешевить ресурсные требования во многих задачах и многие R&D задачи решать без дополнительных серверных ресурсов, экспериментируя локально.
Ссылки:
[1] https://clearspending.ru/opendata/
#duckdb #tech #dataengineering #etl
Полезное чтение про данные технологии и не только:
- DuckDB Spatial: Supercharged Geospatial SQL (GeoPython 2024) [1] не для чтения, а для просмотра. Супер лекция про то как работать с геоданными с помощью DuckDB. Очень хочется применить к следующему геопроекту.
- Europe PMC [2] европейский поисковик по статьям в области наук о жизни. Помимо ссылок на статьи, собирают их тексты, анализируют, выдают в результатах много дополнительной извлечённой информации о финансировании, данных на которые есть ссылки в статьях, цитировании и так далее.
- Why CSV is still king [3] автор нахваливает CSV формат за простоту и переносимость, и утверждает что он ещё долгое время будет популярен. Лично я считаю что он ошибается, скорее поддержка parquet или arrow появится в стандартных инструментах. Например, в сохранении из Excel или Google Spreadsheets или OpenOffice. В командной строке и так далее.
- A.I. May Save Us or May Construct Viruses to Kill Us [4] уже не столько про технологии сколько про видение будущего. ИИ может как спасать от пандемии, так и конструировать новые вирусы.
- BENEFICIAL OWNERSHIP TRANSPARENCY ACT, 2023 [5] 31 июля 2024 года, несколько дней назад вступил в силу закон об обязательном раскрытии конечных бенефициаров компаний на Каймановых островах. Видимо стоит вскоре ожидать что эти данные будут открыты и новых расследований?
- Inside Crowdstrike's Deployment Process [6] о том как был устроен процесс деплоймента обновлений у Crowdstrike. Очень поучительно и познавательно, особенно узнать о том что это было не обновление кода, а обновление конфигурации ПО и поэтому не проходило правильный и отработанный процесс тестирования. В общем, в компании забыли что configuration = code.
Ссылки:
[1] https://www.youtube.com/watch?v=hoyQnP8CiXE
[2] https://europepmc.org/
[3] https://konbert.com/blog/why-csv-is-still-king
[4] https://www.nytimes.com/2024/07/27/opinion/ai-advances-risks.html
[5] https://legislation.gov.ky/cms/images/LEGISLATION/PRINCIPAL/2023/2023-0013/BeneficialOwnershipTransparencyAct2023_Act%2013%20of%202023.pdf
[6] https://overmind.tech/blog/inside-crowdstrikes-deployment-process
#opendata #opensource #ai #tech #readings
- DuckDB Spatial: Supercharged Geospatial SQL (GeoPython 2024) [1] не для чтения, а для просмотра. Супер лекция про то как работать с геоданными с помощью DuckDB. Очень хочется применить к следующему геопроекту.
- Europe PMC [2] европейский поисковик по статьям в области наук о жизни. Помимо ссылок на статьи, собирают их тексты, анализируют, выдают в результатах много дополнительной извлечённой информации о финансировании, данных на которые есть ссылки в статьях, цитировании и так далее.
- Why CSV is still king [3] автор нахваливает CSV формат за простоту и переносимость, и утверждает что он ещё долгое время будет популярен. Лично я считаю что он ошибается, скорее поддержка parquet или arrow появится в стандартных инструментах. Например, в сохранении из Excel или Google Spreadsheets или OpenOffice. В командной строке и так далее.
- A.I. May Save Us or May Construct Viruses to Kill Us [4] уже не столько про технологии сколько про видение будущего. ИИ может как спасать от пандемии, так и конструировать новые вирусы.
- BENEFICIAL OWNERSHIP TRANSPARENCY ACT, 2023 [5] 31 июля 2024 года, несколько дней назад вступил в силу закон об обязательном раскрытии конечных бенефициаров компаний на Каймановых островах. Видимо стоит вскоре ожидать что эти данные будут открыты и новых расследований?
- Inside Crowdstrike's Deployment Process [6] о том как был устроен процесс деплоймента обновлений у Crowdstrike. Очень поучительно и познавательно, особенно узнать о том что это было не обновление кода, а обновление конфигурации ПО и поэтому не проходило правильный и отработанный процесс тестирования. В общем, в компании забыли что configuration = code.
Ссылки:
[1] https://www.youtube.com/watch?v=hoyQnP8CiXE
[2] https://europepmc.org/
[3] https://konbert.com/blog/why-csv-is-still-king
[4] https://www.nytimes.com/2024/07/27/opinion/ai-advances-risks.html
[5] https://legislation.gov.ky/cms/images/LEGISLATION/PRINCIPAL/2023/2023-0013/BeneficialOwnershipTransparencyAct2023_Act%2013%20of%202023.pdf
[6] https://overmind.tech/blog/inside-crowdstrikes-deployment-process
#opendata #opensource #ai #tech #readings
europepmc.org
Home - Europe PMC
Europe PMC is an archive of life sciences journal literature.
К вопросу о poor man data engineering, как обрабатывать данные в условиях ограниченных ресурсов с минимальными нагрузками на диск и на оперативную память, в первую очередь.
В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.
Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.
Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.
Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.
При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.
Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.
Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.
Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.
Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.
Понятно что перенеся всё это на серверную инфраструктуру, в несколько потоков и тд. можно многократно ускорить обработку данных, но и так с помощью DuckDB конвейеры данных можно запускать на очень дешёвом железе и получать приемлемый результат.
#data #thoughts #tech #duckdb #dataengineering
В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.
Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.
Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.
Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.
При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.
Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.
Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.
Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.
Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.
Понятно что перенеся всё это на серверную инфраструктуру, в несколько потоков и тд. можно многократно ускорить обработку данных, но и так с помощью DuckDB конвейеры данных можно запускать на очень дешёвом железе и получать приемлемый результат.
#data #thoughts #tech #duckdb #dataengineering
Подборка ссылок про данные, технологии и не только:
- The Open Data Editor is now ready for the pilot phase [1] обновлённый редактор для подготовки датасетов готов для тестирования, полезный инструмент для всех кто публикует данные с помощью CKAN
- To Be Born in a Bag [2] о исследованиях в разработки искусственной матки и возможностью создавать живых существ искусственным образом. Напоминает воплощение научной фантастики из серии книг Лоис Буджолд. А заодно и там же про создание мамонтов искусственным образом
- DuckDB foundation [3] один из успехов DuckDB в том что это фонд успешно взаимодействующий с несколькими компаниями контрибьюторами. Полезное чтение про успешную модель существования открытого кода.
- The Disappearance of an Internet Domain [4] Великобритания отказывается от суверенитета над островами Чагос и передаёт их Маврикию. Что такое острова Чагос? Это доменная зона .io. Автор рассуждает о его судьбе.
- The Prosopography of Anglo-Saxon England (PASE) [5] онлайн база данных всех британцев как-либо упомянутых в литературных источниках с 6 по 11 века нашей эры. Почти 20 тысяч персон
- Bots, so many Bots [6] боты составляют более 60% из 1 миллиона пользователей ProductHunt. А если говорить о других социальных площадках, то и там ботов всё больше. В какой-то момент должен будет возникнуть перелом когда такие площадки станут бесполезными.
- DatAasee - A Metadata-Lake for Libraries [7] научная статья и открытый код [8] каталога метаданных и озера данных для библиотек.
Ссылки:
[1] https://blog.okfn.org/2024/10/02/the-open-data-editor-is-now-ready-for-the-pilot-phase/
[2] https://press.asimov.com/articles/artificial-wombs
[3] https://davidsj.substack.com/p/foundation
[4] https://every.to/p/the-disappearance-of-an-internet-domain
[5] https://pase.ac.uk/pase/
[6] https://wakatime.com/blog/67-bots-so-many-bots
[7] https://www.semanticscholar.org/reader/7166be7af2fd4bc9cf73d19f076180d9ca83b029
[8] https://github.com/ulbmuenster/dataasee
#opendata #data #tech #dataengineering
- The Open Data Editor is now ready for the pilot phase [1] обновлённый редактор для подготовки датасетов готов для тестирования, полезный инструмент для всех кто публикует данные с помощью CKAN
- To Be Born in a Bag [2] о исследованиях в разработки искусственной матки и возможностью создавать живых существ искусственным образом. Напоминает воплощение научной фантастики из серии книг Лоис Буджолд. А заодно и там же про создание мамонтов искусственным образом
- DuckDB foundation [3] один из успехов DuckDB в том что это фонд успешно взаимодействующий с несколькими компаниями контрибьюторами. Полезное чтение про успешную модель существования открытого кода.
- The Disappearance of an Internet Domain [4] Великобритания отказывается от суверенитета над островами Чагос и передаёт их Маврикию. Что такое острова Чагос? Это доменная зона .io. Автор рассуждает о его судьбе.
- The Prosopography of Anglo-Saxon England (PASE) [5] онлайн база данных всех британцев как-либо упомянутых в литературных источниках с 6 по 11 века нашей эры. Почти 20 тысяч персон
- Bots, so many Bots [6] боты составляют более 60% из 1 миллиона пользователей ProductHunt. А если говорить о других социальных площадках, то и там ботов всё больше. В какой-то момент должен будет возникнуть перелом когда такие площадки станут бесполезными.
- DatAasee - A Metadata-Lake for Libraries [7] научная статья и открытый код [8] каталога метаданных и озера данных для библиотек.
Ссылки:
[1] https://blog.okfn.org/2024/10/02/the-open-data-editor-is-now-ready-for-the-pilot-phase/
[2] https://press.asimov.com/articles/artificial-wombs
[3] https://davidsj.substack.com/p/foundation
[4] https://every.to/p/the-disappearance-of-an-internet-domain
[5] https://pase.ac.uk/pase/
[6] https://wakatime.com/blog/67-bots-so-many-bots
[7] https://www.semanticscholar.org/reader/7166be7af2fd4bc9cf73d19f076180d9ca83b029
[8] https://github.com/ulbmuenster/dataasee
#opendata #data #tech #dataengineering
Open Knowledge Foundation blog
The Open Data Editor is now ready for the pilot phase
This week saw the release of version 1.1.0 of the Open Data Editor (ODE), the new Open Knowledge Foundation's app that makes it easier for people with little to no technical skills to work with data. The app is now ready to enter a crucial phase of user testing.