In verbis, non verba, sed res et ratio, quaerenda est

Parasoft готов "принять с повинной" клиентов Agitar

2008-05-22T12:54:00.001+05:00

Недели две назад компания Agitar объявила о сворачивании операций. На сайте компании, правда, пока ничего об этом не сказано, оповещение отправлено только кредиторам. Сворачивание операций -- это такая мягкая форма банкротства, кредиторам предложено "полюбовно" закрыть тему.

На самом деле, как ни крути, это провал, продать стартап не удалось. В том, что Agitar -- это просто мыльный пузырь, мы нисколько не сомневались с самого момента её появления. Когда-то давно компания Sun Microsystems сделала инструмент для тестирования на основе формальных спецификаций ADL, который использовался для внутренних нужд, а потом ушёл в опенсорс. Компания Agitar заявила, что умеет делать следующий шаг в автоматизации -- генерировать эти самые формальные спецификации. Но секретных технологий никому не рассказывала, что вполне естественно, и инструменты свои попробовать широкой общественности тоже не давала -- а вот это уже было подозрительно. Вместо этого было сделано несколько "продаж" в достаточно солидные фирмы, которые дали весьма хвалебные отзывы, а также наняты "для представительности" такие известные товарищи, как Кент Бек и Роберт Биндер, которые, впрочем, нигде и никогда явно не рекламировали Agitar. Компания участвовала буквально во всех конкурсах и получила кучу наград. Они сделали достаточно интересный корпоративный блог. В общем, раскручивались вовсю. Мы ожидали, что кто-нибудь вскоре купит Agitar, и только после этого он тихонько сдуется но нормальных размеров (какой-никакой, но инструмент они всё же разработали). И вдруг -- хлоп! Неожиданно.

Хм, а причём тут, собственно, Parasoft?

А притом, что они здорово воспользовались этой ситуацией, объявив, что им жуть как жалко невинно пострадавших клиентов Agitar, и потому всем, пришедшим с 20 мая по 15 августа с повинной, будет объявлена амнистия и их с радостью примут в число клиентов Parasoft.

Молодцы, поляки!

Я буду "экспертом" на Training Labs 2008

2008-05-20T12:44:00.001+05:00

28 июня 2008 года в Москве пройдёт необычное мероприятие -- Training Labs 2008. Необычность -- в смешении стилей. То ли это конференция, где вместо традиционных докладов будут проходить тренинги, то ли выставка тренингов в формате конференции. "Докладчики", они же "тренеры" будут демонстрировать своё мастерство, не рассказывая про свои умения, а показывая их на практике. "Слушатели" будут не просто слушать произносимые с трибуны речи, как на традиционных конференциях, а активно принимать участие в проводимых тренингах. А цель всего этого действа -- познакомить потенциальных заказчиков как лично с тренерами, так и с обучающими компаниями.

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

Короче, очень интересно и нестандартно. Приходите, будем зажигать! :)

Баг в контакте

2008-05-16T11:48:00.002+05:00

Наткнулся на любопытный баг "В Контакте". Судя по всему, там можно создать группу с пустым названием. Например, вот такую: http://vkontakte.ru/club717740 . Но само по себе это не является ошибкой. А вот если такая группа встречается в результатах поиска -- происходит смещение полей, выглядит это вот так:

(можно поискать по ключевому слову "Тестирование", указав дополнительно тип группы "Клуб" и тему "Разное" -- тогда указанная группа окажется первой в результатах поиска)

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

В википедии открылся Software Testing Portal

2008-05-12T17:33:00.002+05:00

В википедии открылся Software Testing Portal. Я обрадовался, побежал посмотреть - и был разочарован. Оказалось, что информации про тестирование в википедии крайне мало.

Мы тоже в рамках проекта software-testing.ru предпринимали попытки сделать базу знаний, но не преуспели. Оказывается, и для буржуев это пока не по зубам.

Имеется ещё одна попытка создания базы знаний про тестирование - http://www.testingperspective.com/tpwiki/ , но пока что ещё менее наполненная информацией, увы...

Ну почему тестировщики так не любят писать тексты на профессиональные темы?

Конференция SQADays 2008 - открыта регистрация

2008-04-11T16:40:00.002+05:00

