До поездки

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

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

Несколько позже я посмотрел документальный фильм о Новосибирске. Фильм произвёл на меня настолько сильное впечатление, что мне захотелось побывать во всех местах, о которых там рассказывалось: в кафе с видом на часовню-центр России, в оперном театре, в музее паровозов в Академгородке (строго говоря, в этом музее не только паровозы, но и электровозы, и пассажирские вагоны, и другая специальная техника - я бродил там часа три), на набережной Оби, над которой проходит метро-мост и всех других местах, о которых говорилось в этом фильме. Предлагаю его вашему вниманию. Длительность около 22-х минут.

По приезду

Погода в сибирской столице оказалась нетипично тёплая для этого времени года - в середине ноября было -4 с лёгким снежком. Прелесть! Первые холода начались только в середине января 2012-го -33. Холод в сухом климате Сибири переносится легче, чем на всегда влажном побережье Тихого океана, но минус 33 есть минус 33 - моську пощипывает и покалывает. :-)

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

Второе - энергия места. Особенно это чувствуется в центе у часовни. Похоже, что именно эта энергия притягивает сюда людей, хотя не факт, что все её чувствуют.

Третье - столичный статус. Это чувствуется по многим, казалось бы, мелочам, которые режут глаз приезжему. Чистенькое и аккуратненькое метро, вежливые продавцы в магазинах (даже кассиршы здороваются, что для меня было непривычно, а новосибирцы считают, что именно так и должно быть, не замечая в этом ничего необычного), широкие проспекты, домофоны с ключами-"таблетками" в подъездах жилых домов (работающие, между прочим), огороженные дворы многоэтажек со шлагбаумами, включающимися дистанционно, горячая и холодная вода круглый год и круглые сутки (я ведь ещё помню времена, когда и холодная-то вода была в Приморье по графику), внятные, хорошо поставленным голосом объявления в транспорте, универсальные магнитные карточки для проезда в метро, троллейбусе и трамвае и многое другое...

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

Работа

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

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

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

В итоге

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

Архитектура

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

Единая лента и фотоальбом

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

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

Да здравствуют веб-службы

Главное отличие этой работы от всех моих предыдущих является отказ от веб-ориентированной системы администрирования. То есть, от веб-интерфейса управления сайтом. Вся система управления сайтом реализована в виде веб-служб и внешних программ-клиентов. Что это даёт? Не считая более высокого уровня безопасности, такой подход к управлению даёт удобство привычного оконного интерфейса, скорость работы и полный отрыв от веб-технологий - веб-службы могут работать с любым программным обеспечением на любой платформе. Кроме этого, такая постановка вопроса даёт ощутимую разгрузку сервера путём переноса части операций на сторону клиента. Для управления сайтом я написал две клиентских программы: локальную для обычного компьютера на языке си с использованием библиотеки GTK+ и мобильную, для платформы Андроид, которая работает на моём смартфоне.

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

Полная смена всех платформ

Не смотря на то, что я уже давно ушел с Windows и всех привязанных к ней программ, этот сайт до сих пор работал на Windows, Active Server Pages и MS SQL Server. Но руки мои дошли и до него в итоге. Теперь все компоненты сайта, программной платформы веб-приложений, веб-сервера, СУБД и операционной системы - свободные. Это даёт непревзойденную гибкость, значительно более высокую надёжность, скорость работы и скромные требования к ресурсам сервера - он тоже не резиновый.

Микроблог

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

Полнотекстовый поиск

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

Система антиспама в комментариях

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

Большое количество RSS-лент

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

Мобильная версия сайта

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

Для истории

Ну и вид старого сайта, дизайн которого был любезно создан Борисом Хершбергом около шести лет тому назад:

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

Во-вторых, привязки к датам. Неплохо подходит к периодическим изданиям или новостям. Другими словами, к документам, где эти даты важны. Пример - прогноз погоды. Кому интересен прогноз погоды на вчера? Разве что специалистам в соответствующих областях науки, но никак не простым обывателям. Тоже имеет отражение в реальном мире, хотя и не такой важности. Поиск документов облегчает плохо, если только ищущий не знает заранее даты.

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

Применение

Оценим же нужность этих систем на примере блога.

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

Разделы не дают нужной гибкости, особенно для статей, которые затрагивают несколько тем. Эта система вынуждает выбрать только один раздел, что не всегда возможно. Считаю, что разделы для блога не нужны, даже одновременно с чем-то ещё.

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

Итоги

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

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

• Изменение архитектуры программного кода веб-приложения
• Оптимизация структуры базы данных
• Исключение программного кода как такового, где это возможно.

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

Отказ от динамического форматирования текста

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

Выделение афиши в отдельное поле

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

Одна страница — один запрос

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

Кеширование редко изменяемых данных

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

Отказ от сложных запросов

Очевидно, что для ускорения обработки запросов к базе данных необходимо отказаться от сложных запросов, например, от конструкций типа UNION и JOIN. Как это сделать? Например, список статей блога на этом сайте показывает так же и список меток для каждой статьи. А ведь в базе данных для этого задействованы три таблицы: одна для хранения меток, другая для хранения собственно статей и третья для связи предыдущих двух. Запрос, отображающий список статей со списком меток для каждой получается неприлично запутанным и ресурсоёмким для простого чтения списка. Как же этого избежать?

Кеширование сложных связей в базе данных

Для разрешения создавшейся ситуации мы добавляем в таблицу, хранящую статьи, поле, содержащее в себе массив из пользовательского типа, хранящего имя метки и её идентификатор. Таким образом, наш заумный запрос с несколькими JOIN-ами превращается в простой SELECT к одной таблице, хранящей непосредственно статьи. А заполнением этого поля пусть займутся триггеры, срабатывающие на все три типа операций изменения данных. Мы получаем простой запрос на чтение, экономящий ресурсы и более сложную обработку данных при администрировании сайта.

Перенос ресурсоёмких операций на сторону клиента

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

Отказ от динамических RSS-лент

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

Минимизация файлов стилей и отказ от SSI

Так же нужно сказать, что чем меньше количество файлов стилей на сайте, тем лучше. Не смотря на то, что они кешируются браузером, первая загрузка будет дольше да и обработка тоже. То же самое касается и включаемых на стороне сервера файлов SSI — эти действия совершенно лишние. Исполняемый файл должен быть предварительно скомпилированным и монолитным, что ускоряет его выполнение и исключает дополнительные считывания файлов на сервере. Зачем грузить сервер многократными лишними чтениями диска?

