Июль 2009 - Posts

Презентации с iCamp 2009: OpenGovData.ru как первый шаг к data.gov.ru
30 июля 09 09:31

Продолжаю выкладывать презентации с iCamp Russia 2009. на сей раз очередная презентация всё в том же скучном однотонном стиле, но на сей раз на тему того зачем и как создаётся OpenGovData.ru .

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

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

Originally published at Иван Бегтин. You can comment here or there.

Говорят что Рамблер внес Профессионалы.Ру в RBL
30 июля 09 07:52

Собственно ссылка http://friendfeed.com/welf/ce16b70d

Ежели так то Рамблеру – всяческий респект, уважуха ибо “Профессионалы” достали своим спамом капитально.

Originally published at Иван Бегтин. You can comment here or there.

Postedfrom Иван Бегтин | 1 Comments    
Filed under:
Презентации с iCamp 2009: Государственный интернет
29 июля 09 11:05

Ещё одна презентация с iCamp Russia 2009 в том же шаблоне что и предыдущая для большего занудства.

По сути в этой презентации я объединял другую свою презентацию по анализу 8-ФЗ с данными по госсайтам в Рунете – получилось то что можете пронаблюдать.

Originally published at Иван Бегтин. You can comment here or there.

Презентация с iCamp 2009: Автоматическая геоклассификация сайтов
29 июля 09 10:54

Буду публиковать тематическими группами презентации с iCamp Russia 2009. Поскольку темы разные, то отдельными постами.

Originally published at Иван Бегтин. You can comment here or there.

iCamp Russia 2009: послевкусие
29 июля 09 10:23

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

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

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

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

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

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

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

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

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

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

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

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

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

Originally published at Иван Бегтин. You can comment here or there.

Postedfrom Иван Бегтин | 0 Comments    
Filed under: , ,
Техническое. Почему Скиур иногда подтормаживает
22 июля 09 03:27

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

Текущая же проблема оказалась не столь очевидной, но не менее актуальной. К великому моему сожалению и удивлению Python не умеет сериализовывать скомпилированные регулярные выражения. Вернее он метит такие объекты как unmashalled и, в итоге, несмотря на наличие кода который подгружал базу регулярных выражений из кэша, на самом деле оказывалось что для каждой сессии, при подгрузке базы выражений из кеша, происходила полная их перекомпиляция, а это до нескольких секунд в зависимости от общей нагрузки на сервер.

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

В то же время есть варианты:

- либо компилировать выражения в C или Python код и подключить как уже готовые модули

- либо разрабатывать специальный сериализатор для регулярных выражений для Python ибо готовых нет

- либо выносить всю логику распознавания в отдельный сервер/сервис и обрабатывать все страницы в несколько потоков где выражения предварительно подгружены (самый простой способ)

- либо использовать для разбора веб-страниц не Python, а язык умеющий регулярные выражения сериализовывать

- либо отказаться от регулярных выражений и использовать иные правила анализа текстов.

Часть решений сугубо технические, часть алгоритмические. Какой подход проще уже понятно, непонятно какой лучше.

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

Originally published at Иван Бегтин. You can comment here or there.

Postedfrom Иван Бегтин | 0 Comments    
Про Microsoft и GPL
22 июля 09 12:37

Говорят Черный Властелин сильно уменьшился в

росте, а ноги его обросли густой шерстью

Оказывается Microsoft засабмитили 20 000 строк в ядро Linux код под GPL2 – http://vgabriel.livejournal.com/39139.html

Не то чтобы я сильно удивлён, но новость, ИМХО, заслуживает внимание.

Originally published at Иван Бегтин. You can comment here or there.

Postedfrom Иван Бегтин | 0 Comments    
Filed under: ,
Ссылки на 17.07.2009. Интересные проекты + ярмарка идей
18 июля 09 09:28
Это будет эдакий совмещённый пост – интересного в сети и нескольких последних идей.
Ссылки
  • ShoeBoxed – небольшой стартап с хитрым ноу-хау. Вы отправляете им в конверте свои счета и визитки, а они с помощью специальных сканеров и алгоритмов все это оцифровывают, распознают и предоставляют Вам через веб интерфейс. Задумка более чем интересная, я как раз не так давно задумывался об автоматизации распознавания кассовых чеков
  • URLClassifier – сервис тематической классификации веб страниц. Явно использует словари и классификация у него двухуровневая, но! сама идея правильная и весьма полезная. Предоставляют API
  • Feedity – ещё один сервис по преобразованию HTML в RSS, на сей раз полуавтомат. Анализирует страницу и предлагает варианты. Скиур (моё творение) мне нравится больше, но “пусть растут 100 цветов”, пригодятся все.
  • ColourLovers – огромная база цветов, паттернов и палитр. Проектов таких много, но эти дают ещё и API.

