Alex Nekipelov Blog

ресурс dev.wikitt.com

2012-01-10T13:39:00.000+04:00

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

Также я давно задумывался о том, что пусть и для начинающих написано много, однако все ли написанное стоит читать? Частенько для начинающих пишут такие же начинающие, поэтому с ошибками. Да и более опытные программисты тоже могут ошибаться. Также написанное где-то в блоге некоторое время назад может перестать быть актуальным на сегодняшний день. Ведь меняется язык, меняются процессоры и операционные системы… В общем пришел к тому, что хотелось бы ресурс, подобный wikipedia, но для программистов. Ну и благодаря наличию свободного времени в эти праздники, сделал сайтик http://dev.wikitt.com

Вот, что есть на данный момент:

Советы по оптимизации программ на языке C++

Написал основное, что пришло в голову. Пока не добрался до STL и всяких сортировок… Как будет время, дополню.
Использование идиомы pimpl совместно с умными указателями

Несколько раз встречал на формах сообщения о подобной проблеме. Поэтому решил описать решение и причину.
Что предпочтительней: ссылка или указатель?

Описаны больше свои собственные соображения на этот счет. Хотя коллеги почему-то предпочитают больше оперировать указателями :–)
Почему не следует использовать перегрузку операторов

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

Почему не стоит использовать операторы преобразования типов

Опять же из опыта работы, приходилось иметь дело вот с таким кодом:


  template<typename TYPE> void Assign(const TYPE& tValue)
  {
    Realloc(sizeof(TYPE));
    *(TYPE*)m_ptr = tValue;
  }
  operator void* () { return (void*)m_ptr; }
  operator long* () { return (long*)m_ptr; }
  operator double* () { return ((double*)m_ptr); }
  operator int* () { return ((int*)m_ptr); }
  operator short* () { return ((short*)m_ptr); }
  operator char* () { return ((char*)m_ptr); }
  operator UCHAR* () { return ((UCHAR*)m_ptr); }
  operator LPCSTR () { return ((LPCSTR)m_ptr); }
  operator DATE_FORMAT* () { return ((DATE_FORMAT*)m_ptr); }
  operator TIME_FORMAT* () { return ((TIME_FORMAT*)m_ptr); }
  operator SOFT_REF* () { return ((SOFT_REF*)m_ptr); }

Все желающие поделиться полезной информацией, приглашаются :-)

Qt, resize и нехватка памяти

2011-11-12T12:29:00.001+04:00

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

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


QVector<char> buff;
buff.resize( buffSize );
memcpy( src, buff.data(), buffSize );

Размер buffSize что-то около 200 Мб. Вроде бы и не много. Но когда программа работает долгое время, память фрагментируется, одного куска размером 200 Мб может и не быть. По аналогии с STL я привык, что это корректный код. При нехватке памяти будет сгенерировано исключение, которое будет поймано и обработано, или обработчик этой проблемы освободит память. И когда вылезла беда, стал разбираться… Для выделения памяти в Qt используется аналогичные ANSI-C фукнциям qMalloc, qRealloc, qFree. При невозможности выделить память, они возвращают NULL. Только вот resize не возвращает результата, и исключение не генерируется. Получается, что указанный выше код корректен в STL, но не корректен в случае контейнеров Qt. Подобная же проблема имеется и с классом QByteArray, и вероятно со многими другими.

А самое смешное, вот что говорят в рассылке на эту тему:

A short and simple question.

How an application can detect failure in QByteArray::resize(int newSize) method, since resize() is a void function?

You can’t.

If memory allocation fails, you’re out of luck. You should crash your application at this point and help the system free up memory for other applications.

Источник: http://lists.trolltech.com/qt-interest/2008-10/thread00114-0.html

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

Сравнение http серверов приложений

2011-11-11T11:07:00.001+04:00

Продолжу тему http серверов. На этот раз про сервера приложений для ruby и python. С другими языками я практически не дружу (не считая c++, конечно же).

Их много, все они разные, и главное отличие - скорость обработки запросов. Еще, конечно же, важно назначение http сервера. К примеру назначение http сервера Mongrel и Thin - запуск приложений, написанных на языке ruby, а Tornado или Twisted для приложений, написанных на python. Конечно их можно использовать и для раздачи статических файлов... но я не советую :-)

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

Основная задача, которую я хочу выполнить: узнать максимальное количество запросов в секунду, на которые способны указанные сервера приложений. Они были выбраны как самые быстрые (не считая Mongrel, конечно же). Если вы знаете более быстрые сервера приложений для ruby или python, пожалуйста, сообщите мне об этом. Методика тестирования заключается в создании минимального приложения, которое будет отдавать строку "Hello World". Сначала я хотел делать второй этап теста и отдавать больший объем данных, но судя по результатам, это не значительно влияет на результаты, поэтому их не привожу. Тестовый стенд: AMD Phenom(tm) II X4 940, 8 Gb RAM, Debian Squeeze, сборка для AMD64. Все тексты запускались несколько раз, чтобы убедится в стабильности результатов. Для теста используется ab, первый тест выполняется с аргументом -c 1, второй -c 100 (это количество параллельных запросов). При запуске я привязываю приложение к определенному процессору, чтобы оно не скакало с одного на другой. Полный лог вывода к сожалению не помещается (видимо на Blogger имеется ограничение на размер поста), исходные тексты тестов можно найти в конце текста.

Для начала о сервере Mongrel: http://ru.wikipedia.org/wiki/Mongrel. Помимо написанного в википедии добавлю, что он практически полностью написан на ruby, за исключением парсера http запросов (эта часть написана на C). Как уже указано в википедии, до недавнего времени достаточно нагруженный проект Twitter использовал Mongrel. Вот из статейки об архитектуре Twitter http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster:

Mongrel - hybrid Ruby/C HTTP server designed to be small, fast, and secure

На тот момент twitter использовали примерно 350 000 пользователей, уже кучу серверов, и Mongrel справлялся со своей задачей. Надо отметить, что во время второго теста с 100 клиентов, время от времени ab жаловался на "apr_socket_recv: Connection timed out (110)", что не очень хорошо. Вот, на что он способен (напоминаю, что смотреть нужно значение "Requests per second"):


