«Я не должен бояться.
Страх — убийца разума.
Страх — это маленькая смерть, влекущая за собой полное уничтожение.
Я встречусь лицом к лицу со своим страхом.
Я позволю ему пройти сквозь меня.
И, когда он уйдет, я обращу свой внутренний взор на его путь.
Там, где был страх, не будет ничего.
Останусь лишь я».
(c)Френк Герберт "Дюна"
Friday, December 28, 2007
Thursday, December 27, 2007
Руководство разработчика AspectJ часть 1
Решил поупражнятся в переводе тех литературы... Надеюсь через пару месяцев переведу все http://www.eclipse.org/aspectj/doc/released/progguide/index.html
Руководство разработчика AspectJTM
http://www.eclipse.org/aspectj/doc/released/progguide/index.html
Глава 1. Основы AspectJ
Введение
Многие разработчики программного обеспечения привлечены идеей аспектно - ориентированного программирования (AOP) , но не уверены в том, как начать его использование. Они понимают концепцию сквозного подхода и сталкивались с проблемами при его реализации в прошлом. Тем не менее, существует множество вопросов о том, как приспособить AOP в процесс разработки. В общем, эти вопросы звучат так:
· Возможно ли использовать аспекты в моем существующем коде?
· Какие улучшения я получу от использования аспектов?
· Как выделить аспекты в моих программах?
· Насколько сложно выучить хитрости AOP?
· Какие риски возникают при использовании этой новой технологии?
В этой главе все эти вопросы адресованы внутрь AspectJ : аспектно -ориентированного расширения Java общего назначения. На кратких примерах будут показаны виды аспектов, которые могут быть реализованы программистом и рассмотрены преимущества такого подхода. Читатель, которых захочет ознакомиться с примерами более детально, либо которых хочет изучить, как создавать подобные программы, может найти более подробную информацию и материалы на сайте AspectJ (http://eclipse.org/aspectj).
Самый существенный риск при внедрении любой новой технологии – пытаться внедрить ее слишком быстро и повсеместно. Многие организации консервативны относительно внедрения новых технологий именно из-за беспокойств по этой причине. Для разрешения этой проблемы, примеры в этой главе делятся на три большие группы, где аспекты, более простые для использования в существующем проекте, описаны первыми. В следующем разделе – «Введение в AspectJ» – мы представим вашему вниманию ядро основных возможностей языка, в разделе «Разработка аспектов» - аспекты, которые облегчают такие задачи как отладка, тестирование, настройка производительности приложений. В следующем разделе – «Промышленные аспекты» (тут не уверен за точность совсем, прим перев.) будут представлены аспекты для реализации сквозной логики, в общем, для Java приложений. Мы отложим обсуждение третьей категории, повторно используемых, аспектов до главы «Язык AspectJ»
Такая классификация аспектов по категориям не является жесткой, и не является единственным способом внедрить или приспособить AspectJ для своих нужд. Возможно, вы хотите использовать промышленные аспекты прямо сейчас. Тем не менее, основываясь на нашем опыте, предложенная классификация, единственный быстрый способ для разработчиков получить опыт (и максимум преимуществ) от AOP с минимальными рисками.
Руководство разработчика AspectJTM
http://www.eclipse.org/aspectj/doc/released/progguide/index.html
Глава 1. Основы AspectJ
Введение
Многие разработчики программного обеспечения привлечены идеей аспектно - ориентированного программирования (AOP) , но не уверены в том, как начать его использование. Они понимают концепцию сквозного подхода и сталкивались с проблемами при его реализации в прошлом. Тем не менее, существует множество вопросов о том, как приспособить AOP в процесс разработки. В общем, эти вопросы звучат так:
· Возможно ли использовать аспекты в моем существующем коде?
· Какие улучшения я получу от использования аспектов?
· Как выделить аспекты в моих программах?
· Насколько сложно выучить хитрости AOP?
· Какие риски возникают при использовании этой новой технологии?
В этой главе все эти вопросы адресованы внутрь AspectJ : аспектно -ориентированного расширения Java общего назначения. На кратких примерах будут показаны виды аспектов, которые могут быть реализованы программистом и рассмотрены преимущества такого подхода. Читатель, которых захочет ознакомиться с примерами более детально, либо которых хочет изучить, как создавать подобные программы, может найти более подробную информацию и материалы на сайте AspectJ (http://eclipse.org/aspectj).
Самый существенный риск при внедрении любой новой технологии – пытаться внедрить ее слишком быстро и повсеместно. Многие организации консервативны относительно внедрения новых технологий именно из-за беспокойств по этой причине. Для разрешения этой проблемы, примеры в этой главе делятся на три большие группы, где аспекты, более простые для использования в существующем проекте, описаны первыми. В следующем разделе – «Введение в AspectJ» – мы представим вашему вниманию ядро основных возможностей языка, в разделе «Разработка аспектов» - аспекты, которые облегчают такие задачи как отладка, тестирование, настройка производительности приложений. В следующем разделе – «Промышленные аспекты» (тут не уверен за точность совсем, прим перев.) будут представлены аспекты для реализации сквозной логики, в общем, для Java приложений. Мы отложим обсуждение третьей категории, повторно используемых, аспектов до главы «Язык AspectJ»
Такая классификация аспектов по категориям не является жесткой, и не является единственным способом внедрить или приспособить AspectJ для своих нужд. Возможно, вы хотите использовать промышленные аспекты прямо сейчас. Тем не менее, основываясь на нашем опыте, предложенная классификация, единственный быстрый способ для разработчиков получить опыт (и максимум преимуществ) от AOP с минимальными рисками.
Monday, December 24, 2007
Control to Quality Tree
В силу некоторых факторов, занимаюсь качеством, в том числе 6s.
Ниже мой ни на что не претендующий перевод (интересно я ничего не нарушаю в плане авторских прав)
http://www.anticlue.net/archives/000732.htm
Critical-to-Quality Tree
Дерево требований к качеству (Critical-to-Quality Tree), далее CTQ, - это инструмент методологии 6s для представления требований клиентов (потребителей) в измеримом виде. Данный инструмент используется для выявления и описания требований клиентов, позволяя при этом представить их в особом, удобном для измерения виде. После получения требований в виде CTQ они пригодны для количественного сравнения с имеющимися услугами и продуктами.
Среди преимуществ метода CTQ:
1.Трансформация общих и неопределенных потребностей клиентов в четкие требования.
2. Помощь командам 6s в переходе от общих описаний к конкретным спецификациям
3. Гарантия того, что определены все аспекты запросов клиентов
Ниже перечислены шаги, необходимые для создания и использования CTQ
1. Определение ключевых потребностей клиентов – На этом шаге команда выявляет ключевые потребности клиента относительно продукта или услуги. Этот шаг выполняется после открытой дискуссии. Обычно, такие потребности выражены в наиболее общих формулировках, (например хорошее обслуживание клиентов) чтобы гарантировать то, что команда ничего не пропустила.
2. Выявление первого слоя запросов клиентов - во время шага 2 команда выявляет два или три требования, которые удовлетворяют ключевым потребностям клиентов, выявленных на шаге 1. Например, мы имеем дело с хорошим обслуживанием клиентов, если звонки клиентов обсуживаются быстро и хорошо обученной командой.
3. Выявление второго слоя запросов клиентов – Во время шага 3, команда выявляет два или три требования, которые удовлетворяют каждому из требований шага 2. Например, «быстро ответить» означает, что ответ на звонок происходит после второго сигнала вызова, а «хорошо обученная команда» – это команда, которая может ответить на 90% вопросов без переадресации запроса на другую персону.
4. Когда требования доступные количественному определению извлечены, необходимо остановится - Шаг 4 наступает, когда команда выявила все требования, которые доступны измерению. Команда прекращает выявление требований, когда становится ясно, что все они измеримы.
5. Согласовать финальную версию требование с клиентами – После того как все требования в CTQ собраны в измеримом виде, наступает пятый шаг. Каждое из требований необходимо согласовать с клиентом
Дерево CTQ не является финальным этапом проекта по улучшению продукта либо услуги, но является путеводителем по улучшениям, которые необходимо внедрить. В этом ракурсе, дерево CTQ лишь самое начало проекта, инструмент, который дает возможность сравнить продукт или услугу со стандартом, наблюдая при этом за количественными индикаторами.
Ниже мой ни на что не претендующий перевод (интересно я ничего не нарушаю в плане авторских прав)
http://www.anticlue.net/archives/000732.htm
Critical-to-Quality Tree
Дерево требований к качеству (Critical-to-Quality Tree), далее CTQ, - это инструмент методологии 6s для представления требований клиентов (потребителей) в измеримом виде. Данный инструмент используется для выявления и описания требований клиентов, позволяя при этом представить их в особом, удобном для измерения виде. После получения требований в виде CTQ они пригодны для количественного сравнения с имеющимися услугами и продуктами.
Среди преимуществ метода CTQ:
1.Трансформация общих и неопределенных потребностей клиентов в четкие требования.
2. Помощь командам 6s в переходе от общих описаний к конкретным спецификациям
3. Гарантия того, что определены все аспекты запросов клиентов
Ниже перечислены шаги, необходимые для создания и использования CTQ
1. Определение ключевых потребностей клиентов – На этом шаге команда выявляет ключевые потребности клиента относительно продукта или услуги. Этот шаг выполняется после открытой дискуссии. Обычно, такие потребности выражены в наиболее общих формулировках, (например хорошее обслуживание клиентов) чтобы гарантировать то, что команда ничего не пропустила.
2. Выявление первого слоя запросов клиентов - во время шага 2 команда выявляет два или три требования, которые удовлетворяют ключевым потребностям клиентов, выявленных на шаге 1. Например, мы имеем дело с хорошим обслуживанием клиентов, если звонки клиентов обсуживаются быстро и хорошо обученной командой.
3. Выявление второго слоя запросов клиентов – Во время шага 3, команда выявляет два или три требования, которые удовлетворяют каждому из требований шага 2. Например, «быстро ответить» означает, что ответ на звонок происходит после второго сигнала вызова, а «хорошо обученная команда» – это команда, которая может ответить на 90% вопросов без переадресации запроса на другую персону.
4. Когда требования доступные количественному определению извлечены, необходимо остановится - Шаг 4 наступает, когда команда выявила все требования, которые доступны измерению. Команда прекращает выявление требований, когда становится ясно, что все они измеримы.
5. Согласовать финальную версию требование с клиентами – После того как все требования в CTQ собраны в измеримом виде, наступает пятый шаг. Каждое из требований необходимо согласовать с клиентом
Дерево CTQ не является финальным этапом проекта по улучшению продукта либо услуги, но является путеводителем по улучшениям, которые необходимо внедрить. В этом ракурсе, дерево CTQ лишь самое начало проекта, инструмент, который дает возможность сравнить продукт или услугу со стандартом, наблюдая при этом за количественными индикаторами.
Friday, December 21, 2007
Subscribe to:
Posts (Atom)