Итоги

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

Сначала я грешным делом подумал, что сам штурвал неисправен аппаратно. Это меня малость расстроило, поскольку покупалось на eBay и шло почтой несколько недель. Проверить было легко, подключив к другому симулятору на другом компьютере. Что и было сделано на мелкомягком симуляторе под виндовозом - мир не без добрых людей. На этом шаге я выяснил, что мой штурвал идеально настроен и работает без замечаний. Другими словами, проблема в моем компьютере.

Следующим шагом я проверил что выдает драйвер uhid (что, по-уму надо было сделать в первую очередь). Я подчеркиваю - драйвер uhid из системы FreeBSD, а не sysutils/uhidd из портов (его я тоже пробовал, но получил худший результат). Проверял я это так:

usbhidctl -f /dev/uhid0 -a -l

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

Далее, я сравнил эти показания с результатом утилиты js_demo, что идет в комплекте с симулятором и предназначена специально для тестирования джойстиков и других подобных девайсов (строго говоря, мой штурвал понимается симулятором как подвид джойстика). Утилита js_demo выдает все параметры в диапазоне от -1.0 до +1.0. Ровно так же видит все параметры и сам симулятор. То есть, если повернуть штурвал влево, соответствующий параметр станет равным -1.0, а если повернуть вправо, то значение данного параметра будет менять в большую сторону до тех пор, пока не достигнет значения +1.0 в крайне правом положении штурвала. Таким образом, любой параметр, который не попадает в пределы -1.0 - +1.0, обрабатывается неправильно. На этом этапе я, наконец, определил, что дело не в моей операционной системе и не в драйвере USB, а непосредственно в самом симуляторе, что значительно сузило круг поиска решения.

Следующим шагом я стал искать решение на англо- и русскоязычном форумах FlightGear. В результате нашел описание подобной проблемы (второй пост сверху) от пользователя с ником yurik_nsk. На тот момент это был уже не первый и даже не третий день поисков решения, поэтому у меня уже свербило, и я не стал писать на форум, а связался непосредственно с автором поста Юрием Никифоровым по джабберу. Я застал его в командировке где-то не сервере, но не смотря на это, он мне здорово помог в поиске решения, за что ему спасибо. Проблема оказалась в том, что моя система выдает значение поворота штурвала в диапазоне с двойной точностью (1024 вместо 512), а библиотека plib не может правильно обработать такую ситуацию.

Поскольку проблема сузилась до редактирования исходных кодов библиотеки x11-toolkits/plib, посредством которой FlightGear получает данные с джойстиков, следующим шагом я занялся подбором правильного значения методом научного тыка. В итоге правильными оказались параметры, которые выдает драйвер uhid посредством usbhidctl (что и логично).

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

• Сначала неплохо бы убедиться, что в файле /etc/make.conf есть директива FORCE_PKG_REGISTER=yes, иначе нам будет необходимо вводить эту директиву каждый раз при сборке.
• Копируем файл с исходными кодами библиотеки plib-1.8.5.tar.gz из /usr/ports/distfiles/ куда-нибудь в другое место, хотя бы в Desktop.
• Разворачиваем ее в одноименную директорию plib-1.8.5 (так по-умолчанию делает Nautilus через контекстное меню).
• Вносим необходимые исправления в файлы исходных кодов.
• Архивируем директорию с исправленными файлами обратно в архив с тем же именем (опять же, Nautilus делает всё правильно через контекстное меню).
• Переносим новый файл plib-1.8.5.tar.gz обратно в /usr/ports/disfiles/, перезаписывая при этом старый файл.
• Переходим в директорию библиотеки /usr/ports/x11-toolkits/plib и запускаем сборку командой make NO_CHECKSUM=yes install. Второй параметр имеет ключевое значение, потому как без него система определит по контрольной сумме, что файл не тот и загрузит из Сети новый, перезаписав при этом наши изменения. Параметр clean на данном шаге необязателен - временные файлы почистятся на следующем шаге.
• После нормального окончания сборки plib переходим в директорию симулятора /usr/ports/games/flightgear и собираем симулятор FlightGear обычным способом - make install clean. Пересборка симулятора необходима, потому что при сборке plib получается статическая библиотека libplibjs.a, которая (как и все статические библиотеки) жестко связывается с программой симулятора в момент её компиляции.
• После нормального завершения предыдущего шага мы имеем заново собранными с нашими исправлениями библиотеку и симулятор. Остается только переинициализировать девайс. Если модуль uhid вкомпилирован в ядро (как в ядре GENERIC) - ничего не поделаешь - придется ребутнуться. Если же модуль подгружен вручную или посредством /boot/loader.conf, то нужно сделать четыре шага: физически отключить девайс от USB, выгрузить модуль ядра посредством команды kldunload uhid, загрузить модуль обратно командой kldload uhid и подключить снова девайс в разъем USB.

После всего вышесказанного мой штурвал заработал как положено. Но! Поскольку я увеличил диапазоны параметров для штурвала, то задел и рукоятки квадранта, диапазон которых вдвое меньше. Еще полночи я пытался выправить эти параметры XML-конфигами, но не получалось никак. Видимо, всё же, это делается не так, решил я и снова полез в исходники. В итоге я внес исправления в исходники еще в одно место и все заработало как и было задумано.

Исправления в коде

Все исправления делаются в одном-единственном файле src/js/jsBSD.cxx. Первое исправление касается непосредственно самого штурвала. Нужно найти строчки:

max       [ i ] = 255.0f ;
center    [ i ] = 127.0f ;

У меня в plib версии 1.8.5 это строки с номерами 379 и 380 соответственно. Их надо заменить на:

max       [ i ] = 1023.0f ;
center    [ i ] = 512.0f ;

Далее, нужно найти строчку:

os->cache_axes[i] = (float)d;

У меня в неисправленном файле эта строка была под номером 490. Заменить её нужно на следующее условие:

if (i > 1)
{
    os->cache_axes[i] = (float) (d * 4);
}
else
{
    os->cache_axes[i] = (float) d;
}