Идеи

  • Если в поездах метро между стеклами вагонов поместить полупрозрачные экраны на которые можно было бы во время движения поездов  транслировать рекламу, то рекламодатели получили бы аудиторию в несколько миллионов человек ежемесячно.
  • Классификация по ключевым словам в названиях, моделях телефонов и их стоимости помноженное на накопленные статистические данные по демографии может позволить, с некоторой вероятностью, определять средний возраст людей присутствующих на заданной территории используя BlueTooth. Зачем? Например, рекламный таргетинг
  • Чтобы обеспечить контроль хоть как-то близкий к тотальному, то далеко ходить не надо – достаточно МВД потребовать от всех охранных агенств и вневедомственной охраны ведения электронных журналов учета посетителей. Так чтобы номера паспортов и ФИО вносились не в журнал, а в базы данных синхронизировались с центральной. Разумеется этого никогда не будет.
  • Карты покрытия сотовыми операторами “наоборот”. На них показывается где в городе (или местности) есть места где Вам гарантированно не смогут дозвониться. Для тех кто увлекается кратковременным дауншифтингом сервис будет незаменимым.

Originally published at Иван Бегтин. You can comment here or there.

Развивая тему “латинизма”. Взглянем на другой реестр
17 июля 09 07:27

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

К вопросу, отчего же у меня столь много ехидства и “недоумения” от от действий ФАСа которые напоминают истребление всего живого Ворлоном в войне с Тенями (да, да, вспомним Вавилон 5), да по той простой причине что ничто человеческое не чуждо никому включая любимою мною антимонопольную службу. В самом деле, а всё ли можно измерить только латиницей в текстах?

Для примера, взглянем на реестр недобросовестных поставщиков, который как раз именно ФАС курирует (и вводят туда информацию не заказчики, а их сотрудники!) и посмотрим на следующие записи:

Во всех перечисленных случаях в наименованиях организаций вместо “ООО” русскими буквами написано “OOO” английскими буквами.

А также:

Немного примеров, да, но ведь и реестр невелик всего то 2347 записей из которых 6 с вкраплениями (видимо опечатками) латиницы что составляет 0.2% от общего числа что врядли больше чем опечаток на официальном сайте закупок.

И, к вопросу, о том для чего существует этот реестр. Его главная задача – оградить заказчиков от поставщиков нарушивших условия выполнения контрактов, он потому и называется реестром недобросовестных поставщиков.  Собственно заказчики имеют там возможность проверить не находится ли там поставщик и вопрос в том всегда ли они смогут это сделать гарантированно?

А ведь по поводу латиницы в госзакупках ФАСу ещё надо будет дела в арбитражных судах выигрывать которые ещё не факт что станут на его сторону.

Вот и для меня вопрос как они поступят:

1. Без шума исправят эти опечатки?

2. Признают ошибки несущественными?

3. Признают ошибки и поправят?

4. Или просто проигнорируют?

Вот такие  дела.

Originally published at Иван Бегтин. You can comment here or there.

Почта, СОРМ и нетотальный контроль
17 июля 09 01:33

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

И, кстати, последняя новость про приказ Минсвязи и введение комнат просмотра корреспонденции спецслужбами на почте лично для меня лишь ещё одно подтверждение что до тотального контроля всё ещё очень далеко.

Например, в России всего 42 000 объектов почтовой связи, при этом, хотя и нет цифр по реальному количеству отправлений проходящих суммарно и через отделения по отдельности, но не думаю что удасться обойтись меньшим числом сотрудников спецслужб чем сотрудников самого почтампа.

Итого трудно поверить что можно обеспечить тотальный контроль, больше похоже на контроль выборочный, но тогда закономерный вопрос – заключается в том что какой же в этом резон учитывая развитие Интернета?

В принципе, популярность обычной бумажной почты сейчас только сокращается и её не избежать только при взаимодействии с юр. лицами и приёме бандеролей и посылок.

Но меня больше удивляет другое – ведь то же самое можно было сделать гораздо хитрее. Достаточно было бы выделить Почте России денег на предоставление услуги “почта-по-email” со сканированием текста письма и отправке адресату по электронной почте, а спецслужбы имели бы доступ к базам отсканированных документов.

В общем, моё мнение, что странная это какая-то затея, поразительно бесхитростная.

Originally published at Иван Бегтин. You can comment here or there.

В продолжение АнтиSEO
15 июля 09 11:08

Хотя и может показаться обратное, но я не забыл про эту тему, хотя и она сейчас мне уже менее интересна чем ранее.

