Псевдоэкспертные заметки технаря

Логирование в С++. Сравнительный мини-обзор

2011-09-23T18:01:00.000+04:00

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

После поверхностного поиска я выделил следующее:

log4j клоны для c++ - log4cxx , log4cpp , log4cplus;

Pantheios;
boost-log;
google-glog.

Попробовав log4cxx я заподозрил плохое увидев что по сути в проекте не было изменений с 2004 года. Увидев незакрытые баги связанные с многопоточностью(что для меня критично), я на него забил и решил пока не трогать другие log4j клоны (судя по датам релизов живой только log4cplus и если вам хочется во чтобы-то ни стало использовать клон log4j то наверное стоит обратить внимание именно на него).

Далее идут не клоны log4j, так что стандартная схема log4j включая все плюсы и минусы в них отсутствует. Это не значит что они слабее функционально (хотя некоторые объективно нацелены на простоту), они просто другие.

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

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

Наконец очередь дошла до google-glog. И тут я понял что это то что мне нужно. Очень мощный и одновременно простой функционал. DLOG (ну и DCHECK и тд) например позволяет выкинуть мысли о том во что выльется слишком подробное логирование в плане производительности - как только вы скомпиляете релиз-версию все DLOG вызовы ~~превратятся в тыкву~~ просто исчезнут. Но у glog есть и минусы. Например встроенной ротации логов нет. Документация очень куцая, часто приходится заглядывать в исходники (особенно в http://code.google.com/p/google-glog/source/browse/trunk/src/logging.cc ) для поиска настроек (например для максимального размера логфайла).

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

Достоен внимания и Pantheios особенно если вам импонирует его архитектура.

Ubuntu One vs Dropbox на ubuntu server

2011-09-05T14:46:00.000+04:00

Есть у убунты Ubuntu One - очередная sync/share тулза на облаке. Имея несколько безголовых(для тех кто не в курсе - сервер без монитора,клавы и мыши) убунту серверов и необходимость синхронизировать некоторые некритичные несекретные(достаточно несекретные чтобы использовать сторонний сервис для синхронизации) данные не только между ними но и наружу(в том числе на не *nix системы) решил я попробовать Ubuntu One. Но оказалось что из консоли это можно сделать только с помощью жутких хаков (например, да и то там в комментах пишут что уже не работает). Вобщем удивительное рядом - продукт компании не работающий на другом продукте компании.

В итоге пришлось использовать dropbox. Вот тут например написано как это сделать: http://ubuntuservergui.com/ubuntu-server-guide/install-dropbox-ubuntu-server.

P.S. Впрочем если погуглить то становится понятно что и на десктопе убунты большинство выбирают dropbox.

Параллелим на многоядерный кластер. C/C++ или Java.

2011-08-24T07:13:00.000+04:00

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

Любой кто начнет искать "как бы написать что-нибудь для кластера" наткнётся на аббревиатуру MPI. И наверняка наткнется на аббревиатуру OpenMP когда речь зайдёт о программировании для многоядерных систем.

Когда заходит речь о таких сложных системах желание снизить влияние программистких ошибок на систему(ну или снизить порог уровня годных для этой задачи программистов) вполне имеет право на жизнь. Понятно что если вы сражаетесь за каждый такт процессора на каждом ядре - то у вас нет альтернативы C/C++ библиотекам MPI/OpenMP и команде сильных программистов с крепкой нервной системой. Если же копейки процессорного времени вас не очень волнуют и сильной команды C/C++ спецов нет, то можете взглянуть на Java с её библиотеками-аналогами (MPJ Express и какой-то субъективно сомнительный на вид JOMP). Но будьте готовы что для совсем простых задач "копейки" выльются в двукратное отставание как например тут.

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

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

P.S. На всякий случай: если вы пишете что-то распределённое это вовсе не значит что вам необходим MPI. Но если у вас получается велосипед который повторяет функционал MPI - это повод задуматься.

Всё меняется

2011-03-02T02:15:00.000+03:00

Помнится давным-давно, году так в 2000-2001 читал я предсказания Билла Гейтса(если память не изменяет то в компьютерре) о том как всё будет с компьютерами очень скоро. Говорил он о том что почти весь десктопный софт будет скоро(вроде бы он говорил о 10-15 годах) переориентирован на тонких клиентов. И ведь многие смеялись тогда...

Так о чём я. Если бы мне в 2000 году сказали бы что когда мне понадобится быстренько визуализировать некоторые сложные данные для внутреннего редкого использования, то в 2011 я возьму js-библиотеку и быстренько напишу на java генератор html для отрисовки нужных графиков с использованием этой js библиотеки - я бы повертел пальцем у виска.

С одной стороны я конечно давно уже далёк от десктопных приложений и такое решение мне показалось оптимальным в том плане, что на совсем уж незнакомые грабли наступать не придётся. Ну и js либа уж больно красиво рисует. Года 4 назад я бы наверное налабал скрипт на perl с графической либой какой-нибудь (правда вышло бы уродливо, но наверняка ещё быстрее). В 2000 году мне даже мысль об использовании js для отрисовки не пришла бы в голову.

Библиотека для рисования графиков выбралась сама по себе - я вспомнил что недавно Сироткин искал такую, и тупо позаимствовал у него первую попавшуюся ссылку: http://highcharts.com/.

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

Что будет через 10 лет сложно представить. Наверняка появится ещё пара концептуально других опций для решения этой задачи.

Тестирование сервлетов и Task Queue в GAE (с guice ServletModule).

2010-07-20T07:57:00.005+04:00

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

Но бывает так что с тестами действительно сильно упрощается и ускоряется процесс разработки даже небольших проектов. Например как раз сейчас делаю проектик на GAE (Google App Engine) который достаточно сложный. Много cron-задач создающих task'и (здесь и далее имеются в виду task'и из Task Queue), которые в свою очередь сами могут порождать task'и. Так как cron и Task Queues на девелоперском сервере поддерживаются довольно-таки условно - возникли неудобства с проверкой работоспособности.

