XML
	INI
	JSON
	YAML
	Shell (dotfile)
	Нативные языковые файлы (.py/.rb/.lua и др.)
	Собственный / DSL
	Другой (какой?)

Проголосовало 5313 человек. Воздержалось 1793 человека.

Этот совет написан по мотивам поста В iOS beta 7 пропали настройки EDGE. Сами они там не появятся, а чтобы появились, проделаем небольшую «операцию» (полностью легальную по отношению к Apple, так как выполняется она средствами, разработанными Apple, для подобных случаев)

Итак, приступим:

Первым делом идем сюда и скачиваем iPhone Configuration Utility 3.3 for Mac OS X

Устанавливаем, запускаем и подключаем ваш iPhone кабелем

Сегодня зарелизен свеженький модуль для работы с .yaml конфигурационными файлами. Как обычно, доступен общественности на github Config::YAML::Modern, в CPAN будет добавлен немного позднее Config::YAML::Modern.
Почему этот модуль может быть вам интересен? Он умеет несколько клевых трюков, например:

• корректно смерджить пачку .yaml файлов из директории
• преобразовать file.name.yaml имя файла в { File => { Name => { _content here_ } }
• предоставляет чумовой path-resolution в dive-стиле qw/File Name inner_hash 0 my_key/

Области применения? Навскидку — конфигурация проекта при коллективной работе!
Интересно? Подробности под катом.

Приветствую. Как и обещал — продолжение цикла заметок об управлении конфигурацией ПО, в простонародье называемом Software Configuration Management. Весь цикл можно найти по ссылке на тэг CM. Из ещё неохваченного осталась буквально пара заметок.

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

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

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

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

И снова здравствуйте.

Продолжаю публиковать цикл статей о SCM — управлении конфигурацией ПО.
3 предыдущие заметки можно прочитать в этом же блоге.

Сегодня расскажу о том, с чем работает большинство читателей — о контроле версий.

Disclaimer

Далее будут описаны основные техники, реализованные в подавляющем большинстве систем контроля версий. Как они реализуются в приложениях, которые использует читатель, оставим на откуп многочисленным руководствам пользователя, how-to, FAQ и прочим документам, коих можно найти без труда. Главное – понять, по каким принципам и зачем оно работает именно так.

Вместо предисловия

И снова доброго времени суток!

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

1. Цикл статей по основам Software Configuration Management. О том, что такое СМ, каковы его задачи и за что отвечает в рамках проекта CM-инженер.
2. Software Configuration Management // Конфигурации и baselines. О том, что такое рабочий продукт в терминах SCM, что такое конфигурация, как она стабилизируется, а так же что такое базовые конфигурации — baselines.

В этой заметке речь пойдет о том, что большинство называют bugtracking systems. Мы посмотрим на этот класс задач и инструментов с более обобщенной точки зрения.

Для тех, кому лень читать длинное предисловие: перемотайте до последней части «Простая идея, которая пришла мне в голову».
Я хотел поставить якорь, но хабрапарсер не разрешает :(

Zend_Config и секции

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

На первый взгляд, такая идея кажется разумной, но я столкнулся с некоторыми ограничениями этого подхода…

Я считаю, что использование XML в конфигах — зло и малодушие. Далее попытаюсь обьяснить почему.