Сейчас моя книга “подвисла” посередине – готово 30 страниц, плюс несколько десятков разрозненных заметок и исследований которые надо сводить вместе.

Особенность в том что я не описываю алгоритмы, их нет вообще – я описываю со всеми подробностями правила и классификационные признаки которые по совокупности уже можно классифицировать с помощью SVM, Decision Trees или прочих алгоритмов.

Пока этих признаков 50, вернее не признаков, а выявляющих их правил которые могут быть представлены как одним так и большим числом признаков.

По каждому правилу приводятся статистика и примеры, в некоторые случаях подробные, в некоторых случаях как “допущение”.

В итоге получается не серебрянная пуля, а систематизация правил антиSEO анализа. Разумеется, не исключено что весьма спорная, учитывая что большинство реально работающих антиSEO алгоритмов совершенно непубличны.

Как бы то ни было, книга будет, в том или ином виде – когда точно я ещё отпишу, пока же с желающими можно будет обсудить эту тему на iCamp Russia.

Плюс появилось интересное чтение  в виде описания алгоритма Яндекса - http://helpcontext.ru/?p=507 по выявлению платных ссылок.

Originally published at Иван Бегтин. You can comment here or there.

Postedfrom Иван Бегтин | 0 Comments    
Filed under:
Скиур: некоторые цифры и развитие
15 июля 09 10:40

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

Цифры

Пока же приведу некоторые цифры:

- всего из активно используемых веб страниц имеется 2441 страница в RSS каталоге

- из этих страниц извлечено 123 640 новостных записей (регулярной очистки устаревших) и около 1 миллиона записей если устаревшие записи не вычищать.

- посещаемость у сайта весьма скромная, около 300 уникальных посетителей в сутки что, прямо скажем немного, но для некоммерческого сервиса вполне нормально

- а вот посещаемость RSS лент достигает 2500 уникальных посетителей в сутки.

Текущее состояние

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

Развитие

Проект я изначально задумывал как некоммерческим и он таким продолжает оставаться. Признаться я пока не окончательно решил в какую сторону его развивать – улучшения инструментариев для работы с RSS или сделать частью движка распознавания типовых форм данных (чем он и является внутри).  Пока же буду рад обсудить эту тему на iCamp Russia со всеми желающими. Хотя этот доклад и отсутствует в программе – презентация у меня будет с собой.

Originally published at Иван Бегтин. You can comment here or there.

План-график ФАИТа работ по Электронной России за 2009 год
14 июля 09 10:16

В Минсвязи, а вернее, ФАИТ опубликовали у себя на сайте перечень проектов которые будут сделаны в 2009 году в рамках Электронной России – документ можно скачать по ссылке – http://minkomsvjaz.ru/.cmsc/upload/images/200907/1011367eB.doc

По моему опыту работать с таблицами гораздо удобнее в Excel чем с документами Word, так что выкладываю переработанный документ плана-графика, его можно скачать по ссылке - procurement_plan_fait_2009

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

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

  • 30.2. Вычислительные машины и прочее оборудование для обработки данных; услуги, связанные с их установкой и сборкой блоков вычислительных машин
  • 72.4. Услуги, связанные с базами данных, деятельностью в сети Интернет
  • 72.6. Прочие услуги, связанные с использованием вычислительной техники
  • 73.1. Услуги, связанные с исследованиями и экспериментальными разработками в области естественных и технических наук

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

Для начала о том как читать подобные документы и конкретно коды классификации.

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

Код 72.4 означает что разрабатываемая система будет присутствовать в Интернете или взаимодействовать посредством Интернет каналов. Обычно это означает что помимо того что программный продукт должен быть разработан, он также должен быть развернут и быть доступен по сети.

Код 72.6 это очень общий классификационный код под который подпадают работы (услуги) по разработке ТЗ, разработке ПО, развертыванию тестовых и рабочих копий продуктов на оборудовании и так далее.

Код 73.1 указывает на то что работы подразумевают создание документов концепций и проведение исследовательских работ которые в будущем (как правило в следующем бюджетном году) могут быть разработаны и внедрены.

Как итог – когда Вы читаете описание того что такой-то сайт будет разработан за такие-то деньги – не спешите предполагать что все эти деньги уйдут на разработку ПО. Особенность подавляющего числа госпроектов в том что помимо разработки присутствуют поставки оборудования на весьма немалые суммы от 30 до 80% от всех работ. Это, в общем-то, несложно понять когда появляется конкурсная или аукционная документация где требования к оборудованию и работам детально расписаны.