27 мая 2008 года в Москве пройдёт третья международная конференция SQA Days 2008, на которую приглашаются специалисты по тестированию и обеспечению качества программных систем, а также другие заинтересованные лица. Конференция посвящается вопросам, связанным с тестированием и обеспечением качества веб-приложений.

Для тестировщиков
Сейчас количество людей в России и ближнем зарубежье, занятых в области тестирования и обеспечения качества программных систем, быстро растёт. В условиях быстрого роста отрасли именно конференции дают возможность организовать наиболее динамичное распространение информации и эффективный обмен опытом. Конференция SQA Days 2008 является преемником конференции SQA-2, получившей большой отклик в среде тестировщиков. Мы надеемся, что в новом формате конференция станет ещё интереснее и информативнее.

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

Для их начальников
Хотите организовать отдел тестирования? Хотите узнать, какие инструменты стоит покупать, а какие нет? Хотите узнать, какие методы тестирования сейчас наиболее популярны? Хотите повысить профессионализм ваших тестировщиков? Хотите найти подрядчика для выполнения независимого тестирования или, наоборот, заказчика на свои сервисы по тестированию?

Добро пожаловать на конференцию SQA Days 2008!

Конференция SQADays 2008 - Call for Papers

2008-04-09T13:08:00.002+05:00

27 мая 2008 года в Москве пройдёт третья международная конференция SQA Days 2008, на которую приглашаются специалисты по тестированию и обеспечению качества программных систем, а также другие заинтересованные лица. Конференция посвящается вопросам, связанным с тестированием и обеспечением качества веб-приложений:

функциональное тестирование;
тестирование производительности;
автоматизация тестирования и инструментальные средства;
конфигурационное тестирование;
тестирование удобства использования (usability);
тестирование защищенности (security);
статические методы обеспечения качества;
измерения и мониторинг;
тестирование и обеспечение качества как часть процесса разработки;
аутсорсинг тестирования.

Формы участия

Доклад - оригинальная работа, непосредственно связанная с тематикой конференции, представленная в форме выступления продолжительностью 20-30 минут, сопровождаемого показом слайдов.

Флип - короткое (5-10 минут) выступление на тему, связанную с тематикой конференции или близкую ей, с использованием доски или флип-чарта и фломастеров, либо устно, без использования специальных технических средств.

Форма и сроки подачи и рассмотрения заявок

20 апреля - крайний срок подачи заявок на участие в форме доклада;

27 апреля - срок рассмотрения заявок и формирования программы конференции;

11 мая - срок предоставления докладчиками готовых к показу слайдов.

Желающие выступить с докладом на конференции должны не позднее 20 апреля представить на рассмотрение программного комитета тезисы своего доклада: 1-2 страницы печатного текста.

Все материалы необходимо отправлять на адрес программного комитета: 2008@sqadays.ru

Заявки на участие в форме флипа будут приниматься без ограничений, в том числе непосредственно в день проведения конференции. Отбор флипов будет производиться непосредственно участниками конференции, для чего будет организована некоторая форма голосования.

Дополнительную информацию о конференции можно получить на официальном сайте http://www.sqadays.ru/

Software Testing – Cost or Investment? Часть 2.

2008-01-17T15:41:00.001+04:00

В предыдущей части я написал о том, при каких условиях тестирование можно считать инвестициями, если сервисная компания, выполняющая тестирование на заказ, продолжает сопровождать систему в течение достаточно продолжительного времени. Однако за кадром осталось рассмотрение ситуации, когда сопровождения нет, выполняется разовое тестирование -- может ли в этом случае тестирование рассматриваться как инвестиции?

Как весьма справедливо заметил в комментариях Евгений Пророк, значительную часть моих сентенций можно суммировать одним предложением -- обоим сторонам выгоднее заключить Service Level Agreement (SLA), чем заниматься "работорговлей". Да, это верно, но этого недостаточно. Заключение SLA вместо продажи FTE не превращает автоматически расходы в инвестиции. Потому что, по определению, инвестиции -- это долгосрочные вложения, целью которых является получение прибыли или увеличение активов в будущем. Заключение SLA в долгосрочном проекте можно интерпретировать как одну из форм инвестиций. Но ведь и в краткосрочном проекте тоже можно заключить SLA. Однако это было бы неправильно считать инвестированием, потому что никаких долгосрочных вложений в этом случае не делается.

