Ivan Begtin. Страница 27
3903
@begtin
I am focused on Open Data, Procurement, e-Government, Open Government and other tech stuff
-
Ivan Begtin
Когда читаю государственные или корпоративные новости про внедрение и разработку ИИ не могу не напомнить что без аналитики - нет тех кто измерит результаты машинного обучения. Без дата инженерии не появится нормальных аналитических инструментов. А без дата стратегии всё вообще не сдвинется с места и, с самого начала, пойдет не туда. Поэтому я не перестаю поражаться обилию новых создаваемых государственных информационных систем без стратегии работы с данными которые в них должны собираться. С бизнес продуктами то же самое. Кто-то уже умеет быть и реально строит бизнес на данных, а кто-то умеет казаться и не имеет даже стратегии. Поэтому, в качестве завершения этого короткого ранта, всё начинается со стратегий, далее сбора, обработки и очистки данных, далее профессионально отлаженной аналитики и только в конце уже можно что-то говорить про машинное обучение. А если стратегии нет, остаётся только пустая болтовня. #thoughts #rants #opinion #dataengineering 
-
Ivan Begtin
Полезное чтение про данные, технологии и не только: - SQL Vs. NoSQL: Choose The Most Convenient Technology [1] полезное чтение для начинающих о разнице между SQL и NoSQL базами данных. Почему для начинающих? Потому что в реальности выбор зависит от того насколько выбранный продукт соответствует компетенциям команды и выбранному технологическому стеку. - Evolution of data companies [2] о том как развиваются компании на рынке инструментов работы с данными. - Penpot - The Open-Source design & prototyping platform [3] открытая и свободная альтернатива Figma. Для тех кто хочет проектировать приложения и не хочет платить сервисам за эту возможность - Devops excercises [4] каталог ресурсов, документов, вопросов и ответов и упражнения для DevOps'ов. Полезно, как начинающим, так и углубляющим знания. - ZincSearch [5] альтернативная поисковая система декларируемая как более быстрая чем Elastic - The Production-Grade Data Pipeline [6] о том почему трубы данных надо делать сразу как продукты и о рисках накопления технического долга Ссылки: [1] pub.towardsai.net/sql-vs-…d831b6e4 [2] medium.com/coriers…f4b65e1d [3] https://github.com/penpot/penpot [4] https://github.com/bregman-arie/devops-exercises [5] https://github.com/zinclabs/zinc [6] dataproducts.substack.com/p/the-p…pipeline #opensource #datatools #data #readings #dataengineering -
Ivan Begtin
Я тут несколько раз писал о том что нет удобных инструментов для обработки для обработки NoSQL данных. Нет аналога OpenRefine или возможности удобной манипуляции данными внутри NoSQL баз данных. Писал на русском [1] и на английском языках [2]. Но рассуждать вслух хорошо, а экспериментировать лучше. Поэтому на выходных я сделал вот такой простой инструмент mongorefine [3] воспроизводящий часть функций OpenRefine используя MongoDB как бэкенд. Штука эта экспериментальная, измерения по скорости с другими подходами могут быть не в её пользу, особенно в части плоских данных. Но для не-плоских данных, она полезна даже в таком виде. Основная фича в том чтобы сделать оболочку поверх коллекций MongoDB позволяющую работать с записями как с колоночной базой данных. Свободно удалять отдельные колонки, создавать колонки на основе Лично я пока не обладаю уверенностью что путь создания системы автоматизации обработки данных поверх MongoDB - это оптимальный путь. Но если Вы готовы поэкспериментировать и дать обратную связь, то такой инструмент теперь доступен. P.S. Никогда не делайте экспериментов на рабочих базах данных. Сделайте тестовую копию и тренируйтесь на ней;) Ссылки: [1] https://t.me/begtin/4255 [2] medium.com/@ibegti…a2898a83 [3] https://github.com/ivbeg/mongorefine #data #opensource #mongodb #dataengineering #datawrangling 
-
Реклама
-
Ivan Begtin
Регулярное чтение про данные, технологии и не только: - Complexity: the new analytics frontier [1] в блоге dbt о том что обновление внутренних аналитических моделей у них в компании занимает до 21 часа и о том что сложность работа с аналитическими данными - это новый фронтир. С подробностями проблем. Несомненно актуально - Data Glossary [2] Airbyte выпустили словарик по инженерии данных с определениями и с графом связей между понятиями и вопросами. Хорошая база знаний для тех кто погружен или погружается в эту тему. В основу взяли тему Quartz [3] для генератора статических сайтов Hugo. Я думал сделать похожий словарь, у меня даже более 200 терминов накопилось, но ребята опередили. - How python programmers save the environment (by making python run faster)? [4] текст о том как ускорять Python с отсылкой на прошлогоднюю публикацию [5] о том что Python, Perl и Ruby сжигают более энергии в компьютерах. Сравнение, конечно, так себе. Можно задаться вопросом о том сколько нервных клеток экономят развитые языки программирования и насколько эффективнее разработка. Вообще приход климатической повестки в разработку ПО может оказаться неожиданным. - Go MySQL Server [6] реализация MySQL совместимого SQL сервера написанного на Go и декларируемого как хорошо расширяемого. Делает его команда Dolt, распределенной Git-подобной СУБД. Есть шанс что станет интересным продуктом однажды. - How Fivetran fails [7] Benn Stancil рассуждает о том что SaaS ETL инструмент Fivetran скоро потеряет лидерство и его заменят Airbyte и владельцы крупнейших облачных хранилищ данных Microsoft, Amazon, Google и др. Не без основательное утверждение. Про Fivetran в России мало знают, а в США - это гигантский стартап с большой корпоративной базой клиентов. - Connectors catalog [8] таблица в Airtable со списком сервисов к которым есть коннекторы у облачных ETL движков таких как Fivetran, Hevo Data, Airbyte, Whaly, Stitch и тд. Кстати, давно замечаю что российских сервисов в этих движках не было и нет. Есть ли рынок для отдельного ETL движка здесь? Может быть, но скорее нет, потому что нет облачных хранилищ как драйвера таких сервисов Ссылки: [1] roundup.getdbt.com/p/compl…frontier [2] https://glossary.airbyte.com [3] https://quartz.jzhao.xyz/ [4] laszlo.substack.com/p/how-p…ironment [5] medium.com/codex/w…774b1957 [6] https://github.com/dolthub/go-mysql-server [7] https://benn.substack.com/p/how-fivetran-fails [8] airtable.com/shrQMzH…anS8GtQa #datatools #data #readings #opensource #dataengineering -
Ivan Begtin
Для тех кто "любит командную строку также как люблю её я" (c). Командная строка - это стиль жизни, удобство и привычка. Я сижу за командной строкой уже с незапамятных времен UNIX и MS-DOS и для многих задач это гораздо быстрее чем что-либо ещё. Есть ли оболочки для работы с данными? - nushell [1] потрясающая штука для тех кто работает в командной строке и работает с данными. Умеет открывать CSV, JSON и кучу других типов файлов и показывать их таблицами. Имеет язык запросов (набор функций) позволяющих таблицами работать с файлами и ещё много всего. Пока один важный минус - не поддерживает файлы JSON lines, Parquet и BSON, но это поправимо и не критично. - Textualize и Rich [2] набор утилит и библиотека для создания оболочек для Python. Позволяет очень много, а Rich Cli ещё и умеет подсвечивать дата файлы удобным образом. - bubbletea [3] создаём терминальные приложения на языке Go. Может многое, а ещё его использует gum [4] позволяющий создавать стильные скрипты без строчки кода на Go В 2021 году в Google проводили исследование по доступности инструментов командной строки с полезными советами как их дорабатывать [5]. Командная строка - это, часто, возможность делать что-то быстро, без задержек и раздражения. Современные инструменты позволяют сделать работу с ними значительно удобнее. Ссылки: [1] https://www.nushell.sh [2] https://www.textualize.io/ [3] https://github.com/charmbracelet/bubbletea [4] https://github.com/charmbracelet/gum [5] dl.acm.org/doi/ful….3445544 #datatools #opensource #commandline 
-
Ivan Begtin
В продолжение того о чём я писал тут в телеграм канале про обработку данных [1] написал короткую технологическую заметку NoSQL data wrangling [2] про проблему обработки NoSQL данных и о дефиците инструментов позволяющих обрабатывать JSON/JSON lines. Правда заметка пока в формате размышлений вслух, готового решения у меня нет. Пока нет. Ссылки: [1] https://t.me/begtin/4255 [2] medium.com/@ibegti…a2898a83 #datatools #datawrangling #dataengineering Ivan Begtin Давно хочу написать про обработку документальных структурированных данных в NoSQL. Я затрагивал эту тему в англоязычной заметке Future of NoSQL in Modern Data Stack [1], но проблема, гораздо глубже, она связана со спецификой данных. Классические наиболее распространенные подходы к обработке/очистке данных сейчас - это, или SQL запросы, или датафреймы вроде того же pandas, или инструменты вроде OpenRefine и Trifacta. Они все оперируют простыми плоскими таблицами и умеют по этим таблицам проводить относительно простые операции: переименовать колонку, разделить её, создать новую на основе имеющейся, изменить значение и тд. В SQL это делается относительно просто, с учётом ограничений языка, конечно. В OpenRefine, Trifacta - это внутренние индексы для табличных данных и встроенные функции или внешний код. А для pandas и подхода через датафреймы - это код Python (или похожий в других языках). Для данных с вложенными документами вроде тех что сериализуются в JSON или хранятся в MongoDB так не получится. При переносе…
-
Ivan Begtin
Конгресс США официально открыл API к базе законопроектов [1], а также опубликовал исходный код с примерами работы с этим API [2]. Важно что данных там отдаётся много, фактически не просто законопроекты и законы, а весь их цифровой след, со всеми поправками, голосованиями и тд. Удивительно скорее то что у них это заняло так много времени, поскольку общественные базы данных и API к данным конгресса существуют давно [3]. Но, как бы то ни было, значит число общественных проектов на этих данных только вырастет. Ссылки: [1] blogs.loc.gov/law/202…-gov-api [2] github.com/Library…ress.gov [3] projects.propublica.org/api-doc…ress-api #opendata #us #congress #api #legislation -
Ivan Begtin
В журнале Открытые системы вышла моя статья про открытые данные [1] в контексте цифровой трансформации. Статья на ту же тему о которой я писал ранее, о том что вопросы современных инструментов открытости государства де-факто выносят за скобки цифровой трансформации. Ссылки։ [1] https://www.osp.ru/os/2022/03/13056266 #opendata #opengov #data -
Ivan Begtin
Давно хочу написать про обработку документальных структурированных данных в NoSQL. Я затрагивал эту тему в англоязычной заметке Future of NoSQL in Modern Data Stack [1], но проблема, гораздо глубже, она связана со спецификой данных. Классические наиболее распространенные подходы к обработке/очистке данных сейчас - это, или SQL запросы, или датафреймы вроде того же pandas, или инструменты вроде OpenRefine и Trifacta. Они все оперируют простыми плоскими таблицами и умеют по этим таблицам проводить относительно простые операции: переименовать колонку, разделить её, создать новую на основе имеющейся, изменить значение и тд. В SQL это делается относительно просто, с учётом ограничений языка, конечно. В OpenRefine, Trifacta - это внутренние индексы для табличных данных и встроенные функции или внешний код. А для pandas и подхода через датафреймы - это код Python (или похожий в других языках). Для данных с вложенными документами вроде тех что сериализуются в JSON или хранятся в MongoDB так не получится. При переносе из MongoDB в pandas вложенные объекты автоматически не нормализуются. А если их нормализовать, то потом назад в СУБД не перенести так просто. Будут потери, или в данных, или в возможности их обработки. И так со всем остальным, OpenRefine и аналоги также такой тип данных не поддерживают, только "уплощают" их в таблицы, но обратно могут отдать уже только плоскую таблицу. Как работать с JSON подобными структурами? Например, используя языки запросов у NoSQL баз данных предварительно загрузив данные в саму СУБД. А тут у нас начинают возникать уже ограничения другого рода. Ключевая NoSQL СУБД MongoDB не поддерживает большую часть операций по модификации данных иначе как запуском операций по перебору значений запроса итератором forEach. Самый банальный пример - это преобразование значений в полях в нижний или верхний регистр. То что в SQL решается простейшей командой UPDATE MyTable SET MyColumn = UPPER(MyColumn) для MongoDB требует команды вроде db.MyTable.find([find_criteria]).forEach(function(doc) { db.MyTable.update( { _id: doc._id}, { $set : { 'MyColumn' : doc.MyColumn.toUpperCase() } }, { multi: true } ) }); Похоже со многими другими операциями по преобразованию данных которые просты в табличных структурах, особенно в SQL и крайне затруднены в MongoDB. При том что MongoDB наиболее популярная NoSQL СУБД. Можно ли такие операции проводить не в MongoDB, а, например, в другой NoSQL базе? Их поддерживает, например, ArangoDB. Там также есть циклы на выполнение операций, но они могут проводится внутри движка СУБД. Например, вот так. FOR u IN MyTable UPDATE u WITH { MyColumn: UPPER(MyColumn) } IN MyTable Будет ли это быстрее чем если эту операцию делать извне? Непонятно, требует проверки. Альтернативой использования СУБД является написание аналога pandas DataFrame для не-табличных документов. У Python есть библиотека glom [2] которая позволяет что-то подобное и может быть расширена, но имеет довольно серьёзные ограничения по объёмам данных и по скорости их обработки. В итоге, если честно, я до сих пор не вижу оптимальный бэкэнд для data wrangling для NoSQL. Лучший кандидат как СУБД - это ArangoDB, но без интенсивного тестирования это неточно. Наиболее эффективным способом обработки JSON/JSONlines всё ещё является программная обработка за пределами СУБД и инструментов ручного data wrangling вроде OpenRefine. Ссылки: [1] medium.com/@ibegti…03bc61e8 [2] https://glom.readthedocs.io #data #datatools #thoughts #nosql #dataengineering #datawrangling -
Ivan Begtin
«Торговля страхом»: как нас убедили, что всем нужна система распознавания лиц https://youtu.be/hxxVFdUPoN4?t=1 «Если ничего не нарушаешь, нечего и боятся» — так говорят безгрешные люди, которые никогда не переходили улицу на красный свет. Но какую цену нам всем придется заплатить за удобные технологии? Наши биометрические данные крадут, продают, обрабатывают, и все это делают без нашего согласия. Персональные данные используют в корыстных целях как мошенники, так и государство. Можно думать, что система распознавания лиц вас не коснется. Пока кто-нибудь не захочет добраться конкретно до вас или ваших близких. Многие политические вопросы — проблемы непроработанного прошлого. Система распознавания лиц — проблема нашего будущего, на которую мы незаслуженно не обращаем внимания. Разбираем сценарии киберпанка, который мы заслужили, в новом подкасте «После работы». Гости подкаста – Иван Бегтин, директор АНО «Инфокультура», эксперт в области открытых данных, и Саркис Дарбинян, киберадвокат, со-основатель «Роскомсвободы». -
Ivan Begtin
По поводу свежего постановления российского федерального Пр-ва [1] по поводу того что все госорганы и госструктуры должны использовать только домены в зонах .RU, .SU и .РФ я не могу не напомнить что пока жареный петух в жопу не клюнет, поп не перекрестится. В Инфокультуре (@infoculture) мы уже несколько лет ведем реестр всех госдоменов [2]. Может не самый полный, но полней его нет. Там почти все домены ФОИВов, части РОИВов, некоторых бюджетных учреждений - это 7711 записей, включая не работающие сайты, "потерянные" и разделегированные домены и так далее. Так вот только у нас в базе 16 доменов в зонах .COM, .NET, .ORG, .INFO. Реально их, конечно, больше потому что есть 150+ тысяч госучреждений. Я тут не могу в очередной раз не кинуть камень в адрес Минцифры РФ которые за все эти годы так и не сподобились инвентаризацию госдоменов провести. Мы то свой реестр ведём для цифровой архивации содержания сайтов, а им теперь надо инвентаризировать для мониторинга. Или так, очередное постановление фед. Пр-ва для галочки, а исполнять планов не было?;) P.S. Не могу не добавить, кстати, что внимательно перечитав бюджетных учреждений там не обнаруживаю. Только органы власти и только для электронной почты. Что только снижает качество этого проекта постановления Ссылки: [1] www.rbc.ru/technol…8f0bedc1 [2] https://github.com/infoculture/govdomains #opendata 
-
Ivan Begtin
Подборка ссылок про данные, технологии и не только: - PySearch [1] поисковик по документации библиотек Python поддерживающий запросы на естественном языке. Пока скорее простые запросы вроде "take a tensor and adds a dimension" [2], но автор обещает и более глубокое применение NLP алгоритмов. - The Difficult Life of the Data Lead [3] тяжела и неказиста жизнь простого дата лида, руководителя дата команды. О чем автор и пишет, с картинками о том сколько времени надо проводить в коммуникациях, а не в технической работе. Полезно для тех кто думаете о своей карьере в этом направлении - Want a DS project? There's health insurance data out there [4] в США на поляну дата-сайентистов привалило радости, вышел закон требующих от медицинских организаций и мед. страховщиков публиковать цены в больницах в машиночитаемых форматах. Автор пишет о том где эти данные взять и что с ними можно делать. Это реально 100TB+ хорошо структурированных данных! - What is Data Engineering? Part 1. [5] обзор инженерии данных в блоге Pragmatic Programmer. Что называется, найди себя, хороший текст для описания этой роли и возможности себя с ней идентифицировать. - How does column encoding work? [6] в блоге dbt как работает кодирование данных в колоночных структурах вроде файлов Parquet и некоторых СУБД. Текст в предверии их конференции Coalesce и запуска dbt semantic layer [7] по работе с метриками. Ссылки: [1] https://www.pysearch.com [2] https://www.pysearch.com/search?q=take+a+tensor+and+adds+a+dimension&l=pytorch [3] mikkeldengsoe.substack.com/p/the-d…ata-lead [4] counting.substack.com/p/want-…nsurance [5] newsletter.pragmaticengineer.com/p/what-…g-part-1 [6] roundup.getdbt.com/p/how-d…ing-work [7] https://www.getdbt.com/blog/dbt-semantic-layer/ #readings #data -
Ivan Begtin
Я достаточно давно не публиковал данные над которыми работаем мы сами, а не просто выложенные где-то ещё. Поэтому пора уже разместить такой набор данных - это данные по социально ориентированным НКО в репозитории datacrafter-sonko [1] Это одновременно пример работы datacrafter'а [2] с кодом выгрузки данных в datacrafter.yml и сам набор данных в виде слепков первичных данных выкачанных с портала Минэка РФ data.economy.gov.ru и уже в обработанном виде в виде файла sonko_fin.bson.gz в котором данные Минэка обогащены частью данных с портала openngo.ru. Той частью что относится к классификации НКО. Несколько лет назад мы в openngo.ru разметили все НКОшки по 320 классификационным категориям среди которых есть православные НКО, госНКО, НКО относящиеся к структурам ДОСААФ и ещё много каких. Все это время не доходили и не доходят руки загрузить это на сайт openngo.ru в основном потому что общественного заказчика на некоммерческую аналитику мы так и не нашли. Поэтому эти классификационные признаки я сейчас перенес на эту малую базу СОНКО из 45+ тысяч организаций. Там получилось 213 категорий по которым размечены приtмрно 2/3 всех организаций. Так что если хотите поработать с данными в формате MongoDB, про социально ориентированные НКО и проанализировать их, то в репозитории код, вот тут финальные дампы [3] в которые добавлены статус в ЕГРЮЛ, статус в Минюсте, классификационные группы (orglists) к которым относится организация. Особенность по сравнению с первичными данными в том что в первичных данных по факту не реестр организаций, а реестр поддержки, а в этом наборе данных сведения о поддержке вложены в реестр организаций который на его основе сформирован и дообогащены данными о которых я пишу выше. Вопросы лучше писать в issues репозитория или по контактам указанным в репозитории, предварительно представившись кто Вы и что делаете. Я чуть позже также выложу некоторые метрики и аналитику. Ссылки: [1] https://github.com/datacoon/datacrafter-sonko [2] https://github.com/apicrafter/datacrafter [3] github.com/datacoo…/openngo #ngo #datasets #govngo #opendata -
Ivan Begtin
Если вам кажется что только в Вашей стране, где бы Вы ни были, всё делают через одно место и это не голова, то это не так. Например, Chaos Computer Club (CCC), старейшая хакерская команда в Германии, пишут о том что германская компания Gematik отвечающая за информатизацию здравоохранения плохо понимают в информационной безопасности того что они делают [1]. Текст на немецком языке, но легко переводится и смысл его в том что по номеру медицинской страховки сотрудник аптеки может получить о человеке всю информацию о его рецептах, без дополнительной авторизации и подтверждения самого человека. Учитывая что в Германии идёт цифровизация здравоохранения с переходом на электронные рецепты - то это становится актуально. Я бы ещё обратил внимание на модель угроз которую они описывают. Сотрудник аптеки может продать таблоидам номера страховок знаменитостей и те могут узнать из рецептов от чего знаменитости лечатся. Это не единственный "косяк" от Gematik, но достаточно яркий. А если вернуться к российским реалиям, то для авторизации на российском портале ЕМИАС [2] достаточно номера карточки медицинского страхования и даты рождения. После этого доступны данные о записях к врачам, рецептам и направлениям (хорошо хоть не самой медкарты). Это означает что любой врач в системе ОМС имеющий доступ к Вашему анамнезу может увидеть всю эту информацию на сайте ЕМИАС и Вы никогда об этом не узнаете. Но, всё интереснее. В медицинских полисах последние 6 цифр - это и есть дата рождения. Если у кого-то есть номер вашего мед полиса и даже если этот кто-то не знает даты Вашего рождения он/она может получить доступ к этому же личному кабинету. Страны разные, проблемы похожие. UPD: Речь, в первую очередь, про московский портал ЕМИАС. Как организовано в других регионах надо разбираться отдельно. Ссылки: [1] www.ccc.de/updates…ngelhaft [2] https://emias.info/ #security #privacy #germany #russia -
Ivan Begtin
В рубрике интересных наборов данных новость о том что DBLP, открытая база научных публикаций о компьютерных науках, интегрировали их данные с другой открытой научной базой OpenAlex и пишут об этом [1]. Для тех кто не знает, OpenAlex - это открытый продукт базы данных ссылок на научные публикации созданный НКО OutResearch на базе Microsoft Academic Knowledge Graph, большого набор данных опубликованного компанией Microsoft для помощи в развитии инструментов анализа библиографических данных. DBLP - это проект университета Триера существующий с 1993 года и ведущий крупнейшую в мире систематизированную базу научных публикаций в области компьютерных наук. Интеграция даёт возможность увидеть категории/концепты к которым относится данная публикация, а ранее уже DBLP интегрировали с базами Semantic Scholar, Crossref и OpenCitations. Пока это всё происходит на уровне веб-интерфейсов, но, ничто не мешает использовать открытые данные DBLP [2] что автоматизации анализа в нужных областях. Лично мне в DBLP всегда не хватало возможности подписаться на новые статьи по конкретной теме, исследователю, исследовательскому центру, ключевым словам, но это то что можно делать в других сервисах вроде Semantic Scholar. Я читаю на регулярной основе ключевые научные работы по цифровой архивации, открытым данным и "пониманию данных" (семантическим типам данных, идентификации шаблонов и тд.). Удобные инструменты для поиска таких публикаций очень помогают. Ссылки։ [1] blog.dblp.org/2022/08…-in-dblp [2] https://dblp.uni-trier.de/xml/ #opendata #research #openaccess #datasets -
Реклама
-
Ivan Begtin
Сбербанк социально ориентированная НКО? Я тут много ругался в адрес Минцифры что они в реестр ИТ компаний навключали всяких и они вроде как даже этот реестр начали чистить. Но, конечно, есть примеры и похуже. В плане управления качеством данных есть органы власти для которых делать плохо или неправильно - это норма. 2 года назад я писал колонку в РБК [1] о том что Минэкономразвития отвратительно ведёт реестр социально ориентированных организаций. Они даже валидацию реквизитов ИНН/ОГРН не проводили. Прошло 2 года, валидацию они поправили, новое постановление Пр-ва N 1290 выпустили и, стало ли лучше ? Короткий ответ - нет. Качество данных - это не только качество формы, но и содержания. В реестре социально ориентированных НКО всего 45+ тысяч организаций и там есть не только Сбербанк, но и: - 288 НКО учрежденных федеральными органами власти и госорганизациями (госНКО) - 336 НКО учрежденных региональными органами власти (госНКО) - 314 НКО учрежденных муниципальными органами власти (почти госНКО, с некоторой натяжкой) - 34 муниципальных учреждения - Московское областное отделение КПРФ (а как же остальные отделения, не социально ориентированы?) - 3 региональных министерства и 3 региональных бюджетных учреждения. Мне есть что про это всё сказать, но скорее я напишу. Последний месяц работаю над книжкой по госНКО. Поднял свои старые записки и хочу привести текст к эпистолярному жанру. К сожалению, многие источники данных уже исчезли из открытого доступа, но и оставшихся достаточно для интересного рассказа. А за Сбербанк, лично мне, конечно, очень тревожно. То ИТ компания, то СОНКО, неужели всё так плохо? Ссылки: [1] www.rbc.ru/newspap…dce77585 [2] https://data.economy.gov.ru/analytics/sonko #registry #data #dataquality #ngo 
-
Ivan Begtin
К вопросу о том как исчезает официальный контент государственных инициатив приведу в пример сайт открытого пр-ва open.gov.ru [1]. Сайт перестали обновлять с 2018 года, после смены состава фед. правительства. Какое-то недолгое время он был онлайн, а с января 2021 года у него "протух" сертификат который ещё и был сделан с поддержкой только TLS 1.0 [2] поэтому сейчас рядовому пользователю его не открыть. При этом он остался в проиндексированным в Гугле [3], а с помощью консольных и программных инструментов его можно сохранить и получить конкретную страницу, но это, видимо, тоже пока что временно. Я напомню что государственные сайты, да и вообще сайты в Рунете, не подвергаются обязательной архивации как это происходит в других странах. Нет требований, стандартов, правил, процедур и обязанности к созданию архивов, например, уже закрытых проектов или ликвидируемых организаций. Их цифровой контент и другие цифровые артефакты их деятельности исчезают быстро и безвозвратно. Это не самый яркий пример, были и похуже, но для меня он важен тем что много моей общественной работы было связано с открытостью гос-ва. Ссылки: [1] https://open.gov.ru [2] www.ssllabs.com/ssltest…yze.html [3] www.google.com/search…h #digitalpreservation #openness #opengov #archives -
Ivan Begtin
В рубрике интересных стартапов Mem.ai [1], система для личной и персональной самоорганизации. Главное отличие от других подобных продуктов - это декларируемое подключение ИИ Mem X [2] через автоматическое понимание написанного текста и подсветку ресурсов, тем и участников. Хорошо для автоматического написания контекста, структуризации заметок о встречах, задач для команды и тд. Существуют с 2019 года, подняли инвестиций на $5.6M [3]. Один из тех продуктов которому, мне лично, не хватает опенсорс альтернатив. Потому что хранить личные заметки в облаке не то чтобы совсем плохо, но чревато тем что потом можно всё потерять. Ссылки: [1] https://get.mem.ai [2] https://get.mem.ai/mem-x [3] www.crunchbase.com/organiz…nancials #ai #startups #notes