Agile Gathering 6.

Побывал на Agile Gathering 6 - все очень понравилось. Наверное ещё неделю буду всем рассказывать как интересно там было и как жаль, что не все смогли там побывать. Постараюсь все свои впечатления описать :-).

Все доклады были интересными. Часть докладов была на конференции в Харькове, но звучали они по новому - то есть докладчик заострял внимание на новых моментах, поэтому было интересно их слушать. Жать что в отличии от Харьковской конференции - видео не будет.

В докладе Mixing Agile and RUP by Roman Oksyukovski заинтересовал опыт работы с заказчиком при создании ERP системы, когда применение Agile подхода к планированию позволило получить систему реализующую все нужные заказчику бизнес процессы.

Последним на конференции выступал Scrum Trainer Robin Dymond(американец) - рассказывал о обезжиривание процесса разработки. Полностью название его доклада не запомнил, но не в этом суть. Основная идея (точнее моя интерпретация) состоит в том что нужно максимально снизить затраты на не производственные затраты и как следствии снизить затраты на всю разработку. В общем случае CV(Client Value) + BV(Business Value) и непроизводственные затраты. Если первые два значения интересуют соответственно клиента и заказчика - то последнее только мёртвый груз. В начале доклада как пример эффективного решения этого вопроса производство самолётов(3 дня крупно-блочная сборка боинга767), постройка небоскрёбов и магазин очень часто выпускающий новые - коллекции, но с минимальными изменениями - что приводит к тому что они быстро подстраиваются к тенденциям.

OpenSpace как такового не было. После последнего докладчика - все быстро разошлись.

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

К сожалению фотографий нет. Камера в мобилке делает не очень хорошие снимки ночью.

Реализации strspn

Когда разбирался в коде реализации разбора и преобразования html - в gtkhtml - заметил что при разборе любого текстового файла очень часто используется функции strspn. Конечно это обычная практика - сам так делал, но не анализировал эту ситуацию.

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

Как результат понял что результат разбора очень зависит от скорости работы этот функции. Стало интересно какой алгоритм используется при при реализации strspn - просто ради общего развития, что в этом направлении сделано. И вот что я выяснил:

В glibc 2.7 существует 2 вида реализаций:

• Медленная реализация вида - проход исходной строке в цикле с последующим проходом для каждого символа по строке - шаблону. Довольно таки простой надежный алгоритм, но не более количество проходов если не ошибаюсь сложность O это O(n*m) - где m*n это соответственно количество символов в исходном тексте и количество символов в шаблоне. Используется только для тестирования реализации. Расположена в файле string/test-strspn.c.
• Основная реализация расположена в sysdeps/архитектура/strspn.S и реализует на ассемблере эту функцию для каждой поддерживаемой архитектуры. Алгоритм немного изменился - вначале создается буфер под 256 байт для реализации множества на масcиве флагов(массив создается в стеке). Затем для для каждого символа присутствующего в шаблоне устанавливается флаг. Затем осуществляется проход по исходной строке и осуществляется обычная проверка установлен ли флаг(значение байта != 0). В результате сложность алгоритма не зависит от количества символов в шаблоне(O(n*m)).

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

Возможные пути улучшения:

Заменить массив из 256 байт на массив из 32 байт(256 бит) и проверять установлен ли бит в байте. Имеет основным достоинством что использует меньше памяти и возможно на архитектурах с такой разрядностью и/или аппаратно реализованной проверкой установлен ли бит - получить реализацию с минимальной зависимостью от скорости обращения к памяти при проверке присутствия элемента во множестве. Для архитектур x86 это большого выграша дать не может так как не полностью все множество влазит в размерность регистров и получение данных из кеша достаточно быстрое и получение данных из исходной строки идет с учетом особенностей архитектуры и получение данных идет с размерностью равной 32 бита с последующим получением частей. Так используется получение именно по 4 байта есть подозрение, что на части процессоров оно работает значительно быстрее получения 64 битных значений.

Для реализации получения значения бита в множестве на массиве из 32 байт пришлось бы использовать 5 инструкции:

• получение байта в котором установлен бит через сдвиг(>>5 или >>4),
• получение этого байта из памяти(скорее получение 4-8 байт в котором расположен нужный байт)
• получение позиции в которой должен быть бит через и(i&(1<<5-1))
• сдвиг полученного из памяти значения на полученное выше количество бит
• проверка установлен ли этот бит через &