Учитывая что в GAE есть всё для удобного локального тестирования (здесь) было решено позапускать нужные cron-задачи и task'и в нужной последовательности в тесте и там же проверить результат. Очевидно это быстрее чем руками в девелопмент сервере запускать cron-задачи и руками же проверять результат. Более того - так как это тест, то нет нужды потом зачищать datastore чтобы попробовать запустить то же самое, но с другими параметрами. Вобщем экономия времени была ощутимой, не говоря уже о том что куда приятнее откинуться на спинку кресла и смотреть за прогрессом, чем руками рефрешить сервлеты.

Запустить сервлет в тесте не так уж и сложно - я использовал httpunit. Те кто используют обычные сервлеты могут использовать его. У меня же возникла проблема, все мои cron/task-сервлеты были guice'фицированы и поэтому подход с httpunit не годился.

Немного подумав я решил что достаточно будет написать mock's для HttpServletRequest и HttpServletResponse и использовать полученный с помощью guice объект сервлета чтобы всё это заработало. В итоге всё что получилось я выложил сюда: http://code.google.com/p/gaelocaltest/. Там же есть пример использования на главной странице.

Конечно оно сделано весьма быстро на коленке и имеет ряд ограничений, но работает и вполне покрывает типовые задачи. Собственно кода там мало и он примитивен - так что желающие могут взять его за базу для своих целей если вдруг возможностей этого не хватит. Для тех кто не сталкивался с граблями по конфигурации для Local unit testing'а GAE, советую взглянуть на пример конфига.

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

P.S. Для проектов имеющих посещаемость 1.5 человека в сутки и не имеющих постоянно "молотящих" cron/task сервлетов использование guice приведёт к частому появлению паузы при открытии сайта, так как из-за guice увеличится время старта. Сейчас правда все вроде лучше чем год назад - но народ периодически жалуется на эту багофичу GAE. Так что для таких проектов наверное не следует бежать внедрять guice - проще модифицировать мой код под httpunit (самому мне лень).

Удалить индекс в GAE для Java проекта

2010-05-17T19:13:00.004+04:00

Для тех кто мучается с этой задачей, вот решение из гуглогруп:

1) скачайте GAE python sdk
2) в вашем java проекте создайте файл app.yaml с таким содержимым:

application: YOURJAVA_APPID
version: 1
runtime: python
api_version: 1

handlers:
- url: .*
script: main.py

3) из директории вашего java проекте запустите (предполагается appcfg.py прописан в PATH)
appcfg.py vacuum_indexes .

4) удалите индексы которые хотите удалить

5) удалите файл app.yaml

6) зазвездите здесь чтобы не приходилось так извращаться: http://code.google.com/p/googleappengine/issues/detail?id=1893

P.S. А вообще это какой-то позор и дискриминация.

Быстрый способ обработать большой набор данных

2010-04-29T09:13:00.003+04:00

Довольно стандартная минизадача - взять данные из одного или нескольких источников, сгруппировать и как-либо обработать их и выдать на выход в неком формате. Часто для группировки/обработки сильно помогает наличие SQL базы данных. Для минизадач напрашивается sqlite (для явы я использую http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC но и вариант zentus вроде бы тоже использовал раньше). При больших объёмах данных узким местом обычно становится время затрачиваемое на insert/update. И тут сильно помогает то что в sqlite есть memory режим (имя базы данных для задания в конекте :memory:), что сильно ускоряет insert/update операции. Вобщем разница видна на глаз уже где-то на наборе из 500К объектов, а при отладке экономия времени просто неимоверная.

Про DTO в GAE+GWT

2010-04-01T05:08:00.004+04:00

Не знаю как остальных, а меня всегда раздражала необходимость создавать DTO (Data transfer object) в связке GWT-GAE. Ну не то чтобы раздражала, но не приводила в восторг необходимость клепать одно и то же каждый раз когда в клиентскую часть надо отдать данные объекта.

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

Так что если у кого-то были схожие ощущения делюсь ссылкой: objectify-appengine. Из плюсов - не нужны DTO(конечно при использовании GWT-safe библиотек), быстрый холодный старт и тп. Сам пока в бою не щупал - пока только в планах. Даже есть проектик подходящий.

Java сообщества

2010-02-21T07:39:00.003+03:00

Подписался на некоторые java рассылки/сообщества. Поражен количеством людей не понимающих как оно работает и способных рассуждать только на уровне оберток/фреймворков. Интересно есть термин для программиста способного механически писать только в любимом фрейморке и не понимающего сути?

Про будущее вёрстки

2010-02-14T07:00:00.004+03:00

Не прошло и года, как подвернулся случай изучить "GWT 2.0 Layout system". Случай подвернулся после того как в очередном проектике IE успешно не смог ничего показать, хотя ничего сложного от него не требовалось. В общем впечатления от "standards mode" пока сугубо положительные. Я как человек верстающий крайне редко, всегда убивал много времени на несложные вещи типа хедер с двумя колонками, правая резиновая и тп. Теперь куча проблем решена за меня практически из коробки: http://code.google.com/webtoolkit/doc/latest/DevGuideUiPanels.html . Задействование мозга конечно никто не отменял, но в целом многое упростилось и про хрень типа "а под IE мы напишем хак" в светлом будущем видимо можно будет забыть (да и сейчас при переходе на gwt layout'ы мой проектик мгновенно заработал в IE). Вобщем такими темпами скоро потребность в волшебных верстальщиках для проектов на GWT отпадёт.

Кстати если кто не был на GDD09(как например я), то тут есть записи: http://code.google.com/intl/ru/events/developerday/2009/sessions.html. Пробежавшись по заголовкам я просмотрел "GWT App Architecture Best Practices". В принципе сейчас это и в хелпе есть частично (про MVP), но всё равно советую посмотреть. На русском смотреть не советую - переводчик жжот местами. Жаль не было этой презентации года 3 назад, когда я городил похожее сам и собирал все шишки тоже сам (например злоупотреблял шиной для посыла всего и получал дикую прожорливость и тормознутость из-за этого - тут же докладчик сразу говорит что так делать не стоит, что сбережёт многим много нервных клеток). Правда на практике не всё так гладко как он рассказывает получается с MVP, но для ознакомления с концепцией в принципе и этого примера вполне достаточно чтобы загрузить средний мозг. А все сложности можно решить - главное понимать идею.