Concurrency Level:      1
Time taken for tests:   36.468 seconds
Requests per second:    2742.11 [#/sec] (mean)
Time per request:       0.365 [ms] (mean)
Time per request:       0.365 [ms] (mean, across all concurrent requests)
Transfer rate:          353.47 [Kbytes/sec] received


Concurrency Level:      100
Time taken for tests:   26.562 seconds
Requests per second:    3764.78 [#/sec] (mean)
Time per request:       26.562 [ms] (mean)
Time per request:       0.266 [ms] (mean, across all concurrent requests)
Transfer rate:          485.30 [Kbytes/sec] received

Теперь посмотрим на Thin. Он использует EventMachine, который частично написан на C++. Соответственно используется асинхронная обработка запросов. Парсер запросов также написан на C. Каких-либо историй успехов найти не смог (вероятно плохо искал). Вот его результаты:


Concurrency Level:      1
Time taken for tests:   34.807 seconds
Requests per second:    2872.98 [#/sec] (mean)
Time per request:       0.348 [ms] (mean)
Time per request:       0.348 [ms] (mean, across all concurrent requests)
Transfer rate:          412.43 [Kbytes/sec] received


Concurrency Level:      100
Time taken for tests:   16.325 seconds
Requests per second:    6125.52 [#/sec] (mean)
Time per request:       16.325 [ms] (mean)
Time per request:       0.163 [ms] (mean, across all concurrent requests)
Transfer rate:          879.35 [Kbytes/sec] received

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

Теперь перейдем к python. Честно говоря, я и с этим языком практически не дружу. Поэтому даже не знаю, кто в стане python является самым быстрым. Наиболее часто я слышу про Tornado и Twisted. Для начала о Twisted. Большей частью написан на python, но местами, разумеется, на C. Является не сервером приложений, а событийно-ориентированным фреймворком для разработки серверов. Т.е. то, чем является EventMachine для ruby. Сразу замечу, что результаты не впечатляют. Возможно потому, что парсер запросов не написан на C :-) Во время тестирования ошибка "apr_socket_recv: Connection refused (111)" выскакивала при отсутствии параллельных запросов.


Concurrency Level:      1
Time taken for tests:   70.951 seconds
Requests per second:    1409.43 [#/sec] (mean)
Time per request:       0.710 [ms] (mean)
Time per request:       0.710 [ms] (mean, across all concurrent requests)
Transfer rate:          202.33 [Kbytes/sec] received


Concurrency Level:      100
Time taken for tests:   31.263 seconds
Requests per second:    3198.64 [#/sec] (mean)
Time per request:       31.263 [ms] (mean)
Time per request:       0.313 [ms] (mean, across all concurrent requests)
Transfer rate:          459.18 [Kbytes/sec] received

Теперь Tornado. Был создан в компании Friendfeed и предоставлен на суд общественности после приобретения последней компанией Facebook. Они написали Tornado как раз потому, что Twisted имеет некоторые проблемы с быстродействием, источник: http://bret.appspot.com/entry/tornado-web-server. Судя по результатам, у них это получилось.


Concurrency Level:      1
Time taken for tests:   50.786 seconds
Requests per second:    1969.03 [#/sec] (mean)
Time per request:       0.508 [ms] (mean)
Time per request:       0.508 [ms] (mean, across all concurrent requests)
Transfer rate:          334.58 [Kbytes/sec] received


Concurrency Level:      100
Time taken for tests:   19.708 seconds
Requests per second:    5074.07 [#/sec] (mean)
Time per request:       19.708 [ms] (mean)
Time per request:       0.197 [ms] (mean, across all concurrent requests)
Transfer rate:          862.20 [Kbytes/sec] received

Признаться, я приятно удивлен тем, что ruby сервера справляются лучше, чем python. Но возможно причина в том, что разбор запросов в случае ruby осуществляется на C. Я не ставил целью сравнивать между собой эти два прекрасных языка программирования. Моя цель в том, чтобы показать общую картину. Хотя для того, чтобы показать ее полностью, следовало сравнить фреймворки Ruby On Rails и Django. Там все будет значительно худе, в лучшем случае несколько сотен запросов в секунду. Вот презентация: http://www.scribd.com/doc/51076611/RubyConfUA-Ruby-on-Rails-1000-запросов-в-секунду-Макс-Лашин, где описывается ситуация, что для обработки 1000 запросов в секунду требуется 14 серверов. К сожалению нет деталей, сколько из этих серверов отданы для БД, а сколько для Ruby On Rails. Разумеется это уже не "Hello, world", и вероятно основная нагрузка будет идти на БД. Однако, если судить по архитектуре других проектов, серверов слишком много для такой нагрузки.

Мне кажется, что подобные языки не предназначены для разработки http серверов, где приходится обслуживать большое количество клиентов. Я пишу именно http серверов, а не http приложений. В любое приложение на C или C++ легко встраивается почти любой язык программирования. И явно такие сервера должны быть. Интересно, почему они не пользуются популярностью? Для сравнения, вот, на что способен nginx, работая одним воркером:


Concurrency Level:      1
Time taken for tests:   17.761 seconds
Requests per second:    5630.18 [#/sec] (mean)
Time per request:       0.178 [ms] (mean)
Time per request:       0.178 [ms] (mean, across all concurrent requests)
Transfer rate:          1264.59 [Kbytes/sec] received


Concurrency Level:      100
Time taken for tests:   3.889 seconds
Requests per second:    25715.85 [#/sec] (mean)
Time per request:       3.889 [ms] (mean)
Time per request:       0.039 [ms] (mean, across all concurrent requests)
Transfer rate:          5776.02 [Kbytes/sec] received

При этом у nginx задача чуть сложнее, я не стал писать к нему модуль, поэтому nginx отдает файл. Результаты для 100 клиентов впечатляют. Я несколько раз перепроверял, но ошибки нет. Хотя если вдуматься, что такое 100 000 раз открыть и отправить какой-то там файлик? Это займет пол секунды (специально проверил). Основной расход ресурсов уходит на коммуникацию. Раз уж перешел к отдаче файлов, в последнее время часто упоминается yaws, написанный на Erlang. Встретил даже вот такие восхищенные строки:

Yaws (Yet Another Web Server) - web сервер написанный на языке Erlang. На языке, который по праву считается крайне производительным. Тоже самое можно сказать и об самом web сервере: по сравнению с apache2, yaws - просто реактивный.
http://the-bosha.ru/2010/08/30/yaws-lyogkiy-web-server-na-erlang/

Ну и множество других восторженных отзывов. Пройти мимо просто нельзя. Ради этого даже поставил yaws из репозитария wheezy, чтобы тестировать последнюю версию. Вот, что я получил:


Server Software:        Yaws
Concurrency Level:      1
Time taken for tests:   33.808 seconds
Requests per second:    2957.89 [#/sec] (mean)
Time per request:       0.338 [ms] (mean)
Time per request:       0.338 [ms] (mean, across all concurrent requests)
Transfer rate:          652.82 [Kbytes/sec] received


Concurrency Level:      100
Time taken for tests:   24.427 seconds
Failed requests:        171
   (Connect: 0, Receive: 57, Length: 57, Exceptions: 57)
Write errors:           0
Total transferred:      22587118 bytes
HTML transferred:       1998860 bytes
Requests per second:    4093.88 [#/sec] (mean)
Time per request:       24.427 [ms] (mean)
Time per request:       0.244 [ms] (mean, across all concurrent requests)
Transfer rate:          903.02 [Kbytes/sec] received

В глаза бросается строка (Connect: 0, Receive: 57, Length: 57, Exceptions: 57). И сколько бы я не запускал ab, ошибки вылезают. Видимо 100 запросов на один сервер, многовато. На реактивный он явно не похож.

UPDATE

По совету Viacheslav Biriukov повторил тест на gunicorn для python. Разбираться, как он реализован, пока нет времени. Вот его результаты:


Concurrency Level:      1
Time taken for tests:   37.928 seconds
Requests per second:    2636.57 [#/sec] (mean)
Time per request:       0.379 [ms] (mean)
Time per request:       0.379 [ms] (mean, across all concurrent requests)
Transfer rate:          424.84 [Kbytes/sec] received


Concurrency Level:      100
Time taken for tests:   19.764 seconds
Requests per second:    5059.64 [#/sec] (mean)
Time per request:       19.764 [ms] (mean)
Time per request:       0.198 [ms] (mean, across all concurrent requests)
Transfer rate:          815.27 [Kbytes/sec] received

При отсутствии конкуренции он показал себя значительно лучше Tornado и Twisted.

Итоговый результат в виде картинки:

Ну а теперь исходные тексты.

Mongrel:


require 'mongrel'

class HelloHandler < Mongrel::HttpHandler
        def process(request, response)
                response.start(200) do |head,out|
                        head['content-type'] = 'text/html'
                        out << '<p>Hello World!</p>'
                end
        end
end

h = Mongrel::HttpServer.new("0.0.0.0", "3000")
h.register("/hello", HelloHandler.new)

Thin


require 'thin'

app = proc do |env|
# Response body has to respond to each and yield strings
# See Rack specs for more info: http://rack.rubyforge.org/doc/files/SPEC.html
body = ['<p><p>Hello World!</p>']

[
    200,                                        # Status code
    { 'Content-Type' => 'text/html' },          # Reponse headers
    body                                        # Body of the response
]
end

run app

Twisted


# -*- coding: utf-8 -*-
from twisted.web import server, resource
from twisted.internet import reactor

class Simple(resource.Resource):
    isLeaf = True
    def render_GET(self, request):
        return "<p>Hello world!</p>"

site = server.Site(Simple())
reactor.listenTCP(3000, site)
reactor.run()

Tornado


# -*- coding: utf-8 -*-
import tornado.httpserver
import tornado.ioloop
import tornado.web

class MainHandler(tornado.web.RequestHandler):
        def get(self):
                self.write("<p>Hello, world<p>")

if __name__ == "__main__":
        application = tornado.web.Application([
                (r"/hello", MainHandler),
        ])
        http_server = tornado.httpserver.HTTPServer(application)
        http_server.listen(3000)
        tornado.ioloop.IOLoop.instance().start()

gunicorn


# -*- coding: utf-8 -
from wsgiref.validate import validator

#@validator
def app(environ, start_response):
    """Simplest possible application object"""
    data = '<p>Hello, World</p>'
    status = '200 OK'
    response_headers = [
        ('Content-type','text/plain'),
        ('Content-Length', str(len(data)))
    ]
    start_response(status, response_headers)
    return iter([data])

Зависание при переключении раскладки

2011-03-23T02:39:00.000+03:00

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

Началось все с того, что коллега начал жаловаться, после моих изменений у него начала зависать программа при переключении раскладки. Зависание было иногда и не на долго. Потом появился еще один с такой же жалобой. Ни одна попытка воспроизвести не увенчалась успехом. Снятие дампа, трассировка, тоже не помогли. Через пол года этих "жалобщиков" стало еще больше и деваться стало некуда, пришлось разбираться. Порывшись в интернете я выяснил, что подобная проблема возникает в программах Miranda, Punto Switcher и других. И возникает она после установки Internet Explorer 7.0, который несет в себе так называемые "Дополнительные текстовые службы". После их установки зависание и начинается. А после отключения прекращается. Однако после отключения их любимый IE сам начинает вести себя не адекватно, или перестает переключать раскладку. В общем это не вариант. Еще один вариант исправления - это убрать индикатор раскладки. Но клиентам ни один из вариантов не подойдет.

Пришлось мне сделать очередной spanshot в виртуальной машине и ставить этот самый IE7. Spanshot разумеется для того, чтобы после исправления проблемы вернуть "любимый" IE6.

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

Code that directly or indirectly creates windows (for example, DDE and COM CoInitialize). If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. If you have a thread that uses Sleep with infinite delay, the system will deadlock.

Еще пару лет назад про окна ничего не было написано. Хотя может быть я смотрел устаревший MSDN...

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

ReadFile/WriteFile ERROR_INVALID_ARGUMENT

2011-03-19T00:49:00.000+03:00

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

Как это часто бывает, корректность записи и чтения никто не проверял. Вставив соответствующие проверки я увидел, что ни запись, ни чтение не осуществляются вообще. GetLastError стабильно возвращает код ошибки 87: ERROR_INVALID_ARGUMENT или "Параметр задан неверно". А все что прочиталось - жалкие остатки из буфера для записи. При том, что этот код точно работал и никто его не менял. И ограничение на размер буфера для функций ReadFile и WriteFile составляет 32 мегабайта.

После некоторых разбирательств выяснилось, что проблема проявляется только при записи на сетевой диск, точнее Shared Folder сделанные с помощью VirtualBox.

В общем, на Shared Folder, сделанный с помощью VirtualBox нельзя выполнять вызовы WinAPI ReadFile и WriteFile передавая буфер больше 16 мегабайт за раз.

Как написать свой http сервер

2011-03-06T08:27:00.000+03:00

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

Итак, я не буду вдаваться в совсем уж мелкие подробности вроде того, что такое сокеты, как работает tcp/ip и уж тем более спускаться на канальный уровень. И полностью описать протокол HTTP тоже не смогу, для этого есть соответствующие RFC: 1945 и 2616. Гугл подсказал переводы на русский язык: тут, тут (устаревшая версия) или вот тут. Переводы я не изучал, если они некорректные, извиняюсь. В примерах я указываю только часть заголовков. Если вам хочется рассмотреть их получше, поможет Webkit Inspector в браузере Google Chrome, или Firebug в браузере Firefox, или DragonFly бразуера Opera. Но лучше всего поставить сниффер и смотреть происходящее с его помощью. Описание даю для пользователей, которые уже более менее представляют, что такое HTTP и как оно работает. Другие вряд-ли сюда забредут и уж тем более соберутся писать http сервер :-)

Начнем сначала. Http клиент обращаясь к серверу посылает запрос вида:


    МЕТОД строка_запроса HTTP/Версия
    Поле-Запроса: значение
    Второе-Поле: значение
    ...

Методы бывают разные: GET, POST, HEAD, OPTIONS, PUT, DELETE... Я опишу только первые три. GET - это получение ресурса. Тут и далее я буду называть строку_запроса ресурсом, или запрашиваемым ресурсом. POST - отправка каких-либо данных на сервер. HEAD аналогичен GET за исключением того, что сервер в ответ на запрос отправляет только заголовок запроса, без данных. Версия может и отсутствовать, тогда считается, что она равна 0.9, и в этом случае в запросе есть только первая строка, а клиенту ответ идет без заголовка, только данные. Запрос завершается двойным переводом строки в символом возврата каретки ("\r\n\r\n") и после него идет тело запроса. В этом случае должно быть указано поле Content-Length, которое и сообщает длину тела. Для GET запроса естественно тела быть не может, зато оно будет в случае запроса методом POST или PUT.

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


    <form method="POST">
  <input type="text" name="value1" value="bla-bla" />
  <input type="hidden" name="value2" value="hidden-bla-bla" />
    </form>

Даст вот такое тело запроса:


value1=bla-bla&value2=hidden-bla-bla

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


    <form method="POST" enctype="multipart/form-data">
  <input type="text" name="value1" value="bla-bla" />
  <input type="hidden" name="value2" value="hidden-bla-bla" />
  <input name="attached_file" type="file" />
    </form>

Получим тело запроса:


--FormBoundary_35WYaqzQvblP0xW
Content-Disposition: form-data; name="value1"

bla-bla

--FormBoundary_35WYaqzQvblP0xW
Content-Disposition: form-data; name="value2"

hidden-bla-bla

--FormBoundary_35WYaqzQvblP0xW
Content-Disposition: form-data; name="attached_file"; filename="image.jpg"
Content-Type: image/jpeg

тут-содержимое-файла
--FormBoundary_35WYaqzQvblP0xWl--

Способ, которым следует разбирать тело передается в заголовке запроса от клиента, в поле Content-Type. В первом случае будет Content-Type: application/x-www-form-urlencoded, а во втором Content-Type: multipart/form-data; boundary=--FormBoundary_35WYaqzQvblP0xW. Разделителем для второго случае является указанный в Content-Type boundary и символ новой строки и также видно, что клиент передает тип содержимого.

Сервер тоже использует Content-Type для того, чтобы показать клиенту тип содержимого, которое он отдает. К примеру Content-Type: text/html; charset=utf-8. Если клиент - это браузер, то подобный ответ он будет разбирать как html файл. Если там будет image/png, браузер отобразит картинку. Если же там будет что-то, чего браузер отобразить не может, пользователь увидит диалог скачивания файла.

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


Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Charset:UTF-8,*;q=0.5
Accept-Encoding:gzip,deflate,sdch
Accept-Language:ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4

Тут браузер говорит, что ожидает в первую очередь XML, XHML или HTML файл, но согласен и на обычный текстовый файл, или даже картику, но и все остальное тоже примет. Дальше идет предпочитаемая кодировка. Это значение зависит от настроек браузера. Следущие поля - способы сжатия файла. Ответ может быть сжат указанным способом и клиент сможет его распаковать. Сжатие позволяет экономить трафик. Следующим идет язык. В моем браузере указано предпочитать русский язык, следом идет английской. Разделитель q= указывает на степень предпочтения. Если браузер клиента больше предпочитает en-US, то следует отдать ему файл на английском языке. Именно так некоторые сайты выдают контент на родном для пользователя языке.

А если запрос связан с тем, что браузер при разборе html файла встретил вот такое:


<link href="/css/main.css" rel="stylesheet" media="all" type="text/css" />

То его запрос будет содержать уже другой текст:


Accept:text/css,*/*;q=0.1
Accept-Charset:UTF-8,*;q=0.5
Accept-Encoding:gzip,deflate,sdch
Accept-Language:ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4

Т.е. браузер хотел бы получить css файл.

Запрашиваемый у http сервера ресурс должен начинаться с /путь/еще/файл. Разделителями пути выступают слеши, т.к. он всегда использовался как разделитель пути в системах unix. Если ресурс - это программа или скрипт, то ему могут быть переданы дополнительные аргументы. К примеру в вашеуказанной форме метод POST заменим на GET:


    <form method="GET">
  <input type="text" name="value1" value="bla-bla" />
  <input type="hidden" name="value2" value="hidden-bla-bla" />
    </form>

Теперь браузер не может передать параметры в теле запроса. Поэтому он передает их в URL. И запрашиваемый ресурс будет таким:


/path/file?value1=bla-bla&value2=hidden-bla-bla

Аргументы идут после символа ? и также разделяются символом &. Если требуется передать символ ? или & в качестве значения, а также некоторые другие символы, их необходимо заменять на код символа, добавляя символ процента %. Разумеется такой метод запросов можно использовать не только для передачи форм, но и для вызова обработчика на сервере с определенными аргументами. В случае, если ресурс указывает на обычный файл, а не какой-то специализированный обработчик, дополнительные аргументы игнорируются.

Обработчики, принимающие эти аргументы, чаще всего бывают написаны на скриптовых языках. К примеру на perl, php, python или ruby. Хотя там может скрываться программа на любом языке, главное, чтобы сервер мог ее запустить. Стандартный метод запуска - это CGI - Common Gateway Interface. На каждый запрос запускается новый экземпляр программы. Все данные, необходимые CGI программе, передаются через окружение. Т.к. программы старательно жирнеют и толстеют, сейчас запускать программу на каждый запрос является расточительством. Поэтому появился FastCGI, а за ним и SCGI. При использовании последних программа запускается один раз и обрабатывает запросы по мере их поступления крутясь в цикле. Такие программы могут быть быть расположены на любой другой машине в сети, как правило обращение к ним идет по tcp/ip или unix сокетам и запускаются они в нескольких экземплярах. Еще есть возможность использовать мультиплексирование - параллельную обработку нескольких запросов через одно соединение, но к сожалению до сих пор не все хорошо с поддержкой этого мультиплексирования. Ну может быть оно не так уж и нужно, когда можно заранее рассчитать необходимое количество экземпляров и запустить их.

В последнее время частенько используются http сервера, сами написанные на этих скриптовых языках. В таких случаях http сервер, выставленный наружу (front-end) только проксирует запросы серверу приложений (back-end) и раздает статические файлы. Доверять раздачу статических файлов серверам на скриптовых языках рановато :-)

Так как установка TCP/IP соединения занимает достаточно длительное время, т.к. клиенту и серверу необходимо обменяться различными пакетами, придумали возможность поддерживать соединение, это называется keep-alive. Т.е. без keep-alive на каждый запрос создается новое соединение. Если используется Keep-alive, соединение не обрывается, а через него может пойти следующий запрос. Версия HTTP 1.1 всегда использует Keep-Alive, а для версии 1.0 используется поле запроса Keep-Alive. Но можно указать серверу, что соединение можно закрывать, для этого в запрос вставляется поле "Connection: close".

В последние годы набирает популярность так называемый Ajax - асинхронный Javascript. Это когда запрос отсылает не пользователь, а скрипт на странице. Допустим, возможно обращение к ресурсу /data. Если туда обратится пользователь, то ему следует выдать html страницу с запрашиваемыми данными. А если же Javascript, то предпочтительней XML или JSON код. В этом случае к запросу со стороны клиента следует добавлять поле X-Requested-With: XMLHttpRequest. Популярные фреймворки вроде jQuery делают это сами. Обработчик запроса смотрит содержимое этого поля и решает, что отдавать.

Еще одна важная вещь - это кеширование. Вообще по этой теме следует писать отдельную статью. Я опишу только кратко. Кеширование предназначено для того, чтобы снизить нагрузку на сервер - избавить от лишних запросов или хотя-бы уменьшить объем передаваемого трафика. Когда сервер отвечает клиенту, он может передать поле Last-Modified с указанием даты последней модификации. Тогда в следующий раз клиент пришлет запрос с полем If-Modified-Since. Сервер должен проверить, не изменился ли запрашиваемый ресурс. Если изменился, то если даже метод запроса GET, сервер не пересылает данные, а отправляет только заголовок а код ответа устанавливает в 304 (Not Modified). Дата модификации подходит не всегда, поэтому имеется еще один способ проверки на модифицированность ресусра: передача сервером специального значения и поле ETag, или даже нескольких значений. Эта возможность появилась начиная с версии 1.1. В этом случае клиент добавляет в запрос поле If-None-Match, в котором указывает ранее полученные значения. Чаще всего эти значения являются хешем содержимого. В случае отсутствия изменений клиенту также передается код ответа 304. Еще имеются поля Pragma, Cache-Control, Expires и т.д., но для начала хватит и описанного мной :-)

Надо добавить, что с кешированием связаны две крайности: всячески противостоять кешированию или наоборот, кешировать все, что только можно. Истина, как всегда, где-то по середине. Кеширование, и не только в отношении http серверов, очень помогает. Но иногда оно лишнее и приведет к проблемам.

Достаточно важную роль играет поле Host, появившееся в HTTP 1.1. Туда клиент записывает адрес сервера, к которому он обращается. Т.е. если идет обращение по адресу http://www.google.com, то в запросе имеется строка Host: www.google.com. Именно благодаря этому полю работают так называемые "виртуальные сервера", когда на одном физическом с одним ip адресом расположено множество серверов с различными именам. Сервер принимая запрос анализирует содержимое поля и использует ту или иную конфигурацию. И также благодаря наличию этого поля работает так называемое прозрачное кеширование: когда все запросы со стороны клиента принудительно перенаправляются на прокси сервер, который работает в прозрачном режиме (transparent), там обрабатываются (контроль доступа или кеширование) и только потом куда-то уходят. И не факт что уходят они туда, откуда их запросил клиент. К примеру у меня прокси сервер режет рекламу и блокирует часть сайтов, а запросы на статьи в СМИ по возможности преобразует в ссылки на "версию для печати".

При взаимодействии пользователя и web сервера иногда нужно сохранять какие-либо данные пользователя. Например корзину товаров для интернет магазина. Или идентификатор пользователя в рекламной сети. Однажды я спросил у яндекса, как правильно готовить гречневую кашу, так потом меня не меньше месяца преследовал яндекс директ предлагая различные рецепты. Для этого предназначены Cookie. Однажды сервер выдает клиенту в заголовке Set-Cookie: name=value; и при каждом следующем обращении клиент будет вставлять поле Cookie: name=value. Именно поэтому следует выносить статические файлы на отдельное доменное имя, куда клиент не будет отправлять Cookie. Ведь лишние символы - это лишний трафик. Еще у Cookie имеется путь, к которому они привязаны, имя домена и дата, до которой они действительны. Также бывают "безопасные" Cookie, которые пересылаются серверу только в случае использования https соединения. На использование cookie накладывается ряд ограничений по количеству на домен и по размеру. Поэтому хранить в них что-то серьезное не получится, и обычно довольствуются идентификатором сессии: уникальный набор байт, которые выступают ключем к данным сессии. Сами данные сессии могут храниться в файлах, в базе данных или в memcached. Лет 10 назад еще не задумывались о красоте URL и частенько передавать идентификатор сессии прямо в URL, т.е. примерно так: http://www.example.com/file.php?sid=0D6441FEA4496C2, и все ссылки в этом файле также включали sid=0D6441FEA4496C2. Ужасно некрасиво.

На последок немного расскажу о современных http серверах. Среди используемых наиболее популярны: Apache, Miscrosoft IIS, nginx и lighttpd. Про IIS я не могу ничего сказать, т.к. никогда не сталкивался. Apache долгое время удерживает первое место по популярности. Не смотря на рост nginx и lighttpd, очень часто за ними скрывается все тот же apache. Между apache и nginx или lighttpd существует существенное архитектурное отличие. Первый обслуживает клиентов создавая дочерние потоки (начиная с версии 2) или процессы. Процессы очень удобны если физический сервер используется различными клиентами. В unix каждый процесс обладает своим набором прав и привилегий. И для каждого клиента http сервер запускается с привилегиями этого самого клиента. А значит, клиент не имеет права доступа к файлам другого клиента, который также имеет файлы на этом же сервере. Но к сожалению эта архитектура связана с накладными расходами, поэтому растет популярность альтернативной архитектуры, которой обладают nginx и lighttpd. Они не запускают дочерних потоков или процессов для каждого клиента, а используют асинхронную обработку запросов. Кажется, Алан Кокс (один из основных разработчиков ядра Linux) сказал, что "потоки нужны только тем, кто не умеет программировать конечные автоматы". Операционной системе действительно не очень то удобно переключаться туда-сюда между потоками и процессами, на это тратится драгоценное время. Если в системе сотни процессов/потоков, то ничего страшного, но если их десятки тысяч? Тогда значительно больше ресурсов (CPU и RAM) уйдет на обслуживание этих процессов и потоков, если сервер вообще справится с такой нагрузкой. Асинхронная архитектура позволяет полностью нагрузить процессор только полезной работой. Делается это примерно так: создается один процесс, который принимает запрос от клиента. Или от 10 000 клиентов. Процесс самостоятельно не опрашивает состояние этих клиентов (есть у них данные или нет), а передает список сокетов операционной системе. И как только от клиента придут какие-то данные, система будит процесс и сообщает, какой именно сокет следует читать. Когда http сервер прочитал часть данных и, к примеру, ему нужно прочитать и отдать клиенту большой файл, он выполняет асинхронную фукнцию чтения, запрашивая небольшой кусок из этого файла. Не секрет, что чтение с диска достаточно медленная операция. А у нас в очереди еще есть клиенты, которых можно обслужить, пока выполняется чтение с диска. Поэтому http сервер снова запускает цикл обработки сообщений, продолжая обслуживать клиентов. Как только кусок из файла будет прочитан, http сервер начнет его отправлять. Отправка клиенту, особенно если тот использует медленное соединение, тоже может занять время. Поэтому пока кусок данных уходит, можно успеть обслужить других клиентов. После отправки первого куска файла будет отправлен следующий, за ним другой и т.д. И все это реализуется как конечный автомат (FSM - Finite State Machine). Для реализации подобной архитектуры следует прочитать о epoll на Linux, kqueue на FreeBSD и о портах завершения (IO Completion Ports) на Windows. Но значительно проще воспользоваться библиотекой libev, libevent или Boost.Asio.

Прикладываю пример простенького и совершенно не полноценного HTTP сервера написанного на C++ с использованием Qt: http://nekipelov.net/blog/example-httpd.tar.gz. Но файлы он отдавать способен и выглядит вроде бы не сложно. Изначально он вообще не был предназначен для раздачи файлов. Также я убрал всю оптимизацию, которая усложняла код. К сожалению из-за этого код немного изуродовался (и нет времени наводить красоту, а тем более делать из него более полноценный сервер), ну и мог где-нибудь мог допустить ошибку, и скорее всего не одну. Если вы наткнетесь на такое, пожалуйста сообщите мне комментарием к статье или лично alex@nekipelov.net. Собирается примерно так: qmake && make. Мог бы выложить и пример с использованием Asio, но лучше уж взять официальный вот от сюда.

"Пример" ожидает запросы на 3000 порту, соответственно в браузере следует открывать http://127.0.0.1:3000. Раздает файлы из текущего каталога. Порт можно изменить в файле main.cpp. Процесс работы там простой: ожидаем строку запроса и разбираем ее. Когда принят весь заголовок, вызываем ProcessReqeust::processRequest() который и обрабатывает http запрос. Я перевел комментарии на русский, кодировка UTF-8. Тем, что все читает на английском моя статья вряд-ли не пригодится :-)

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

Парсинг html файлов

2011-03-02T23:43:00.001+03:00

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

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

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

К примеру выбор всех изображений, являющихся ссылками с помощью CSS селекторов: "a > img", с помощью XPath - "//a/img".

При этом нормальные библиотеки, к примеру libxml позволяют работать и с невалидным html файлом. Обертки над libxml есть для большинства языков, например nokogiri для ruby или lxml для python.

Замечу, что отличие CSS селекторов от XPath в большей краткости первого способа, но большей производительности второго.

Альтернатива ассоциативным контейнерам в C++

2011-02-27T14:18:00.001+03:00

Сегодня наткнулся на статейку http://habrahabr.ru/blogs/cpp/114518/. Совет рассмотреть альтернативы ассоциативным контейнерам конечно хороший. Вот только тестирование производительности совершенно неправильное.

Судя по результатам, в vector вставка осуществлялась без предварительного вызова reserve. Следовательно много времени ушло на перевыделение памяти. Вызывать reserve следует всегда, хотя-бы для ориентировочного количества элементов.

А вставка в map выполнялась с помощью перегруженного operator[]. Это очень плохо потому, что каждый вызов operator[] сначала выполняет поиск и только потом вставку. Поэтому вставлять большое количество элементов следует с помощью метода insert. Разумеется в этом случае вставляемые данные должны быть предварительно отсортированы.

От себя дам другой совет: используйте контейнеры ориентируясь на их слабые и сильные стороны. Например вставка без предварительного выделения памяти очень быстро выполняется в deque. С предварительным выделением и в vector. А если требуется вставить множество элементов в ассоциативный контейнер, в случаях, когда последовательность этих элементов идет в случайном порядке, следует сначала вставить их в vector или deque, отсортировать и только потом вставлять в ассоциативный контейнер с помощью метода insert.

std::locale в gcc

2011-02-19T06:47:00.002+03:00

Завершил доработку для приложения и пошел обновлять его на сервере. Но там оно не заработало, выдавая исключение locale::facet::_S_create_c_locale name not valid. При том, что локаль ru_RU.UTF-8 вообще-то имеется в системе и все должно быть нормально.

А как раз перед этим я собирал новый gcc (мне понадобились кое-какие фичи из C++0x). Быстренько глянул в google, ответа не нашел. Пришлось лезть в исходники libstdc++, где я обнаружил два различных места установки локали, причем в одном из них принимается только локаль "C" и ничего больше. Последнее называлось generic, а мне нужна была фукнциональность из gnu.

Полез в скрипты и логи configure, и выяснил, что оно пытается установить локаль de_DE и если этого не получилось, выбирает generic, т.е. просто не использует локали! Ну а я не люблю, когда в системе что-то лишнее. Естественно, что я не стал ставить de_DE. Пришлось уж ее поставить (dpkg-reconfigure locales && locale-gen) и только после этого все собралось как надо.

Враг производительности - фрагментация

2010-02-04T14:01:00.002+03:00

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

Решил отвлечься, и тут меня осенило: да это же фрагментация! Из-за того, что файлы базы данных были сильно фрагментированы, скорость чтения упала в 20 раз. Аж стыдно признаваться, что я сразу это не понял. Но у меня есть оправдание: к моменту разбирательств мой рабочий день длился уже 14 часов.

Выявление места исключения по адресу инструкции

2009-07-17T07:22:00.009+04:00

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

Разберем пример с ошибкой:


class Foo {
 public:
  Foo() : i(0) {}

  int bar() const {
    return i;
  } 
 private:
  int i;
};

int main(int, char **)
{
 Foo *foo = 0;
 foo->bar();
 
 return 0;
}

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

Теперь нам нужен map файл для модуля, в котором произошла ошибка (аргумент /Fm компилятора Visual C++). Вот кусок из map файла для данной программы:


  Address         Publics by Value              Rva+Base     Lib:Object

 0001:00000000       _main                      00401000 f   crush.obj
 0001:00000020       ?bar@Foo@@QBEHXZ           00401020 f i crush.obj
 0001:00000030       _mainCRTStartup            00401030 f   LIBC:crt0.obj
 0001:0000010f       __amsg_exit                0040110f f   LIBC:crt0.obj
 0001:00000158       __cinit                    00401158 f   LIBC:crt0dat.obj
 0001:00000185       _exit                      00401185 f   LIBC:crt0dat.obj

Нас интересует колонка Rva+Base. Это адреса фукнций, по которым они расположены в памяти. А в сообщении об ошибке мы имеем адрес инструкции. В нашем случае он 0x0040102a. Найдя в таблице ближайший адрес меньше нашего, мы узнаем фукцнию и объектный файл, ответственные за это безобразие. Нам подходит адрес 00401020, следовательно это функция ?bar@Foo@@QBEHXZ в объектном файле crush.obj. Разумеется имя фукцнии декорировано. Разница между адресом фукнции и адресом исключение - будет локальное смешение внутри фукнции. Чтобы понять, что находится по смещению 0x0a (0x0040102a-00401020) нужен файл листинга (аргумент /FAsc компилятора Visual C++, результат в виде файла с расширением cod). Этот файл содержит C++ код, ассемблрные команды, в которые он был преобразован и машинный код.

Вот как выглядит результат для нашего метода Foo::bar()


; COMDAT ?bar@Foo@@QBEHXZ
_TEXT SEGMENT
_this$ = -4
?bar@Foo@@QBEHXZ PROC NEAR    ; Foo::bar, COMDAT

; 5    :   int bar() const {

  00000 55   push  ebp
  00001 8b ec   mov  ebp, esp
  00003 51   push  ecx
  00004 89 4d fc  mov  DWORD PTR _this$[ebp], ecx

; 6    :     return i;

  00007 8b 45 fc  mov  eax, DWORD PTR _this$[ebp]
  0000a 8b 00   mov  eax, DWORD PTR [eax]

; 7    :   } 

  0000c 8b e5   mov  esp, ebp
  0000e 5d   pop  ebp
  0000f c3   ret  0
?bar@Foo@@QBEHXZ ENDP     ; Foo::bar
_TEXT ENDS
END

Чтобы не осталось вопросов, разберем детальнее. Код начинается со строки:


; 5    :   int bar() const {

; 5 - это номер строки в исходном файле. Дальше идет текст из исходного файла.


  00000 55   push  ebp
  00001 8b ec   mov  ebp, esp

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

По искомому адресу 0x0a находится следующий код:


; 6    :     return i;

  00007 8b 45 fc  mov  eax, DWORD PTR _this$[ebp]
  0000a 8b 00   mov  eax, DWORD PTR [eax]

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

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

Я описал работу только с компилятором Visual C++, но описанная методика подходит и для других популярных компиляторов для ОС Windows. В Linux/unix, как правило, к таким ухищрениям прибегать не приходится.

Еще одна маленькая БД: Embedded InnoDB

2009-04-22T03:46:00.005+04:00

Сегодня OpenNet обрадовал новыми новостями. Наконец-то вышел релиз GCC 4.4.0, новая версия MySQL... и очередная встраиваемая БД. Вот текст новости:

Компания Oracle выпустила под лицензией GPLv2 вариант транзакционного хранилища данных Embedded InnoDB, предназначенного для использования независимо от MySQL, путем прямого встраивания движка в пользовательское приложение.

Доступ к данным производится через низкоуровневый набор функций, в корне отличающийся по синтаксису от SQL и больше напоминающий ISAM-подобный API. При этом поддерживаются операции работы с курсором, управление транзакциями и возможность использования индексов. Размер присоединяемой к приложению библиотеки составляет 838 Кб, поддерживаются языки C и C++. С точки зрения поддержки одновременного доступа к базе, допускается использование библиотеки в многопоточных программах и жестко конкурирующих процессах. Подключение базы организуется примерно тем же способом, что и BerkeleyDB.

Некоторые из заявленных возможностей Embedded InnoDB:

Встроенные средства для восстановления целостности базы после краха;

Возможность хранения данных в сжатом виде;

Высокая производительность и масштабируемость;

Мультиверсионный механизм обработки одновременных запросов с поддержкой блокировки на уровне строк;

Автоматическое выявление взаимных блокировок (deadlock);

Возможности кластеризации и подключения вторичных B-tree индексов;

Автоматическая буферизация добавляемых в базу данных.

Источник: http://www.opennet.ru/opennews/art.shtml?num=21377

Совсем недавно я писал о Berkeley DB (http://alex-nekipelov.blogspot.com/2009/03/berkeley-db.html.) Похоже, что в полку прибыло. На фоне засилья больших и медленных RDBMS, это очень радует.

Совпадение, что InnoDB, как и Berkeley DB, используется в качестве движка в MySQL. Учитывая последнюю новость о покупке Sun компанией Oracle (http://www.sun.com/third-party/global/oracle/index.jsp), наверное стоит ждать еще и Embedded MyIASM? :-)

Параллельные вычисления

2009-03-26T03:45:00.005+03:00

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

К сожалению для программистов это означает очередные сложности. Одно дело распараллелить большую задачу по обработке данных, которую можно разбить на независимые блоки. Или сервер, обслуживающий множество запросов... И совсем другое, распраллеливать каждодневные операции. Язык C++, в отличии от функциональных языков программирования, мало предназначен для распараллеливания. Однако в этом направлении намечаются улучшения. Начиная с версии 4.2 в компилятор GCC включена поддержка OpenMP. Также она имеется и в других современных компиляторах (от Microsoft, Sun, Intel). В грядущей версии GCC 4.4 обещают автоматическое распараллеливание циклов. Эта новость меня очень обрадовала. Это означает, что всю кучу уже написанного в Linux кода, который вряд-ли кто-либо соберется переписывать с учетом многоядерности, можно будет чуть-чуть ускорить.

И еще, меня обрадовал случайно обнаруженный каталог /usr/include/c++/4.3/parallel. Я только недавно установил последнюю версию gcc и даже не ожидал увидеть там такое, почему-то пропустил release notes (слишком много дел, даже не успеваю следить за нужными новостями). Там содержатся основные алгоритмы STL, использующие многопоточность на основе OpenMP: http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html. Может быть скоро я перестану поглядывать на TBB (http://www.threadingbuildingblocks.org/).

Заметка о маленькой БД, с большими возможностями: Berkeley DB

2009-03-26T02:28:00.007+03:00

Недавно передо мной встала задача получить быстрый доступ по 4-х байтовому ключу к данным, размер которых 8 байт. Всегда такая задача решается элементарно через std::map, или что-нибудь подобное hash_map... но на этот раз количество элементов превышает 150 млн. При этом нужно уместиться в адресное пространство на Windows (2 гагабайта), и очень хотелось бы оставить еще немного памяти для работы. Потенциально размер ключа может быть увеличен до 8-и байт, а количество элементов растет с каждым днем. Разумеется в оперативной памяти такой объем не уместить.

Обдумывая решение для сложившейся ситуации вспомнил про такую хорошую штуку, как dbm. Задачи, подобные моей (т.е. хранение большого количества данных с доступом по ключу) возникают у многих, если не у всех. И когда-то давным давно, когда программы еще были маленькими, а компьютеры большими... Кен Томпсон (да-да, тот самый, создатель unix и языка C) придумал и реализовал стандартный интерфейс Database Manager для доступа к данным по ключу. Подробнее о dbm написано тут: http://en.wikipedia.org/wiki/dbm. Программисты, переписывающие проприетарный unix для проектов BSD и GNU реализовали аналоги: Berkeley DB (далее BDB) и GNU Dbm. Конечно же есть и множество других клонов... но они не относятся к делу. Так вот, GNU Dbm как то так и остался на том же уровне, а вот создатели BDB развивали и совершенствовали свое детище. Кстати, интересный факт: одним из создателей является программист - женщина :-)

С тех пор прошло много времени, проект BDB немного подрос... сейчас скомпилированная версия 4.26 занимает 1 мегабайт. По нынешним меркам, совсем крошечная программа. Но нужно смотреть на ее возможности:

Примерно 200 000 000 (200 млн) пользователей этой БД, по данным компании Oracle.

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

Поддержка баз данных объемом до 256 ТБ.

Кроссплатформенность (большинство unix, Windows, в том числе и мобильная CE, некоторые Real-Time OS).

Наличие интерфейсов для множества языков (C, C++, java, ruby, perl, python, tcl...)

Полноценная поддержка ACID транзакций.

4 режима организации данных (B-Tree, Hash, Queue, RecNo).

Высокая скорость (примерно 1 млн операций чтения или 0,5 млн
операций записи в секунду на обычных десктопных компьютерах).
Разумеется это в случае не использования транзакций.

Лицензия на любой вкус: свободная или комерческая

Ну как, впечатляет? А ведь это еще не все...

Разработкой BDB занималась компания Sleepycat Software, которая была приобретена компанией Oracle в 2006 году. Официальный сайт BDB тут: http://www.oracle.com/technology/products/berkeley-db/index.html

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

программы, без которых я не могу обойтись

2008-06-09T02:52:00.000+04:00

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

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

Firefox в качестве браузера. Когда-то давно мне очень нравится браузер Netscape 4. Главное, что он был быстрым и удобным. Потом появилась Mozilla и Netscape 6, чуть позже Firefox и большое количество других, использующих движок Gecko. Но у всех была одна проблема: очень медленная скорость работы. Но мир www очень активно развивался, поэтому постепенно мне пришлось отказаться от использования Netscape в пользу Opera. Но, к сожалению, по некоторым причинам, в прошлом году я решил отказаться от Opera в пользу Firefox. В качестве бонуса я получил полноценное и удобное средство разработки и отладки web разработок с плагинами Firebug и Web Developer.

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

Midnight Commander в Linux или Far Manager в Windows. Уж как-то исторически сложилось, что я привык к файловым менеджерам в стиле Norton Commander и не могу комфортно себя чувствовать в пустой консоли или чем-нибудь в стиле проводника. Возможно это потому, что в домашнем каталоге уже меня всегда бардак, приходится туда-сюда перетаскивать, разбирать, лазить по архивам... :-)

GNU GCC - в качестве компилятора C и C++. C++ является для меня основным языком разработки. Иногда использую icc или msvc, но g++ является эталонным компилятором.

MPlayer для проигрывания как аудио, так и видео. Это самый быстрый и удобный проигрыватель. У него нет GUI (при желании frond-end`ов конечно предостаточно), большой набор кодеков, управление с клавиатуры.

VirtualBox и VMWare для создания виртуального окружения.

MySQL и PostgreSQL в качестве серверов баз данных. Мне нравятся обе программы, а выбор происходит в зависимости от положения звезд на небе. Надеюсь, мое руководство не доберется до этого блога и не спросит, почему это я не выбираю БД, разработкой которой я занимаюсь :-)

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

Венгерская нотация - это зло

2008-04-23T13:08:00.000+04:00

Сегодня продолжал портирование ядра нашей ERP системы на Qt. На очереди была библиотека графического интерфейса. Из-за отсутствия многих стандартных GUI компонентов нагородили своих, усиленно используя библиотеку MFC от Microsoft. Я не являюсь ненавистником продукции Miscrosoft, но поделка под названием Microsoft Foundation Class Library пожалуй одна из ужаснейших, что я встречал. Особенно ужасает дизайн классов и использование венгерской нотации. Разбираясь в дебрях этих совершенно не понятных и неадекватных имен типов и переменных у меня вырабатывается ужасное отвращение к ней. Помнится, она была принята во времена, "когда компьютеры были большими, а программы маленькими". В те времена не было такой простой навигации по исходным текста. Но те времена прошли давным давно. Сейчас можно нажать элементарную комбинацию клавиш и увидеть тип переменной.

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

Программисты забывают дать осмысленное имя переменной. И приходится лицезреть что-нибудь вроде LPCWSTR lpcwstrStr.

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

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

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

Размышления о современном ПО

2008-04-04T00:52:00.001+04:00

Я тесно общаюсь с компьютерными программами еще со времен DOS`а. Как говорят, Когда компьютеры были большими, а программы маленькими. И ведь так и было. Программа должна была помещаться на дискету размером 5,25" и объемом 360 кб (и то при условии, что эта дискета двойной плотности, иначе ее объем был 110 кб). Точнее на этой дискете еще должно было остаться место для операционной системы, файлового менеджера и рабочих файлов.

С тех пор прошло много лет. Теперь просто программа выводящая "Hello World" будет занимать около 5 кб. И это в том случае, если она динамически связана с run-time библиотекой. Иначе, файлик скомпилированный g++ версии 4.1.3, весит больше 600 кб! Рассказ о том, что содержит такая программа - это отдельная история, и скорее всего уже неоднократно описанная. Для сравнения, в DOS такое занимало бы менее 20 байт. Не потому, что тогда не было run-time части, а потому, что программисты предпочитали assembler :-)

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

Но даже медленную скорость можно стерпеть. Зато у нас есть новые возможности. Вот со стабильностью программ точно беда. И учитывая, что точно такие же программы работают в других железках, вроде плеера, мобильного телефона, маршрутизаторов, видео проигрывателей и т.д., то с ними возникают те же самые проблемы. На рынок выходят устройства, которые еще полностью не протестированы, и содержат ошибки. Например мой mp3 плеер при проигрывании песен иногда зацикливается на нескольких каталогах. Ждешь, что он будет играть все песни по порядку, а эта пакость какой-то один каталог все играет и играет до тех пор, пока не поймешь, что эту песню ты уже слышал много раз. Прошивка мобильника также содержит ошибки, которые были мной замечены в первые же дни использования. На днях в аэропорте Хитроу из-за ошибок в программах открытие 5-го терминала прошло с позором. Широкое распространение получают методы разработки программ, позволяющие выпускать продукты быстро, часто, но при этом с ошибками. Несколько лет назад мне понравилась программа виртуализации VirtualBox. Но сколько я не пытался ее использовать (последний раз это было несколько месяцев назад на версии 1.5.6), она не выдерживает и суток при интесивной работе (конечно не ручной, а в качестве тестового стенда), обязательно падает. Приходится использовать более медленные, но более стабильные продукты VMWare. Некоторое время назад я писал об Eclipse, который тоже содержит большое количество ошибок. Получается, что покупая, мы приобретаем недоделанные и способные выполнять свои функции продукты. Очень жаль, что законом не предусмотрены штрафы и компенсации за такое свинство. Именно поэтому я предпочитаю ПО с открытыми исходными текстами. Ошибок также предостаточно, но чаще всего их можно исправить. С закрытым ПО это не получится.

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

Или может быть, воспоминания о том, как когда-то все было хорошо и красочно, просто признак старения? :-)

Оптимизация доступности сайта

2008-04-02T11:33:00.000+04:00

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

Я относительно недавно начал работу над небольшим web проектом с перспективой стать большим. Пока в качестве хостинга используется домашний сервер вот такой конфигурации: процессор Celeron 2,4 Ghz, 4 жестких диска по 500 Гб объединенные в RAID, 512 RAM. До этого момента сервер не испытывал больших нагрузок, поэтому такая конфигурация более чем устраивала. Начал задумываться о том, как оптимальней использовать доступные ресурсы и накопал в сети достаточно интересные статьи и решил поделиться ссылками.

http://webo.in/articles/clientside2007/common-pages-optimization/
Оптимизация часто показываемых страниц. Александр Моисеев

Довольно интересные советы по оптимизации очень часто показываемых страниц.

http://webo.in/articles/habrahabr/03-presentation-layer-performance-tuning/

Перевод очень хорошей статьи "Оптимизируем загрузку веб-страницы". К своему стыду должен признать, что только из этой статьи я впервые узнал о CDN (Content Delivery Networks).

http://webo.in/articles/habrahabr/08-all-about-css-sprites/
CSS Sprites: все, что вы знали, но боялись спросить.

И похожая по смыслу CSS Sprites и их использование

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

На сайте http://webo.in/ имеется еще большое количество полезных статей, которые я возможно пропустил.

Очень полезны правила, выработанные в yahoo: Best Practices for Speeding Up Your Web Site

Также полезно прочитать статьи об архитектуре высоконагруженных порталов. Или посмотреть доклады с конференции HighLoad2007.

1-ое апреля

2008-04-01T12:56:00.000+04:00

Сегодняшний мой день прошел как и все остальные. Проснулся, на работу, с работы домой. И только вечером, читая новости я начал подозревать, что что-то тут не то. Новости какие-то странные. И вот добравшись до новости о том, что разработчикам ядра Linux придется откатываться на 1,5 года назад я понял, в чем причина. Сегодня же первое апреля! И вот так у меня каждый год :-)

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

Традиционно больше всех шутит www.securitylab.ru

Ошибка в Linux чуть не привела к гибели всего человечества

Чем могло обернуться возникновение миниатюрной черной дыры у такого насыщенного материей объекта, как планета Земля, нетрудно представить – поглощение материи растущей черной дырой было бы спонтанным, наша планета могла исчезнуть менее чем за две минуты.

Алексей Лукацкий будет отвечать за вживление чипов в мозг россиян

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

...

По словам Алексея, если эксперимент будет признан успешным, то уже в следующем году можно ожидать массовую “чиповку мозгов” всем жителям России. Экспериментом также заинтересовался мэр Москвы Юрий Лужков, который выступает за более широкое использование данных чипов. Он предлагает внедрять чипы каждому мигранту или приезжему из других регионов в Москву, чтобы контролировать соблюдение законов о регистрации приезжих. В случае, если окажется что приезжий не смог легально зарегистрироваться в положенные сроки, мэр предлагает установить функцию блокировки мозга, в результате которой можно было бы легко вычислить нелегала среди настоящих москвичей.

У Mozilla Россия налоговые проблемы

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

Да уж, налоговики совсем озверели... :-)

Linux.org.ru тоже старается не отставать:

Выпуск финальной версии Wine 1.0

После длительной разработки тихо и незаметно вышел wine 1.0. Среди кучи исправлений (как всегда) выделяют следующие:

Работа Adobe Photoshop CS2, CS3, полная поддержка MS Office 2003 и 2007, полная поддержка OpenGL и DirectX.

Особенностью данного релиза является включение кода WINE@Etersoft в основную ветку и поддержка 1С и Консультант+

Презентация новой версии состоится 12 апреля на Microsoft Summer of Code.

Opera Software сфокусируется на музыкальном бизнесе

Так как в настоящее время компании Opera Software её кроссплатформенный браузер приносит менее 15% дохода, то компания решила сфокусироваться на музыкальном бизнесе и прекратить разработку браузера.

VIA покупает AMD, NVidia и IBM

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

Т. о., циркулировавшие ранее слухи о том, что VIA собирается купить NVidia, а последняя собирается купить AMD, которая, в свою очередь, собирается слиться с IBM, нашли неожиданное подтверждение одновременно.

Получившийся конгломерат VIA-AMD/ATI-NVIDIA/AGEIA-IBM, возможно, сможет составить хоть какую-нибудь конкуренцию Intel-Havok на микропроцессорном рынке.

Так как продукция AMD, NVidia и IBM на настоящий момент обладает гораздо худшей производительностью, чем процессоры VIA Idinah и видеокарты VIA Chlame10, то скорее всего их продукция будет упразднена.

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

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

WinCE Frameworks

2008-03-27T22:48:00.000+03:00

К сожалению при выборе PDA пришлось купить машинку с установленной Windows CE. Подходящих по характеристикам PDA с предустановленным или возможностью установки Linux не нашлось. Поэтому использую то, что есть :-)

Разумеется всего необходимого ПО я найти не смог. Что-то нужно делать самостоятельно. Т.к. времени у меня мало, писать на чистом WinAPI нет никакого желания. Первый выбор пал на .NET Framework и язык C#. Однако когда начал писать программы, оказалось, что Compact .NET Framework уж очень сильно обрезан по сравнению с обычной версией. Конечно понятно, чем руководствовались разработчики: .NET большой набор библиотек и все это сложно запихнуть на маленький PDA. Однако для меня, как разработчика, это очень неудобно. На мой взгляд, PDA обладает более чем достаточными возможностями и объемом памяти, для наличия полноценного Framework, максимально аналогичного десктопной версии.

К счастью вспомнилось, что относительно недавно пробегала новость: наконец-то Qt Trolltech можно использовать и для приложений на Windows CE: http://trolltech.com/developer/downloads/qt/qt-windows-ce. К сожалению пока только в статусе Beta и портирована не полностью. И только что взял wxWidgets и заметил среди каталогов wince. Нужно будет опробовать в работе.

Впечатления от Eclipse

2008-03-27T10:21:00.001+03:00

На работе давно задумывали сделать нашу разработку кроссплатформенной и отказаться от привязки к Windows и Microsoft Visual Studio. Естественно в первую очередь я начал глядеть в сторону Eclipse. Использовал в течении месяца. Накопилось большое количество впечатлений, к сожалению, большей частью отрицательных. Работает очень медленно (хотя MS VS тоже не блещет скоростью), выдает совершенно не понятные ошибки. Может быть человеку, который занимается разработкой на Java эти ошибки и понятны, однако я этот язык не знаю и знать не хочу. Поэтому Java исключения со стеком вызова мне мало о чем говорят.

Сначала Eclipse отказывался запускаться. Точнее отказывался запускаться с помощью eclipse.exe, только eclipsec.exe, который оставляет консольное окно. Ладно, стерпел... но через некоторое время и он перестал запускаться. Полез в форумы, оказалось, что нужно поправить eclise.ini. Сделал. Некоторое время работало, через некоторое время опять запуск можно было осуществлять только через eclipsec.exe. И разумеется позже и этот способ перестал работать. Опять полез в форумы, там советовали запускать сразу указывая workspace. Написал .bat файл, запускающий eclipse с указанием workspace. Вроде работало. При этом если писать start eclipse -data "...", то опять возникает исключение.

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

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

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

Хотя при использовании Eclipse под Linux проблем было гораздо меньше. Но я не смогу сказать директору, что наши программисты должны мучиться с этой ужасной вещью. К сожалению придется искать что-то другое. Для себя я бы однозначно выбрал vim/gvim, однако большинству нужна IDE в стиле Visual Studio. Может быть, когда KDE полностью портируют на Windows, KDevelop справится с этой задачей? А пока попробую Netbeans.

переход на UTF8

2008-03-23T07:50:00.000+03:00

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

Около месяца назад я изменил локаль в Linux с koi8-r на utf8. Проблем почти не возникло. Разве что firefox (точнее Iceweasel) при сохранении файлов с русскими именами делает это криво. Теперь начал и всю обработку текстовой информации вести utf8. И вот тут уже начались проблемы. Сначала пришлось помучиться, чтобы заставить mysql учитывать русский текст при поиске/сортировке (а вот с PostgreSQL никаких проблем не возникло). Потом оказалось, что многие мои утилитки, использующие другие утилитки, не могут работать с utf8. Например сейчас столкнулся с тем, что в HTML::Parser (модуль из языка perl) есть такой код:


sub parse_file
{
    my($self, $file) = @_;
    my $opened;
    if (!ref($file) && ref(\$file) ne "GLOB") {
        # Assume $file is a filename
        local(*F);
        open(F, $file) || return undef;
        binmode(F);  # should we? good for byte counts
        $opened++;
        $file = *F;
    }
    my $chunk = '';
    while (read($file, $chunk, 512)) {
        $self->parse($chunk) || last;
    }
    close($file) if $opened;
    $self->eof;
}

Чтение равно по 512 байт приводит к тому, что в многобайтовой кодировке может прочитаться только част байт символа. Ну, это не большая проблема, решение там описано. Только почему-то HTML::TreeBuilder коверкает часть особых символов, но мне уже надоело разбираться, лучше перепишу это на ruby.

На работе у меня в плане полное перепроектирование системы, разработкой которой я занимаюсь. Она наконец-то станет кросс-платформенной. Соответственно исходники следует перевести в utf8. Интересно, коллеги сильно обидятся, если столкнуться с подобными проблемами? :-)

fb2-tools-perl: обработка изображений скриптом html2fb2.pl

2008-03-22T02:55:00.000+03:00

Появилась у меня необходимость связаться со скриптами из проекта http://fb2-perl-tools.sourceforge.net/ - это набор скриптов для конвертации книг из/в формат Fictionbook. Мне нужно было конвертировать html файл в fb. Все бы хорошо, только изображения игнорировались. Пришлось, как всегда, приложить руку.

Результат можно взять тут в виде патча.

UPDATE 2008-04-24: Патч был включен в репозиторий проекта, поэтому убираю его с сервера.

Первое сообщение

2008-03-22T02:45:00.000+03:00

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

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