Так что же, краткосрочные проекты -- это всегда чистый расход? Нет, нет, и ещё раз нет! Так может показаться только в том случае, если принимать в расчёт только финансовые активы. Однако современная экономическая наука трактует активы более широко. Например, в соответствии с концепцией сбалансированной системы показателей (balances score-card) следует рассматривать компанию с четырёх перспектив (групп показателей):

"традиционная" финансовая,
клиентская (лояльность клиентов, "популярность" и т.п.),
внутренние процессы (зрелость, гибкость, инновационность и т.п.),
персонал (развитие и рост).

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

Жизненный цикл разработки программного обеспечения -- что бы это значило?

2008-01-05T03:21:00.001+04:00

Каждый год я рассказываю студентам, что такое ЖЦПС (жизненный цикл программной системы), что такое ЦРПС (цикл разработки программной системы), и в чём разница между ними. И всё было хорошо, пока в этом году один из студентов не пришёл ко мне и не сказал, что он дескать прочитал сделанное Сергеем Орликом переложение SWEBOK на русский язык, и там вводится другой термин (со ссылкой на Скотта Амблера) -- жизненный цикл разработки программного обеспечения. Пытливый студент хотел понять, как этот самый "ЖЦРПО" соотносится с теми двумя понятиями, про которые я рассказывал на лекциях.

Студента пришлось разочаровать, объяснив ему, что термин "жизненный цикл разработки программного обеспечения" вообще не имеет права на существование, потому что он внутренне противоречив. И что там скорее всего имелся в виду термин "цикл разработки программного обеспечения", а слово "жизненный" затесалось туда по недоразумению. Именно это объяснение я и собираюсь здесь привести.

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

Когда мы говорим о циклах, это подразумевает наличие некоторого циклического процесса. Процесс есть последовательная смена состояний некоторого объекта или явления. Если в этой последовательности выделяются некоторые регулярно повторяющиеся подпоследовательности, можно говорить о наличии циклов.

Таким образом, противоречие в термине ЖЦРПО возникает из-за того, что неясно, какой процесс имеется в виду -- процесс существования (жизни) программной системы или процесс её разработки.

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

Говоря о жизненном цикле некоторого объекта или явления, мы можем иметь в виду один из двух смысловых вариантов.

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

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

Бывают ситуации, когда применимы оба варианта одновременно, то есть и процессы существования различных однотипных объектов схожи, и в процессе существования единичного объекта можно выделить некоторые циклы. Например, процесс жизни многолетнего растения можно интерпретировать как по второму варианту (зарождение, рост, размножение, гибель), так и по первому варианту, рассматривая циклические сезонные изменения.

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

Второй способ разрешения противоречия -- выкидывание слова "жизненный", так что получается другой осмысленный, хотя уже и не очень часто употребляемый термин "цикл разработки программного обеспечения" или "цикл разработки программной системы". Этот способ подразумевает, что речь идёт о процессе разработки программной системы, который является частью, или подпроцессом, всего процесса её существования, причём из контекста ясно, что Скотт Амблер имел в виду именно этот вариант.

Напоследок хочется отметить, что поиск в русскоязычном Интернете показывает достаточно широкое распространение термина ЖЦРПО, причём в большинстве случаев подразумевается как раз второй вариант уточнения (ЦРПС), а слово "жизненный" просто выступает в роли слова-паразита.

Но в англоязычном Интернете ситуация гораздо хуже -- я вообще не понимаю, как они сами разбираются, что означает термин Software Development Life Cycle (SDLC). Скажем, Википедия при открытии страницы http://en.wikipedia.org/wiki/Software_development_life_cycle перебрасывает на страницу "Software development process", то есть эти понятия трактуются как полностью идентичные, а кроме того, указывается, что синонимом являются также термины "software lifecycle" и "software process", всё смешано в одну кучу. Имеется также страничка "Systems Development Life Cycle", на которой опять таки объявляется, что синонимом этого термина является "Systems Life Cycle". А наряду с этим существуют (видимо, специально для индусов) разъяснения, согласно которым SDLC вообще является синонимом линейной (водопадной) модели процесса разработки ПО. Такие дела.

Аккредитация ИТ-компаний -- бесплатно??!

2007-11-15T23:21:00.002+04:00

Примерно неделю назад Правительство РФ приняло Постановление № 758 "О государственной аккредитации организаций, осуществляющих деятельность в области информационных технологий".

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