Поскольку поворот и горизонтальное перемещение штурвала имеют номера 0 и 1 соответственно, то все элементы управления с номерами больше единицы должны иметь вдвое меньший диапазон. Что в данном месте кода выражается умножением на 4.

Оговорюсь, что всё вышесказанное справедливо для системы FreeBSD 8.1, симулятором FlightGear 2.0.0_3 и plib 1.8.5. Возможно, что с другими системами и версиями нужны будут другие множители, но суть изменений, надеюсь, ясна.

Таких фильмов сейчас уже не снимают. Романтическое приключение с красивыми боями без голливудской крови, грязи и пошлости. Платоническая любовь, в которой показали только один поцелуй (в современном голливудском фильме непременно случился бы скоропостижный секс под лирическую музыку где-нибудь по кустом), а герой без рисования перед публикой и лишних разговоров побеждает своих врагов и идёт дальше своей дорогой. Но не будем забывать, что это все таки французский фильм - не Голливуд, что придаёт ему какое-то особое очарование.

На мой взгляд, это лучший из шестнадцати (как оказалось) фильмов об этом необычном человеке. Интересно, что у Зорро был реальный прототип, даже не прототип, а реальный человек, история которого описала Исабель Альенде в своей книге Зорро. Рождение легенды. Его действительно звали Диего де ла Вега, и он действительно сражался в маске за угнетённых.

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

Окончательно добила меня биография самого Алена Делона. Почитав про его жизнь, посмотрев на его фотографии, начиная с юности, заканчивая современными (а ему уже 75 лет, однако), я как-то в очередной раз почувствовал быстротечность времени. Герой моей юности, который представал в своих фильмах молодым и активным, сейчас уже практически старик. Хотя и продолжает с успехом сниматься. Например, в сериале Фрэнк Рива.

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

• Монтирую виртуальную файловую систему procfs в точку монтирования /proc. В /etc/fstab это выглядит так:

proc           /proc       procfs  rw  0   0

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

• Добавляю себя в группу operator:

pw groupmod operator -m {мой_юзер}

После описанных телодвижений автомонтирование работает, хотя на FreeBSD 8.1 и GNOME 2.32.1 оно работает и без этого, как говориться, из коробки. Если мы сейчас вставим флеш-накопитель с файловой системой VFAT и русскими именами файлов, записанными в виндовозе, то нормально прочитать их мы не сможем. Проблема заключается в том, что кодовая страница среды GNOME - UTF-8, а в виндовозе - CP-1251. Лечится разница в кодировках очень просто.

Для файловой системы VFAT в редакторе конфигурации gconf-editor пишем в /system/storage/default_options/vfat значение:

longnames, -u=, large, -D=Windows-1251, -L=ru_RU.UTF-8

Для NTFS в /system/storage/default_options/ntfs пишем:

-m=755,-C=UTF-8

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

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

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

Если верить Википедии, плагины этого типа работают в Mozilla Firefox как родные. В моем браузере такие плагины устанавливаются путем правого клика на ссылку плагина и выбора в появившемся контекстном меню команды "Установить пользовательский скрипт". После выбора которой, он автоматически загружается, сохраняется в нужное место и уже готов к использованию. Подозреваю, что в Firefox процедура установки не особо сложнее.

Приложения

Установить клубничный плагин

Существует несколько вариантов решения. Первый - прямое преобразование кодировки типа:

String arg = new String (arg.getBytes ("UTF-8"), "ISO-8859-1")

Этот способ представляется мне несколько кривым и неизящным. Второй - создание фильтра, который преобразует все запросы в UTF-8. Такой способ мне кажется слишком громоздким.

Самый правильный, на мой взгляд, вариант решения - комплексный. Первое, что надо сделать, это добавить в параметры используемого коннектора Tomcat директиву URIEncoding="UTF-8" в файле server.xml и перезапустить Tomcat. Но одной этой меры недостаточно. Второе, в сервлетах, печатающих текст, необходимо добавить три строки в таком порядке:

response.setContentType ("text/html; charset=UTF-8");
PrintWriter out = response.getWriter ();
request.setCharacterEncoding ("UTF-8");

Для ничего не печатающих сервлетов достаточно только последней строчки.

Для правильно принятия текста в JSP и JSPX можно использовать тег fmt из набора JSTL. Здесь нужно добавить в начало файла директиву

<fmt:requestEncoding value="UTF-8" />

Это позволяет принимать данные в нужной кодировке. Для JSP и JSPX, которые не принимают данные, использования тега fmt не требуется. Но этого тоже недостаточно. Тег fmt основывается на кодировке локали браузера клиента, но не все браузеры правильно передают локаль в HTTP-запросе. При невозможности получить локаль от клиента, экземпляр тега берёт данные о кодировке из параметра javax.servlet.jsp.jstl.fmt.request.charset, которая по умолчанию соответствует кодировке системы, где работает Tomcat. Чтобы такого не случилось, нужно явно определить значение данного параметра в дескрипторе развертывания вот так:

<context-param>
    <param-name>javax.servlet.jsp.jstl.fmt.request.charset</param-name>
    <param-value>UTF-8</param-value>
</context-param>

Теперь все данные будут попадать в веб-приложение в UTF-8. Но для правильного вывода текста в JSP и JSPX описанных мер недостаточно. Необходимо добавить в JSP первой строкой:

<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>

А для JSPX сразу после директив jsp:root и jsp:output doctype-root-element добавить такие строки:

<jsp:directive.page contentType="text/html; charset=UTF-8" />
<jsp:directive.page pageEncoding="UTF-8" />

Вот только теперь все данные в обе стороны будут в кодировке UTF-8.

До этого я читал по большей части в PDF и CHM. Но первый задумывался как формат для печати со всеми вытекающими, а второй делался только для виндовоза. Хотя, и в других осях читать его можно, но это не наш путь. :-)

Через какое-то время мне попался на глаза FictionBook, и выбор пал на него - он мне понравился сразу. Формат изначально задуман для электронных книг и лишен неудобного наследства бумажных книг. Выбор программ для чтения оказался невелик - большинство только под виндовоз или мне не нравятся. А поскольку в Гноме на моей любимой FreeBSD читать толком не чем, решил написать свою.