Лучший способ убить GAE

2010-02-09T17:16:00.003+03:00

Если вдруг у вас в логах появились сплошные сообщения "Request was aborted after waiting too long to attempt to service your request. Most likely, this indicates that you have reached your simultaneous dynamic request limit. This is almost always due to excessively high latency in your app. Please see http://code.google.com/appengine/docs/quotas.html for more details." и вы недавно задеплоили новую версию, то не стоит первым делом проклинать гугл который не даёт вам по крону запускать относительно лёгкий на ваш взгляд скрипт. Потому что заподозрив гугл в плохом я стал искать признаки того что моя jvm постоянно релоадится из-за того что на сайт нету нагрузки извне и заниматься прочими глупостями. А всё оказалось очень просто. Относительно несложный regex натравленный на пару килобайт текста сжирал весь процессор в одну харю ну а дальше по цепочке не хватало процессора всем бэкграундным скриптам (которые впрочем успевали переодически пробиваться и худо-бедно работать). Самое хреновое что при этом почему-то и логгинг не работал(те чекпойнты заботливо прописанные по скрипту тупо ничего не писали в лог, а писалось только сообщение которое я привел выше), так что выделив методом исключения фрагмент кода на котором GAE ложился пришлось тупо догадаться в чём дело. :)

GAE как сделать rollback в java

2010-02-07T13:35:00.003+03:00

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

Вобщем наконец я смог сломать своё приложение до состояния когда пришлось пользоваться консолью. Во время очередного деплоймента мне показалось что оно зависло и я отменил его и перезапустил eclipse. В итоге стал получать сообщение вида: "Another transaction by user *** is already in progress for this app and major version. That user can undo the transaction with appcfg.py's "rollback" command.". Вобщем пришлось лезть к консольным GAE тулзам в eclipse (*path to eclipse*)/plugins/com.google.appengine.eclipse.sdkbundle_VERSION/appengine-java-sdk/bin/ и там запустить (вариант для винды) appcfg.cmd -e vasyapupkin@gmail.com rollback <путь к war директории проекта eclipse>.

Также попробовал GAE "Task Queues". На мой взгляд замечательная вещь, очень удобно по сравнению со стандартными велосипедами на кроне. Жаль пока это экспериментальная фича и повально использовать даже в своём тестовом проектике я не буду пока.

Из новых обнаруженных небольших недостатков GAE:
- сторадж не очень стабилен, т.е. ситуации когда что-то не удаляется или не добавляется не так уж редки, что для серьёзных задач наверное сильно добавит гемороя;
- в java невозможно удалить неиспользуемые индексы (в гуглогруппах советуют сделать это из питоновского sdk), это ни на что не влияет но раздражает :).

GAE

2009-09-28T06:02:00.006+04:00

Чуствую GAE меня добъёт. Таких чудес насмотрелся - что на всю жизнь хватит. Надо будет поплотнее сесть, чтобы разобраться. Из последнего: в базе один основной объект с кучкой owned и unowned объектов (разных классов). Так вот через query без фильтров он возвращается как надо, а через getObjectById возвращается без child'ов. Как такое получается пока понять не смог. Из полезного - обнаружил что есть усечённая админ панель для локальной разработки, что облегчает жизнь ощутимо: http://localhost:8080/_ah/admin (в последних билдах http://localhost:8888/_ah/admin ) .

Update: разгадка-решение к чудесам - (defaultFetchGroup="true") . Расписывать не буду - гуглиться в соответствующих гуглогруппах и не только там.

Тестирование в GWT

2009-08-03T14:57:00.003+04:00

Прочитал занимательную статью про тестирование GWT приложений: http://code.google.com/webtoolkit/articles/testing_methodologies_using_gwt.html. Интересный подход с MVP и EasyMock, но на мой взгляд слишком затратный в плане оверхеда. Т.е. для небольших проектов вряд ли стоит такое воротить. Также полезная ссылка о том как тестировать RPC в GWT: http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=google-web-toolkit-doc-1-5&t=DevGuideJUnitAsync.

