Иван Бегтин

Вчера пришло очень много вопросов, писем и комментариев.

Некоторые повторяются так что я отвечу на часть из них тут и объясню как работает проект.

1. Ключевая особенность ГосСети от любых каталогов веб-сайтов. Мы вначале создаём карточку госструктуры к которой сайт относится и лишь потом добавляем сайт. И ни один из сайтов не добавляется без такой привязки. В свою очередь органы власти имеют привязку к региону, ветви власти, виду структуры и так далее.

2. Данные в Госсеть вносятся двумя способами – автоматически и вручную. Например, автоматически вносились территориальные подразделения ФАС, Казначейства, управления ГИБДД и многие другие. В то же время, например, данные о сайтах проектов органов власти, ФЦП, сайтов закупок и большая часть региональных сайтов вносятся вручную.

3. Конечно, в системе есть ошибки. Связаны они и с тем что информация на сайтах органов власти не всегда является достоверной или же просто с ошибками. А также с тем что информацию о сайтах вносится автоматически. Поэтому, например, в некоторых случаях названия сайтов могут выглядеть странно. Но лишь по той причине что в некоторых случаях название приходится извлекать из тэга TITLE с главной страницы сайта, а там оно может быть, скажем так, разным.

4. Информация о CMS, Счетчиках, хостингах, геолокации, данных валидации по W3C собирается полностью автоматически.  Собственно какое-то время назад я писал у себя в блоге что результатом всех моих исследований Рунета является сервис аналогичный BuiltWith.com с той лишь разницей что он непубличен, а работает в режиме веб-сервиса. Собственно ГосСеть – это его первая публичная апробация.

5. ГосСеть – это долгосрочный проект и, как я уже писал ранее, это фундамент на основе которого могут быть построены и другие проекты и сервисы нацеленные на общественное благо. Те из Вас кто знают про проекты по открытым данным от New York Times и британской Guardian поймут о чём речь. Конечно, тема открытых данных в России пока ещё вызревает, но тема открытости государства уже горячая

6. В этом проекте как и проекте ГосЛюди.Ру я выступаю в качестве создателя и руководителя, при этом оба проекта делаются в пользу Полит.Ру и благодаря их финансовой и медийной поддержке.  Собственно что это означает. То что у меня что у редакции Полит.Ру есть чёткое взаимное понимание что сейчас у нас в стране есть серьёзный дефицит технологических проектов по открытости государства и нацеленных на общественное благо.

7. Проект с самого начала нацелен на партнёрство со всеми заинтересованными сторонами. И если у Вас есть конкретные предложения, например, публикации своих рейтингов, исследований, лучших практик, получения данных, предоставления данных и так далее – пишите на ibegtin (собака) gmail.com .

И немного статистики.

На 08.06.2010 в Госсети есть:

• 2453 госучреждения
• 30 видов госучреждений
• 1808 веб-сайтов
• 11 видов веб-сайтов
• 94 региона
• 19 нормативно-правовых документов
• 195 - видов признаков выявляемых с госсайтов: CMS, хостинг и т.д.
• 19973 – выявленных признаков на госсайтах

В Arstechnica появилась хорошая статья про SPDY^eng – протокол ускорения загрузки веб-страниц который предлагают иccледователи из Google.

SPDY – это протокол расширяющий и дополняющий HTTP таким образом чтобы убрать из него все неоднозначности, вроде того что статус в ответе описан иначе чем остальные поля и сжатие запросов и ответов и так далее.  Подробнее можно прочитать здесь – http://dev.chromium.org/spdy

При том что действительно, тема интересная важная и так далее, а Google при его массе и скорости может эту идею даже протолкнуть, на самом деле всё несколько сложнее. Собственно в статье в Arstecnica это изложено:

1. Сейчас SPDY работает только поверх сессий SSL что во-первых ограничивает кеширование данных, а во вторых не повлияет на то что большая часть контента в публичной части сети доступно не по SSL, и в третьих использование SSL априори создаёт дополнительную нагрузку на ресурсы клиента и сервера что также ограничивает применимость.

2. Протокол SCTP который там уже упоминается всё ещё в весьма зачаточном состоянии, примерно как IPv6, но IPv6 всё таки активно продвигается на страхе что адреса IPv4 скоро закончатся, а вот для SCTP такой мотивации нет, а изменений потребуется не меньше. В то же время без SCTP эффект от SPDY поверх TCP будет невелик.