Средства и инструменты долго выбирать не пришлось - уже давно подсел на GTK+ и Анюту. Для чтения XML-файла с книгой - libxml2 как хорошо проверенную временем и быструю библиотеку. Для хранения служебной и прочей информации - встраиваемую базу данных sqlite3. Все эти средства переносимы, стало быть, работают на разных платформах. С лицензией вопрос тоже не стоял - GPLv3.

Определимся с основными задачами, которые программа должна решать:

• Полная поддержка формата - что, как оказалось, редкость (забегая вперед, скажу, что от поддержки CSS я все же отказался).
• Закладки (автоматическое запоминание места, где закрыл книгу, плюс пользовательские закладки).
• Навигация (оглавление, ссылки, вложения и история).
• Библиотека (уже на 50-ти книгах я начал ловить себя на том, что ищу нужную мне книгу глазами, а когда их будет тысяча?).
• Настройка отображения самой книги (формат, за небольшим исключением, не оговаривает способ отображения текста, возлагая эту задачу на программу для чтения).
• Кое какие дополнительные функции, о которых пока промолчу.

Кроме того, неплохо было бы реализовать интеграцию с Гномом. А это зарегистрированный в среде MIME-тип, ассоциация его с программой, предосмотр в Наутилусе (другими словами, в папках вместо иконки файла видна обложка книжки) и, конечно же, видимость программы в системном меню.

Первая версия программы использовала технологию DOM как одну из самых простых. Суть DOM такова, что в памяти создается структура, полностью соответствующая файлу по иерархии и содержимому. А дальше эта структура читается программой, и из нее извлекаются данные. Прочитав пару десятков книг в своей еще не готовой до конца программе, я убедился, что DOM не совсем подходит для решения задачи. Во-первых, файл парсится минимум в два прохода, а это накладные расходы. Во-вторых, поскольку структура строится в памяти, расход памяти становится просто неприличным. В-третьих, ограничения технологии DOM, на которые я наткнулся, не давали реализовать задуманное простым и элегантным способом. В итоге я решил переписать программу заново с использованием технологии SAX. Это очень быстрая событийная технология, читающая XML-файл за один проход, использующая минимум памяти, а главное, ниже уровнем, чем DOM (SAX все равно работает внутри DOM, когда в памяти создается структура XML-файла). Программного кода в итоге получилось значительно больше, но скорость чтения ощутимо возросла. Плюс к тому, я учел опыт создания и использования первой версии.

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

Исполняемый файл отдельной программы для показа обложек вместо иконок в Гноме получился чуть больше 10 Кб. Когда я прикрутил его к Гному, на папки с книгами стало приятно смотреть - прямо как в библиотеке. :-)

В интерфейсе программы я старался следовать философии HIG, то есть простота и понятность интерфейса вкупе с продуманной организацией управляющих элементов. По совету разработчиков GTK+ я поглядывал на организацию интерфейса таких программ, как Evince и gedit (а на gedit еще и по организации программного кода). Что мне не нравится в аналогичных программах для чтения - так это большая привязка к формату, чем к интерфейсу. Этого я решил избежать. По моему мнению, читатель не должен и понятия иметь о внутренней структуре файла книги, но должен видеть перед собой очевидные и уже привычные из других программ инструменты.

С самого начала разработки я отдавал себе отчет в том, что без программы-библиотеки мне не обойтись. Я реализовал ее как отдельное окно в программе плюс возможность запуска библиотеки отдельно от читалки с помощью ключа командной строки. Посмотрев на организацию интерфейса аналогичных программ, я получил неприятные впечатления. Во-первых, многошаговые операции с деревом (аля жанр -> автор -> серия -> книга), во-вторых, неочевидная организация интерфейса вообще (включая показ непосредственно книг), в-третьих, отсутствие пользовательских инструментов для управления библиотекой (я не имею в виду разного рода импорты-экспорты и прочие сторонние для библиотеки функции). Мне гораздо больше импонирует логика таких программ как Rhythmbox где можно самому организовать структуру свой библиотеки.

Поскольку библиотека, да и сама программа в целом является однопользовательской, по моему мнению, логично использовать для хранения встраиваемую базу данных. Вот тут я открыл для себя sqlite3 - очень быстрая и мощная база данных (тут тебе и реляционные связи, и индексы, и проверки и прочие приятные мелочи, которые скорее ожидаешь увидеть в "тяжелых" СУБД). А коль скоро я задумал программу как межплатформенную, то решил хранить в sqlite3 вообще все: и пользовательские настройки, и закладки, и служебную информацию библиотеки. Дабы не плодить излишние сущности типа GConf или виндовозного реестра.

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

Пользовательские настройки программы я решил разделить на общие и относящиеся непосредственно к книге. Дабы не усложнять настройку и соответствовать принципу KISS.

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

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

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

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

Качество изображения

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

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

Оптимальные параметры для мониторов с электронно-лучевой трубкой (CRT) такие:

• для экрана с диагональю 15 дюймов лучшим разрешением будет 800х600 точек с частотой обновления не менее 85 Гц
• для экрана с диагональю 17 дюймов, соответственно, 1024х768 и 100 Гц
• для 19-ти дюймов - 1280х1024 и 120 Гц

Для жидкокристаллических мониторов частота обновления значения не имеет (точнее, ставьте всегда минимальную - 60 Гц). А разрешение лучше всего то, которое рекомендует производитель монитора. На практике рекомендованное разрешение оказывается на порядок выше, чем у мониторов с трубой - 1024х768 на 15-ти дюймовом мониторе, 1280х1024 на 17-ти дюймовом и так далее.

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

Яркость экрана должна примерно соответствовать окружающему освещению или немного ярче.

Расположение монитора и элементов управления

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

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

Расположение пользователя

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

Стол должен быть такой высоты, чтобы локти на нем лежали свободно.

Что необходимо исключить

• Блики на экране являются самым вредным явлением на сегодняшний день. Необходимо сориентировать рабочее место относительно источников света. За спиной пользователя не должно быть никаких источников света, включая окна с закрытыми жалюзи (которые не закрывают свет полностью). Особенно вредны блики, попадающие только на один глаз. Увидеть блики легко при выключенном мониторе.
• Источник света, бьющий в глаза, имеет эффект ослабленного блика (к примеру, сидя лицом к окну). Необходимо исключить.
• Любое напряжение в теле, которое возникает из-за неудобной позы или мебели.