Про GAE и GWT

2009-07-19T13:45:00.003+04:00

Недавно я решил плотно пощупать Google App Engine (GAE), а также подтянуть скилы по GWT. Надо сказать что с появлением Google плагина для Eclipse жизнь заметно упростилась и пропали например баги с RPC которые были относительно недавно и даже побудили меня переносить проект под нетбинс. Вобщем для того чтобы собрать и выкатить проект на GWT+GAE (на яве) никаких шаманств мне пока совершать не пришлось. Никаких глюков пока тоже не заметил.

Когда начал писать проект в первые пару дней показалось вот оно счастье - настолько всё удобно и продуманно. Удобно отлаживать когда серверный и клиентский код доступен в одном дебагере и написан на одном языке, удобно выкатывать приложение(нажал кнопку и оно уже там). Но потом нашлись некоторые минусы. Например интернационализация. Я выбрал наиболее правильный на мой взгляд метод - с помощью статических строк(static string internationalization). Но на серверной стороне его использовать невозможно(потому что нужно использовать GWT.create) и возникает проблема когда например надо кинуть исключение на серверной стороне RPC с локализованным текстом. Пока ничего умнее как создание специального класса исключения с enum'ом всех типов исключений, и класса который на клиентской стороне производит получение нужного текста по типу исключения с учётом текущей локали я не придумал. Вобщем пустячок а неприятно - усложняет слегка жизнь. Второе разочарование постигло когда выяснилось что в GAE Datastore не предусмотрено создание unique ограничений. Но в целом пока впечатление сильно положительное, буду смотреть что там дальше будет при более глубоком погружении.

P.S. Да чуть не забыл - отсутствие какого-либо GUI редактора/просмотрщика данных для datastore очень огорчает.

Темы GWT. фичобаг

2009-01-28T05:46:00.003+03:00

Если вы делаете достаточно сложный с точки зрения вёрстки проект, и что-то у вас результат не всегда соответствует тому что вы хотите, и сильно отличается в браузерах, то советую вам взглянуть на магическую незакомментированную строчку в вашем XXX.gwt.xml файле: <inherits name="'com.google.gwt.user.theme.standard.Standard'/">

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

Настройка дополнительных клавиш под Linux

2008-09-29T13:20:00.003+04:00