И, кстати, вопрос – стоит ли публиковать такие небольшие датасеты в рамках OpenGovData.ru ?

Originally published at Иван Бегтин. You can comment here or there.

Минэкономразвития про некорректный ввод закупок
14 июля 09 12:13

Сегодня пресс-служба Минэкономразвития выпустила пресс-релиз

На случай если они его поправят к тому времени то прочитать его можно на сайте ОПОРА России и на главной странице zakupki.gov.ru.

С целью противодействия размещению на официальном сайте www.zakupki.gov.ru извещений, содержащих признаки некорректного ввода наименования закупки (лота), затрудняющего поиск информации, Министерством экономического развития Российской Федерации подготовлен пакет обновлений программного обеспечения, предусматривающий создание на официальном сайте реестра заказов («Извещения с признаками некорректного вода наименования»), в который будут включаться все извещения, в наименовании которых буквы кириллического алфавита используются одновременно с символами и/или буквами других алфавитов, цифрами, а также содержатся признаки  заменены на буквы других алфавитов или цифры. Сведения об указанных процедурах размещения заказа будут направляться Минэкономразвития России в ФАС России для проведения внеплановых проверок. Указанный реестр заказов будет вестись на главной странице официального сайта с 15 июля 2009 года.

Обратите внимание на слово вода после некорректного. Я вот гадаю что оно может означать – намек что мол бывают не только некорректный ввод, или стремление начать наполнять этот реестр начиная с этой новости?

Я же лишь отмечу что со стороны ФАС была публичная реакция, а вот со стороны МинЭкономРазвития никто публично выступить не решился – ограничились обезличенным пресс-релизом.

Относительно латиницы и подмены букв напомню что это не единственный способ сокрытия информации и об этом я недавно писал.

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

И, кстати, очень интересно, а постановление правительства или хотя бы приказ по Минэкономразвитию для ведения этого реестра существует? И, может быть, мы его даже увидим?

Originally published at Иван Бегтин. You can comment here or there.

Относительно Google OS
13 июля 09 01:50

К вопросу зачем Гуглу своя операционная система.

Лично я считаю что как продукт, особенно как платный продукт, она ему совершенно ненужна. Больше того, я думаю что Google свою ОС продавать не будут, а ОС нужна будет только и исключительно чтобы потеснить MS, но не на десктопе, а на нетбуках и прочих подключенных к сети устройствах.

Собственно, ключевое отличие будет в том что Google могут воспользоваться принципиально иной моделью – не совместимостью, а перенос ПО в онлайн.

Например, по аналогии с тем как Microsoft поддерживали и развивали рынок настольного ПО  и Shareware , точно также Гуглу будет достаточно запустить партнерскую программу для онлайн сервисов и значительно интенсифицировать создание ПО в рамках Google App Engine.

Получится у них или нет – время покажет.

Originally published at Иван Бегтин. You can comment here or there.

Postedfrom Иван Бегтин | 5 Comments    
Filed under:
Блог В.Д. Миловидова (руководителя ФСФР)
13 июля 09 01:30

По наводке с gov-gov.ru нашёл блог Миловидова – http://www.investor.ru/user_content/blog/32476

причём там пока ещё одна только запись, но, множество комментариев и ответов к ним в первой же записи.

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

Originally published at Иван Бегтин. You can comment here or there.

В продолжение темы сокрытие госзакупок. Не в латинице дело
12 июля 09 12:01