Дополнительные ссылки

Эргономика работы за компьютером - субъективные заметки

Началось все с того, что мой старший брат привез из заграничного рейса ATARI 800XL. Это было в феврале 1984-го. Сам компьютер был 1983-го года выпуска. Это было что-то нереальное - представьте себе в советские времена большую красочную коробку с интересным и загадочным чудом техники внутри. Машина имела такие характеристики: 64 Кб памяти, кассетный цифровой магнитофон в качестве долговременной памяти, разрешение 320х192, 256 цветов.

Первые в моей жизни компьютерные игры были собственноручно введенными с клавиатуры программами из журнала COMPUTE!. Со следующих рейсов брат привез коммерческие игры (Bruce Lee, Bounty Bob Strikes Back, Ghost Chaser, Zorro, шахматы Colossuss Chess и еще несколько), язык Action! и литературу - подробнейшее описание процессора 6502, машинного языка, бейсика и еще кучу всего. Брат в то время своими руками в машинных кодах (что-то типа COPY CON PROGRAM.EXE) написал ассемблер и дизассемблер (не написал на ассемблере, а именно написал ассемблер со всеми причиндалами) - кто представляет что это такое, поймет. Кто сейчас осмелится на подобное?

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

Надо сказать, что все мои школьные друзья частенько составляли мне компанию в играх (ATARI 800XL позволял подключить сразу два джойстика) - мы бились по многу часов подряд.

Несколько лет спустя, я нашел во Владивостоке игровой клуб, в котором использовались исключительно ATARI, и переписал у них еще несколько игр (Boulder Dash, River Raid, Карате, Ninja и ряд других).

Но больше всего меня захватывало программирование. Бывает, сядешь после школы за компьютер... Бах! Уже утро! Брат тогда потратил кучу времени, обучая меня встроенному диалекту ATARI Basic по привезенным книгам. Конечно же, все они были английские (с этим у меня никогда проблем не было - когда я был совсем маленьким, мой отец рассказывал мне сказки только по-английски). Изучение бэйсика в 14 лет (когда в городе на тот момент был один-единственный персональный компьютер) направило меня в нужное русло и дало мне скачок - с того времени я освоил с десяток других языков.

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

Так с чего же я начал? Ах да, прочитал на Мембране статью и отзывы ностальгирующих (сейчас эти отзывы что-то не могу найти на Мембране). Скачал и запустил игрушки своей юности, которые не видел уже больше 15-ти лет. Слезы на глазах. Кинул ссылку на эмулятор ATARI в комментарий к статье на Мембране - эффект тот же, что и у меня - люди плачут. Не у одного меня ностальгия.

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

Все это время звучала...

...оригинальная музыка из игры Jet Set Willy, которую ни я, ни кто-то другой из моих знакомых не смог пройти до конца (я изрисовал несколько листов формата А2 схемой игры, но это было далеко не все). Фрагмент, конечно. До сих пор удивляюсь, как можно было впихнуть такую длинную музыку в 48К памяти вместе с кодом игры.

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

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

Что же мы имеем в итоге?

Достоинства

• Сохранение фотографий и мувиков одним кликом
• Автоматическое переименование файлов при сохранении
• Полная защита от всплывающих окон
• Ограничение доступа к программе и сохраняемым файлам
• Управление категориями файлов
• Моментальное закрытие окна программы с клавиатуры
• Все необходимые средства для просмотра сохраненных файлов

Некоторые достоинства начальники и слишком ревнивые жены могут извращенно понимать как недостатки. :-)

Недостатки

• Невозможность прикрутить скрипт, о котором я писал
• Невозможность просмотра в нескольких окнах одновременно

Выводы

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

Экспорт статистики подразумевает понимание двух моментов: куда мы будем сливать данные и в каком формате. В идеале формат должен быть таким, чтобы переносить данные можно было бы куда угодно.

Определяемся с форматом файла

Лучшим из известных мне форматов представления данных является XML, который имеет следующие плюсы:

• Формат XML позволяет в одном файле представить сколь угодно сложную структуру данных
• Почти все (а может и все) современные СУБД понимают формат XML
• XML относительно легко воспринимается человеком
• XML является самодостаточным форматом в том смысле, что для его чтения и анализа необязательно использовать базу данных

При всех его достоинствах файл формата XML имеет весьма значительный размер, что не может не сказаться при передачи файла по сети. Однако, он хорошо сжимается (мне удалось сжать XML-файл в 17 раз).

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

Предварительные меры

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

Выбираем среду разработки

Я решал задачу по экспорту статистики в своей любимой оси OS/2 Warp, на этом примере и опишу данный процесс. За выбором реализации программы-обработчика дело не стало - самым естественным решением, идеально подходящим для решения нашей задачи в OS/2 Warp, является REXX. REXX, для тех, кто не знает - это язык программирования, командный язык и макроязык в одном флаконе, на котором можно делать практически все, что позволяет операционная система (например, легким движением левой задней ноги напрямую вызывать функции API операционной системы, создавать многопоточные приложения и подключать внешние библиотеки). Не смотря на то, что REXX - язык интерпретируемый, программы на нем летают как пули.

Если InJoy Firewall работает в среде Windows, то самым простым вариантом реализации программы-обработчика будет использование встроенного в систему VBScript, который предоставляет родные для Windows средства доступа к файловой системе. Для UNIX, соответственно sh или аналог.

Собственно обработка

Как я уже говорил, в результате обработки файла статистики в базе данных получается восемь таблиц, каждую из которых необходимо отобразить в XML-файле. Я не буду подробно вдаваться в описание кода программы-обработчика и описание структуры XML-файла, вместо этого я даю готовый скрипт на REXX, который все это делает (для запуска изменить расширение на CMD, если кто не знает). Кому интересно, может посмотреть код программы и заглянуть в XML.

На самом деле обозначенный скрипт делает несколько больше, чем просто конвертирование файла статистики файрвола в XML - он обрабатывает сразу два файла статистики двух файрволов (внутреннего и внешнего), предварительно проверив дату последнего обновления обоих файлов, заливает все эти данные в один XML-файл (то есть, уже 16 таблиц), сжимает его в ZIP, отправляет по FTP на сервер, пишет лог, удаляет за собой все временные файлы и делает запись в специальном флаговом файле о дате последней удачно проведенной процедуры. Таким образом достигается непрерывность переноса данных статистики, так как следующая процедура переноса данных будет начинаться с даты, идущей непосредственно за последней удачно прошедшей заливкой. В моем случае ZIP-файл заливается на сервер статистики, где распаковывается, и данные заливаются непосредственно в базу данных.