Решил задействовать дополнительные клавиши моей относительно недавнокупленной Logitech Wave Keyboard. С удивлением увидел что утилиты под иксы которая бы подхватила мою клаву прямо "из коробки" нету(напомню - у меня fedora), более того настроить дополнительные клавиши тоже нечем - они игнорятся теми настройщиками какие есть. Править конфиги руками - лениво мне, всё же не 90-е уже. И тут я нашёл то что нужно в репозитории от Tigro (если кто не знает: http://tigro.info ) - keytouch и keytouch-editor.

keytouch правда тоже мою клаву не знал, но keytouch-editor осилил мою клаву, правда комбинации типа Fn-F7 приходится нажимать хитро сначала жмём Fn, потом мышкой кнопку New а потом уже F7. Иначе в сканкод у вас запишется код клавиши Fn. После работы в keytouch-editor результаты сохранил в файл который потом подгрузил в keytouch. Жить с настроенными дополнительными клавишами стало веселее и более эффективно.

Работа с удалённой ФС через ssh

2008-09-16T04:14:00.002+04:00

Довольно типичная задача когда необходимо быстренько что-то залить на сервер или перекинуть с сервера на сервер, причём ftp на серверах нет и не будет(по разным причинам). Когда это "что-то" - мои исходники/скрипты и т.п., то я использую svn потому что такие вещи у меня всегда в репозитории. Но что делать когда это например гигантский дамп БД, куча логов и тп? Тогда я обычно использовал scp - отлично копирует, но по юзабилити конечно консольно минимилистична. В принципе с помощью scp можно сделать всё что нужно. Но не очень удобно в некоторых случаях.

А удобнее использовать fuse и sshfs (в федоре пакеты fuse и fuse-sshfs). Тогда для того чтобы подмонтировать удалённую ФС необходимо сделать что-то типа такого:

sshfs root@server.com:/path/on/server /path/on/local

Тогда в /path/on/local у вас будет доступна /path/on/server находящаяся на сервере server.com. Отмонтировать можно например так:

fusermount -u /path/on/local

Вобщем в некоторых случаях sshfs экономит кучу времени.

Организация бэкапов в linux

2008-08-23T00:59:00.004+04:00

Долгое время я вполне обходился рукописным велосипедом для создания бэкапов. Ну т.е. использовал tar с небольшими скриптами.

Но недавно наткнулся на достаточно удобную утилиту написанную на perl - rsnapshot. Она использует rsync и hard links для создания серии бэкапов с заданными промежутками (у меня например создаются каждые 4 часа, каждый день и каждую неделю). При этом можно не просто указать что бекапить но и задать скрипты запускающиеся до/после очередного бекапа. Также есть много полезных функций например есть diff (например rsnapshot diff daily.0 daily.1 сравнит последний и предпоследний ежедневные бекапы), rsnapshot du покажет сколько отожрано места под ваши бекапы (отжирает надо сказать не так уж и много - читайте подробнее по ссылкам в заметке). Вобщем изучение man'а занимает минуты, всё просто и удобно - советую.

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

Ссылки по теме:

http://www.mikerubel.org/computers/rsync_snapshots/ - желающим соорудить свой велосипед во чтобы то ни стало :)
http://gentoo-wiki.com/HOWTO_Backup_to_DVD - о тонкостях бэкапа на DVD
http://www.linux-backup.net/App/ - куча ссылок по теме, но много устаревших

P.S. да и делайте бэкап не на тот же диск на котором данные которые вы бэкапите. Помните закон Мерфи - бэкап нужен тогда когда его нет.

Сходил на YAPC::Russia 2008

2008-05-18T18:10:00.008+04:00

Сходил на May Perl, впечатления смешанные.

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

1 день:

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

Профилирование perl-кода - в принципе несмотря на то что большая часть информации для меня не была новой, но например kcachegrind надо будет попробовать (cправедливости ради отмечу что слышал и раньше про неё, но по-моему не использовал).

May POE - ну доклад в принципе грамотный, но мне не особо интересный, так как новой информации там для меня было (да и в целом доклад в основном обзорный был).

Потом я пошёл на мастеркласс POE - но там были проблемы с инетом, поэтому всё пошло как-то сумбурно. В целом наверное зря я на него пошёл - мастеркласс мне был не нужен, я собственно хотел задать один вопрос (задал только во второй день поймав Серёжкина с утра, но об этом ниже). Вобщем поскучал я тут, в отличие от тех кого поражала/развлекала скорость эффективного кнопкодавления в *nix консоли и emacs'е - я 90% времени живу в никсах, поэтому меня это не развлекло. Вобщем со стороны конечно виднее - но можно было и без инета придумать чего-нибудь (как вариант запустить apache/nginx и его дрючить POE или носить с собой usb-bluetooth и мобилу на случай отсутствия инета(хотя такой тонкий канал поможет не всегда)).

"Аргументы в пользу XSLT" - на мой взгляд инородный доклад. Лично мне абсолютно неинтересен был - аргументы и за и против XSLT давно известны всем интересующимся, а про какое-то приложение к perl'у не было вообще ничего сказано.

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

Perl и Web 2.0 - несмотря на то что ничего особо нового для меня не было сказано, было весело и запомнилось. Не зря докладчику дали приз. :)

2-й день:

Блицы вобщем понравились все. Единственное что про обфускатор Stunnix мне было неинтересно(всё очевидно и уж больно самопиарно, хотя может кому полезно будет), ну а "CGI.pm - зло?!" не очень вписывается в формат блиц-доклада на мой взгляд, т.к. вопросы из зала наверняка бы были. :) Ну и у Серёжкина блиц получился не до конца

Perl+виртуализация - меня не зацепило, но возможно я просто не проникся до конца.