4. Государственную аккредитацию вправе получить российская организация, осуществляющая деятельность в области информационных технологий, независимо от организационно-правовой формы и формы собственности при условии, что данная организация осуществляет разработку и реализацию программ для ЭВМ и баз данных на материальном носителе или в электронном виде по каналам связи независимо от вида договора и (или) оказывает услуги (выполняет работы) по адаптации и модификации программ для ЭВМ и баз данных (программных средств и информационных продуктов вычислительной техники), установке, тестированию и сопровождению программ для ЭВМ и баз данных (далее - организация).

Приносишь в ФАИТ документы согласно установленному перечню, они определяют, действительно ли деятельность организации соответствует п.4 Постановления, если всё в порядке -- заносят организацию в реестр, и можно идти пользоваться налоговыми льготами. Пока, конечно, непонятно, как они будут выявлять "несоответствия деятельности организации, указанной в справке, деятельности, указанной в пункте 4 настоящего Положения", и даже не написано, кто должен разработать критерии, согласно которым будет определяться это соответствие. Ладно, постепенно выяснится, скорее всего ФАИТ и будет это делать -- ему аккредитовывать, вот пусть само и готовит критерии.

Но гораздо больше меня поразил п.9, вторая его половина:

"Плата за аккредитацию, в том числе за выдачу выписки из реестра, не взимается".

Это же ФАИТ может попасть на немалые деньги! ИТ-компаний и так немало, а если этот механизм предоставления льгот реально будет работать, не-ИТ-компании вполне могут задуматься о том, не вычленить ли ИТ-подразделение в отдельную компанию, которая будет оказывать ИТ-услуги своей "маме", пользуясь при этом льготами. И тогда ИТ-компаний станет ещё больше. А если ещё учесть, что надо бы проводить время от времени проверки, чтобы отбирать аккредитацию у тех, кто сначала прошёл проверку на соответствие и получил льготы, а потом занялся неподобающей деятельностью. Это тоже кто-то должен оплатить.

Где тут секрет? На какие деньги будет вестись этот реестр? Загадка...

(А может быть они будут брать деньги за аннулирование аккредитации? Ведь про аннулирование не написано, что оно бесплатное. Ха-ха :) )

Контроль за процессом тестирования в TrackStudio

2007-11-07T22:50:00.000+04:00

Тестируем приложение на платформе интеграции. Почти сотня компонентов, более или менее независимых друг от друга. У каждого компонента свой план релизов. Иногда бывают релизы, в которых обновляется несколько связанных компонентов (когда меняются интерфейсы между ними), но обычно компоненты обновляются независимо друг от друга. Тестирование каждого релиза происходит в несколько итераций, как правило 2-3, но бывает и до десятка, если попадается очень уж заморочный функционал, из которого дефекты так и прут. При этом заказчик хочет получать ежедневные статус-отчёты, показывающие текущее состояние дел по всем компонентам, которые в настоящий момент находятся на тестировании (или на доработке по результатам тестирования).

Процесс тестирования примерно таков:

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

Поначалу мы вели учёт в одном файле MS Excel. Плюсы: простота организации (сделали файл и всё), удобство создания отчётов для заказчика (фильтруем по статусу и копируем табличку в письмо). Минусы: сложность одновременной работы с файлом нескольких человек (в итоге получилось так, что все докладывали контролёру о всех изменениях статуса, а он вносил эту информацию в файл), отсутствие истории (кто что когда делал).

И вот примерно месяц тому назад мы наконец-то перенесли контроль процесса тестирования в TrackStudio. Это позволило устранить оба минуса (сложность одновременной работы и забывание истории), сохранив при этом простоту генерации отчётов (а может быть даже упростив).

Диаграмма процесса выглядит следующим образом:

Здесь всё достаточно очевидно, кроме, быть может, жёлтых промежуточных состояний. Смысл их заключается в том, что это точки, где происходит передача работы от одного человека к другому -- см. выше описание процесса. Жёлтое состояние нестабильное, оно означает, что предыдущий участник процесса уже работу сдал, а новый ещё не принял. Это состояние требует срочного реагирования и перехода в следующее состояние. Например, когда "контролёр" принимает новый релиз, он отдаёт его системному администратору, переводя задачу в состояние "На установку". Это сигнал -- системный администратор должен принять работу. Когда он переводит задачу в состояние "Установка", значит он принял работу. Передача установленной системы тестировщику происходит при посредничестве контролёра, из-за этого на этом участке имеется два нестабильных жёлтых состояния.