Описание переменных

В начале REXX-файла есть выделенная область, в которой задаются переменные. Их необходимо определить до первого запуска программы и создать все нужные директории. Все файлы (включая временные и файл-флаг) программа создает автоматически. Вот краткое описание переменных:

Параметры запуска

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

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

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

Дополнительные утилиты

Описанная выше REXX-программа использует в своей работе некоторые утилиты, которые должны находиться в директории C:\OS2\APPS\.

Для правильной работы статистики необходимо запускать файл в начале каждых суток по расписанию согласовано с установленным в параметрах файрвола временем задержки сохранения статистики в файл (параметр Account-Interval в файле firewall/firewall.cnf). Для запуска по расписанию можно, например, использовать cron.

Для сжатия в ZIP необходима программа pkzip. Программа работает именно с PKZIP. Тестировалась с версией 2.50, но будет работать и с любой другой аналогичной.

Для заливки файла по FTP никаких дополнительных утилит не требуется, потому как REXX-программа использует встроенное FTP API системы OS/2 Warp.

В заключение

Описанная выше моя программа работает около двух лет, обрабатывая каждую ночь статистику нескольких хостов-шлюзов, и сливая ее на один общий сервер статистики. Время работы программы при обработке двух файлов статистики за раз на самом слабом из шлюзов (Pentium 166 при 80-ти мозгобайтах памяти) занимает меньше секунды.

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

Для начала надо понять какие виды клубничных сайтов существуют в Сети. Конечно, количество таких сайтов огромно, но во всем своем разнообразии они поддаются четкой классификации. Следует заметить, что львиная доля сайтов - платные. При этом, большинство из них показывают чуть-чуть клубнички бесплатно, аля замануха. И все. Но это не наш путь, ведь нас интересуют бесплатные сайты с большим количеством клубнички, не так ли? Таких сайтов очень много.

Таким образом, мы будем классифицировать только бесплатные сайты. А точнее, только один из типов бесплатных сайтов. Вся суть в том, что на самом деле бесплатных сайтов почти нет. Возникает резонный вопрос - о чем тогда вообще разговор? Справедливо. При этом, существуют сайты, которые позволяют нам видеть клубничку бесплатно и в большом количестве. Где же собака порылась? :-) Попробуем разобраться.

Существует тип сайтов, называемый TGP (Thumbnail Gallery Posts - Публикации Галерей с Предосмотром). На самом деле не всегда с предосмотром, но ведь нас интересуют именно сайты с предосмотром, не правда ли? Предосмотр выглядит как список небольших фотографий, являющихся ссылками на фото- или видео-галереи и бывает двух видов:

1. Все фотографии ведут на соответствующие галереи в рамках этого же сайта (хорошо, конечно, но в большинстве случаев так бывает только на платных сайтах).
2. Все фотографии ведут на галереи на других сайтах, на такие же списки-предосмотры на других сайтах или куда-либо еще с рекламной целью. (Такой подход, как правило, распространен на бесплатных сайтах, стало быть, рассмотрим этот вариант подробнее).

TGP-сайты с галереями второго типа встречаются следующих категорий:

1. Опасные (их мы рассматривать не будем - зачем нам лишняя головная боль?)
2. С прямыми ссылками (самые желаемые, но их очень мало), то есть, каждое фото ведет непосредственно на конкретную галерею, соответствующую фотографии предосмотра.
3. С непрямыми открытыми ссылками (вот таких просто море), то есть, ссылки-фотографии таких сайтов ведут на этот же сайт, но в параметрах, передаваемых в адресной строке, открытым текстом присутствует адрес запрашиваемой галереи. Стало быть, нам остается только отделить нужный адрес гелереи от лишней для нас шелухи. Но вернемся к этому позже.
4. С непрямыми закрытыми ссылками (таких тоже много, но меньше, чем предыдущих) - то же, что и пункт 3, за тем исключением, что адрес нужной галереи зашифрован HTML-символами. В этом случае нам нужно не только отделить нужный адрес, но и расшифровать его обратно в читаемый вид. К этому мы тоже вернемся позже.
5. С непрямыми зашифрованными ссылками (таких сайтов, пожалуй, еще меньше) - то же, что и предыдущая категория, только алгоритм шифрования адреса галереи уже более серьезен. На них в этой статье мы останавливаться не будем, скажу только, что почти все ссылки (если кликать на них обычным образом) ведут на TGP-сайты предыдущих двух категорий, то есть, и здесь есть чем поживиться.

Подытожим. Получается, что нам интересны только TGP-сайты с непрямыми ссылками, независимо от того, зашифрованы ссылки в виде HTML-символов или нет. Конечно, можно вручную найти все эти ссылки в коде-источнике вебстраницы и (опять же вручную) подставлять их в адресную строку браузера. Мы даже можем вручную или с помощью какого-нибудь текстового макроса расшифровывать HTML-зашифрованные адреса и подставлять их в адресную строку браузера. Но мы так делать не будем, если весь этот процесс можно автоматизировать.

Автоматизировать будем методом букмарклетов или закладурок, как их еще называют. Суть метода в объединении двух технологий: букмарки (закладки в браузере) и аплеты (java-программы на стороне клиента, работающие в браузере). Выглядит это так. На панель ссылок в браузере (такая панель есть и в Internet Explorer, и в Mozilla Firefox) помещается кнопка-букмарклет, нажатие на которую превращает все непрямые ссылки в обычные прямые ссылки и убирает HTML-шифрование. То есть, загрузив сайт (надо обязательно дождаться полной загрузки страницы), надо просто клинкуть мышкой по кнопке на панели ссылок браузера и наслаждаться зрелищем.

Осталась одна, так сказать, мелочь - как же определить какие сайты нам нужны? Повторюсь, что нам нужны неопасные сайты (то есть, без вирусов, непонятно куда ведущей рекламы, всплывающих окон и прочего безобразия). Рекомендации следующие:

1. Если ваш антивирус (а жить без антивируса в Сети нельзя) хоть раз ругнулся на вирус на TGP-сайте или на любом другом сайте, куда ведут ссылки с этого TGP-сайта, то данный сайт уже будет потенциально опасным.
2. Если TGP-сайт (или сайты куда он ведет) постоянно открывает всплывающие окна (даже если окна выходят при закрытии самого сайта), то это не наш случай.
3. Если даже после нажатия кнопки на странице закладок ссылки TGP-сайта ведут не на галереи, а на рекламные страницы, платные сайты или на главные страницы других сайтов, то про этот TGP-сайт нужно забыть.
4. Необходимо отличать фотографии-ссылки, ведущие на галереи, от баннеров и прочей шелухи. Это несложно.

И самое главное - вот как использовать описанную выше технологию. Надо создать на панели ссылок кнопку (ярлык интернета) и вписать вместо адреса вот этот скрипт. Можете назвать его, например, "Убрать редиректы" или что-то в этом роде. Теперь после открытия клубничного сайта просто нажмите на эту кнопку на панели закладок и все ссылки на галереи станут прямыми - можете смело кликать, и вы попадете непосредственно на нужную галерею.

Читайте так же

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

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

[Firewall accounting log - Period: Dec, 2003]

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

[Last revised 03.01.2004 - 03:19:47]

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

[DATE: 01.12.2003]

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

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

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

[MONTHLY TOTAL]

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

Для дальнейшей обработки сумм статистики необходимо иметь в виду два важных момента:

Соглашения о представлении данных

Вся информация о трафике рассчитывается и хранится внутри файрвола в байтах. В файле же статистики суммы отображаются в разных величинах. То есть, если какая-либо сумма превысила килобайт, то данная сумма будет пересчитана в килобайты и будет отображаться в килобайтах. То же самое справедливо для мегабайта и гигабайта. Пересчет происходит, как и положено, по 1024. Исходя из пересчета сумм, мы имеем следующий момент:

Округление сумм

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

Итоги

Какие же данные мы можем получить из файла статистики? А не так уж мало:

• Месячная итоговая статистика для всей сети
• Месячная итоговая статистика для каждого компьютера внутри сети
• Месячная суммарная почасовая статистика для каждого компьютера внутри сети
• Месячная суммарная почасовая статистика для всей сети
• Суточная суммарная статистика для каждого компьютера внутри сети
• Суточная суммарная статистика для всей сети
• Почасовая статистика для каждого компьютера внутри сети
• Почасовая статистика для всей сети

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

Продолжение следует

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

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

Красноречивый пример. Директор считает себя очень знающим человеком в информационных технологиях (хотя по факту все, что он достиг это установка почтового клиента The Bat! с пятой попытки) мог запросто уронить отстроенный сервер, похоронив при этом бухгалтерскую базу данных вместе в резервными копиями. Бухгалтер, конечно, была очень рада.

Дальше - больше. Полгода (!) с момента моего прихода в эту компанию я не мог добиться постановки задачи, которая была нужна "еще вчера". А через два месяца после этого задача была отменена (во всяком случае, для меня) не глядя на то, что я уже сделал. До этого момента меня в компании держало только обещание закончить разработку (поскольку мне уже порядком надоел внутренний бардак), поэтому отказ от задачи был для меня большим облегчением. В тот же день я уволился.

Мораль той басни такова - если вы - разработчик, и вас привлекают интересные задачи, очень тщательно выбирайте место работы. Возможно, я еще расскажу о своем понимании этого дела. Для тех, кому интересен вопрос рекомендую статью того же Джоэла Сполски "Я начальник - ты дурак" и команда клоунов.

InJoy Firewall вместо привычной для других файрволов одной очереди правил, применяемых последовательно сверху вниз, имеет целых пять, работающих с разным приоритетом. Порядок обработки правил такой: Whitelist rules, Blacklist rules, User rules, System rules, Traffic shape.

Кроме этого, в InJoy Firewall существует динамический файрвол, который можно назвать шестой очередью правил. Работает он на основе очереди системных правил (System rules). Суть динамического файрвола заключается в оперативном реагировании на изменения трафика.

Например, какая-то редиска пытается провести сканирование IP-портов вашего шлюза на предмет открытости. Динамический файрвол тут же загоняет его IP-адрес в черный список (Black List), и ваш хост для него вообще исчезает в тумане. Или же другой умник терпеливо долбит какой-то определенный порт, скажем 139 (они это любят). Динамический файрвол после определенного количества попыток опять же загоняет его IP в черный список с тем же результатом. При желании, можно назначить такое правило, которое включает специальную систему наблюдения в случае конкретно оговоренного антиобщественного поведения какого-нибудь IP-адреса.

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

Запрет выхода в Интернет для некоторых адресов

Допустим, вам требуется разрешить выход в Интернет только для определенных IP-адресов, а всех остальных отправить нюхать цветы.

Для этого требуется создать правило типа NAT в очереди White List для нужных IP-адресов, а в очереди Black List запретить выход для всех других. В таком случае очередь Whitelist rules будет применяться только для разрешенных адресов, а очередь Blacklist rules - только для запрещенных. То же самое справедливо и для частичного открытия портов (например, кого-то надо пускать только за почтой).

Разрешение входа из внешней сети (порт мапинг)

Бывают случаи, когда необходимо разрешить доступ из сети Интернет к какому-либо внутреннему ресурсу, например, вебсерверу. Для этого требуется создать правило типа Allow в очереди White List, разрешающее доступ к внешнему IP-адресу шлюза (Destination - MyIP) по 80-му порту с двусторонним направлением (Bidirectional). В дополнение к этому нужно включить переадресацию (Redirect) на IP-адрес вебсервера внутри сети. Внешний и внутренний порты могут не совпадать.

Использование расписаний

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

Реагирование на адреса посещаемых сайтов

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

Разделение трафика по приоритетам

Для некоторых сетей, особенно с большим трафиком, очень важно разделять проходящий через интернет-шлюз трафик по важности. Для этого в InJoy Firewall существует специальная очередь правил, именуемая Traffic shape. Она применяется к проходящему трафику последней. Суть правил Traffic shape в том, чтобы разделить разные виды трафика по группам и определить для них приоритеты. Например, компания активно пользуется электронной почтой, простой которой может нанести финансовый ущерб деятельности компании. В этом случае почтовому трафику назначается наивысший приоритет, что гарантирует бесперебойную работу почты даже в случае перегрузки интернет-канала.