UTF Perl Practice - в принципе полезный доклад для тех кто не хочет сам пройтись по граблям. Жаль что его не было лет 5 назад когда я на эти грабли наступал изо всех сил. :)

CMS для крупного портала на примере TRAVEL.RU - ну реально работающие решения всегда интересны. Докладчик грамотно отбивался от каверзных и не очень вопросов - видно что не в первый раз. :)

ООП. Parrot. - Ну тут для меня тема была относительно новая, да и у Серёжкина на этот раз были заранее приготовленные слайды так что доклад был интересен и безэксесен :).

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

Теперь не про доклады, а про разное:

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

Но на второй день случайно поймав Серёжкина, всё же спросил его про POE. Он сказал что у него оно работает и не течёт, но версия 1.0002. Я же пробовал давно и наверняка более младшую версию. Вобщем придётся видимо опять уколоться и пожрать кактус.

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

Из минусов - накладки в докладах одного из организаторов (это я про Серёжкина), это как-то не очень радовало. Хотя я иногда малотерпим к чужой неорганизованности, поэтому может излишне предвзят. Ну и кроме того к чему-то придраться надо, а тут вроде как и по делу... :)

Добавление:
Забыл про два доклада вошедшие вне программы:
ПеАр LinuxFormat - на удивление прошёл на удивление легко.
ORM - местами было интересно, хотя я пока для своих задач не вижу смысла в нём особого.

Добавление 2:
Забыл написать что в целом неплохо, но могло быть лучше. :)

Update 3: решил дать ссылку на страницу где есть ссылки на презентации а не втыкать их сюда по одной :) : http://event.perlrussia.ru/yr2008/talks

В рассылке jerom выложил новое мегарешение гольфа про деление на 11 (автор некто mtve):

#!perl -lp
$_=s/..?\b/"@:[0..$&]"/e?redo:/^( {11})*$/?yes:'no'

Вобщем я поражён, пока больше и сказать нечего. :)

Update 4: видео с конференции здесь: http://event.perlrussia.ru/yr2008/media/video.html

vim как удобный diff (часть 2)

2008-05-07T00:20:00.000+04:00

В предыдущем посте vim как удобный diff я уже описал как использовать vim в качестве diff. Но погуглив нашёл что оказывается есть дополнительная настройка которая делает использование vim для этой задачи ещё удобнее. Настройка называется diffopt и по умолчанию установлена в filler:

:set diffopt=filler

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

:set diffopt+=iwhite

Ну и конечно можно задать игнорирование регистра при сравнении:

:set diffopt+=icase

Также можно задать кол-во строк между "схлопнутыми одинаковыми фрагментами" и отличающимися фрагментами (коряво описал - но прямее не получается чего-то), по умолчанию выставлено в 6:

:set diffopt+=context:2

