Авторство установленное по свойствам Word-документа — весьма сомнительно!
Я очень много работаю с документами и хочу сказать, что мое авторство указано не более чем в половине документов. Т.к. ряд документов приходится не создавать, а редактировать (будь то «рыба» от коллеги или официальный бланк с оф. сайта потенциального партнера или в конце-концов образец).
Т.о. исполнитель тендерной документации от МЧС вполне мог взять образец, например у жены или знакомых.
Безусловно, странно, что авторство не принадлежит МЧС, но не более!
Легкая статья и интересные картинки!
Не совсем понял вашу позицию? Вы «за» или «против»?
Если «за», то хотел бы поспорить.
Очевидно, в налаживание неформальных отношений между руководящим составом, подчиненным и различными (временами враждующими) подразделениями. Гораздо тяжелее отказать человеку, с которым делил стол, кров и тянул канат в одной команде, в просьбе, выходящей за прямые обязанности и требующей задержаться на работе на пару часов.
Сухие факты: некоторое время я работал в такой организации, где был сплаченный колектив и сильно развито чувство товарищества — бывали случаи, когда приходилось задерживаться и помогать кому-либо с выполнением индивидуальной задачи (либо задачи для отдела).
Позднее я работал на предприятии, где отношения были более официальные, просить о помощи там было не принято.
В первом месте:
— больше бездельников;
— ниже мотивация.
Третье: под действием алкоголя или просто в расслабленном состоянии, в умах сотрудников могут родиться гениальные идеи, которые в трезвом виде, они бы никогда не озвучили, а тем более не договорились бы с другими подразделениями компании. Случается редко, но оно того стоит.
Бывало и такое… Но в большинстве случаев все эти гениальные идеи проваливаются, когда выясняется, что их нужно кому то реализовывать.
P.S. Возможно приходилось сталкиваться с ISO9000, а может быть и просто слышали о Деминге, настроения которого я уловил в вашей статье, то лично я придерживаюсь «Анти-Деминга» (во всяком случае в настоящее время и на постсоветском пространстве): quality.eup.ru/MATERIALY8/anti-deming.htm.
Исходя из этих двух тезисов, получается, что компания каждый год платят «проценты» в виде сниженной эффективности труда за использование не самого актуального ПО
Эсли я правильно понял, что «платить» эквивалентно «недополучить прибыль», то под такую витиеваютую формулировку можно «запихать» очень многое.
Например: «Домохозяйки каждый год платят „проценты“ в виде сниженной эффективности труда за использование не самой актуальной кухонной техники».
С разрешения babai я бы сказал так:
«Перестает удовлетворять растущим требованиям бизнеса и новым потребностям.»
Проблема ПО не в том, что оно движеться назад, а в том, что оно не движеться вперед! И без обновлений и патчей ПО не начнет выдавать ошибочные данные там, где раньше выдавало правильные, а просто не сможет реализовать возникшие требования!
меня удивило.
Использую Hudson.
Точно так же в свое время стоял на распутии, что же выбрать и одним из «за» при выборе Hudson для меня было нежный и интуитивно понятный интерфейс.
Ни в коем случае не хочу вступать в дебаты, но если не сложно, то скажите пожалуйста, что именно вам не нравиться в GUI Hudson (это не для того, что бы «пиписьками» меряться, а в контексте критичной оценки и сравнения с TeamCity мне было бы интересно).
конфигурационный файл будет храниться в SVN, как по по мне так это достаточно удобно.
Скажите, не получатся ли у вас при этом, что при внесении изменений в процесс сборки (т.е. в конфигурационный файл) первый build выполняемый после этого будет не актуальным (т.е. будет выполнен по старым «правилам»)?
В том смысле, что TeamCity сначала берет конфигурационный файл, а потом производит update из репозитория или же наоборот?
Я использую Hudson и у меня такая проблема есть (не совсем уж и проблема, но как то корявенько получается).
Вердикт: Крайне важно поддерживать принцип: слил из хранилища и собрал без проблем.
Наверное это зависит от специфики проекта, но я думаю, что все же лучше собирать на отдельном сервере (а потом запускать то что собралось на другом отдельном сервере). Иначе возрастает риск столкнуться с проблемами типа: "… а на моем ПК это работат".
Я очень много работаю с документами и хочу сказать, что мое авторство указано не более чем в половине документов. Т.к. ряд документов приходится не создавать, а редактировать (будь то «рыба» от коллеги или официальный бланк с оф. сайта потенциального партнера или в конце-концов образец).
Т.о. исполнитель тендерной документации от МЧС вполне мог взять образец, например у жены или знакомых.
Безусловно, странно, что авторство не принадлежит МЧС, но не более!
<=99% же.
Не совсем понял вашу позицию? Вы «за» или «против»?
Если «за», то хотел бы поспорить.
Сухие факты: некоторое время я работал в такой организации, где был сплаченный колектив и сильно развито чувство товарищества — бывали случаи, когда приходилось задерживаться и помогать кому-либо с выполнением индивидуальной задачи (либо задачи для отдела).
Позднее я работал на предприятии, где отношения были более официальные, просить о помощи там было не принято.
В первом месте:
— больше бездельников;
— ниже мотивация.
Бывало и такое… Но в большинстве случаев все эти гениальные идеи проваливаются, когда выясняется, что их нужно кому то реализовывать.
P.S. Возможно приходилось сталкиваться с ISO9000, а может быть и просто слышали о Деминге, настроения которого я уловил в вашей статье, то лично я придерживаюсь «Анти-Деминга» (во всяком случае в настоящее время и на постсоветском пространстве): quality.eup.ru/MATERIALY8/anti-deming.htm.
Хм… Не внимательно читал. Значит «платить» это именно «платить».
Эсли я правильно понял, что «платить» эквивалентно «недополучить прибыль», то под такую витиеваютую формулировку можно «запихать» очень многое.
Например: «Домохозяйки каждый год платят „проценты“ в виде сниженной эффективности труда за использование не самой актуальной кухонной техники».
«Перестает удовлетворять растущим требованиям бизнеса и новым потребностям.»
Проблема ПО не в том, что оно движеться назад, а в том, что оно не движеться вперед! И без обновлений и патчей ПО не начнет выдавать ошибочные данные там, где раньше выдавало правильные, а просто не сможет реализовать возникшие требования!
Очень интересное замечание, т.к. у меня за update как раз отвечает один из target'ом NAnt'a. Попробую возложить задачу update на CI.
меня удивило.
Использую Hudson.
Точно так же в свое время стоял на распутии, что же выбрать и одним из «за» при выборе Hudson для меня было нежный и интуитивно понятный интерфейс.
Ни в коем случае не хочу вступать в дебаты, но если не сложно, то скажите пожалуйста, что именно вам не нравиться в GUI Hudson (это не для того, что бы «пиписьками» меряться, а в контексте критичной оценки и сравнения с TeamCity мне было бы интересно).
Я собственно что хотел спросить:
Скажите, не получатся ли у вас при этом, что при внесении изменений в процесс сборки (т.е. в конфигурационный файл) первый build выполняемый после этого будет не актуальным (т.е. будет выполнен по старым «правилам»)?
В том смысле, что TeamCity сначала берет конфигурационный файл, а потом производит update из репозитория или же наоборот?
Я использую Hudson и у меня такая проблема есть (не совсем уж и проблема, но как то корявенько получается).
P.S. Статья интересная!
2.6.7 был минорный релиз (т.е. это как бы 2.6, но т.к. в июле то добавили ещё и «7»).
Во всяком случае я так понял.
А ведь буквально недавно была 2.6.7, а тут тебе прям 2.8.
Попробуем…
Или все таки: «Для сайта требуется создать и встроить базу данных состояющую из 3 таблиц:»?
И так: «При этом все три таблицы связаны между собой следующими отношениями:»?
Наверное это зависит от специфики проекта, но я думаю, что все же лучше собирать на отдельном сервере (а потом запускать то что собралось на другом отдельном сервере). Иначе возрастает риск столкнуться с проблемами типа: "… а на моем ПК это работат".