Белый дом (США) опубликовал меморандум об обязательном оперативном раскрытии результатов научных исследователей финансируемых из федерального бюджета США [1] [2].
К середине 2023 года все федеральные органы власти должны обновить свои планы по открытию доступа и обмене данными, а с 31 декабря 2025 года результаты всех научных исследований должны публиковаться в открытом доступе.
От себя добавлю что портал открытых данных в США data.gov - это, во многом, портал раскрытия научных данных такими ведомствами как НАСА, геологической службой США и ещё рядом органов власти, но он не был приспособлен к раскрытию именно научных данных, например, он не присваивает DOI, не даёт публиковать данные под эмбарго и тд.
Поэтому этот меморандум имеет большое значение и интересно будут ли в США создавать отдельный национальный портал открытого доступа или обновят data.gov.
Ссылки:
[1] https://www.whitehouse.gov/ostp/news-updates/2022/08/25/ostp-issues-guidance-to-make-federally-funded-research-freely-available-without-delay/
[2] https://www.whitehouse.gov/wp-content/uploads/2022/08/08-2022-OSTP-Public-Access-Memo.pdf
#opendata #openaccess #datasharing #usa
К середине 2023 года все федеральные органы власти должны обновить свои планы по открытию доступа и обмене данными, а с 31 декабря 2025 года результаты всех научных исследований должны публиковаться в открытом доступе.
От себя добавлю что портал открытых данных в США data.gov - это, во многом, портал раскрытия научных данных такими ведомствами как НАСА, геологической службой США и ещё рядом органов власти, но он не был приспособлен к раскрытию именно научных данных, например, он не присваивает DOI, не даёт публиковать данные под эмбарго и тд.
Поэтому этот меморандум имеет большое значение и интересно будут ли в США создавать отдельный национальный портал открытого доступа или обновят data.gov.
Ссылки:
[1] https://www.whitehouse.gov/ostp/news-updates/2022/08/25/ostp-issues-guidance-to-make-federally-funded-research-freely-available-without-delay/
[2] https://www.whitehouse.gov/wp-content/uploads/2022/08/08-2022-OSTP-Public-Access-Memo.pdf
#opendata #openaccess #datasharing #usa
The White House
OSTP Issues Guidance to Make Federally Funded Research Freely Available Without Delay
Today, the White House Office of Science and Technology Policy (OSTP) updated U.S. policy guidance to make the results of taxpayer-supported research immediately available to the American public at no cost. In a memorandum to federal departments and agencies…
Подборка свежего чтения про работу с данными и не только:
- The Rise of Data Contracts [1] текст о важности контрактов по работе с данными (контракт - это договоренность поставщиков и потребителей данных о существенных условиях вроде обратной совместимости, итеративности изменений и тд.)․ Можно было бы поиронизировать что молодежь открыла для себя contract programming, но хорошо что открыли и пишут и нужная вещь. Полезно для тех кто не в курсе того как это работает и полезно обновить знания тем кто уже знает.
- Qloo [2] интересный стартап обещающий что могут предсказывать культурные предпочтения пользователей. Называют себя "Cultural AI". Недавно они подняли инвестиций на $15M
- Ziliz [3] стартап по созданию Cloud-native service for Milvus я про Milvus писал ранее - это такая интересная облачная база данных удобная для рекомендательных сервисов и нечёткого поиска. Подняли $60M инвестиций [4] вдогонку к предыдущим $53.
- Apache Hudi vs Delta Lake vs Apache Iceberg - Lakehouse Feature Comparison [5] сравнение трёх платформ для озер данных от стартапа Onehouse. Читать надо с осторожностью, они делают свой сервис на Hudi, так что не стоит доверять без оглядки.
- Why Apache Iceberg will rule data in the cloud [6] чтобы иметь другую картину в сравнениях озер данных, альтернативный взгляд с позиции преимуществ Iceberg. Но лучше выберите любое и пробуйте, пробуйте, пробуйте пока не набьёте шишек.
- Professional Pandas: The Pandas Assign Method and Chaining [7] для тех кто уже всё про pandas знаете и хочет поизучать более сложные техники на базе pandas. Конкретно здесь про пользу метода assign и итоговые результаты.
Ссылки:
[1] https://dataproducts.substack.com/p/the-rise-of-data-contracts
[2] https://qloo.com/
[3] https://zilliz.com
[4] https://zilliz.com/news/vector-database-company-zilliz-series-b-extension
[5] https://www.onehouse.ai/blog/apache-hudi-vs-delta-lake-vs-apache-iceberg-lakehouse-feature-comparison
[6] https://www.infoworld.com/article/3669848/why-apache-iceberg-will-rule-data-in-the-cloud.html
[7] https://ponder.io/professional-pandas-the-pandas-assign-method-and-chaining/
#data #readings #datatools #startups
- The Rise of Data Contracts [1] текст о важности контрактов по работе с данными (контракт - это договоренность поставщиков и потребителей данных о существенных условиях вроде обратной совместимости, итеративности изменений и тд.)․ Можно было бы поиронизировать что молодежь открыла для себя contract programming, но хорошо что открыли и пишут и нужная вещь. Полезно для тех кто не в курсе того как это работает и полезно обновить знания тем кто уже знает.
- Qloo [2] интересный стартап обещающий что могут предсказывать культурные предпочтения пользователей. Называют себя "Cultural AI". Недавно они подняли инвестиций на $15M
- Ziliz [3] стартап по созданию Cloud-native service for Milvus я про Milvus писал ранее - это такая интересная облачная база данных удобная для рекомендательных сервисов и нечёткого поиска. Подняли $60M инвестиций [4] вдогонку к предыдущим $53.
- Apache Hudi vs Delta Lake vs Apache Iceberg - Lakehouse Feature Comparison [5] сравнение трёх платформ для озер данных от стартапа Onehouse. Читать надо с осторожностью, они делают свой сервис на Hudi, так что не стоит доверять без оглядки.
- Why Apache Iceberg will rule data in the cloud [6] чтобы иметь другую картину в сравнениях озер данных, альтернативный взгляд с позиции преимуществ Iceberg. Но лучше выберите любое и пробуйте, пробуйте, пробуйте пока не набьёте шишек.
- Professional Pandas: The Pandas Assign Method and Chaining [7] для тех кто уже всё про pandas знаете и хочет поизучать более сложные техники на базе pandas. Конкретно здесь про пользу метода assign и итоговые результаты.
Ссылки:
[1] https://dataproducts.substack.com/p/the-rise-of-data-contracts
[2] https://qloo.com/
[3] https://zilliz.com
[4] https://zilliz.com/news/vector-database-company-zilliz-series-b-extension
[5] https://www.onehouse.ai/blog/apache-hudi-vs-delta-lake-vs-apache-iceberg-lakehouse-feature-comparison
[6] https://www.infoworld.com/article/3669848/why-apache-iceberg-will-rule-data-in-the-cloud.html
[7] https://ponder.io/professional-pandas-the-pandas-assign-method-and-chaining/
#data #readings #datatools #startups
Substack
The Rise of Data Contracts
And Why Your Data Pipelines Don't Scale
Продолжая тему приватности мобильных приложений. Есть стартапы создающие мобильные приложения, а есть стартапы помогающие отслеживать нарушения приватности в этих приложениях. Например, Privado [1] предоставляют сервис отслеживания обработки чувствительных данных в приложениях для Android'а через сканирование исходного кода. Проверить код можно скачав их open source сканер [2] и запустив с параметром 'privado scan <folder name>'.
Я его проверял на швейцарском государственном приложении отслеживания COVID-19 swisscovid-app-android [3].
Из плюсов - он работает
Из минусов - только с Java кодом, не поддерживается приложения на Javascript или Kotlin не говоря уже о Flutter и тд.
Из странностей - ложные срабатывания. Например, срабатывает на обработку высоты изображения как рост человека height, хотя в коде видно что срабатывание неверное.
Приложение хотя и open source, но будьте осторожны, результаты оно постит сразу на сайт community.privado.ai, то есть открытый код, но с зависимостью от облачного сервиса.
Главная фишка - генерация Data Safety манифеста для Google Play. Иначе говоря, автоматизация комплаенс процедуры для приложений Android.
Продукт интересный, буду наблюдать за его развитием. Может быть он сможет работать и с декомпилированным кодом или сам научится декомпилировать DEX файлы? А может у него появятся конкуренты.
Ссылки:
[1] https://www.privado.ai/
[2] https://github.com/Privado-Inc/privado
[3] https://github.com/SwissCovid/swisscovid-app-android
#mobileapps #privacy #android #security
Я его проверял на швейцарском государственном приложении отслеживания COVID-19 swisscovid-app-android [3].
Из плюсов - он работает
Из минусов - только с Java кодом, не поддерживается приложения на Javascript или Kotlin не говоря уже о Flutter и тд.
Из странностей - ложные срабатывания. Например, срабатывает на обработку высоты изображения как рост человека height, хотя в коде видно что срабатывание неверное.
Приложение хотя и open source, но будьте осторожны, результаты оно постит сразу на сайт community.privado.ai, то есть открытый код, но с зависимостью от облачного сервиса.
Главная фишка - генерация Data Safety манифеста для Google Play. Иначе говоря, автоматизация комплаенс процедуры для приложений Android.
Продукт интересный, буду наблюдать за его развитием. Может быть он сможет работать и с декомпилированным кодом или сам научится декомпилировать DEX файлы? А может у него появятся конкуренты.
Ссылки:
[1] https://www.privado.ai/
[2] https://github.com/Privado-Inc/privado
[3] https://github.com/SwissCovid/swisscovid-app-android
#mobileapps #privacy #android #security
Я давно не писал про мою любимую тему, семантические типы данных, а, между тем, я активно продолжаю ей заниматься в свободное время, в основном. Создавая metacrafter-registry [1] [2], реестр существующих семантических типов данных и регулярных выражений для их идентификации.
Для тех кто не знает что это такое, напомню про мой текст с рассказом того как их применяют и зачем они нужны [3], если кратко то для автоматизации визуализации, анализа, навигации и обработки данных.
Реестр вырос уже до 284 типов данных сгруппированных по 26 категориям и в привязке к 11 странам. Более всего страновых идентификаторов по России - более 70 (ИНН, СНИЛС, КЛАДР и все остальные), но по мере обработки порталов данных и других источников растет список и по другим странам.
Самые главные изменения в том что многие типы данных теперь имеют привязку к Wikidata и Schema.org. Какие-то ещё можно привязать, но, к сожалению не все. Wikidata почти не покрывает персональные идентификаторы, зато включает сотни идентификаторов литературных источников почти нигде "в диком виде" не встречающиеся.
Реестр всё лучше перелинкован, синхронизован с используемыми инструментами и понемногу включает и регулярные выражения для идентификации типов данных. Часть их уже перенесена в утилиту metacrafter [4] для идентификации семантических типов данных, а часть будет перенесена постепенно позже.
Ссылки:
[1] https://registry.apicrafter.io/
[2] https://github.com/apicrafter/metacrafter-registry
[3] https://medium.com/@ibegtin/semantic-data-types-systematic-approach-and-types-registry-a2c2a60a467b
[4] https://github.com/apicrafter/metacrafter
#opensource #data #datatools #metadata #semanticdatatypes
Для тех кто не знает что это такое, напомню про мой текст с рассказом того как их применяют и зачем они нужны [3], если кратко то для автоматизации визуализации, анализа, навигации и обработки данных.
Реестр вырос уже до 284 типов данных сгруппированных по 26 категориям и в привязке к 11 странам. Более всего страновых идентификаторов по России - более 70 (ИНН, СНИЛС, КЛАДР и все остальные), но по мере обработки порталов данных и других источников растет список и по другим странам.
Самые главные изменения в том что многие типы данных теперь имеют привязку к Wikidata и Schema.org. Какие-то ещё можно привязать, но, к сожалению не все. Wikidata почти не покрывает персональные идентификаторы, зато включает сотни идентификаторов литературных источников почти нигде "в диком виде" не встречающиеся.
Реестр всё лучше перелинкован, синхронизован с используемыми инструментами и понемногу включает и регулярные выражения для идентификации типов данных. Часть их уже перенесена в утилиту metacrafter [4] для идентификации семантических типов данных, а часть будет перенесена постепенно позже.
Ссылки:
[1] https://registry.apicrafter.io/
[2] https://github.com/apicrafter/metacrafter-registry
[3] https://medium.com/@ibegtin/semantic-data-types-systematic-approach-and-types-registry-a2c2a60a467b
[4] https://github.com/apicrafter/metacrafter
#opensource #data #datatools #metadata #semanticdatatypes
GitHub
GitHub - apicrafter/metacrafter-registry: Registry of metadata identifier entities like UUID, GUID, person fullname, address and…
Registry of metadata identifier entities like UUID, GUID, person fullname, address and so on. Linked with other sources - apicrafter/metacrafter-registry
В рубрике как это работает у них the Global Open Science Cloud Initiative (GOSC) [1] проект CODATA (Комитета по данным Международного научного совета).
Идея его простая - создать стандарты и инфраструктуру для интеграции больших национальных и международных проектов открытой научной инфраструктуры. Я об этих проектах многих писал: EOSC, ARDC, NFDI, NRDIO и многих других. В мире идёт активное развитие таких платформ, например, развивается La Refencia в Латинской Америке и African Open Science Platform, как вы догадываетесь, в Африке.
Все они на разных стандартах, идентификаторах, протоколах, и вот CODATA организуют инициативы по их обзору и интеграции. Что любопытно, оплачивает это CNIC CAS (Компьютерный сетевой информационный центр Китайской академии наук). И вот организаторы обещают уже 12 октября представить первые результаты в рамках GOSC IPO [3]. Ждать недолго и даже если это будет только результат анализа существующих проектов - это уже будет интересно.
Почему это важно? Существенная часть открытой научной инфраструктуры - это доступность научных данных, инструментов их обработки и облачных сервисов. Лично я сомневаюсь появления глобальной [некоммерческой] научной инфраструктуры как digital commons в ближайшие годы, но сама идея интеграции национальных инициатив выглядит актуально.
Ссылки:
[1] https://codata.org/initiatives/decadal-programme2/global-open-science-cloud/
[2] https://codata.org
[3] https://codata.org/launch-of-the-gosc-international-programme-office/
#openaccess #openscience #opendata
Идея его простая - создать стандарты и инфраструктуру для интеграции больших национальных и международных проектов открытой научной инфраструктуры. Я об этих проектах многих писал: EOSC, ARDC, NFDI, NRDIO и многих других. В мире идёт активное развитие таких платформ, например, развивается La Refencia в Латинской Америке и African Open Science Platform, как вы догадываетесь, в Африке.
Все они на разных стандартах, идентификаторах, протоколах, и вот CODATA организуют инициативы по их обзору и интеграции. Что любопытно, оплачивает это CNIC CAS (Компьютерный сетевой информационный центр Китайской академии наук). И вот организаторы обещают уже 12 октября представить первые результаты в рамках GOSC IPO [3]. Ждать недолго и даже если это будет только результат анализа существующих проектов - это уже будет интересно.
Почему это важно? Существенная часть открытой научной инфраструктуры - это доступность научных данных, инструментов их обработки и облачных сервисов. Лично я сомневаюсь появления глобальной [некоммерческой] научной инфраструктуры как digital commons в ближайшие годы, но сама идея интеграции национальных инициатив выглядит актуально.
Ссылки:
[1] https://codata.org/initiatives/decadal-programme2/global-open-science-cloud/
[2] https://codata.org
[3] https://codata.org/launch-of-the-gosc-international-programme-office/
#openaccess #openscience #opendata
CODATA, The Committee on Data for Science and Technology
Global Open Science Cloud - CODATA, The Committee on Data for Science and Technology
Invitation to Collaborate on the Global Open Science Cloud Initiative Preamble The major global scientific and human challenges of the 21st century (including COVID-19 and future pandemics, anthropogenic climate change, sustainable development, and disaster…
Онтология типов данных
Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология OntoDT [1] ещё 2016 года, но сайт с ним уже недоступен, и сама онтология кое-где ещё доступна как RDF/OWL [2]. Основной автор Panče Panov явно переключился на более прикладные исследования [3]
В качестве других примеров։
- онтология EDAM [4] в биоинформатике, с акцентом на особенности анализа и майнинга данных в этой области
- CDM (Common Data Model) [5] не-формальная онтологии от Microsoft привязанная с акцентом на продажах, пользователях, маркетинге и тд.
- онтология типов данных при ответах на вопросы по геоаналитике [6] прошлогоднее исследование с акцентом на геоданные.
Есть, также, какое-то количество других научных и не только научных публикаций на эту тему, но в целом их довольно мало. Они чаще всего происходят в контексте задач по анализу данных и его автоматизации. Самое развитое идёт в сторону автоматизации создания и аннотирование моделей для ИИ. Проект D3M (Data-Driven Discovery of Models) [7] от DARPA в США. Я не так давно писал о нём и порождённых им стартапах. [8]
По тому что я вижу, рано или поздно, но с практической или научной или обеих точек зрения будет продолжение развитие моделирования типов данных. Помимо задач автоматизации обработки данных, есть явный тренд на развитие инструментов их хранения.
Ещё какое-то время назад в СУБД на родном уровне поддерживались только самые базовые типы данных։ INT, FLOAT, STRING/VARCHAR, BLOB и тд. с небольшими вариациями. Сейчас, современные СУБД, поддерживают многочисленные дополнительные типы данных, перешедших из смысловых (семантических) в базовые типы. Пример: ip-адреса и mac-адреса уже достаточно давно имеющиеся в некоторых СУБД [9] и недавно добавляемые в другие [10].
Ранее всего это произошло с датами и временем в разных вариациях, с геоданными для которых есть сейчас много отдельных функций и индексов внутри СУБД. Также происходит с сетевыми наиболее популярными данными.
Мои ощущения что на этом процесс не остановится. Например, меня удивляет что всё ещё нет СУБД общего типа с отдельными типами данных под хэши (SHA1, SHA256 и др.).
Многие составные идентификаторы и коды классификаторов сейчас в СУБД хранятся как строки, при том что часто они нужны в декомпозированной форме и, в итоге, создаётся избыточность разбирая этот код на части. Пример в России: Вы можете хранить код КЛАДР как есть, а можете разделить его на подэлементы и осуществлять поиск по ним когда это необходимо.
Не знаю появится ли когда-либо движок для СУБД дающий возможность значительно большей гибкости в хранении и индексировании данных иди же, на самом деле, это далеко от насущных необходимостей, но важно то что к у каждого смыслового типа данных есть важная связка с практиками обработки данных и эволюция СУБД в этом направлении явно происходит.
Ссылки:
[1] https://fairsharing.org/FAIRsharing.ydnwd9
[2] https://kt.ijs.si/panovp/OntoDM/archive/OntoDT.owl
[3] https://orcid.org/0000-0002-7685-9140
[4] http://edamontology.org/page
[5] https://docs.microsoft.com/en-us/common-data-model/
[6] https://digitalcommons.library.umaine.edu/josis/vol2020/iss20/2/
[7] https://datadrivendiscovery.org
[8] https://yangx.top/begtin/3926
[9] https://www.postgresql.org/docs/current/datatype-net-types.html
[10] https://mariadb.com/kb/en/inet4/
#data #rdbms #research #metadata #semanticdatatypes
Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология OntoDT [1] ещё 2016 года, но сайт с ним уже недоступен, и сама онтология кое-где ещё доступна как RDF/OWL [2]. Основной автор Panče Panov явно переключился на более прикладные исследования [3]
В качестве других примеров։
- онтология EDAM [4] в биоинформатике, с акцентом на особенности анализа и майнинга данных в этой области
- CDM (Common Data Model) [5] не-формальная онтологии от Microsoft привязанная с акцентом на продажах, пользователях, маркетинге и тд.
- онтология типов данных при ответах на вопросы по геоаналитике [6] прошлогоднее исследование с акцентом на геоданные.
Есть, также, какое-то количество других научных и не только научных публикаций на эту тему, но в целом их довольно мало. Они чаще всего происходят в контексте задач по анализу данных и его автоматизации. Самое развитое идёт в сторону автоматизации создания и аннотирование моделей для ИИ. Проект D3M (Data-Driven Discovery of Models) [7] от DARPA в США. Я не так давно писал о нём и порождённых им стартапах. [8]
По тому что я вижу, рано или поздно, но с практической или научной или обеих точек зрения будет продолжение развитие моделирования типов данных. Помимо задач автоматизации обработки данных, есть явный тренд на развитие инструментов их хранения.
Ещё какое-то время назад в СУБД на родном уровне поддерживались только самые базовые типы данных։ INT, FLOAT, STRING/VARCHAR, BLOB и тд. с небольшими вариациями. Сейчас, современные СУБД, поддерживают многочисленные дополнительные типы данных, перешедших из смысловых (семантических) в базовые типы. Пример: ip-адреса и mac-адреса уже достаточно давно имеющиеся в некоторых СУБД [9] и недавно добавляемые в другие [10].
Ранее всего это произошло с датами и временем в разных вариациях, с геоданными для которых есть сейчас много отдельных функций и индексов внутри СУБД. Также происходит с сетевыми наиболее популярными данными.
Мои ощущения что на этом процесс не остановится. Например, меня удивляет что всё ещё нет СУБД общего типа с отдельными типами данных под хэши (SHA1, SHA256 и др.).
Многие составные идентификаторы и коды классификаторов сейчас в СУБД хранятся как строки, при том что часто они нужны в декомпозированной форме и, в итоге, создаётся избыточность разбирая этот код на части. Пример в России: Вы можете хранить код КЛАДР как есть, а можете разделить его на подэлементы и осуществлять поиск по ним когда это необходимо.
Не знаю появится ли когда-либо движок для СУБД дающий возможность значительно большей гибкости в хранении и индексировании данных иди же, на самом деле, это далеко от насущных необходимостей, но важно то что к у каждого смыслового типа данных есть важная связка с практиками обработки данных и эволюция СУБД в этом направлении явно происходит.
Ссылки:
[1] https://fairsharing.org/FAIRsharing.ydnwd9
[2] https://kt.ijs.si/panovp/OntoDM/archive/OntoDT.owl
[3] https://orcid.org/0000-0002-7685-9140
[4] http://edamontology.org/page
[5] https://docs.microsoft.com/en-us/common-data-model/
[6] https://digitalcommons.library.umaine.edu/josis/vol2020/iss20/2/
[7] https://datadrivendiscovery.org
[8] https://yangx.top/begtin/3926
[9] https://www.postgresql.org/docs/current/datatype-net-types.html
[10] https://mariadb.com/kb/en/inet4/
#data #rdbms #research #metadata #semanticdatatypes
Docs
Common Data Model - Common Data Model
Common Data Model is a standardized, modular, and extensible collection of data schemas that Microsoft published to help you build, use, and analyze data.
Если медицинская организация имеет личный кабинет и использует сервис CDN для раздачи контента и данные в личном кабинете тоже через него отдаются, то это в чистом виде трансграничная передача данных. Ведь данные проходят пользователю через сервера в США и/или Европе. Пожалуйся на них в Роскомнадзор и те прибегут и наштрафуют. Но есть ли ущерб потребителю? Честно говоря, я сомневаюсь. Называть компанию не буду, более того, их много.
А если ВК раздают пользователям приложения в котором 90% приложений отдаёт данные Гуглу, Facebook'у и тд. или если некоторые, не будем показывать пальцами, органы власти то Роскомнадзор даже не почешется.
Как это правильно назвать по-русски?
#privacy
А если ВК раздают пользователям приложения в котором 90% приложений отдаёт данные Гуглу, Facebook'у и тд. или если некоторые, не будем показывать пальцами, органы власти то Роскомнадзор даже не почешется.
Как это правильно назвать по-русски?
#privacy
Весьма любопытное мини-исследование о том сколько времени занимает создание open source альтернативы проприетарному продукту [1].
Автор на научность не претендует, зато много чего проанализировал и выложил в виде CSV файла [2]․
Цифр и примеров там много, почитать будет любопытно, жаль что литературного обрамления маловато, о каждом продукте можно рассказать целую историю.
А вывод очень простой - есть тренд на сокращение сроков запуска open source альтернативы существующему продукту. С 18 лет связки Unix - GNU/Linux, до менее года (343 дня) с связки Clubhouse и его опенсорс альтернативы Dogehouse.
Предлагаю подумать над выводами из этого. Я лично главным выводом вижу коммодизацию разработки ПО, в том числе открытого. Интересно посмотреть не только на open source альтернативы, но и на появление сравнимых конкурентов, оно тоже сократилось. Чем это грозит рынку ПО и сервисов? Тем что бежать надо быстрее, сильнее, лучше, а не ждать что создав продукт можно стричь купюры до конца жизни.
Ссылки:
[1] https://staltz.com/time-till-open-source-alternative.html
[2] https://github.com/staltz/ttosa
#opensource #itmarket
Автор на научность не претендует, зато много чего проанализировал и выложил в виде CSV файла [2]․
Цифр и примеров там много, почитать будет любопытно, жаль что литературного обрамления маловато, о каждом продукте можно рассказать целую историю.
А вывод очень простой - есть тренд на сокращение сроков запуска open source альтернативы существующему продукту. С 18 лет связки Unix - GNU/Linux, до менее года (343 дня) с связки Clubhouse и его опенсорс альтернативы Dogehouse.
Предлагаю подумать над выводами из этого. Я лично главным выводом вижу коммодизацию разработки ПО, в том числе открытого. Интересно посмотреть не только на open source альтернативы, но и на появление сравнимых конкурентов, оно тоже сократилось. Чем это грозит рынку ПО и сервисов? Тем что бежать надо быстрее, сильнее, лучше, а не ждать что создав продукт можно стричь купюры до конца жизни.
Ссылки:
[1] https://staltz.com/time-till-open-source-alternative.html
[2] https://github.com/staltz/ttosa
#opensource #itmarket
Полезное чтение про данные и не только:
- WSJ пишет что метеорологическая служба США начала закупать данные у двух частных компаний чтобы заполнить пробелы в покрытии их спутников [1]. Статья о том что государство действует очень медленно в таких случаях, закупать данные у частного сектора госорганам непросто.
- научная статья о том как регулируется (ограничивается) ИИ в разных странах [2] статья под пэйволом, но весьма полезна и по сути построена на сравнении предпочтении граждан.
- критическая статья в Politico о том что предполагалось что ИИ изменит систему здравоохранения и о том почему этого не происходит [3]. Если коротко то - завышенные обещания, несовместимые системы и тд. Самое плотное применение ИИ в США сейчас в радиологии.
Ссылки:
[1] https://www.wsj.com/articles/u-s-government-effort-to-tap-private-weather-data-moves-along-slowly-11661335203
[2] https://www.tandfonline.com/doi/full/10.1080/13501763.2022.2094988?src=
[3] https://www.politico.com/news/2022/08/15/artificial-intelligence-health-care-00051828
#data #readings
- WSJ пишет что метеорологическая служба США начала закупать данные у двух частных компаний чтобы заполнить пробелы в покрытии их спутников [1]. Статья о том что государство действует очень медленно в таких случаях, закупать данные у частного сектора госорганам непросто.
- научная статья о том как регулируется (ограничивается) ИИ в разных странах [2] статья под пэйволом, но весьма полезна и по сути построена на сравнении предпочтении граждан.
- критическая статья в Politico о том что предполагалось что ИИ изменит систему здравоохранения и о том почему этого не происходит [3]. Если коротко то - завышенные обещания, несовместимые системы и тд. Самое плотное применение ИИ в США сейчас в радиологии.
Ссылки:
[1] https://www.wsj.com/articles/u-s-government-effort-to-tap-private-weather-data-moves-along-slowly-11661335203
[2] https://www.tandfonline.com/doi/full/10.1080/13501763.2022.2094988?src=
[3] https://www.politico.com/news/2022/08/15/artificial-intelligence-health-care-00051828
#data #readings
WSJ
U.S. Government Effort to Tap Private Weather Data Moves Along Slowly
The U.S. government’s six-year-old effort to improve its weather forecasting ability by purchasing data from private-sector satellite companies has started to show results, although the process is moving more slowly than anticipated.
Счетная палата РФ выпустила бюллетень N30 посвящённый государственным информационным системам [1], о нем уже написали TAdviser, РБК и много других изданий. РБК, например, делают акцент на критике Гостеха [2] в бюллетене, другие издания другие акценты, а я могу посоветовать почитать сразу весь бюллетень.
С точки зрения системного подхода к госинформатизации, не углубляясь в политические аспекты, это, безусловно, важный доклад с грамотными выводами что считать расходы на создание ГИСов сложно, что они плохо систематизированы, что ФГИС КИ в текущем состоянии весьма запущенная система и ещё много чего. В целом камни в огород здесь в адрес Минцифры в нынешней и прошлых инкарнациях этого органа власти.
1. Число государственных информационных систем в России несопоставимо с [не]доступностью данных из этих же информационных систем. Иначе говоря огромное число информационных систем существуют в полностью закрытом режиме и, в лучшем случае, по ним доступны только сведения перечисленные в их ТЗ размещённом на сайте госзакупок.
2. Архитектура многих информационных систем - это продолжение госполитики по сверхконцентрации полномочий в Москве и подмосковье. Георезервирования данных нет не только потому что на этом экономят или не умеют, но и по причине трансформации федеративного государства в техноунитарное. А то есть там где нельзя забрать полномочия у субъектов федерации вместо этого на стыке полномочий создается федеральная информационная система от которой региональной власти оказываются в критической зависимости (не могут без неё работать). Это не только про электронные учебники, это ещё и про системы Росреестра, ГИС Торги, портал госзакупок и ещё многие другие системы.
3. Лично мне не хватило в бюллетене отражение "успехов" Гостех в правительстве Москвы и в Казахстане. Но даже упоминание критичности зависимости платформы от воли Сбербанка - это достаточно существенная критика.
4. Мировой опыт, будем честными, отражён очень слабо. В бюллетене много упоминается опыт по планам цифровизации, а тут скорее про решения общестрановые по информатизации и создании инфраструктуры. В мире ключевое для государственных информационных систем сейчас - это процедуры соответствия облаков обязательным стандартам, их сертификация, сертификация ПО в этих облаках и, самое главное, широкое повторное использование открытого кода в госуправлении.
Я могу рассказывать про это всё довольно долго, о многом пишу в телеграм канале, а почитать бюллетень СП будет полезно, несомненно.
Ссылки:
[1] https://ach.gov.ru/statements/bulletin-sp-8-2022
[2] https://www.rbc.ru/technology_and_media/30/08/2022/630cc2709a7947836b2ef7c4
#government #it #digital #opengov
С точки зрения системного подхода к госинформатизации, не углубляясь в политические аспекты, это, безусловно, важный доклад с грамотными выводами что считать расходы на создание ГИСов сложно, что они плохо систематизированы, что ФГИС КИ в текущем состоянии весьма запущенная система и ещё много чего. В целом камни в огород здесь в адрес Минцифры в нынешней и прошлых инкарнациях этого органа власти.
1. Число государственных информационных систем в России несопоставимо с [не]доступностью данных из этих же информационных систем. Иначе говоря огромное число информационных систем существуют в полностью закрытом режиме и, в лучшем случае, по ним доступны только сведения перечисленные в их ТЗ размещённом на сайте госзакупок.
2. Архитектура многих информационных систем - это продолжение госполитики по сверхконцентрации полномочий в Москве и подмосковье. Георезервирования данных нет не только потому что на этом экономят или не умеют, но и по причине трансформации федеративного государства в техноунитарное. А то есть там где нельзя забрать полномочия у субъектов федерации вместо этого на стыке полномочий создается федеральная информационная система от которой региональной власти оказываются в критической зависимости (не могут без неё работать). Это не только про электронные учебники, это ещё и про системы Росреестра, ГИС Торги, портал госзакупок и ещё многие другие системы.
3. Лично мне не хватило в бюллетене отражение "успехов" Гостех в правительстве Москвы и в Казахстане. Но даже упоминание критичности зависимости платформы от воли Сбербанка - это достаточно существенная критика.
4. Мировой опыт, будем честными, отражён очень слабо. В бюллетене много упоминается опыт по планам цифровизации, а тут скорее про решения общестрановые по информатизации и создании инфраструктуры. В мире ключевое для государственных информационных систем сейчас - это процедуры соответствия облаков обязательным стандартам, их сертификация, сертификация ПО в этих облаках и, самое главное, широкое повторное использование открытого кода в госуправлении.
Я могу рассказывать про это всё довольно долго, о многом пишу в телеграм канале, а почитать бюллетень СП будет полезно, несомненно.
Ссылки:
[1] https://ach.gov.ru/statements/bulletin-sp-8-2022
[2] https://www.rbc.ru/technology_and_media/30/08/2022/630cc2709a7947836b2ef7c4
#government #it #digital #opengov
ach.gov.ru
Официальный сайт Счетной палаты Российской Федерации
Forwarded from Ах, этот Минфин (Olya Parkhimovich)
Дождались! Минэк расторг контракт на портал открытых данных.
Правда возникает вопрос, почему это не было сделано еще, например, в конце 2020 года, когда подрядчик в декабре 2020 года не провел хакатон, а Минэк в августе 2021 (!) его отменил доп. соглашением.
Интересно, что одна из причин расторжения - отсутствие банковской гарантии, срок действия которой истек в январе 2022 года. Но расторгли контракт только сейчас.
Напомню, что подрядчиком была петербургская компания, у которой было 3-4 клона с одинаковыми названиями, учредителями, адресами. И одну из этих компаний Минэк внес в РНП по предыдущему госконтракту на портал ОД.
Правда возникает вопрос, почему это не было сделано еще, например, в конце 2020 года, когда подрядчик в декабре 2020 года не провел хакатон, а Минэк в августе 2021 (!) его отменил доп. соглашением.
Интересно, что одна из причин расторжения - отсутствие банковской гарантии, срок действия которой истек в январе 2022 года. Но расторгли контракт только сейчас.
Напомню, что подрядчиком была петербургская компания, у которой было 3-4 клона с одинаковыми названиями, учредителями, адресами. И одну из этих компаний Минэк внес в РНП по предыдущему госконтракту на портал ОД.
Я довольно много писал про недокументированные API госорганов [1] и упоминал похожий гражданский проект в Германии [2].
Так вот скажу что этих самых недокументированных API к государственным и окологосударственным системам, сайтам, порталам значительно больше чем может показаться со стороны.
Причём есть всего несколько причин их появления:
- наличие API как продукта редкие случаи, когда API изначально было предусмотрено, но в силу многих причин его создатель не может, не умеет или не хочет его нормально документировать.
- наличие API как следствие архитектуры приложения, как правило это следствие применение подходов вроде JAMSTACK когда вызовы к API осуществляются из Javascript на фронтэнде
- наличие API по умолчанию это когда API есть у продукта который используется для конкретной цели, но его пользователь об этом не знает
Всех этих API великое, нет огромное количество.
Какое-то время назад я размещал на сервисе Postman коллекцию с документацией таких API [3]․ Там их немного, 6 государственных систем, около пары-тройки десятков точек подключения. Все они идут по 1-й или по 2-й категории API, а есть немало API которые просто являются частью продукта и вот их примеры.
Есть такой продукт DSpace используемый ВУЗами для создания репозиториев научных результатов. Он много где установлен в мире, в основном университетами, но даже открытые библиотека НАТО и Мирового банка тоже работают на DSpace. В России он используется, например, в СПбГУ.
У DSpace по умолчанию есть интерфейс раскрытия данных по стандарту OAI-PMH, это такой стандарт архивации научных и библиотечных знаний. Поэтому, к примеру, у инсталляции DSpace есть API интерфейс для доступа [4], подробнее о нём и как работать с протоколом OAI-PMH легко гуглится. Специалисты, как правило, о таких интерфейсах знают заранее. Неспециалисты очень удивляются когда неожиданно обнаруживают.
Другой пример, у Wordpress есть API, идущее практически по умолчанию в новых инсталляциях. Оно сводится к точке подключения /wp-json/ через который можно выкачать. Это полезно, например, для цифровой архивации. Я специально для такого сделал утилиту wparc [5] позволяющую архивировать данные из инсталляций Wordpress. В России, например, Wordpress, используется на сайте Госкомиссии по Арктике и, конечно, wp-json там активирован [6].
Таких примеров много, они не описываются на порталах открытых данных и инициативах вроде bund.dev или нашей коллекции госAPI.
Ссылки:
[1] https://yangx.top/begtin/3550
[2] https://yangx.top/begtin/4194
[3] https://www.postman.com/infoculture/workspace/infoculture-public/documentation/1428203-a769e0a6-0cc9-4de4-bdcc-5f8a0fa06e36
[4] https://dspace.spbu.ru/oai/
[5] https://github.com/ruarxive/wparc
[6] https://arctic.gov.ru/wp-json/
#api #openapi #government #undocumented
Так вот скажу что этих самых недокументированных API к государственным и окологосударственным системам, сайтам, порталам значительно больше чем может показаться со стороны.
Причём есть всего несколько причин их появления:
- наличие API как продукта редкие случаи, когда API изначально было предусмотрено, но в силу многих причин его создатель не может, не умеет или не хочет его нормально документировать.
- наличие API как следствие архитектуры приложения, как правило это следствие применение подходов вроде JAMSTACK когда вызовы к API осуществляются из Javascript на фронтэнде
- наличие API по умолчанию это когда API есть у продукта который используется для конкретной цели, но его пользователь об этом не знает
Всех этих API великое, нет огромное количество.
Какое-то время назад я размещал на сервисе Postman коллекцию с документацией таких API [3]․ Там их немного, 6 государственных систем, около пары-тройки десятков точек подключения. Все они идут по 1-й или по 2-й категории API, а есть немало API которые просто являются частью продукта и вот их примеры.
Есть такой продукт DSpace используемый ВУЗами для создания репозиториев научных результатов. Он много где установлен в мире, в основном университетами, но даже открытые библиотека НАТО и Мирового банка тоже работают на DSpace. В России он используется, например, в СПбГУ.
У DSpace по умолчанию есть интерфейс раскрытия данных по стандарту OAI-PMH, это такой стандарт архивации научных и библиотечных знаний. Поэтому, к примеру, у инсталляции DSpace есть API интерфейс для доступа [4], подробнее о нём и как работать с протоколом OAI-PMH легко гуглится. Специалисты, как правило, о таких интерфейсах знают заранее. Неспециалисты очень удивляются когда неожиданно обнаруживают.
Другой пример, у Wordpress есть API, идущее практически по умолчанию в новых инсталляциях. Оно сводится к точке подключения /wp-json/ через который можно выкачать. Это полезно, например, для цифровой архивации. Я специально для такого сделал утилиту wparc [5] позволяющую архивировать данные из инсталляций Wordpress. В России, например, Wordpress, используется на сайте Госкомиссии по Арктике и, конечно, wp-json там активирован [6].
Таких примеров много, они не описываются на порталах открытых данных и инициативах вроде bund.dev или нашей коллекции госAPI.
Ссылки:
[1] https://yangx.top/begtin/3550
[2] https://yangx.top/begtin/4194
[3] https://www.postman.com/infoculture/workspace/infoculture-public/documentation/1428203-a769e0a6-0cc9-4de4-bdcc-5f8a0fa06e36
[4] https://dspace.spbu.ru/oai/
[5] https://github.com/ruarxive/wparc
[6] https://arctic.gov.ru/wp-json/
#api #openapi #government #undocumented
Telegram
Ivan Begtin
Продолжая тему недокументированных государственных API приведу ещё один живой пример с некоторыми техническими подробностями.
Вот, в Санкт-Петербурге есть портал бюджетных инициатив граждан [1]. В целом неплохой, современно выглядящий и с примерно 29 тысячами…
Вот, в Санкт-Петербурге есть портал бюджетных инициатив граждан [1]. В целом неплохой, современно выглядящий и с примерно 29 тысячами…
Forwarded from Координация профанации
Рубрика "Циничное законописательство"
После вчерашней публикации Счетной палатой отчета по ЭАМ про ГИСы и Бюллетеня на ту же тему Минцифры решило хайпануть на теме и продемонстрировать, как быстро оно умеет отрабатывать рекомендации уважаемого Высшего органа государственного аудита.
Уже сегодня на Регулейшене появился проект внесения изменений в 149-ФЗ, в котором сделана очередная обреченная на провал попытка определения термина "государственная информационная система". Ссылку на Регулейшен и цитаты из "законопроекта" я не даю, потому что этот "законопроект" написан исключительно с целью ИБД (ИБД - имитация бурной деятельности, а не что-то про информационную безопасность). Шансов на то, что этот проект попадет в Госдуму, практически ноль - скорее всего, его зарубят на этапе антикоррупционной экспертизы еще на Регулейшене (там коррупциогенность не в терминологии, а в другом пункте - про приостановку финансирования ГИС).
В Минцифры не могут понять главного - любые попытки внесения в 149-ФЗ каких-либо изменений, относящихся к крайне немногочисленным в этом законе положениям про ИС и ГИС (если не считать статьи про ЕБС, которая вообще должна была стать отдельным законом, а не уродливым "горбом" у 149-ФЗ), являются ничем иным, как разновидностью гальванизации трупа. 149-ФЗ как субъект регулирования именно госИТ давно и бесповоротно убит Роскомнадзором, превратившим его в закон о запрете информации.
Сфера госИТ нуждается в своем отдельном федеральном законе - примерно таком в концептуальном смысле, каким был светлой памяти 24-ФЗ от 1995 года. И вот уже в рамках этого, отделенного от цензуры и надзора закона, нужно давать определения ГИС, ГИР (государственных информационных ресурсов), цифровых платформ, Гостеха и т.п.
Но для написания такого закона сейчас нет экспертного ресурса - ни среди юристов по информационному праву, ни среди ИТшников, способных генерировать правильные с технической и юридической точек зрения определения.Вот только я один и остался из экспертов - как три тополя на Плющихе.
А начать следовало бы вообще с узаконивания очень простой мысли - любая информационная система, созданная, развиваемая и эксплуатируемая за счет бюджета, является государственной информационной системой, независимо от целей ее создания, сферы применения, реализуемой функциональности и т.д. Все используемые сегодня определяющие критерии для ГИС должны определять не то, ГИС перед нами или не-ГИС, а конкретную категорию ГИС - ГИС госуслуг, ГИС полномочий, ГИС инфраструктуры, ГИС взаимодействия, ГИС поддержки процессов и т.п. Но это уже будет классификация второго рода. А классификация первого рода очень простая - "чьи деньги в системе?".
Вот и всё. Будет время, распишу эти мысли подробнее. А пока вот так
После вчерашней публикации Счетной палатой отчета по ЭАМ про ГИСы и Бюллетеня на ту же тему Минцифры решило хайпануть на теме и продемонстрировать, как быстро оно умеет отрабатывать рекомендации уважаемого Высшего органа государственного аудита.
Уже сегодня на Регулейшене появился проект внесения изменений в 149-ФЗ, в котором сделана очередная обреченная на провал попытка определения термина "государственная информационная система". Ссылку на Регулейшен и цитаты из "законопроекта" я не даю, потому что этот "законопроект" написан исключительно с целью ИБД (ИБД - имитация бурной деятельности, а не что-то про информационную безопасность). Шансов на то, что этот проект попадет в Госдуму, практически ноль - скорее всего, его зарубят на этапе антикоррупционной экспертизы еще на Регулейшене (там коррупциогенность не в терминологии, а в другом пункте - про приостановку финансирования ГИС).
В Минцифры не могут понять главного - любые попытки внесения в 149-ФЗ каких-либо изменений, относящихся к крайне немногочисленным в этом законе положениям про ИС и ГИС (если не считать статьи про ЕБС, которая вообще должна была стать отдельным законом, а не уродливым "горбом" у 149-ФЗ), являются ничем иным, как разновидностью гальванизации трупа. 149-ФЗ как субъект регулирования именно госИТ давно и бесповоротно убит Роскомнадзором, превратившим его в закон о запрете информации.
Сфера госИТ нуждается в своем отдельном федеральном законе - примерно таком в концептуальном смысле, каким был светлой памяти 24-ФЗ от 1995 года. И вот уже в рамках этого, отделенного от цензуры и надзора закона, нужно давать определения ГИС, ГИР (государственных информационных ресурсов), цифровых платформ, Гостеха и т.п.
Но для написания такого закона сейчас нет экспертного ресурса - ни среди юристов по информационному праву, ни среди ИТшников, способных генерировать правильные с технической и юридической точек зрения определения.
Вот и всё. Будет время, распишу эти мысли подробнее. А пока вот так
Полезное чтение про данные, стартапы и технологии:
- Developer Experience Infrastructure (DXI) [1] о том как создавать продукты для разработчиков и что разработчики от них ждут. Похоже на подходы User Experience, только пользователи тут особые
- The Good Research Code Handbook [2] о том как реорганизовать код в при исследовательском проекте. Я бы сказал что это надо студентам прям преподавать, но полезно не только им
- StarTree подняли $47M инвестиций [3] и развивают свой продукт по облачной аналитике. Это та команда что создала Apache Pinot и делают теперь его корпоративный вариант.
- Data Governance Checklist [4] сильно связанный с регулированием, персональными данными и иными законами в США. Что не мешает ему быть актуальным не только в США
Ссылки:
[1] https://kenneth.io/post/developer-experience-infrastructure-dxi
[2] https://goodresearch.dev/index.html
[3] https://www.startree.ai/blog/a-new-phase-of-growth-for-startree-and-the-real-time-user-facing-analytics-movement
[4] https://medium.com/@corymaklin/data-governance-checklist-152a3a691002
#readings #data #startups
- Developer Experience Infrastructure (DXI) [1] о том как создавать продукты для разработчиков и что разработчики от них ждут. Похоже на подходы User Experience, только пользователи тут особые
- The Good Research Code Handbook [2] о том как реорганизовать код в при исследовательском проекте. Я бы сказал что это надо студентам прям преподавать, но полезно не только им
- StarTree подняли $47M инвестиций [3] и развивают свой продукт по облачной аналитике. Это та команда что создала Apache Pinot и делают теперь его корпоративный вариант.
- Data Governance Checklist [4] сильно связанный с регулированием, персональными данными и иными законами в США. Что не мешает ему быть актуальным не только в США
Ссылки:
[1] https://kenneth.io/post/developer-experience-infrastructure-dxi
[2] https://goodresearch.dev/index.html
[3] https://www.startree.ai/blog/a-new-phase-of-growth-for-startree-and-the-real-time-user-facing-analytics-movement
[4] https://medium.com/@corymaklin/data-governance-checklist-152a3a691002
#readings #data #startups
kenneth.io
Developer Experience Infrastructure (DXI) | Kenneth Auchenberg
Developer Experience Infrastructure (DXI) is a new emerging infrastructure category sitting on top of API and cloud infrastructure. It enables any company to deliver world-class developer experiences by offloading the intricate details and complexities of…
Периодическая таблица элементов открытых данных [1] от Open Data Policy Lab. В ней ничего про технологии и много про организацию процесса, ответственных, взаимодействие с пользователями, нормативное закрепление и так далее.
Сложно сказать насколько это применимо в России и сейчас, скорее не применимо, но для тех стран, регионов, городов и организаций которые в открытые данные вкладывают время и силы - это безусловно полезно, в первую очередь, для структуризации собственных мыслей.
По ссылке кроме этой таблицы подробный опросник.
Ссылки:
[1] https://periodictable.opendatapolicylab.org/
#opendata #opengov #data #datamanagement
Сложно сказать насколько это применимо в России и сейчас, скорее не применимо, но для тех стран, регионов, городов и организаций которые в открытые данные вкладывают время и силы - это безусловно полезно, в первую очередь, для структуризации собственных мыслей.
По ссылке кроме этой таблицы подробный опросник.
Ссылки:
[1] https://periodictable.opendatapolicylab.org/
#opendata #opengov #data #datamanagement
Полезное чтение про данные, технологии и не только:
Данные
- State of gender data [1] есть такая большая тема - учет гендерных особенностей в системах регистрации статистики, учетных системах или, как упоминают авторы, "data systems". Текст о том что учет гендерных данных недостаточен.
- One Data Point Can Beat Big Data [2] о том что не всё решается большими данными и понимание данных и тщательная их фильтрация, избавление от шума, могут дать больше чем просто расширение источников и объёмов данных
- Making Government Data Publicly Available: Guidance for Agencies on Releasing Data Responsibly [3] руководство о том почему и как публиковать открытые данные от Center for Democracy and Technology. Адресовано органам власти (агентствам) в США, но актуально для всех
- Closing the Data Divide for a More Equitable U.S. Digital Economy [4] о неравенстве в доступе к данным и что с этим делать на примере экономики США. В основном рекомендации для регуляторов. Акценты на том что есть многие сообщества (в нашем понимании муниципалитеты) качество данных по которым невелико и они выпадают из многих госпрограмм поддержки. Тема важная, подход системный, но, конечно, инфраструктура и экономика США от других стран существенно отличаются.
ИИ и умные города
- Why Japan is building smart cities from scratch [5] о том почему в Японии создают умные города с нуля. На самом деле в статье именно на этот вопрос ответа нет, есть рассказ про несколько городов в Японии построенных с нуля. Это интересно, хотя я подозреваю что в Китае в в этом направлении даже больший прогресс.
Технологии и программирование
- Building modern Python API backends in 2022 [6] о структуре и архитектуре современных бэкэндов приложений на Python. Конечно, на самом деле, альтернатив куда больше, но прикладной стек расписан хорошо.
- Ruff [7] очень быстрый проверятель (linter) исходного кода для Python, написанный на Rust. Показывают производительность выше в 10-100 раз чем другие аналогичные инструменты вроде flake8, pylint и т.д.
—
P.S. Я подумываю выделить рубрику чтение (#readings) в какой-то отдельный формат, например, еженедельную рассылку, в отличие от моей личной рассылки которую я веду не регулярно или же скорректировать личную рассылку (begtin.substack.com) и добавить туда еженедельной регулярности.
Ссылки:
[1] https://data2x.org/state-of-gender-data/
[2] https://behavioralscientist.org/gigerenzer-one-data-point-can-beat-big-data/
[3] https://cdt.org/insights/making-government-data-publicly-available-guidance-for-agencies-on-releasing-data-responsibly/
[4] https://datainnovation.org/2022/08/closing-the-data-divide-for-a-more-equitable-u-s-digital-economy/
[5] https://www.nature.com/articles/d41586-022-02218-5
[6] https://backfill.dev/blog/2022-08-21-modern-python-backends/
[7] https://github.com/charliermarsh/ruff
#opendata #data #government #policy #tech #programming #readings
Данные
- State of gender data [1] есть такая большая тема - учет гендерных особенностей в системах регистрации статистики, учетных системах или, как упоминают авторы, "data systems". Текст о том что учет гендерных данных недостаточен.
- One Data Point Can Beat Big Data [2] о том что не всё решается большими данными и понимание данных и тщательная их фильтрация, избавление от шума, могут дать больше чем просто расширение источников и объёмов данных
- Making Government Data Publicly Available: Guidance for Agencies on Releasing Data Responsibly [3] руководство о том почему и как публиковать открытые данные от Center for Democracy and Technology. Адресовано органам власти (агентствам) в США, но актуально для всех
- Closing the Data Divide for a More Equitable U.S. Digital Economy [4] о неравенстве в доступе к данным и что с этим делать на примере экономики США. В основном рекомендации для регуляторов. Акценты на том что есть многие сообщества (в нашем понимании муниципалитеты) качество данных по которым невелико и они выпадают из многих госпрограмм поддержки. Тема важная, подход системный, но, конечно, инфраструктура и экономика США от других стран существенно отличаются.
ИИ и умные города
- Why Japan is building smart cities from scratch [5] о том почему в Японии создают умные города с нуля. На самом деле в статье именно на этот вопрос ответа нет, есть рассказ про несколько городов в Японии построенных с нуля. Это интересно, хотя я подозреваю что в Китае в в этом направлении даже больший прогресс.
Технологии и программирование
- Building modern Python API backends in 2022 [6] о структуре и архитектуре современных бэкэндов приложений на Python. Конечно, на самом деле, альтернатив куда больше, но прикладной стек расписан хорошо.
- Ruff [7] очень быстрый проверятель (linter) исходного кода для Python, написанный на Rust. Показывают производительность выше в 10-100 раз чем другие аналогичные инструменты вроде flake8, pylint и т.д.
—
P.S. Я подумываю выделить рубрику чтение (#readings) в какой-то отдельный формат, например, еженедельную рассылку, в отличие от моей личной рассылки которую я веду не регулярно или же скорректировать личную рассылку (begtin.substack.com) и добавить туда еженедельной регулярности.
Ссылки:
[1] https://data2x.org/state-of-gender-data/
[2] https://behavioralscientist.org/gigerenzer-one-data-point-can-beat-big-data/
[3] https://cdt.org/insights/making-government-data-publicly-available-guidance-for-agencies-on-releasing-data-responsibly/
[4] https://datainnovation.org/2022/08/closing-the-data-divide-for-a-more-equitable-u-s-digital-economy/
[5] https://www.nature.com/articles/d41586-022-02218-5
[6] https://backfill.dev/blog/2022-08-21-modern-python-backends/
[7] https://github.com/charliermarsh/ruff
#opendata #data #government #policy #tech #programming #readings
Как организовать рассылку еженедельных списков для чтения (дайджестов) про открытые данные, данные в принципе, технологии, государство и тд.?
Anonymous Poll
16%
Сделать отдельную еженедельную рассылку дайджеста
7%
Добавить еженедельное письмо в личную рассылку begtin.substack.com
55%
Можно ничего не менять, достаточно постов в Телеграм в канале @begtin
7%
Лучше отдельный канал в телеграм только для дайджестов
14%
Мнения не имею, хочу посмотреть ответы
Купище державное
Я чувствую уже что слишком часто пишу про инициативы Минцифры РФ, гораздо реже стал писать в последнее время про госзакупки или другие органы власти, а чаще про них и про технологии. Вот недавно на Regulation выложили свежий проект постановления Пр-ва РФ [1] с обновлённым положением ГосТех'а и положением о ФГИС "ГосМаркет".
Во первых, не могу не посетовать на неизобретательность авторов. Сплошные англицизмы, а могли бы назвать imperium foro (на латыни) или купище державное / державное купище (почти старославянский). Но это ирония, будем честными, ничего другого мы и не ждали.
Сама идея того что называют Госмаркетом в том чтобы у производителей ПО была бы возможность продажи своих продуктов госорганам в режиме магазина. Зашёл, кликнул, получил, начал работать.
Очень простая схема для продуктов поставляемых в конкурентных рынках, по оферте с типовыми условиями.
В чём проблема с "ГосМаркетом" в России?
С тем что заказчики покупают не продукты, а по сути лицензии. Чаще всего на основе этих лицензий идёт последующая доработка софта или его кастомизация даже для таких, казалось бы, типовых решений как сайты госорганов.
Поэтому в мире, как минимум в развитых странах, произошла эволюция понятия government marketplace в каталог аттестованных/сертифицированных продуктов поддерживаемый владельцем облачной платформы.
Например, Azure Government Marketplace [2] и AWS GovCloud с руководствами по публикации там приложений [3].
В чем особенность ГосМаркета?
1. Зависимость от ГосТех'а что довольно странно поскольку сам ГосТех выглядит "големимсто". В том смысле что НПА вокруг него уже принято больше чем видно реального результата.
2. Оторванность от ГосОблака - кто-то ещё помнит, а такой проект был и никуда не делся. Но с суетой вокруг ГосТех'а его куда-то задвинули на второй или третий план.
3. Отсутствие сертификации соответствия облачных решений. Вообще обычно вначале их разрабатывают и актуализируют и только потом уже создают платформы вроде Державного купища
Я на эту тему могу рассуждать и писать ещё долго, но пока ограничусь напоминанием что портал ГосУслуг в России запускали трижды. Сколько раз будут запускать ГосТех и ГосМаркет?
Денег в стране ещё много, я делаю
ставку что больше двух раз;)
Ссылки:
[1] https://regulation.gov.ru/projects#npa=131116
[2] https://docs.microsoft.com/ru-ru/azure/azure-government/documentation-government-manage-marketplace
[3] https://aws.amazon.com/ru/blogs/awsmarketplace/category/public-sector/government/
#government #digital
Я чувствую уже что слишком часто пишу про инициативы Минцифры РФ, гораздо реже стал писать в последнее время про госзакупки или другие органы власти, а чаще про них и про технологии. Вот недавно на Regulation выложили свежий проект постановления Пр-ва РФ [1] с обновлённым положением ГосТех'а и положением о ФГИС "ГосМаркет".
Во первых, не могу не посетовать на неизобретательность авторов. Сплошные англицизмы, а могли бы назвать imperium foro (на латыни) или купище державное / державное купище (почти старославянский). Но это ирония, будем честными, ничего другого мы и не ждали.
Сама идея того что называют Госмаркетом в том чтобы у производителей ПО была бы возможность продажи своих продуктов госорганам в режиме магазина. Зашёл, кликнул, получил, начал работать.
Очень простая схема для продуктов поставляемых в конкурентных рынках, по оферте с типовыми условиями.
В чём проблема с "ГосМаркетом" в России?
С тем что заказчики покупают не продукты, а по сути лицензии. Чаще всего на основе этих лицензий идёт последующая доработка софта или его кастомизация даже для таких, казалось бы, типовых решений как сайты госорганов.
Поэтому в мире, как минимум в развитых странах, произошла эволюция понятия government marketplace в каталог аттестованных/сертифицированных продуктов поддерживаемый владельцем облачной платформы.
Например, Azure Government Marketplace [2] и AWS GovCloud с руководствами по публикации там приложений [3].
В чем особенность ГосМаркета?
1. Зависимость от ГосТех'а что довольно странно поскольку сам ГосТех выглядит "големимсто". В том смысле что НПА вокруг него уже принято больше чем видно реального результата.
2. Оторванность от ГосОблака - кто-то ещё помнит, а такой проект был и никуда не делся. Но с суетой вокруг ГосТех'а его куда-то задвинули на второй или третий план.
3. Отсутствие сертификации соответствия облачных решений. Вообще обычно вначале их разрабатывают и актуализируют и только потом уже создают платформы вроде Державного купища
Я на эту тему могу рассуждать и писать ещё долго, но пока ограничусь напоминанием что портал ГосУслуг в России запускали трижды. Сколько раз будут запускать ГосТех и ГосМаркет?
Денег в стране ещё много, я делаю
ставку что больше двух раз;)
Ссылки:
[1] https://regulation.gov.ru/projects#npa=131116
[2] https://docs.microsoft.com/ru-ru/azure/azure-government/documentation-government-manage-marketplace
[3] https://aws.amazon.com/ru/blogs/awsmarketplace/category/public-sector/government/
#government #digital
Docs
Azure Government Marketplace - Azure Government
This article provides guidance on how to use Azure Government Marketplace.
cruise_final_myheritage.gif
15.5 MB
Просто таки замечательный текст [1] о том насколько уже сейчас можно использовать генераторы изображений с помощью ИИ такие как Stable Diffusion для создания видео. Краткий ответ - можно уже сейчас.
Приложенная картинка сгенерирована автором с помощью DeepNostalgia [2] движка от MyHeritage по оживлению фотографий.
Автор там разбирает много других уже существующих способов генерации видео из изображений, рекомендую прочитать текст до конца и, конечно, важный акцент на рынке порнографии.
Как скоро появятся сервисы "Загрузи фото своей бывшей/актрисы/игрового персонажа и получи порно по заданным параметрам?". Ещё вопрос, станет ли это явление массовым и убьёт рынок рынок порнографии в текущем виде, или будет как со многими нынешними продуктами. Бесплатные сервисы и "более продвинутые" платные аналоги. Но то что именно этот рынок ждёт революция у меня лично сомнений не вызывает.
Может уже пора делать стартапы по персонифицированной порнографии? Уже появились венчурные фонды со специализацией в этой теме?
Ссылки:
[1] https://metaphysic.ai/stable-diffusion-is-video-coming-soon/
[2] https://blog.myheritage.com/2021/02/deep-nostalgia-goes-viral/
#ai #video #stablediffusion
Приложенная картинка сгенерирована автором с помощью DeepNostalgia [2] движка от MyHeritage по оживлению фотографий.
Автор там разбирает много других уже существующих способов генерации видео из изображений, рекомендую прочитать текст до конца и, конечно, важный акцент на рынке порнографии.
Как скоро появятся сервисы "Загрузи фото своей бывшей/актрисы/игрового персонажа и получи порно по заданным параметрам?". Ещё вопрос, станет ли это явление массовым и убьёт рынок рынок порнографии в текущем виде, или будет как со многими нынешними продуктами. Бесплатные сервисы и "более продвинутые" платные аналоги. Но то что именно этот рынок ждёт революция у меня лично сомнений не вызывает.
Может уже пора делать стартапы по персонифицированной порнографии? Уже появились венчурные фонды со специализацией в этой теме?
Ссылки:
[1] https://metaphysic.ai/stable-diffusion-is-video-coming-soon/
[2] https://blog.myheritage.com/2021/02/deep-nostalgia-goes-viral/
#ai #video #stablediffusion