Пример того что получается при выставленном icase и context:2 приведён ниже(я добавил в f1 и f2 дополнительных 8 строк чтобы fold'инг был виден):

vim как удобный diff

2008-05-06T03:26:00.004+04:00

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

Пусть у нас есть два файла f1 и f2.
Файл f1 состоит из 5 следующих строк:

row1
row2
row3
row4
row5

Файл f2 получен из f1 закоментированием одной строки и добавлением двух новых:

row1
row2
#row3
newRow1
row4
newRow2
row5

Выполнение diff нам даёт следующий результат:

[***]# diff f1 f2
3c3,4
< row3
---
> #row3
> newRow1
4a6
> newRow2

В принципе понятно но не сказать что прямо сразу. Можно сделать чуть получше:

[***]# diff -u f1 f2
--- f1 2008-05-06 03:24:16.000000000 +0400
+++ f2 2008-05-06 03:24:41.000000000 +0400
@@ -1,5 +1,7 @@
row1
row2
-row3
+#row3
+newRow1
row4
+newRow2
row5

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

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

P.S. Если вдруг когда-нибудь сюда набегут emacs'овцы - на emacs'е я сидел, правда довольно давно. Со временем стал считать что он избыточен для одних задач и недостаточен/неудобен для других (это вовсе не значит что vim для этих задач достаточен), так же избегаю лишних наворотов в vim'е. Но своё мнение другим не навязываю. :)

Покажи мне свою history и я скажу кто ты есть...

2008-04-28T14:24:00.003+04:00

Увидел на одном зарубежном блоге как собрать статистику по history коммандной строки в *nix, увеличил кол-во выводимых позиций до 50 и получил следующую картину:

history 1000 | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head -n 50

134 vim
123 svn
108 make
91 ssh
48 dig
34 mc
33 perl
29 rpm
24 yum
24 wget
23 ps
23 ls
22 ./uri_test.pl
21 startx
21 service
18 mysql
15 shutdown
12 touch
12 man
11 kill

Всё что меньше 10 я отрезал - там вобщем много всего и неинтересно. В моём случае стата конечно не очень репрезентативна. dig - это временное явление, так как я настраивал dns кэш просто. Ну и make это не потому что я что-то руками собираю или на c/c++ мастерю - а в основном из-за сборки/инсталла perl-овых модулей (ну малая доля вызовов make пришлась на небольшой с++ проект). Но вобщем и целом видно чем человек занимается.

Оригинальный аргумент в пользу того что PHP зло

2008-04-11T20:14:00.003+04:00

Недавно нашёл доказательство мразостности PHP - люди посчитали количество goto в сорцах разных языков тут: http://blog.ptpm.ru/index.php/2008/03/24/mrazotnyjj-pkhp/. :)

Perl получился менее мразостным чем PHP (что и так очевидно) и чем Python.

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

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

Неправильный POST через LWP

2008-04-02T09:48:00.003+04:00

Писал я тут небольшое приложение и написал к нему тест на perl - с помощью LWP посылал POST запрос ну и соответственно проверял реакцию. Реакция оказалась неправильной, но при этом если я руками через firefox слал то же самое то всё замечательно работало. Побайтно сравнив посылаемое в обоих случаях - обнаружил что perl не эскейпит символ "!", т.е. посылает как есть, а firefox как %21. Полез искать почему так - нашёл что в итоге вызывается query_form (в URI::_query) который соответственно вызывает метод query такой:


sub query
{
  my $self = shift;
  $$self =~ m,^([^?\#]*)(?:\?([^\#]*))?(.*)$,s or die;

  if (@_) {
my $q = shift;
$$self = $1;
if (defined $q) {
    $q =~ s/([^$URI::uric])/$URI::Escape::escapes{$1}/go;
    $$self .= "?$q";
}
$$self .= $3;
  }
  $2;
}

Т.е. эскейпится всё кроме символов в $URI::uric. Полез смотреть что там прописано:

$reserved = q(;/?:@&=+$,[]);
$mark = q(-_.!~*'()); #'; emacs
$unreserved = "A-Za-z0-9\Q$mark\E";
$uric = quotemeta($reserved) . $unreserved . "%";

Т.к. "!" в $mark то он тоже не преобразуется. Полез смотреть стандарты в rfc1866 сказано следующее:

The form field names and values are escaped: space
characters are replaced by `+', and then reserved characters
are escaped as per [URL]; that is, non-alphanumeric
characters are replaced by `%HH', a percent sign and two
hexadecimal digits representing the ASCII code of the
character. Line breaks, as in multi-line text field values,
are represented as CR LF pairs, i.e. `%0D%0A'.

Тут конечно можно задуматся входит "!" в alphanumeric или нет, но rfc2396 рассеивает все сомнения:

alpha = lowalpha | upalpha

lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"

upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"

digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"

alphanum = alpha | digit

Т.е. firefox прав, а lwp нет. В принципе lwp вообще непонятно зачем form_query в POST вызывает - оно не для этого. Ну ладно - это всё лирика...

Поправить дело можно относительно легко - исправить $URI::uric на то что нужно перед POST, а потом обратно. Заменить можно например так: $URI::uric = quotemeta("=&+")."A-Za-z0-9"; . Но возможно(скорей всего) я тут что-то не учёл - просто для моего теста это сработало, а всесторонне исследовать - времени нет.

Всё-таки LWP написан очень плохо - в который раз убеждаюсь. Зачитать про другой баг LWP.