В алгоритмах вместо этого используется косвенная операция проверки установлен ли элемент в массиве testb, которая в теории проработает быстрее чем 5 ранее указанных .

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

Особого ускорения это не даст - может пара процентов. Нужно бы это проверить на досуге....

Конференции

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

Зато в субботу насладился по полной :-) Слушал весь день. Постараюсь не пропустить Agile Gathering 6.

Содержание можно посмотреть по ссылкам.

Выложил реализацию recaptha на erlang

Сегодня обнаружил, что на googleсode выложили реализацию протокола openid. У нас в компании тоже есть реализация протокола openid - но она не полная, там не все особенности протокола реализованы - только наиболее важные для реализуемой нами системы.

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

Ура:-) UTF8 работает в mc

Сегодня я наконец исправил установочный скрипт mc в используемом мною дистрибутиве, теперь русские буквы отображаются правильно и сроки не разжижаются - до сих пор я менял локаль, чтобы хоть как-то пользоваться mc(уж очень меня это досаждало). Теперь у меня красиво с подсветкой табов (показываются стрелочки) и все надписи ровненькие и не появляются в разных частях экрана. Пытался прикрутить патчи от CRUX, fedora и gentoo:-) Подошли объединенные скрипты :-)

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

Нашел patches от CRUX все заработало, но версия mc (4.6.1) не поддерживала отображение табов стрелочками и надписи верхнего меню немного были неправильного размера.

Решил попробовать еще раз, но от генту (она использует patches от дебиана) и все заработало теперь мой любимый mc(4.6.2-pre1) работает как мне нужно:-)

Потом решил на этом не останавливаться и попробовать установить новые иксы - как раз вышла новая меса. Оказалось у меня в системе(в дистрибутиве) стоят почти последнее версии пакетов нужно было вручную обновить только xorg, libdrm и mesa. Обновил - запускаю, а у меня появильсь 3D ускорение(r4xx) - теперь можно в игрушки в линуксе запускать. И довольно неплохо - демки тунеля показывает 150 fps в игре gl-117 - 35 кадров(только какие-то глюки с клавой). И это на gpl дровах:-). Пропроритарные у меня не смогли откомпилить модуль ядра и не запустились - и во общем-то не очень и хотелось возиться с установкой приложения с закрытыми исходниками.

Из неполностью рабочего остался только wifi(ath5k) - он как-то тормознуто и не всегда стартует. А так если пару раз перегрузить карточу она отликаеться - но пока не очень уверено. Можно конечно написать разработчикам ядра - но пока не нашел кому написать и как правильно нописать описание ошибки. На своем не очень богатом опыте знаю, что правильное сообщение ошибки 90 процентов решения ее.

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

В общем ура:-)

Исправление gtkhtml

Для исправления моего проекта, решил немного подправить:

1. не поддерживал иные кодировки кроме utf, нужно было перекодировать исходный текст страниц;
2. не корректная кодировка в передаваемом запросе.

Результат моих изменений можно посмотреть в папке patches.

В исходном коде удалена перекодировка entity - так как кодировка определяется после разбора кода страницы. В разборе удалена перекодировка строк и проверки на соответствие последовательности байт utf, теперь код только копирует части строк. При запросе из разобраного дерева tokens они перекодируються и заменяються Entity. В результате рендеринг отображает страницу в правильной кодировке, если кодировка указана в заголовке ответа или через указание http-equiv. Для перекодировки при формирование запроса заменил код http_encoding_string - теперь при вызове указываеться кодировка в которую нужно перекодировать строки. Данные о кодировке беруться из htmlengine.

В коде остались такие проблемы:

1. в gtkhtml храниться кодировка хотя там она не как не используеться - нужно перевести на использование кодировки указаной в htmltokenizer
2. в htmltokenizer есть код в цикле добавляющий по одному символу в буфер нужно заменить на strcpy
3. существуют проблемы перекодировки на mail.ru заголовки сылок заменяються знаками вопроса

Портирование приложений на 64 битные платформы

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

Так как размеры могут не совпадать и компилятор вполне может что предположить например привести к какому-то типу ( наприме ошибка из-за которой на новом компиляторе gcc 4.3.x не компилируеться erlang) . Если не изменять типы указателей маловероятны ошибки когда на разных платформах приложения работают по разному. Даже без особеностей адресации и доступа к памяти как на ppc.

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

(Идея содрана как мне кажеться с интерфейса работы с gobject c Python и c управления памятью .NET(C#)).

P.S. Еще близкое к этой теме.