3. По хорошему новый протокол бы надо обсуждать через IETF и прежде чем его активно продвигать, понять востребован ли будет он на рынке, да и вообще оценить нет ли там чего-либо неучтенного.

На мой взгляд подход должен быть иным – не подмена протокола, а организаций кеширования, prefetching и реорганизация контента под блочное кеширование.

А то есть менять надо не транспортный протокол который затронет операционные системы, сетевое оборудование, IDS системы, фаерволы, антивирусы и прочая, прочая.

Вместо этого можно поступить так:

1. Поисковики могут создавать свои CDN’ы и начать заключать договора с крупнейшими хостингами чтобы те предлагали их CDN своим клиентам по умолчанию и на бесплатной основе, а также заманивать владельцев сайтов в эти CDN за счет ускорения отклика от сайта что позволит и повысить удобство посетителям сайтов, так и позволит поисковикам собирать информацию быстрее. А где-то и в реальном времени.

2.  Из SPDY взять те идеи которые не слишком меняют текущий HTTP протокол, например, сжатие заголовков HTTP, запрет на дублирование заголовков и так далее, а также добавить веб-сайтам способность идентифицировать что протокол поддерживается и предоставлять доступ к нему по определённому урлу.

3. Предложить механизмы, программы, продукты и так далее кеширования отдельных участков веб страниц и интегрировать эту информацию на уровне HTTP протокола. То есть создать возможность при запросе веб-страницы или любого иного документа с комплексным содержимым возвращать не один ETag код, а несколько хэшей/идентификаторов блоков, но не более 20 блоков. Далее с помощью расширения к HTTP запрашивать о том не изменились ли отдельные или все блоки и в результате получать не всю страницу или подтверждения что она не менялась, а статус частично изменено и данные только изменившихся блоков склейка которых происходит уже на клиенте.

Это в принципе не так уж сложно сделать, а эффект будет куда больше, поскольку это позволит локализовать статические куски контента при обновлении страниц, а, при некотором развитии этого подхода, распространять кеширование с одной страницы на их группы.

Например, если блок футера на страницах сайта является статическим, то он может быть включён в перечень таких глобально кешируемых участков и применятся также как применяются Cookie к определённому пути.

Да, это немного усложнит и увеличит HTTP запросы от клиента, но в любом случае себя оправдает, а при наличии веса Google можно было бы протолкнуть с куда большей вероятностью.

Только что вернулись с iCamp Russia 2009 – впечатлений и общения было очень много, постараюсь рассказать о самом интересном.

В первый день в Нижнем Новгороде меня более всего впечатлили 3 доклада:

• Анатолий Левенчук  (ailev) рассказывал про килопроекты и системную инженерию (system engineering) – тема очень интересная и актуальная. Жаль что у нас в стране проектов примеры которых он приводит очень и очень мало. Если вообще есть в последние годы
• Дмитрий Песков (sartac) говорил про Метавер и образование которое вкорне отличается от принятых ныне подходов к обучению. По классификации ЛЕСа на iCamp – это чистой воды «эльфийская» тема, нацеленная на социальное переустройство, а не на прибыль и тем более эта тема интересна. Очень надеюсь что она приобретёт своё развитие.
• Гаррет Джонсон из МТС буквально зажигал на сцене рассказывая про мобильные устройства. То о чем он говорил запоминалось с трудом, но драйву и движухи в его выступлении было очень много.

Далее 4 дня на теплоходе – небольшие секции, выступления и доклады на уже куда меньшую аудиторию.

Лично я успел рассказать 4 секции:

• Государственный интернет
• Автоматическая геоклассификация веб-сайтов
• OpenGovData.ru: приглашение к проекту
• Государственные закупки. Стоит ли участвовать?

А также рассказывал про ряд социальных проектов которые интересны мне и, как оказалось, и многим участникам. Об этих проектах я ещё расскажу подробнее чуть позже.

Тема госзакупок заинтересовала очень многих – однако лично я отметил что немногие на самом деле знают как устроено наше государство изнутри. Реально не хватает книг – «Госуправление за 24 часа» и «Государство для чайников» где всё было бы описано просто и доходчиво.

В ближайшее время постараюсь выложить свои презентации в сети и они появятся в блоге.

Какие выступления понравились более всего:

• «Ответственный пациент» Бориса Зингермана. Понятно и очень доходчиво про электронную историю болезни и то как гражданин/пациент может сам управлять своей информацией.
• Несколько выступлений Олега Кудрявцева про привлечение инвестиций и то как нужно презентовать свои проекты инвесторов. Много реальных примеров и описание логики и стиля мышления инвесторов. При том что в основном речь шла об инвесторах стратегических, а не венчурных, было интересно.

Что также хочу отметить – так выступления про облачные вычисления Андрея Артищева из Оверсан Скалакси. Тема интересная, видно что у создателей есть понимание того что они хотят сделать, но лично мне интересно в какую форму они облекут услуги и какие будут цены по сравнению с тем же Amazon AWS. В любом случае – пусть растет сто цветов и чем больше провайдеров облачного хостинга, тем больше конкуренция, качество услуг и так далее.

Как резюме – большое спасибо организаторам и участникам, ибо формат оказался очень удачным и результативным.

Чтобы понять разницу между дизайном и информационной архитектурой – мало объяснений нужны и примеры.

Недавно у меня перед глазами такой пример образовался – обновился официальный сайт закупок Воронежской области, http://zakaz.gfu.vrn.ru

Точнее вместо старого сайта появился новый.

Причём к новому сайту в плане дизайна у меня серьёзных претензий нет – доводилось видеть как хуже так и лучше. А по сравнению с федеральным – так просто конфетка. 

Но не дизайн определяет то как же информация становится доступной пользователям.  

Например:

1. На сайте начисто отсутствует RSS как для отслеживания закупок так и просто для новостей – хотя сложного тут ничего нет. 

2. В реестрах организаций нет поиска по инн, названию и так далее

3. У организаций нет пермалинков и нет возможности просматривать закупки по определённому заказчику. Зачем это нужно? Да хотя бы для того чтобы департаменты области, ГУПы и МУПы могли указывать на своих сайтах не просто ссылку на сайт закупок области, а ссылку на свою карточку на сайте где можно просмотреть их заказы

4. Почему-то поиск электронных аукционов отсутствует, возможно он скрыт за формой регистрации на аукцион, но это противоречит закону – публичные данные должны быть общедоступны.

5. Интерфейс проведения электронных аукционов сделан на Flash Flex. При том что Flex – это, конечно, модно тем не менее 600 килобайтный рантайм это не так мало. Если скрипты для AJAX’а можно прооптимизироать использовав сжатие – то тут сжатия не получится и вообще

6. Нет инструкций по тому какие браузеры можно использовать. Например, автоподгрузка списков в формочки для AJAX в Chrome у меня не заработали и ещё вопрос нужны ли они когда, например, список организаций будет весьма велик – тут не автоподгрузка нужна, а всплывающая поиска.

—

Все эти частные замечания можно разбить на следующие критерии анализа:

1. Целостность данных – отсутствие пермалинков. 

2. Качество представления данных – полнота форм поиска и удобсто навигации.

3. Отсутствие описаний технических требований к клиентскому ПО.

Как резюме, несмотря на сравнительно неплохой внешний вид сайта – информационная архитектура у него хромает.

Как можно увидеть на скриншоте SEC (US Securities and Exchange Comission) официально начало предоставлять RSS ленты по отдельным организациям что позволяет отслеживать документы публичных организаций обязанных отчитываться в SEC, практически сразу же.

Это к вопросу о том как небольшие технические изменения быстро меняют уровень доступности информации.

Базы данных

• CouchDb – бесплатная документо-ориентированная система управления данными с открытым исходным кодом и входящая в состав проектов Apache Foundation
• Project Voldemort – совсем недавно появившаяся система ориентированная на горозонтальную расширяемость
• Mongo – система очень похожая на CouchDb, но приближающаяся к хранению объектов
• Drizzle – движок на базе MySQL 6.0 и с сохранением возможности хранения реляционных данных
• MemcacheDB – движок на принципах key/value (ключ/значение) на базе Memcached.  Подкупает простотой реализации и тем что его используют в digg.com

Статьи

• Is relations databases doomed? – ReadWriteWeb - отличная обзорная статья по технологиям key/value баз данных

Я обычно пишу мало про практическое программирование потому как не так часто им давно уже занимаюсь,  но некоторые трюки и подходы могут быть полезны особенно тем кто программирует на Python и Django.