Дополнительно

Инструмент управления правилами имеет два режима - Simple и Advanced. Они различаются количеством видимых настроек очередей правил и переключаются контекстным меню непосредственно в дереве правил. Все более-менее сложные операции с правилами делаются в режиме Advanced.

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

Мою жену положили в роддом с признаками приближающихся родов, как оказалось, за полторы недели до родов. Нескончаемые уколы и процедуры. (Может, так и надо?) Отвратительное по качеству и количеству питание. (Вновь поступившим котлеты нельзя. Де не хватает. При этом, половина противня котлет стоит на виду. Домой тащат?) В большинстве своем пофигистический персонал. Грубость. Ну да ладно, это всего лишь ожидание.

Я приехал в роддом при первых схватках и имел возможность наблюдать за процессом от начала до конца.

Схватки

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

Роды

Сами роды в холодном родзале (хорошо хоть пар не шел) прошли относительно быстро. В перерыве между схватками акушерка пыталась мне навялить обезболевающее из-под полы (ну, разумеется, я согласился!). Но когда дело дошло до зашития нескольких ссадин она на редкость похабно (а поработав год в операционной, я видел как аккуратно зашивают специалисты) зашивала огромной иглой безо всякого обезболивания (эти швы непрерывно болят по настоящий момент). Я видел как было больно моей жене и пытался надавить (в том числе за деньги) на эту гребанную акушерку, чтобы она обезболила перед тем, как шить. Но в ответ я услышал только какие-то кривые отмазки (ты какого хрена полчаса назад предлагала мне купить обезболивающее???)

Палата

После родов нас поместили в отдельную палату (это у них называется сервисная платная палата). Комнатушка 2х2. Отдельный санузел.

Коридор - проходной двор (каждые полчаса крики во все горло типа: "Маааня, тебя к телефооону!!!") Дверь для персонала не существует - вламываются с грохотом без предупреждения (не говоря уже о стуке) чего-то орут и с таким же грохотом уходят. На призывы быть потише ответ был такой: "Да они ничего еще не слышат." (И откуда берутся такие знатоки детского слуха?)

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

Вежливость

Одна из детских врачей пришла к нам на какой-то осмотр в момент смены пеленок. "Сначала я посмотрю, а потом ты будешь говно салфетками размазывать", - сказала она. (Кто пускает в детское учреждение таких циничных ублюдков???)

Процедуры

В последний день незадолго до выписки дежурный педиатр сказала, что надо взять кровь у ребенка. Выглядело это так. Ручка трехдневного ребенка сгибается в запястье до упора, а в наружную сторону ладони втыкается игла. Берет эта хренова сестра толстую иглу, втыкает ее под кожу, но в вену не попадает. Шарит иглой под кожей ребенка, но опять ничего не выходит. Ребеночек, естественно, кричит от боли. Тогда она вынимает иглу, и процедура повторяется с тем же успехом. Еще два захода на другой руке. "Ой как трудно найти вены..." И дает попробовать другой сестре. (Ты какого, спрашивается, хрена берешься делать уколы младенцам, если у тебя руки из задницы???)

Алчность

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

Алчность

Святослав Рерих называл таких врачей ремесленниками от медицины. Хорошо, что не все они такие, даже в роддоме. А ведь я видел в деле первоклассных специалистов, вежливых и участливых к больным. Уважаю. Побольше бы таких.

Несколько очередей правил безопасности

InJoy Firewall анонсируется производителем как файрвол нового поколения. Одной из причин такого серьезного заявления, на мой взгляд, является уникальный подход к организации правил безопасности. В обычном файрволе с классическим подходом существует определенный набор правил, которые просматриваются и выполняются сверху вниз. В InJoy Firewall существует несколько очередей правил, которые выполняются с разным приоритетом. InJoy Firewall просматривает сверху вниз сначала очередь правил с наивысшим приоритетом, потом с более низким и так далее. Таким образом, дается дополнительная гибкость в настройке и удобство при большом количестве правил. Порядок просмотра правил такой: Whitelist rules, Blacklist rules, User rules, System rules, Traffic shape.

Установка нескольких экземпляров файрвола

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

Все эти задачи решаются с помощью установки нескольких экземпляров файрвола. Каждый экземпляр привязывается к своему конкретному интерфейсу и осуществляет фильтрацию трафика, проходящего только через этот интерфейс. Процедура установки двух и более экземпляров подробно описана в readme, что живет в корне файрвола - нужно поправить четыре файла: config.sys, protocol.ini, startup.cmd и файл gateway.cnf в папке config каждого экземпляра. Единственным недокументированным нюансом является порядок запуска серверов экземпляров файрвола - запускать нужно в обратном порядке параметру Device-Index, что в файле config/gateway.cnf.

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

Использование удаленных командных файлов

В меню File файрвола (хоть удаленного, хоть локального) есть два пункта Execute "script1.cmd" и Execute "script2.cmd", которые запускают на выполнение соответственно командные файлы script1.cmd и script2.cmd, что живут в корневой папке файрвола. Для выполнения этих файлов неважно, удаленно вы подключились к файрволу или локально.

Использовать эти файлы (что очень удобно) можно разными способами, например, для удаленного выключения/перезагрузки компьютера или же обработки статистики. При выключении или перезагрузке неплохо бы сначала корректно погасить файрвол командой sync -kill из комплекта поставки файрвола.

Использование системы уведомлений

Правила InJoy Firewall 3.0 имеют очень приятную возможность - уведомления (или алерты, проще говоря). Если переключить любую из очередей правил в расширенный режим (Advanced), то мы увидим, что на каждое правило можно назначить уведомление (узел дерева Alert ветки Rule Processing).

Уведомление работает в двух режимах: Audio и Autostart. Первый - в случае удаленно стоящего сервера - не очень интересен, а вот второй можно использовать на полную катушку. Например, у нас в сети имеется почтовый сервер (за неимением можно за несколько минут поставить и настроить бесплатный по умолчанию сервер Weasel на той же машине, что и файрвол). В этом случае по срабатыванию любого нужного правила можно легко настроить файрвол так, чтобы он отправлял соответствующее уведомление администратору по электронной почте.