Настроенный в TrackStudio процесс выглядит так:

А текущее состояние дел отображается примерно так:

Следующий шаг -- хочется настроить полностью автоматическую генерацию ежедневных статус-репортов релиз-менеджерам прямо из TrackStudio.

P.S. Поначалу мы хотели ещё сильнее автоматизировать процесс, так чтобы вообще исключить контролёра из процесса. Сообщение о готовности новой сборки приходит во входящий почтовый ящик TrackStudio, она анализирует его и самостоятельно создаёт задание на установку. После того, как установка выполнена, TrackStudio опять таки сама по заложенному в неё алгоритму выбирает тестировщика (например, того, на ком меньше всего назначенных заданий) и создаёт задание на тестирование. Сама отправляет баг-репорт или отчёт о завершении тестирования. Но после некоторого размышления отказались от этих идеалистических воззрений. Автоматическая обработка сообщения о поступлении новой сборки требует, чтобы релиз-менеджеры придерживались определённых правил при написании таких писем. Но если учесть, что они вообще стараются вместо написания письма сообщить об этом по телефону, такие нововведения вряд ли вызывали бы у них прилив энтузиазма. Для автоматического выбора тестировщика, которому нужно передать сборку на тестирование, не удалось придумать адекватный алгоритм. А после всего этого отправка баг-репортов и отчётов о тестировании уже потеряла смысл как совсем несущественная часть, от автоматизации которой выгода практически нулевая.

Software Testing - Is it a cost or an Investment?

2007-10-23T10:18:00.000+05:00

Прочитал заметку Software Testing – Cost or Investment?, потом прочитал предшествовавшее ей обсуждение в LinkedIn, и задумался -- как же всё это ложится на сервисную модель, когда компания занимается исключительно предоставлением услуг по тестированию?
(Вообще-то опрос был нацелен на "продуктовые компании численностью от 100 и выше", но ответы учитывали и другие варианты.)

Если тестирование -- это чистый расход, то получается, что сервисная компания вообще не инвестирует. Максимум, о чём может идти речь -- об инвестициях в репутацию. Ладно, пусть так.

Теперь предположим, что это таки инвестиции. Результатом этих инвестиций является "снижение расходов на сопровождение". Вкладываем сейчас, чтобы сэкономить потом. Но проблема в том, что экономятся-то чужие деньги! Получается, что это инвестиции не в себя, а в заказчика, то есть опять таки расход!

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

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

Второй вариант более интересен, но и в нём есть одна неприятность. Дело в том, что далеко не всякий заказчик готов делиться деньгами, съэкономленными за счёт этих инвестиций, сделанных тестировщиками!

То есть если бы вы работали на себя, вы могли бы рассуждать так: "мы сейчас как следует потестируем, наймём 5 очень хороших тестировщиков, подтянем ремень, но зато потом на тестировании можно будет держать одного человека; а если сейчас мы возьмём 5 так-себе-тестировщиков, потом будет как всегда и придётся постоянно держать здесь трёх человек". Экономия -- два человека.

А если то же самое делается для заказчика? Если заказчик жадный, то подтягивать ремень и активно вкладываться в тестировании -- себе дороже, потому что он потом скажет: "ну, у вас же один человек прекрасно справляется с сопровождением, за одного и заплатим". А если не особо стараться, то он будет платить за трёх. Выбор очевиден.

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

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

Переезд на независимую площадку

2007-10-19T09:22:00.000+05:00

Раньше блог был здесь: http://it4business.ru/forum/index.php?automodule=blog&blogid=2
Но движок IPB перестал меня устраивать, всё таки это форумный движок, а блоги там реализованы так себе.

Кроме того, с появлением MS Office 2007 появилась возможность писать заметки и публиковать в блог прямо из Ворда. Можно также писать в Google Docs. IPB, естественно, не поддерживается ни в одном из этих редакторов.

Наконец, я просто хочу собрать все свои относительно длинные статьи в одном месте, чтобы не искать их по разным сайтам.

В общем, причин много, а результат один -- теперь блог будет здесь.