Поскольку после того как президент побеседовал с Шуваловым (http://www.1tv.ru/news/economic/147174) о закупках и гиперактивизации ФАС (http://fas.gov.ru/stateorder/documents/a_25239.shtml) может показаться что что-либо изменилось, то поспешу развеять это заблуждение. В том что касается доступности и открытости информации, использование латиницы лишь верхушка айсберга и смешение букв лишь наиболее наглядный пример того как информация может быть скрыта, но пример не единственный.

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

Откроем сайт “zakupki.gov.ru“, введём в строку поиска по заказчику Федеральное государственное образовательное учреждение высшего профессионального образования “Кубанский государственный аграрный университет”

Список закупок будет состоять из названий:

и так далее, там большой список.

А если открыть любое из описаний закупки, то можно убедиться что везде в названии лота присутствует “согласно документации”.

Разумеется, в документации присутствует описание того что же закупает заказчик, но документация не индексируется, ни средствами сайта, ни внешними поисковыми системами.

Впрочем, на самом деле, текущая версия zakupki.gov.ru вообще не ищет по названиям лотов. Это легко проверить введя те же слова “согласно документации” в поисковое поле и увидев нулевой результат, а это значит что заказчики для того чтобы ограничить поставщиков по своим заказам и избежать придирок ФАС достаточно будет просто указывать наименование закупки так как я привел выше, а в названии лотов писать правильный текст того что же закупается.

Поставщики всё равно найти закупки не смогут, во всяком случае средствами оф. сайта.

По закупкам что я привел как пример можно, также, увидеть ещё один “нюанс”.  Заказчики практически вообще никак не указывают номенклатуру товаров кодами структурированной номенклатуры. Среди сотен просмотренных мною извещений лично мне так и не удалось найти хоть одного что код номенклатуры не был бы указан как “A”, а наименование товара как “Новая позиция”.  Впрочем даже если бы номенклатуру вбивали, то госзаказчики не несут ответственности за неправильное указание её кодов, а сам оф. сайт рубрикации по ней не предоставляет.

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

Вот поэтому я могу повторить то же что недавнно говорил в интервью на РенТВ (http://www.ren-tv.com/news/latest/5824-2009-07-01-07-53-00).

На 90% в текущей ситуации с сокрытием информации виновато бездействие МинЭкономРазвития и лишь на 10% виноваты заказчики.

Originally published at Иван Бегтин. You can comment here or there.

Про электронные аукционы с пессимизмом
08 июля 09 11:48

Я всё думал как прокомментировать недавнее распоряжение правительства по 3-м федеральным ЭТП.

Поскольку из СМИ сейчас идёт поток оптимизма в связи с их появлением, то я добавлю свою ложку дёгтя для общего счастья.

Далее краткими тезисами:

1. Сами по себе электронные аукционы на борьюу с коррупцией и коррупцию никак не повлияют без мер по обеспечению доступности информации поставщикам и последующего контроля результатов работ.

2. Коррупция при госзаказе в принципе слабо связана с процедурами проведения. И непосредственно связана  с предварительным планированием заказов, соответствием стоимости работ и поставок рыночным ценам и последующему контролю результатов.

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

4. 3 площадки – это очень немного на всю Россию. Я не знаю зачем представители ФАС утверждают что 3 площадки контролировать проще чем 20, но знаю что при соответствующей нормативной базе можно обеспечить контроль прохождения любой закупки хоть при сотнях площадок.

5. Если насчёт торговой площадки  Москвы у меня нет сомнения что у них есть опыт проведения большого числа электронных аукционов, например, все ЭТП в Москве работают уже давно и со связкой с ЕАИСТ и сайтом tender.mos.ru, то, например, Сбербанк раньше электронными торгами не занимался. Причём тут вопросы не только организационные, но и технические, ибо при нормальном числе электронных аукционов (до 1000 в сутки) нагрузка на системы будет весьма нехилой.

6. Для участия во всех торгах на всех площадках есть ограничение что нужно будет использовать: пакет CryptoPro, ОС Windows XP/Vista/W7 и Internet Explorer от версии 6 поскольку везде используется ЭЦП для подписи и проверки подписи документов.  При этом, обычно, несмотря на эти требования в гостевом то режиме должна быть возможность просматривать торги.

Но только на ЭТП Сбербанка, по загадочной причине, всех пользователей Chrome, Firefox (до 30% Рунета) сразу отравляют к чертовой бабушке…, а вернее к Internet Explorer’у даже только при заходе на сайт. Не могу понять – это баг или шутка такая?

Originally published at Иван Бегтин. You can comment here or there.

Сжатие документов. Итоговая сравнительная таблица
07 июля 09 05:35

В результате всех экспериментов со сжатием файлов получилась следующая таблица результатов.

Объём Процентов
Без сжатия 70745088 100
OpenDocument используя OpenOffice 20511664 28,99
OpenDocument после OpenOffice с дожатием 10231845 14,46
b2xtranslator* 11266825 15,93
b2xtranslator с дожатием 10937971 15,46
MS Word 2007 20145429 28,48
MS Word 2007 с дожатием 14249582 20,14
* В случае b2xtranslator оценки могуть быть неточными так как иногда он портит файлы – около 1% от общего числа.
Напомню что использовался массив из 566 документов в формате .doc (MS Word 2000/XP/2003) общим объёмом в 70 мегабайт собранный из реальной жизни – это извещения, конкурсная документация и протоколы закупок. Документы преобразовывались в форматы OpenDocument и OOXML с помощью различных инструментов и далее “дожимались” без потери содержимого, качества и совместимости.
По результатам можно сказать что лучшие результаты у дожимания документов OpenDocument которые выдаёт OpenOffice, у того же OpenOffice и худший результат если файлы не дожимать.
b2xtranslator сжимает документы предельно эффективно и дожатие документов после его работы почти не помогает, но его использование это хождение по минному полю ибо часть документов он преобразует с ошибками, а на части просто виснет.
MS Word 2007 по умолчанию сжимает документы не лучше чем OpenOffice и дожатие документов не позволяет приблизится к дожатию документов OpenOffice’ом.
Лично для меня эти эксперименты рассеяли миф что OOXML куда лучше подходит для архивации документов с точки зрения уменьшения их объёма.

Originally published at Иван Бегтин. You can comment here or there.

OpenGovData.ru: Первые открытые данные
07 июля 09 05:02

На OpenGovData.ru появился раздел с открытыми данными – пока ещё там только 3 опубликованных массива, но будет больше. Сейчас дорабатывался механизм импорта данных из различных источников и полноценное пополнение данных “на поток” будет уже после его завершения.

При том что все данные публикуются в 3-х форматах: CSV, TSV и openDataXML.

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

Для машиночитаемости и обнаружаемости все имеющиеся массивы перечисляются в файле opendataindex.xml

Конечно, сильно тормозит процесс необходимость извлечения данных. Причём не однократная, а автоматизированная. Впрочем и эта задача решается.

Originally published at Иван Бегтин. You can comment here or there.

OpenGovData.ru: Первые открытые данные
07 июля 09 05:02

На OpenGovData.ru появился раздел с открытыми данными – пока ещё там только 3 опубликованных массива, но будет больше. Сейчас дорабатывался механизм импорта данных из различных источников и полноценное пополнение данных “на поток” будет уже после его завершения.

При том что все данные публикуются в 3-х форматах: CSV, TSV и openDataXML.

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

Для машиночитаемости и обнаружаемости все имеющиеся массивы перечисляются в файле opendataindex.xml

Конечно, сильно тормозит процесс необходимость извлечения данных. Причём не однократная, а автоматизированная. Впрочем и эта задача решается.

Originally published at Иван Бегтин. You can comment here or there.

Практическое сжатие документов OpenDocument в цифрах. Продолжение
06 июля 09 08:53

Продолжая тему сжатия документов используя форматы OOXML и OpenDocument на сей раз подробнее остановлюсь на OpenDocument и затрону тему преобразования существующих форматов MS Office в формат OpenDocument и сравнение с преобразованием аналогичной выборки в OOXML с помощью b2xtranslator.

Для оценки сжимания документов использовалась выборка из 566 файлов в формате MS Word 2000/XP/2003 (.doc) из архивов Енота Поискуна суммарным объёмом в 70 745 088 байт, а то есть около 70 мегабайт. Эта выборка отличается от выборки из прошлого исследования, так как при анализе результатов преобразования в OOXML с помощью b2xtranslator оказалось что много файлов Excel преобразовались с ошибками (как я и упоминал b2xtraslator всё ещё очень сырой продукт) и для эталонной выборки была взята выборка из документов MS Word.  Впрочем и здесь полагаться на результаты преобразования с помощью b2xtranslator на 100%  нельзя так как он иногда портит файлы (а иногда виснет, но для этого эксперимента файлы где он вис не учитывались).

Для OpenDocument сжатие проводилось в два шага:

1. Преобразование документа в OpenDocument с помощью OpenOffice

2. Дожатие документа различными способами – пережатие контейнера, чистка мусора, сжатие картинок и так далее.

Аналогично для OOXML были два шага:

1. Преобразование документа в OOXML (WordML) с помощью b2xtranslator

2. Дожатие документа пережатием контейнера и сжатием картинок.

Особенность эксперимента в том что картинок то было совсем немного – практически небыло вовсе, отсюда главное что показывал эксперимент – это сжатие и дожатие текстовых структурированных документов.

Первый шаг

При преобразовании документов из .doc в OpenDocument их итоговый объём без пережатия составил 20 511 664 байт или 28,99% от начального объёма.

При преобразовании документов из .doc в OOXML их итоговый объём без пережатия составил 11 266 825 байт или 15,93% от начального объёма

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

Дожатие OpenDocument

Если в первой части эксперимента оказалось что OOXML создаваемые b2xtranslator меньше чем документы создаваемые при конвертации посредством OpenOffice, то во второй части мы посмотрим насколько они поддаются дожатию.

Для документов OpenDocument к каждому из них применялись следующие способы уменьшения их размера:

1.  Удаление thumbnail и прочего “мусора’ оставляемого OpenOffice’ом

2. Пережатие изображений (если они есть)

3. Пережатие ZIP-контейнера

После всех этих операций итоговый объём документов составил 10 231 845 мегабайт или 14,46% от начального объёма.

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

Дожатие OOXML

Для документов OOXML сосздаваемых b2xtranslator применялись те же оптимизационные способы что и в прошлом эксперименте:

1.  Пережатие изображений (если они есть)

2. Пережатие ZIP-контейнера

Необходимость в чистке мусора отсутствовала поскольку b2xtranslator выдаёт максимально “чистый файл”, без ненужной для отображения и работы информации.

Итоговый объём документов после дожатия составил 10 937 971 мегабайт или 15,46% от начального объёма

Резюме

По результатам экспериментов можно сказать что OpenDocument ничуть не хуже чем OOXML пригоден для архивного хранения документов. Разница в  1% в пользу OpenDocument по результатам сравнения дожатых документов не столь существенна чтобы говорить о серьёзном преимуществе, но говорить о том что документы OOXML получаются значительно меньше чем OpenDocument будет некорректно.

В то же время, несмотря на положительные результаты сравнения форматов, основной проблемой использования OpenDocument можно назвать OpenOffice. В частности, значительная разница между недожатыми документами OpenDocument и OOXML состоит в том что OpenOffice всегда закладывает в файлы OpenDocument изображение thumbnail и довольно плохо сжимает ZIP-контейнер. В итоге, преобразование документов для архивного хранения в OpenDocument нужно осуществлять без использования OpenOffice, но для этого всё ещё нет подходящих инструментов или же дожимать  созданные в OpenOffice файлы до приемлимого объёма.

P.S. В последнии дни мой основной блог из-за смены хостинга и обновления до Wordpress 2.8 работал с перебоями, но зеркало на Livejournal должно работать всегда. Найти его можно тут – ivbeg.livejournal.com.


Originally published at Иван Бегтин. You can comment here or there.

Postedfrom Иван Бегтин | 0 Comments    
Преобразование и сжатие документов в цифрах в случае OpenXML и OpenDocument
01 июля 09 12:44

В продолжение темы сжатия документов используя новые форматы OOXML и OpenDocument перейду к конкретным цифрам, по возможности, нейтрально по отношению к любому из форматов.

Для начала приведу цифры по преобразованию документов в случае OpenXML – в одном из следующих постов попробую описать ту же процедуру для OpenDocument. Попробую, поскольку создание стенда для OpenDocument сложнее, но возможно.

Для начала как и что проверялось.

Проверялись 4 датасета документов из архива Енота Поискуна:

  • 318 документов OpenDocument (.odt) – 14 482 368 байт
  • 620 документов OOXML (.docx и .xlsx) – 24 451 860 байт
  • 419 документов MS Office 2000/XP/2003 (.doc, .xls) – 58 669 568 байт
  • 39 документов MS Powerpoint  2000/XP/2003 (.ppt) – 74 423 296 байт

Датасеты не подбирались специально, был просто общий архив документов, а далее документы разного типа были сгруппированы. Отдельно отмечу что архив документов не синтетический, а такой какими документы встречаются в “дикой природе”, в данном случае размещаются госзаказчиками на сайтах закупок.

Причем с датасетами проверялось следующее:

  • для документов OOXML и OpenDocument проверялась пригодность для “дожатия” документов. Техника которую я ранее описывал в заметке практическое сжатие электронных документов.
  • для документов MS Office проверялось их сжатие после преобразование в OpenXML с последующим “дожатием”.

Проверка “дожатия” документов

Дожатие документов проводилось по принципу пережатия ZIP контейнера улучшенным deflate алгоритмом (см. статью выше) и пережатием изображений в документах алгоритмами без потери качества.

Для датасета документов OpenDocument документы были дожаты до совокупного объёма в 12 364 803 байт или, иначе, до 85,37% от начального объёма.

Для датасета документов OOXML документы были дожаты до совокупного объёма в 17 113 886 байт или, иначе, до 70% от начального объёма.

Итого можно заметить что документы OOXML сжимаются лучше. Но это не единственное что их отличает, кроме того документы OOXML в среднем меньше чем документы OpenDocument.

Для датасета OpenDocument средний размер документа  равен: 14 482 368 / 318 = 45 562 байт до дожатия и 12 364 803 / 318 =38 883 байт после дожатия.

Для датасета OOXML средний размер документа дожатия равен: 24 451 860 / 620 = 39 438 байт до дожатия и 17 113 886 /620 = 27 603 байт после дожатия.

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

В чем особенность, например, формата OpenDocument и работы OpenOffice?

Если распаковать любой ODT документ и заглянуть в его внутренности то там можно обнаружить:

  • папку Thumbnails содержащую файл thumbnail.png размером от 900 байт до 10 000 байт, в среднем же около 5400 байт
  • папку Configurations2 содержащую ряд (обычно) пустых поддиректорий и конфигурацию OpenOffice
  • файл двоичный файл layout-cache размером от 18 до 881 байта (по тем данным что есть) или, в среднем, 121 байт
  • а также перечисление всех этих файлов в файле META-INF/manifest.xml

Обо всей этой информации можно сказать с уверенностью лишь одно – к содержанию документа она отношения не имеет. Это “полезный мусор” и некоторые удобства при работе в виде thumbnail’а, но не более.

Проверять вычистку ODT документов автоматически задача довольно трудоёмкая, поэтому произвольным образом была сделана проверка “дожатия” на примере одного документа размером в 30 836 байт в оригинальном виде и в 30 328 байт в “дожатом виде” (пережат контейнер и картинки). В итоге после удаления Thumbnails, Configurations2, layout-cache и чистки манифеста файла, и последующего сжатия в контейнер размер документа составил 18 007 байт, или 58% от оригинального файла. Что гораздо лучше чем просто сжатие документов OpenDocument и лучше даже чем сжатие OOXML. Итого, за счёт ряда ухищрений и доработки OpenOffice, в том что касается долгосрочного хранения докуменов и небольшого их объёма OpenDocument не уступит OOXML.

Сжатие докуметов MS Office преобразованием в OpenXML

Впрочем задача дожимать документы возникает сравнительно редко, чаще возникает вопрос выигрыша при переводе документов из устаревших форматов в новые. Но инструментов преобразования документов немного – фактически для перевода офисных документов в OpenDocument мало вариантов кроме как воспользоваться API OpenOffice, а для перевода документов в OOXML есть варианты в виде API MS Office и B2XTranslator (http://b2xtranslator.sourceforge.net/) – бесплатный движок на работающий на .NET и Mono.

В данном случае тестирование проводилось именно с помощью B2xtranslator которые более чем другие способы заточен под потоковое преобразование документов.

С его помощью два датасета – датасет документов MS Office (.doc, .xls) и датасет презентаций MS Powerpoint были преобразованы в формат OpenXML, а далее уже имеющимся у меня движком “дожаты” в части ZIP контейнера и изображений.

В итоге получились следующие результаты.

Преобразованием в OpenXML датасет документов MS Office (.doc, .xls) был уменьшен до 16,78% от начального объёма (от 58 669 568 байт до 9 848 436 байт), а то есть в 6 раз.

После дожатия документов их объём составил 9 401 414 байт или 16,02%. Можно обратить внимание что дожатие документов принесло всего около 0,76% выигрыша объёма и связано это с несколькими факторами:

  • файлы .doc и .xls из выборки почти не содержали изображений
  • b2xtranslator использует более эффективный Deflate алгоритм для создания ZIP файлов и дожатие помогает несильно.

Преобразованием в OpenXML датасет презентаций MS Powerpoint был уменьшен до 84% от начального объёма (от 74 423 296 байт до 62 634 326 байт), а то есть на 15%.

После дожатия документов их объём составил 55 137 124 байт или 74%.

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

При этом, сжатие презентаций может быть существенно улучшено при использовании дожатия с потерями, например, преобразованием векторной графики и внедренных OLE объектов картинок Adobe Photoshop и Corel Draw в растровые изображения.

Неохваченное и нюансы

1. Неохваченным осталось преобразование документов из форматов MS Office в OpenDocument, но для того чтобы его организовать на поток надо соответствующим образом собирать стенд с OpenOffice’ом. Если кто-нибудь хочет это проделать самостоятельно – могу передать все вышеперечисленные датасеты для экспериментов.

2. b2xtranslator всё ещё ОЧЕНЬ сырой продукт. Несмотря на то что разработчики в нём очень оперативно реагируют на каждый отправленный им баг (а я им отправил уже с 5 штук), тем не менее в некоторых случаях он производит нечитаемые OpenXML документы, а в некоторых просто виснет.

3. Преобразование документов, разумеется, фатально с точки зрения эталонности документов, наличия у них ЭЦП и так далее. Преобразованный документ по объёму существенно отличается от оригинала.

Зачем всё это нужно?

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

В моём случае вопрос упирается в то что документов накопилось уже несколько сотен тысяч и в общей совокупности это более 48 гигабайт.

С одной стороны это немного, но с другой стороны когда для хранения документов используется Amazon S3, это оказывается более чем актуально.

<td style="height: 12.75pt; width: 48pt;" width="64" height="17" align="right">
</td> <td style="height: 12.75pt; width: 48pt;" width="64" height="17" align="right"></td> <td style="height: 12.75pt; width: 48pt;" width="64" height="17" align="right"></td>

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

This Blog

Tags

Archives

Syndication