Не секрет что поисковиков по данным очень мало, основной - это Google Dataset Search [1] который всё ещё скорее исследовательский проект и где просто ну очень много SEO спама поскольку проект основан на самостоятельной разметке объектов пользователями по стандарту Schema.org объектам типа Dataset [2].
Ещё в прошлом году исследователи Google из MIT проанализировали несколько сотен тысяч страниц с датасетами и разработали классификатор определяющий что на веб странице действительно набор данных [3]․ Они же выложили датасет с результатами такой разметки [4], можно сказать датасет про датасеты.
Лично по мне так той же цели, широкого покрытия наборов данных поиском без потери качества, можно достичь и более простыми методами, а классификация страниц и сам стандарт Schema.org уж очень сильно заточен под поисковые системы в отличие от других протоколов для обнаружения данных (data discovery).
Тем не менее исследование интересное и чуть приоткрывает свет на работу которую проделывают в Google Dataset Search.
Ссылки:
[1] https://datasetsearch.research.google.com/
[2] https://schema.org/Dataset
[3] http://people.csail.mit.edu/tarfah/papers/dataset.pdf
[4] https://www.kaggle.com/datasets/googleai/veracity-of-schemaorg-for-datasets-labeled-data
#opendata #datasets #search #research
Ещё в прошлом году исследователи Google из MIT проанализировали несколько сотен тысяч страниц с датасетами и разработали классификатор определяющий что на веб странице действительно набор данных [3]․ Они же выложили датасет с результатами такой разметки [4], можно сказать датасет про датасеты.
Лично по мне так той же цели, широкого покрытия наборов данных поиском без потери качества, можно достичь и более простыми методами, а классификация страниц и сам стандарт Schema.org уж очень сильно заточен под поисковые системы в отличие от других протоколов для обнаружения данных (data discovery).
Тем не менее исследование интересное и чуть приоткрывает свет на работу которую проделывают в Google Dataset Search.
Ссылки:
[1] https://datasetsearch.research.google.com/
[2] https://schema.org/Dataset
[3] http://people.csail.mit.edu/tarfah/papers/dataset.pdf
[4] https://www.kaggle.com/datasets/googleai/veracity-of-schemaorg-for-datasets-labeled-data
#opendata #datasets #search #research
schema.org
Dataset - Schema.org Type
Schema.org Type: Dataset - A body of structured information describing some topic(s) of interest.
Для тех кто мог упустить, в прошлом году, в октябре вышла записка The future of open data [1] за авторством Карлоса Иглесиаса о том в какую сторону развиваются тренды в открытости данных в мире. Записка там вышла довольно короткая, ключевое в ней 7 пунктов большая часть которых вообще не про технологии, а про людей. И даже конкретно про сообщества, обучение, организацию процессов и так далее.
Я хотел написать об этом тексте ещё в конце 2021 года, но в начале 2022 вышел другой текст с идентичным (!) названием, также The Future of Open Data [2], но с авторством двух канадок
и с очень чётким фокусом на геоданные.
Чего не хватает в этих документах, так это понимания того кто аудитория порталов открытых данных и инициатив по открытости. А ещё точнее кто уже является аудиторией и кто должен быть аудиторией. Часто это разные группы: программисты, создатели стартапов, корпорации, журналисты, ученые, госслужащие, активисты и студенты. Есть много пользовательских сценариев, и не только для порталов открытых данных, но и для открытых данных в принципе.
Пока я не видел ни одного полномасштабного исследования в этой теме, даже от крупных институций, но, всё это, проделанные работы в вроде той что сделал Карлос Иглесиас, не обесценивает.
Важное отличие развитие открытых данных в демократических странах в том что остальные инициативы по работе с данными в госсекторе связаны с ними и так или иначе их дополняют.
В России государственный портал открытых данных и иные дата-продукты государства существуют почти не пересекаясь. Это не хотят понимать, ни те кто должны обеспечивать открытость гос-ва, ни те кто оценивают эту открытость.
Открытые и общедоступные данные у нас окончательно рассинхронизуются уже давно. Данные которые мы собирали с порталов государственных информационных системы мы собирали, как минимум, на два порядка больше данных чем с официальных порталов открытых данных.
Ссылки:
[1] https://datos.gob.es/en/documentacion/future-open-data
[2] https://ruor.uottawa.ca/handle/10393/43648
#opendata #research
Я хотел написать об этом тексте ещё в конце 2021 года, но в начале 2022 вышел другой текст с идентичным (!) названием, также The Future of Open Data [2], но с авторством двух канадок
и с очень чётким фокусом на геоданные.
Чего не хватает в этих документах, так это понимания того кто аудитория порталов открытых данных и инициатив по открытости. А ещё точнее кто уже является аудиторией и кто должен быть аудиторией. Часто это разные группы: программисты, создатели стартапов, корпорации, журналисты, ученые, госслужащие, активисты и студенты. Есть много пользовательских сценариев, и не только для порталов открытых данных, но и для открытых данных в принципе.
Пока я не видел ни одного полномасштабного исследования в этой теме, даже от крупных институций, но, всё это, проделанные работы в вроде той что сделал Карлос Иглесиас, не обесценивает.
Важное отличие развитие открытых данных в демократических странах в том что остальные инициативы по работе с данными в госсекторе связаны с ними и так или иначе их дополняют.
В России государственный портал открытых данных и иные дата-продукты государства существуют почти не пересекаясь. Это не хотят понимать, ни те кто должны обеспечивать открытость гос-ва, ни те кто оценивают эту открытость.
Открытые и общедоступные данные у нас окончательно рассинхронизуются уже давно. Данные которые мы собирали с порталов государственных информационных системы мы собирали, как минимум, на два порядка больше данных чем с официальных порталов открытых данных.
Ссылки:
[1] https://datos.gob.es/en/documentacion/future-open-data
[2] https://ruor.uottawa.ca/handle/10393/43648
#opendata #research
В рубрике о нас пишут, о нашем исследовании приватности мобильных приложений написали:
- Эксперты оценили долю американских трекеров в RuStore РБК
- «Инфокультура» исследовала приватность мобильных приложений в RuStore Роскомсвобода
- Почти 90% приложений в RuStore имеют встроенный иностранный трекер Runet.News
- В приложениях российского магазина RuStore нашли зарубежные модули слежки Ferra
а также ещё пара десятков СМИ и телеграм каналов.
Не менее важно кто ничего о нём не написал: CNews, Коммерсант, Ведомости и ещё ряд изданий. Как говорится, Бог простит, а я запишу (с) ;)
Это не последнее наше исследование, будут и другие и не только про мобильные приложения.
#research #privacy #mobileapps
- Эксперты оценили долю американских трекеров в RuStore РБК
- «Инфокультура» исследовала приватность мобильных приложений в RuStore Роскомсвобода
- Почти 90% приложений в RuStore имеют встроенный иностранный трекер Runet.News
- В приложениях российского магазина RuStore нашли зарубежные модули слежки Ferra
а также ещё пара десятков СМИ и телеграм каналов.
Не менее важно кто ничего о нём не написал: CNews, Коммерсант, Ведомости и ещё ряд изданий. Как говорится, Бог простит, а я запишу (с) ;)
Это не последнее наше исследование, будут и другие и не только про мобильные приложения.
#research #privacy #mobileapps
РБК
Эксперты оценили долю американских трекеров в RuStore
Почти 90% приложений из магазина RuStore используют иностранные трекеры — они могут собирать как техошибки, так и данные пользователей. Создатель маркетплейса — холдинг VK подчеркивает: на безопасность данных это не влияет
У Postman вышел их ежегодный обзор 2022 State of the API Report [1] составленный через опрос разработчиков пользующихся их платформой и схожий с исследованиями JetBrains.
Исследование полезное, много графиков, большая выборка, много чего любопытного. Конечно, с оговоркой что они делают акценты там где их собственный продукт посильнее, а некоторые темы вроде предпочтений по корпоративной интеграции или языки разработки охватывают мало или недостаточно.
Полезно будет, в первую очередь, тем кто выбирает приоритеты в изучении новых технологий.
Ссылки:
[1] https://www.postman.com/state-of-api/how-to-share-the-report/
#api #studies #research #postman
Исследование полезное, много графиков, большая выборка, много чего любопытного. Конечно, с оговоркой что они делают акценты там где их собственный продукт посильнее, а некоторые темы вроде предпочтений по корпоративной интеграции или языки разработки охватывают мало или недостаточно.
Полезно будет, в первую очередь, тем кто выбирает приоритеты в изучении новых технологий.
Ссылки:
[1] https://www.postman.com/state-of-api/how-to-share-the-report/
#api #studies #research #postman
Онтология типов данных
Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология 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://t.me/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://t.me/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.
The Open Data Canvas–Analyzing Value Creation from Open Data [1] научная статья за авторством Yingyng Gao и Marijn Janssen посвящённая созданию аналога канвы для бизнес модели, но для проектов на открытых данных. Авторы неплохо поработали над структурой канвы, с научной точки зрения интересны полезна их логика рассуждения, с практической - это структура запуска проекта на открытых данных. Составление таких канв проектов полезно когда ты проектируешь новый проект, или в процессе обучения, или, не в меньшей степени, на хакатонах и конкурсах, когда участники вначале проектируют то что они хотят сделать.
В статье примеры канвы по COVID-19 Dashboard, в целом отражающей действительности.
Со своей колокольни я вижу то чего в такой канве не хватает - это устойчивости (sustainability). В канве бизнес-модели этого нет потому что предполагается что бизнес приносит деньги, а если он не приносит, то это не бизнес. Иначе говоря, бизнес модель всегда предполагает наличие кэш флоу если не от клиентов, то от инвесторов.
В случае с любыми некоммерческими проектами, такими как проекты на открытых данных, кэш флоу может не быть. То что указано в Costs может быть как постоянным, частью деятельности чего-то, как COVID-19 Dashboard часть деятельности института Джона Хопкинса, так и может быть и, чаще, является потребностью в поиске финансирования/смены структуры продукта и проекта.
Как бы то ни было этот шаблон канвы вполне пригоден и полезен в работе. Осталось его только красиво оформить, поместить во что-нибудь вроде Miro и похожие инструменты.
Ссылки:
[1] https://dl.acm.org/doi/pdf/10.1145/3511102
#opendata #canvas #businessmodel #research
В статье примеры канвы по COVID-19 Dashboard, в целом отражающей действительности.
Со своей колокольни я вижу то чего в такой канве не хватает - это устойчивости (sustainability). В канве бизнес-модели этого нет потому что предполагается что бизнес приносит деньги, а если он не приносит, то это не бизнес. Иначе говоря, бизнес модель всегда предполагает наличие кэш флоу если не от клиентов, то от инвесторов.
В случае с любыми некоммерческими проектами, такими как проекты на открытых данных, кэш флоу может не быть. То что указано в Costs может быть как постоянным, частью деятельности чего-то, как COVID-19 Dashboard часть деятельности института Джона Хопкинса, так и может быть и, чаще, является потребностью в поиске финансирования/смены структуры продукта и проекта.
Как бы то ни было этот шаблон канвы вполне пригоден и полезен в работе. Осталось его только красиво оформить, поместить во что-нибудь вроде Miro и похожие инструменты.
Ссылки:
[1] https://dl.acm.org/doi/pdf/10.1145/3511102
#opendata #canvas #businessmodel #research
В рубрике интересных наборов данных новость о том что DBLP, открытая база научных публикаций о компьютерных науках, интегрировали их данные с другой открытой научной базой OpenAlex и пишут об этом [1].
Для тех кто не знает, OpenAlex - это открытый продукт базы данных ссылок на научные публикации созданный НКО OutResearch на базе Microsoft Academic Knowledge Graph, большого набор данных опубликованного компанией Microsoft для помощи в развитии инструментов анализа библиографических данных.
DBLP - это проект университета Триера существующий с 1993 года и ведущий крупнейшую в мире систематизированную базу научных публикаций в области компьютерных наук.
Интеграция даёт возможность увидеть категории/концепты к которым относится данная публикация, а ранее уже DBLP интегрировали с базами Semantic Scholar, Crossref и OpenCitations.
Пока это всё происходит на уровне веб-интерфейсов, но, ничто не мешает использовать открытые данные DBLP [2] что автоматизации анализа в нужных областях.
Лично мне в DBLP всегда не хватало возможности подписаться на новые статьи по конкретной теме, исследователю, исследовательскому центру, ключевым словам, но это то что можно делать в других сервисах вроде Semantic Scholar.
Я читаю на регулярной основе ключевые научные работы по цифровой архивации, открытым данным и "пониманию данных" (семантическим типам данных, идентификации шаблонов и тд.). Удобные инструменты для поиска таких публикаций очень помогают.
Ссылки։
[1] https://blog.dblp.org/2022/08/31/openalex-integration-in-dblp/
[2] https://dblp.uni-trier.de/xml/
#opendata #research #openaccess #datasets
Для тех кто не знает, OpenAlex - это открытый продукт базы данных ссылок на научные публикации созданный НКО OutResearch на базе Microsoft Academic Knowledge Graph, большого набор данных опубликованного компанией Microsoft для помощи в развитии инструментов анализа библиографических данных.
DBLP - это проект университета Триера существующий с 1993 года и ведущий крупнейшую в мире систематизированную базу научных публикаций в области компьютерных наук.
Интеграция даёт возможность увидеть категории/концепты к которым относится данная публикация, а ранее уже DBLP интегрировали с базами Semantic Scholar, Crossref и OpenCitations.
Пока это всё происходит на уровне веб-интерфейсов, но, ничто не мешает использовать открытые данные DBLP [2] что автоматизации анализа в нужных областях.
Лично мне в DBLP всегда не хватало возможности подписаться на новые статьи по конкретной теме, исследователю, исследовательскому центру, ключевым словам, но это то что можно делать в других сервисах вроде Semantic Scholar.
Я читаю на регулярной основе ключевые научные работы по цифровой архивации, открытым данным и "пониманию данных" (семантическим типам данных, идентификации шаблонов и тд.). Удобные инструменты для поиска таких публикаций очень помогают.
Ссылки։
[1] https://blog.dblp.org/2022/08/31/openalex-integration-in-dblp/
[2] https://dblp.uni-trier.de/xml/
#opendata #research #openaccess #datasets
Незаслуженно упущенная мной публикация июля этого года What is the value of data? A review of empirical methods [1] от исследователей из Bennett Institute for Public Policy Университета Кэмбриджа. Они разбирают методы оценки стоимости/ценности данных, в первую очередь, с точки зрения экономических оценок их использования и ссылаются на их же работу 2020 года Value of Data report [2], а также на оценки ОЭСР и других.
С научной точки зрения и с точки зрения лоббирования раскрытия данных и принятия политик представления данных (data sharing) в странах где прислушиваются к доводам исследователей - это полезный текст.
Ссылки:
[1] https://www.bennettinstitute.cam.ac.uk/publications/value-of-data/
[2] https://www.bennettinstitute.cam.ac.uk/wp-content/uploads/2020/12/Value_of_data_summary_report_26_Feb.pdf
#opendata #research #policies
С научной точки зрения и с точки зрения лоббирования раскрытия данных и принятия политик представления данных (data sharing) в странах где прислушиваются к доводам исследователей - это полезный текст.
Ссылки:
[1] https://www.bennettinstitute.cam.ac.uk/publications/value-of-data/
[2] https://www.bennettinstitute.cam.ac.uk/wp-content/uploads/2020/12/Value_of_data_summary_report_26_Feb.pdf
#opendata #research #policies
Bennett Institute for Public Policy
What is the value of data? A review of empirical methods - Bennett Institute for Public Policy
A policy brief by Diane Coyle and Annabel Manley summarises the various methods being used in practice to value datasets and how they compare.
9. Одна из наиболее внятных и разумных инициатив - конкурсы Код-ЦТ и Код-ИИ организуемые Фондом содействия инноваций - это реальные попытки хоть что-то изменить и попытаться опереться на те ИТ компании и ИТ команды которые готовы и умеют развивать продукты с открытым кодом. ФСИ даёт гранты даже большие чем германский Prototype Fund, но это капля в море по сравнением с субсидиями академическим институтам и университетам на научную деятельность результат которой не виден, не известен и закрыт.
10. Аналогично с инициативами связанными с Национальным репозиторием кода, Гостехом и ещё много чем. Для понимания, в основе Гостех в Сингапуре или в Эстонии открытый код. Все лучшие примеры цифровизации госухи в мире на которые сотрудники РосГосТеха могут ссылаться тоже будут открытыми, а вот их платформа даже намеков на открытость не имеет
11. В случае с национальным репозиторием кода, то что он заменит ФАП не означает что код там будет открыт. Скорее он будет открыт для технического аудита, но даже не факт что разработка будет вестись в нём, а не использоваться только для публикации кода в момент сдачи контрактной отчетности. Это уже прогресс, но медленный.
12. Но, я повторюсь, что всё начинается с открытости результатов научных исследований. Почему он не публикуется? Спросите Минобрнауки, но там даже отвечать некому;)
Тут надо бы добавить что всё это было справедливо в мирные времена, а сейчас многие из тех кто понимает что и как можно было бы исправить и изменить, не будут работать с российскими госорганами ни на каких условиях, даже если госполитика цифровизации была бы иной.
Ссылки:
[1] https://data.world/ibegtin/open-source-government-project
[2] https://government.github.com/
#government #opensource #it #opendata #openaccess #research
10. Аналогично с инициативами связанными с Национальным репозиторием кода, Гостехом и ещё много чем. Для понимания, в основе Гостех в Сингапуре или в Эстонии открытый код. Все лучшие примеры цифровизации госухи в мире на которые сотрудники РосГосТеха могут ссылаться тоже будут открытыми, а вот их платформа даже намеков на открытость не имеет
11. В случае с национальным репозиторием кода, то что он заменит ФАП не означает что код там будет открыт. Скорее он будет открыт для технического аудита, но даже не факт что разработка будет вестись в нём, а не использоваться только для публикации кода в момент сдачи контрактной отчетности. Это уже прогресс, но медленный.
12. Но, я повторюсь, что всё начинается с открытости результатов научных исследований. Почему он не публикуется? Спросите Минобрнауки, но там даже отвечать некому;)
Тут надо бы добавить что всё это было справедливо в мирные времена, а сейчас многие из тех кто понимает что и как можно было бы исправить и изменить, не будут работать с российскими госорганами ни на каких условиях, даже если госполитика цифровизации была бы иной.
Ссылки:
[1] https://data.world/ibegtin/open-source-government-project
[2] https://government.github.com/
#government #opensource #it #opendata #openaccess #research
data.world
Open source government project - dataset by ibegtin
Aggregated statistics of developers activity for open source government projects. All data collected from government.github.com and Github API for every open source government repository. Final resul
Вышел доклад/исследование State of Frontend [1] по технологиям фронтэнд разработки основанный на опросе 3703 разработчиков и с комментариями нескольких экспертов. Хотя я лично и далёк от темы фронтэнда, но тут большой любопытный текст с интересными результатами.
Вот подборка фактов:
- большинство прошедших опрос работают дистанционно: 59.7%, ещё 35.3% в гибридном формате
- в безусловных лидерах фреймворки Angular (51%) и React (25%), наиболее перспективные Svelte и Next.js
- самые популярные дизайн системы Material UI, Tailwind UI и Bootstrap
- Typescript используют 84% разработчиков и большинство (43%) считают что он заменит Javascript однажды
- большинство используют сервера AWS (Amazon) или свои собственные
- подавляющее большинство используют Visual Studio Code: 74.4%
И там ещё много всего, что-то кажется очевидным, что-то совсем нет. Например, про VS Code или про Typescript.
Ссылки:
[1] https://tsh.io/state-of-frontend/
#reports #research #frontend #javascript #development
Вот подборка фактов:
- большинство прошедших опрос работают дистанционно: 59.7%, ещё 35.3% в гибридном формате
- в безусловных лидерах фреймворки Angular (51%) и React (25%), наиболее перспективные Svelte и Next.js
- самые популярные дизайн системы Material UI, Tailwind UI и Bootstrap
- Typescript используют 84% разработчиков и большинство (43%) считают что он заменит Javascript однажды
- большинство используют сервера AWS (Amazon) или свои собственные
- подавляющее большинство используют Visual Studio Code: 74.4%
И там ещё много всего, что-то кажется очевидным, что-то совсем нет. Например, про VS Code или про Typescript.
Ссылки:
[1] https://tsh.io/state-of-frontend/
#reports #research #frontend #javascript #development
The Software House
The State of Frontend 2022 report
Based on surveys filled in by 3073 developers from 125 countries, the State of Frontend 2022 is supported by 19 expert commentaries about frontend trends and the future.