К вопросу о том что я писал ранее про проект Спутник и его закрытие [1] и об отсутствии "культуры провалов" в государственном ИТ (это, кстати, вместе с системой госзакупок и формирует ситуацию когда правоохранители прийти могут к каждому ответственному за государственные информационные системы, даже если это кристально "честный и порядочный человек" (c), они встречаются как и единороги, я верю в это (с).
В США GSA (U.S. General Service Administration) опубликовали руководство по снижению рисков при внедрении государственных ИТ проектов [2]. Начало там хорошее "Only 13% of large government IT projects succeed" из отчёта Standish Group "Haze" [3].
Вот лишь несколько рекомендаций оттуда, по стадии Планирование:
- Назначьте выделенных и уполномоченных владельцев продуктов чтобы возглавить усилия по разработке
- Вовлекайте конечных пользователей на ранней стадии и чаще в работу по разработке ПО
- Оценивайте риски в ситуациях сделать-или-купить, учитывайте все факторы при принятии решений
- Обеспечивайте открытость по умолчанию (открытость разработки кода, в первую очередь)
- Требуйте реализации инфраструктура-как-код и однокомандного развертывания и еже-спринтовую государственную верификацию функциональности
- Лидер должен устанавливать направления и усиливать команды
- Усилия по разработке должны быть четко определены для снижения риска и избежания перерасходов
- Ясный "путь до продукта" до заключения контракта
- Дайте командам доступ к инструментам взаимодействия которые им нужны для успеха
- Инвестируйте в технологии постепенно и управляйте бюджетом для управления рисками прототипирования
Всё это из Federal Field Guide [4]
И там же далее стоит обратить внимание и на остальные стадии. В целом материал там хорошо изложен и его даже если просто перевести на русский язык, то оно применимо и к госпроектам в России. Вернее могло бы быть применимо, если бы в последние годы у нас не было бы ровно противоположной тенденции - укрупнение ИТ проектов, сверхконцентрация усилия на мега-ФГИС и миллиардные расходы (и последующие посадки).
Ссылки:
[1] https://t.iss.one/begtin/2103
[2] https://derisking-guide.18f.gov/
[3] https://www.standishgroup.com/sample_research_files/Haze4.pdf
[4] https://derisking-guide.18f.gov/federal-field-guide/
#opensource #guides #it #failures
В США GSA (U.S. General Service Administration) опубликовали руководство по снижению рисков при внедрении государственных ИТ проектов [2]. Начало там хорошее "Only 13% of large government IT projects succeed" из отчёта Standish Group "Haze" [3].
Вот лишь несколько рекомендаций оттуда, по стадии Планирование:
- Назначьте выделенных и уполномоченных владельцев продуктов чтобы возглавить усилия по разработке
- Вовлекайте конечных пользователей на ранней стадии и чаще в работу по разработке ПО
- Оценивайте риски в ситуациях сделать-или-купить, учитывайте все факторы при принятии решений
- Обеспечивайте открытость по умолчанию (открытость разработки кода, в первую очередь)
- Требуйте реализации инфраструктура-как-код и однокомандного развертывания и еже-спринтовую государственную верификацию функциональности
- Лидер должен устанавливать направления и усиливать команды
- Усилия по разработке должны быть четко определены для снижения риска и избежания перерасходов
- Ясный "путь до продукта" до заключения контракта
- Дайте командам доступ к инструментам взаимодействия которые им нужны для успеха
- Инвестируйте в технологии постепенно и управляйте бюджетом для управления рисками прототипирования
Всё это из Federal Field Guide [4]
И там же далее стоит обратить внимание и на остальные стадии. В целом материал там хорошо изложен и его даже если просто перевести на русский язык, то оно применимо и к госпроектам в России. Вернее могло бы быть применимо, если бы в последние годы у нас не было бы ровно противоположной тенденции - укрупнение ИТ проектов, сверхконцентрация усилия на мега-ФГИС и миллиардные расходы (и последующие посадки).
Ссылки:
[1] https://t.iss.one/begtin/2103
[2] https://derisking-guide.18f.gov/
[3] https://www.standishgroup.com/sample_research_files/Haze4.pdf
[4] https://derisking-guide.18f.gov/federal-field-guide/
#opensource #guides #it #failures
Telegram
Ivan Begtin
Ростелеком окончательно закрыл проект национального (читай - государственного) поисковика "Спутник" [1], на который было потрачено около 2 миллиардов рублей [2]. Хорошо это или плохо что его закрыли - я судить не берусь, кто-то скажет что идея была абсурдная…
При любом историческом событии крайне важно сохранять архивы, как минимум для себя лично, как максимум для всего общества.
Поэтому, специально для тех кто понимает что необходимо всегда сохранять архивы происходящего и думают как это делать, я подготовил и отправил в рассылку Гайд по быстрой архивации цифрового контента [1] с охватом того как архивировать отдельные веб страницы, сайты, социальные сети.
Некоторые инструменты совсем простые, для некоторых нужны базовые навыки работы с командной строкой. Если Вы знаете какие-либо дополнительные инструменты или есть проблемы с архивацией контента который в гайде не представлен - пишите мне лично на почту [email protected] или в чат @begtinchat.
Ссылки:
[1] https://begtin.substack.com/p/24
#digitalpreservation #guides #webarchival #socialnetworks
Поэтому, специально для тех кто понимает что необходимо всегда сохранять архивы происходящего и думают как это делать, я подготовил и отправил в рассылку Гайд по быстрой архивации цифрового контента [1] с охватом того как архивировать отдельные веб страницы, сайты, социальные сети.
Некоторые инструменты совсем простые, для некоторых нужны базовые навыки работы с командной строкой. Если Вы знаете какие-либо дополнительные инструменты или есть проблемы с архивацией контента который в гайде не представлен - пишите мне лично на почту [email protected] или в чат @begtinchat.
Ссылки:
[1] https://begtin.substack.com/p/24
#digitalpreservation #guides #webarchival #socialnetworks
Ivan’s Begtin Newsletter on digital, open and preserved government
#24. Гайд по быстрой архивации цифровых материалов
Сейчас, когда происходят катастрофические события, идут военные действия, публикуется огромное число текстов, изображений и видео которые могут быть недостоверными и исчезнуть через несколько часов после публикации, как никогда актуальна архивация цифровых…
Forwarded from Национальный цифровой архив
Почему веб архивы неполны, охватывают не всё и даже самостоятельно сохранив сайт в нём можно не найти то что видно пользователю?
Большинство систем архивации материалов с сайтов основаны на принципах поисковых роботов, они обходят веб страницы, извлекают из HTML кода ссылки и далее переходят по ним, как правило, индексируя в первую очередь наиболее часто цитируемые страницы/ссылки.
Так работает для большинства сайтов, но, часто, разработчики сайтов сознательно или в силу технических особенностей делают сайты непригодными для такого индексирования. Например, ранее популярные технологии Adobe Flash и Microsoft Silverlight очень мешали таким поисковым роботам.
Главное же препятствие сейчас - это технологии динамической подгрузки контента Ajax. В качестве примера рассмотрим сайт Заповедник | Россия за пределами столиц (zapovednik.space). Это контентный сайт, состоящий из текстов, фотографий и изображений, относительно небольших по объёму.
Типовая ссылка на материал на сайте выглядит вот так
https://zapovednik.space/material/osobennosti-natsionalnoj-pandemii
Однако в теле веб страницы не найти её текста или ссылок на изображения. Это можно увидеть открыв ссылку
view-source:https://zapovednik.space/material/osobennosti-natsionalnoj-pandemii
и посмотрев на HTML код. Посмотрев на код других страниц можно убедиться что он везде одинаковый.
Чуть изучив код сайта можно выяснить что текст и изображения подгружаются через специальный Ajax запрос в виде JSON файла.
Для рассмотренного примера по такой ссылке
https://zapovednik.space/api/material?id=otdelitsja-ot-traditsij-i-podchinitsja-pravilam
Как архивировать подобные сайты? Есть два подхода
1. Написать специальный скрипт который вначале найдёт все ссылки на страницы /material/[идентификатор] и сохранит все JSON файлы, а далее на основе ссылок на картинки и ссылок в текстах соберет все связанные ресурсы. В этом случае будет потеряна вся интерфейсная часть сайта, но сохранится его контент. Придётся отдельно хранить результаты архивации интерфейса и данные+контент.
2. Использовать такие краулеры как Brozzler или Browsertrix использующие реальные браузеры и сохранять сайт не то как его видит поисковый паук, а то как он представлен пользователю. Они медленнее, но их результат более приближен к тому что ожидает увидеть пользователь.
Этот пример лишь один из многих поясняющих почему веб-архивация и архивация цифрового контента не может быть полностью автоматизирована в ситуации когда мы стремимся к полноте охвата содержания и не хотим чего-либо упустить.
#guides #digitalpreservation #webarchives #crawl
Большинство систем архивации материалов с сайтов основаны на принципах поисковых роботов, они обходят веб страницы, извлекают из HTML кода ссылки и далее переходят по ним, как правило, индексируя в первую очередь наиболее часто цитируемые страницы/ссылки.
Так работает для большинства сайтов, но, часто, разработчики сайтов сознательно или в силу технических особенностей делают сайты непригодными для такого индексирования. Например, ранее популярные технологии Adobe Flash и Microsoft Silverlight очень мешали таким поисковым роботам.
Главное же препятствие сейчас - это технологии динамической подгрузки контента Ajax. В качестве примера рассмотрим сайт Заповедник | Россия за пределами столиц (zapovednik.space). Это контентный сайт, состоящий из текстов, фотографий и изображений, относительно небольших по объёму.
Типовая ссылка на материал на сайте выглядит вот так
https://zapovednik.space/material/osobennosti-natsionalnoj-pandemii
Однако в теле веб страницы не найти её текста или ссылок на изображения. Это можно увидеть открыв ссылку
view-source:https://zapovednik.space/material/osobennosti-natsionalnoj-pandemii
и посмотрев на HTML код. Посмотрев на код других страниц можно убедиться что он везде одинаковый.
Чуть изучив код сайта можно выяснить что текст и изображения подгружаются через специальный Ajax запрос в виде JSON файла.
Для рассмотренного примера по такой ссылке
https://zapovednik.space/api/material?id=otdelitsja-ot-traditsij-i-podchinitsja-pravilam
Как архивировать подобные сайты? Есть два подхода
1. Написать специальный скрипт который вначале найдёт все ссылки на страницы /material/[идентификатор] и сохранит все JSON файлы, а далее на основе ссылок на картинки и ссылок в текстах соберет все связанные ресурсы. В этом случае будет потеряна вся интерфейсная часть сайта, но сохранится его контент. Придётся отдельно хранить результаты архивации интерфейса и данные+контент.
2. Использовать такие краулеры как Brozzler или Browsertrix использующие реальные браузеры и сохранять сайт не то как его видит поисковый паук, а то как он представлен пользователю. Они медленнее, но их результат более приближен к тому что ожидает увидеть пользователь.
Этот пример лишь один из многих поясняющих почему веб-архивация и архивация цифрового контента не может быть полностью автоматизирована в ситуации когда мы стремимся к полноте охвата содержания и не хотим чего-либо упустить.
#guides #digitalpreservation #webarchives #crawl
Заповедник
Путешествие по России за пределами столиц
Подборка регулярного чтения про данные, технологии и не только:
- A Eulogy for Dark Sky, a Data Visualization Masterpiece [1] о визуализации данных в погодном приложении The Dark Sky для iOS и там же про наглядные решения контекстуализации данных. Я бы добавил этот термин в словарь "констектуализация данных" - это когда данные у Вас есть, но Вы подаёте их в том виде в каком они наиболее информативны и наглядны именно в том контексте/приложении/среде в которой их смотрят. А это приложение погоды отличный пример
- The Beginner's Guide to Databases [2] для новичков желающих разобраться в базах данных отличное руководство, оно не покрывает очень много чего, но одновременно даёт все нужные вводные для старта работы
- Meet Alpaca: Stanford University’s Instruction-Following Language Model that Matches GPT-3.5 Performance [3] новый интересный продукт как альтернатива GPT-3.5 под названием Альпака, главные отличия в открытости и меньших требованиях к железу. Открытый код главное преимущество [4]
- Finding Undocumented APIs [5] автор пишет про мою любимую тему, обнаружение недокументированных API. Я несколько выступлений и лекций проводил за эти годы про поиск и нахождение недокументированных API и ещё немало трюков могу рассказать о том как API находить, помимо перехвата запросов браузера к серверу. Так вот два самых очевидных способа часто срабатывающих:
* 1) Поискать API поиском Гугла на сайте явным образом вроде "REST API site:roskachestvo.gov.ru" и результат может удивить
* 2) Выяснить на каком программном продукте работает сайт и проверить не сохранилось ли в нём API идущее по умолчанию, у многих продуктов такое есть. Пример: Архив оцифрованных материалов Национальной электронной детской библиотеки РФ arch.rgdb.ru работает на движке DSpace, а у DSpace по умолчанию API доступно по ссылке /rest, проверяем, ага, вот и оно https://arch.rgdb.ru/rest/
Я могу не то что презентацию, а целый курс прочитать только по этой теме. Тем не менее ту статью рекомендую, часто информацию о API приходится выковыривать из сессий браузера.
- Data wrangling essentials: comparisons in JavaScript, Python, SQL, R, and Excel [6] сравнение функций преобразований данных в Excel, Python, R, SQL и Javascript. Полезно для тех кто вынужден пользоваться 2-3 языками/синтаксисами. Python там, правда, это не совсем Python, а конкретно Pandas, но текст от этого ценности не теряет.
Ссылки:
[1] https://nightingaledvs.com/dark-sky-weather-data-viz/
[2] https://technically.substack.com/p/the-beginners-guide-to-databases
[3] https://pub.towardsai.net/meet-alpaca-stanford-universitys-instruction-following-language-model-that-matches-gpt-3-5-490a38114a7e
[4] https://github.com/tatsu-lab/stanford_alpaca
[5] https://inspectelement.org/apis.html
[6] https://observablehq.com/@observablehq/data-wrangling-translations
#opensource #readings #api #data #guides
- A Eulogy for Dark Sky, a Data Visualization Masterpiece [1] о визуализации данных в погодном приложении The Dark Sky для iOS и там же про наглядные решения контекстуализации данных. Я бы добавил этот термин в словарь "констектуализация данных" - это когда данные у Вас есть, но Вы подаёте их в том виде в каком они наиболее информативны и наглядны именно в том контексте/приложении/среде в которой их смотрят. А это приложение погоды отличный пример
- The Beginner's Guide to Databases [2] для новичков желающих разобраться в базах данных отличное руководство, оно не покрывает очень много чего, но одновременно даёт все нужные вводные для старта работы
- Meet Alpaca: Stanford University’s Instruction-Following Language Model that Matches GPT-3.5 Performance [3] новый интересный продукт как альтернатива GPT-3.5 под названием Альпака, главные отличия в открытости и меньших требованиях к железу. Открытый код главное преимущество [4]
- Finding Undocumented APIs [5] автор пишет про мою любимую тему, обнаружение недокументированных API. Я несколько выступлений и лекций проводил за эти годы про поиск и нахождение недокументированных API и ещё немало трюков могу рассказать о том как API находить, помимо перехвата запросов браузера к серверу. Так вот два самых очевидных способа часто срабатывающих:
* 1) Поискать API поиском Гугла на сайте явным образом вроде "REST API site:roskachestvo.gov.ru" и результат может удивить
* 2) Выяснить на каком программном продукте работает сайт и проверить не сохранилось ли в нём API идущее по умолчанию, у многих продуктов такое есть. Пример: Архив оцифрованных материалов Национальной электронной детской библиотеки РФ arch.rgdb.ru работает на движке DSpace, а у DSpace по умолчанию API доступно по ссылке /rest, проверяем, ага, вот и оно https://arch.rgdb.ru/rest/
Я могу не то что презентацию, а целый курс прочитать только по этой теме. Тем не менее ту статью рекомендую, часто информацию о API приходится выковыривать из сессий браузера.
- Data wrangling essentials: comparisons in JavaScript, Python, SQL, R, and Excel [6] сравнение функций преобразований данных в Excel, Python, R, SQL и Javascript. Полезно для тех кто вынужден пользоваться 2-3 языками/синтаксисами. Python там, правда, это не совсем Python, а конкретно Pandas, но текст от этого ценности не теряет.
Ссылки:
[1] https://nightingaledvs.com/dark-sky-weather-data-viz/
[2] https://technically.substack.com/p/the-beginners-guide-to-databases
[3] https://pub.towardsai.net/meet-alpaca-stanford-universitys-instruction-following-language-model-that-matches-gpt-3-5-490a38114a7e
[4] https://github.com/tatsu-lab/stanford_alpaca
[5] https://inspectelement.org/apis.html
[6] https://observablehq.com/@observablehq/data-wrangling-translations
#opensource #readings #api #data #guides
Nightingale
A Eulogy for Dark Sky, a Data Visualization Masterpiece
A deep look at how the Dark Sky weather app used simple but highly effective charts to report and contextualize the weather.