Например, в публичном репозитарии Поискуна теперь доступен Django sitemap generator скрипт по генерации файлов sitemap включая индексы sitemap’ов для большого числа элементов до 500 000 и более. В скрипте задаётся информация о моделях, правилах формирования ссылок и размере «нарезки» числа ссылок в одном сайтмапе – остальное он генерит автоматически. 

Собственно хотя и в Django есть собстенный генератор Sitemap’ов, для моделей для которых постоянно добавляются новые объекты и общее число их превосходит 10 000, встроенных механизм sitemap’ов неудобен, а в крупных проектах число экспортируемых ссылок может доходить до миллионов.

В том что касается онтологии веб и задач классификации – я несколько раз касался этой темы ранее в публикации «Эффективное геокодирование данных» и метапосте с полным перечнем моих заметок и рассуждений.

Я чуть подробнее остановлюсь на том что же являлось основной моих рассуждений и общем подходе к классификации который далёк от алгоритмических способов.

Для начала зададимся вопросом о том что же такое веб сайт. Это домен, домен + содержимое, домен + содержимое + хостинг? Трактовок может быть множество. В моём представлении веб сайт это домен – как точка входа и совокупность программно-технических средств по предоставлению информации посетителям. Но более всего веб сайт является формой представления объектов материального мира в мире цифровом. А ещё более точнее, он является одной из форм представления и самозначащей сложной (составной) сущностью одновременно. 

Говоря условно мы можем разделить практически все веб сайты на две условные категории – связанные один-к-одному с объектами внешнего, физического мира и ресурсами находящимися полностью в онлайне.  Например, сайты компаний, туристических агенств, городов, офлайновых магазинов, курортов, путеводителей, выставок – все они один в один являются онлайновыми представительствами данных объектов в сети. 

А вот сайты поисковых систем, тематических порталов, онлайнового радио, социальных сетей (по большей части), онлайновых газет и журналов (отчасти) и ещё ряда других – являются исключительно онлайновыми ресурсами. 

Эта, первоначальная, буквально бинарная классификация всех ресурсов на две категории позволяет в дальнейшем перейти к ответу на вопросы о том как же определить привязку веб-сайта к географическим координатам.

В прошлой заметке я упоминал следующие 4 типа привязок веб сайта к гео данным.

• Местонахождение (вопрос “Где?”). Определяет физическое местонахождение веб ресурса.
• Владение (вопрос “Где владелец?”). Определяет физическое местонахождение организации или физ.лица владельца ресурса.
• Аудитория (вопрос “Для кого?”). Определяет местонахождение потребителей информации с данного веб сайта, его целевую аудиторию.
• Тематика (вопрос “О чём?”). Определяет геопривязки тематики ресурса.
• Continue reading «Онтология веб’а. Тематическая, географическая и иная классификация веб сайтов»

В Yahoo! опубликовали спецификацию на YQL – Yahoo! Query Language – язык запросов для получения данных из информационных массивов Yahoo! Причём доступ к данным производится через специальный вебсервис, а результаты можно получить в XML или JSON. Нехватает толькок Thrift./

При том что сама по себе идея очень интересная, она так и просится в различные системы раскрытия информации и предоставления онлайного программного доступа к массивам данных.

В последнее время всё активнее обсуждают тему можно ли регулировать / модерировать Рунет или нет и что для этого нужно.

Внесу и мои 5 копеек. Проблема контроля и регулирования Рунета той же природы что и проблема модерирования крупных социальных сетей вроде Одноклассники, Вконтракте, Facebook и так далее. Эта проблема в необходимости в огромном и постоянно растущем штате людей которые бы вычитывали новые и уже опубликованные материалы, просматривали бы подозрительные сайты.

Решение этой проблемы есть и будет в создании публичного реестра сайтов кандидатов под цензуру и социальной сети по его наполнению с трёхуровневой  логикой принятия решений.

На первом – люди собирают и отмечают ресурсы и материалы как экстремисткие или недопустимые.

На втором – группа экспертов подтверждает или отвергает народную оценку, фиксируя и беря на себя принятие решение голосованием по модели прямого большинства.

На третьем – модератор/администратор принимает решение о включение ресурса или материала в как кандидата на принятие мер в соответствии с законодательством.

Особенность всего вышеописанного в том что если Интернет-цензура будет неизбежной, то она должна быть:

a. Публичной.

б. Прозрачной.

в. Начиная с 2-го уровня в виде экспертной оценки – неанонимной.
В эффективность всех остальных моделей я, признаться, неверю.