Самый простой способ избежать конфликтов в конфигурационных файлах — это хранить шаблон конфигурационного файла в системе контроля версий. Например, если приложение использует файл db.properties, то в системе контроля версий должен храниться файл db.properties.tmpl. При первой загрузке изменений из системы контроля версий (update, pull, etc) каждый разработчик переименовывает .tmpl файл избавляясь от расширения (так как приложение использует db.properties, без наличия этого файла ничего работать не будет) и заодно подставляя нужные ему значения конфигурации. При последующих обновлениях шаблона конфигурационного файла каждый разработчик будет видеть что добавились новые параметры и что нужно добавить соответсвующие декларации в свой конкретный конфигурационный файл при этом подставив нужные значения.
Я не могу придумать применение (помимо картографии) огромному массиву точек, визуализацию которого нужно упрощать. Разве подобного рода упрощение не происходит на server-side? Не думаю что имеет смысл гонять кучу данных (координаты точек) от сервера к клиенту для того, чтобы уже на клиенте минимизировать количество визуализированных точек.
Отличная статья! Поражает невежество и, своего рода, потребительский подход комментаторов — всё разжевывать нужно.
Со своей стороны есть несколько комментариев/вопросов.
1. Результаты анализа данных о прошедших (с 2006 г.) оцениваниях относительно модели CMMI, опубликованные SEI в сентябре 2011, показывают, что 66% оцениваний проведены в компаниях категории «1-100 человек», при этом внутри этой категории главные подкатегории «25 и менее» и «26-50». Сложно поверить в то, что небольшие компании могут обладать высокими уровнями CMMI. Насколько я понял из пояснения к первому мифу, достаточно высок процент небольших компаний, обладающих каким либо уровнем зрелости. Интересно было бы подробнее узнать, какие это уровни. Не уверен что коллективу из 50 человек может быть нужен 4-й уровень, а если даже и нужен, то непонятно как этот уровень в естесственных (не навязанных заказчиком, менеджментом, еще кем либо) условиях может поддерживаться — компания и ее сотрудники должны обладать высокой культурой ведения IT-бизнеса и хорошим пониманием процессов. Или, другими словами, все 50 человек включая девушку на ресепшне — это монстры своего дела, а о сотрудниках-джуниорах не может идти даже речи. Это при всём том, что для большинства процессных задач можно найти нужные и эффективные инструменты. Если большинство компаний небольшого размера имеют уровень не выше 3-го, тогда вопрос снимается. Вообщем, очень интересно было бы посмотреть на статистику.
2. Из практики (и из Agile Manifesto): несмотря на все желание быть Agile и работать с заказчиком ну очень близко, наша компания, обжегшись, все же взялась за усиление контрактной составляющей сотрудничества.
Не совсем понятно зачем понадобилось усиление контрактной составляющей. Неужели для того, чтобы заставлять заказчика что-то делать в соответствии с выстроенными процессами? :) Если заказчик хочет одновременно agile и cmmi, то он должен понимать что это серьезный коммитмент в интересах качества, а также иметь в виду усилия, которые со своей стороны нужно прикладывать. Если же в компании cmmi, a заказчик хочет agile и нужно их как-то подружить, то ОЧЕНЬ много зависит от адекватности заказчика. Часто слишком много усилий уходит для того, чтобы объяснить, почему процесс построен так, а не иначе. Я бы не стал предлагать/навязывать свои процессные модели заказчику если он не способен безболезненно в эти модели интегрироваться. А контрактные обязательства — это не всегда безболезненно.
3. CMMI будет оправдывать ожидания (и затраченные средства), если компания продает solution, управляет процессом удовлетворения бизнес потребностей клиента.
Интересно было бы узнать о практике применения CMMI для аутсорсинга. Ведь есть отдельный раздел — CMMI for Acquisition, ориентированный на это. Так что не совсем обязательно, что CMMI аппрайзал не может быть использован для повышения эффективности аутсорсинговых компаний. Согласен с тем, что это несколько сложнее. Но если заказчик хочет и готов к сотрудничеству в этом направлении, то выстроить процессы может оказаться даже проще, чем для продуктовой компании.
То есть, проще говоря, нужно иметь CMP (Configuration Management Plan). Этого достаточно? Всё перечисленное можно втиснуть в рамки этого документа. Но мне всё таки интересно, есть ли требования CMMI к тому, что конкретно должно быть обязательно включено в CMP. Ведь сами по себе практики конфигурационного менеджмента вроде как опциональны. Кроме контроля версий стандарт требует наличие каких-то практик? Если да, то каких? Насколько глубоко описываются требования к использованию контроля версий и вообще специфицируется ли то, что же конкретно такое контроль версий?
Обязательно пишите про механику внедрения по возможности. Лично мне будет интересно.
И еще хотелось бы узнать как же конкретно CMMI относится к конфигурационному менеджменту? Предъявляются ли какие-то требования к процессам конфигурационного менеджмента или он просто «должен быть»? Насколько я знаю, в CMMI не предъявляется жетских требований к необходимости использования, к примеру, контроля версий. Если так, то как тогда как CMMI предлагает осуществлять конфигурационный менеджмент? Ведь контроль версий — это его основной процесс. С другой стороны я понимаю что CMMI не должен опускаться до таких деталей, но, тем не менее, всё равно интересно насколько детализированы/абстрактны описания высоких уровней зрелости.
Извините, действительно не очень уместо вот так давать ссылку без комментариев. Хотел узнать ваше мнение по поводу того, что в smalltalk «it's too easy to make a mess». Действительно ли это так и насколько тесно можно провести паралели между Ruby и Smalltalk?
я имел в виду issue tracking. как насчет присутствия enhancement в issue tracking system, в этом случае она все еще «система отслеживания дефектов»?
употребление «баг-трекер» для описания bug-tracker'ов мне кажется вполне допустимым :)
«контроль постановки задач» — это неправильно? буду рад если вы приведете пример более употребляемого словосочетания. искал искал — не нашел
ну и вроде как я не отождествляю bug tracking и issue tracking, а наоборот — разграничиваю. кстати, по тем же причинам, на которые вы указали: баг трекер — частный случай
db.properties, то в системе контроля версий должен храниться файлdb.properties.tmpl. При первой загрузке изменений из системы контроля версий (update, pull, etc) каждый разработчик переименовывает.tmplфайл избавляясь от расширения (так как приложение используетdb.properties, без наличия этого файла ничего работать не будет) и заодно подставляя нужные ему значения конфигурации. При последующих обновлениях шаблона конфигурационного файла каждый разработчик будет видеть что добавились новые параметры и что нужно добавить соответсвующие декларации в свой конкретный конфигурационный файл при этом подставив нужные значения.я и вправду забыл. все вопросы снимаются)
Со своей стороны есть несколько комментариев/вопросов.
1. Результаты анализа данных о прошедших (с 2006 г.) оцениваниях относительно модели CMMI, опубликованные SEI в сентябре 2011, показывают, что 66% оцениваний проведены в компаниях категории «1-100 человек», при этом внутри этой категории главные подкатегории «25 и менее» и «26-50». Сложно поверить в то, что небольшие компании могут обладать высокими уровнями CMMI. Насколько я понял из пояснения к первому мифу, достаточно высок процент небольших компаний, обладающих каким либо уровнем зрелости. Интересно было бы подробнее узнать, какие это уровни. Не уверен что коллективу из 50 человек может быть нужен 4-й уровень, а если даже и нужен, то непонятно как этот уровень в естесственных (не навязанных заказчиком, менеджментом, еще кем либо) условиях может поддерживаться — компания и ее сотрудники должны обладать высокой культурой ведения IT-бизнеса и хорошим пониманием процессов. Или, другими словами, все 50 человек включая девушку на ресепшне — это монстры своего дела, а о сотрудниках-джуниорах не может идти даже речи. Это при всём том, что для большинства процессных задач можно найти нужные и эффективные инструменты. Если большинство компаний небольшого размера имеют уровень не выше 3-го, тогда вопрос снимается. Вообщем, очень интересно было бы посмотреть на статистику.
2. Из практики (и из Agile Manifesto): несмотря на все желание быть Agile и работать с заказчиком ну очень близко, наша компания, обжегшись, все же взялась за усиление контрактной составляющей сотрудничества.
Не совсем понятно зачем понадобилось усиление контрактной составляющей. Неужели для того, чтобы заставлять заказчика что-то делать в соответствии с выстроенными процессами? :) Если заказчик хочет одновременно agile и cmmi, то он должен понимать что это серьезный коммитмент в интересах качества, а также иметь в виду усилия, которые со своей стороны нужно прикладывать. Если же в компании cmmi, a заказчик хочет agile и нужно их как-то подружить, то ОЧЕНЬ много зависит от адекватности заказчика. Часто слишком много усилий уходит для того, чтобы объяснить, почему процесс построен так, а не иначе. Я бы не стал предлагать/навязывать свои процессные модели заказчику если он не способен безболезненно в эти модели интегрироваться. А контрактные обязательства — это не всегда безболезненно.
3. CMMI будет оправдывать ожидания (и затраченные средства), если компания продает solution, управляет процессом удовлетворения бизнес потребностей клиента.
Интересно было бы узнать о практике применения CMMI для аутсорсинга. Ведь есть отдельный раздел — CMMI for Acquisition, ориентированный на это. Так что не совсем обязательно, что CMMI аппрайзал не может быть использован для повышения эффективности аутсорсинговых компаний. Согласен с тем, что это несколько сложнее. Но если заказчик хочет и готов к сотрудничеству в этом направлении, то выстроить процессы может оказаться даже проще, чем для продуктовой компании.
Ну и интересно по поводу проигрывания музыки и подключения сносной акустической системы
И еще хотелось бы узнать как же конкретно CMMI относится к конфигурационному менеджменту? Предъявляются ли какие-то требования к процессам конфигурационного менеджмента или он просто «должен быть»? Насколько я знаю, в CMMI не предъявляется жетских требований к необходимости использования, к примеру, контроля версий. Если так, то как тогда как CMMI предлагает осуществлять конфигурационный менеджмент? Ведь контроль версий — это его основной процесс. С другой стороны я понимаю что CMMI не должен опускаться до таких деталей, но, тем не менее, всё равно интересно насколько детализированы/абстрактны описания высоких уровней зрелости.
употребление «баг-трекер» для описания bug-tracker'ов мне кажется вполне допустимым :)
ну и вроде как я не отождествляю bug tracking и issue tracking, а наоборот — разграничиваю. кстати, по тем же причинам, на которые вы указали: баг трекер — частный случай