Движок наш собственный. Лао-Ностра — обычный пользовательский инф, правда, у него много энкодов — особых фраз, с помощью которых можно ответить на любой вопрос без конкретики, но более-менее адекватно.
Зайти в гараж (www.iii.ru/garage) и нажать на каттер (такая фигня, которой щелкают перед камерой после фразы «мотор!») с надписью Заставка (прислонен к дивану).
UPD: елки-палки! вэ-три-це уже успели в августе перетереть тему бинарного хмл (http://www.w3.org/2003/08/binary-interchange-workshop/Report.html) и родить кое-что осязаемое (http://www.w3.org/XML/Binary/)!
Сугубо ИМХО, но если binary, то уже не xml. Википедия говорит «Binary XML, or Binary Extensible Markup Language, refers to any specification which defines the compact representation of XML in a binary format», то есть бинарный хмл — это название ЛЮБОЙ спецификации, которая преобразует xml в бинарный вид. Так что, в принципе, tar cjf data.bxml data.xml вполне себе бинарный хмл.
Для меня же лично самый главный бенефит и признак хмл в том, что я могу открыть его хоть перочиным ножиком и глазами смотреть и руками изменять. Ну, это помимо классического и всеобъемлющего www.w3.org/TR/REC-xml/
Файл описания формы по-сути я является подобным шаблоном — в формате ini, xml, php-array, yaml, etc. В файле описываются правила представления (декораторы, трансляторы и фильтры) и получение-обработка данных (назначение обработчика через action, валидаторы, etc).
/usr/bin/env — путь один и тот же на любом юниксе от маков до netbsd.
ни тот ни этот скрипты я использовать не буду, потому что от проекта к проекту сильно меняются как структура каталогов, так и базы. Как минимум если у меня будет pgsql, то эти скрипты мне не подойдут. Но для файлов я буду пользоваться rsync.
svn exportнужно использовать потому что в .svn хранится практически копия рабочей копии и при (не дай бог) уничтожении репозитория эта информация никак не поможет его восстановить, но место в архиве занимать будет.
Бинарные логи нужно бэкапить потому что это единственный способ восстановить базу данных до состояния максимально близкого к моменту ее падения. Есть такое выражение «накатить транзакционный лог» — первый шаг по восстановлению данных после серьезного падения сервера бд.
1. Вместо #/usr/local/bin/php кошерно #!env php — ведь кто его знает где именно установлена консольная версия php
2. Крон ребутить не нужно
3. Посмотрел статью про баш — тут те же яйца, только в профиль. Отличия: там один файл, а тут два; там bash, а тут php
4. Глупо/не глупо — зависит от задачи
5. Эксклюдить svn — это лол. Попробуйте выполнить svn help export
А по поводу mysql — какая задача по бэкапу базы стоит? Если некритичный дамп небольшой базы чтобы неспешно раскидать по разработчикам, тогда ок. Но если РЕАЛЬНО важный бэкап, то лучше редкого снепшота mysqldump'ом и более частых копий бинарных логов еще ничего не придумали.
Не уверен насчет xml — данные настройки формы переиспользовать где-то еще не выйдет, поэтому xml по большому счету ничего не даст.
А вот если стоит задача минимизировать ручную писанину, то замена ini на yaml даст хороший результат. Тем более, есть враппер для перловой библиотеки Syck в виде php-модуля.
Ну, а написать свой Zend_Config_Yaml дело десяти минут. Или можно взять такую реализацию.
Господи ты боже мой (с)
Всю статью можно ужать в:
«Для вертикального текста я использую повернутую на 90 градусов картинку с текстом. Для конвертации кириллицы я не использую iconv() потому-то и потому-то, а вместо нее наковырял свой велосипед.»
tar cjf data.bxml data.xmlвполне себе бинарный хмл.Для меня же лично самый главный бенефит и признак хмл в том, что я могу открыть его хоть перочиным ножиком и глазами смотреть и руками изменять. Ну, это помимо классического и всеобъемлющего www.w3.org/TR/REC-xml/
И все.
/usr/bin/env— путь один и тот же на любом юниксе от маков до netbsd.ни тот ни этот скрипты я использовать не буду, потому что от проекта к проекту сильно меняются как структура каталогов, так и базы. Как минимум если у меня будет pgsql, то эти скрипты мне не подойдут. Но для файлов я буду пользоваться rsync.
svn exportнужно использовать потому что в .svn хранится практически копия рабочей копии и при (не дай бог) уничтожении репозитория эта информация никак не поможет его восстановить, но место в архиве занимать будет.Бинарные логи нужно бэкапить потому что это единственный способ восстановить базу данных до состояния максимально близкого к моменту ее падения. Есть такое выражение «накатить транзакционный лог» — первый шаг по восстановлению данных после серьезного падения сервера бд.
#/usr/local/bin/phpкошерно#!env php— ведь кто его знает где именно установлена консольная версия php2. Крон ребутить не нужно
3. Посмотрел статью про баш — тут те же яйца, только в профиль. Отличия: там один файл, а тут два; там bash, а тут php
4. Глупо/не глупо — зависит от задачи
5. Эксклюдить svn — это лол. Попробуйте выполнить
svn help exportА по поводу mysql — какая задача по бэкапу базы стоит? Если некритичный дамп небольшой базы чтобы неспешно раскидать по разработчикам, тогда ок. Но если РЕАЛЬНО важный бэкап, то лучше редкого снепшота mysqldump'ом и более частых копий бинарных логов еще ничего не придумали.
А вот если стоит задача минимизировать ручную писанину, то замена ini на yaml даст хороший результат. Тем более, есть враппер для перловой библиотеки Syck в виде php-модуля.
Ну, а написать свой Zend_Config_Yaml дело десяти минут. Или можно взять такую реализацию.
Всю статью можно ужать в:
«Для вертикального текста я использую повернутую на 90 градусов картинку с текстом. Для конвертации кириллицы я не использую iconv() потому-то и потому-то, а вместо нее наковырял свой велосипед.»
Все.