|
|
| (не показаны 2 промежуточные версии 2 участников) |
| Строка 1: |
Строка 1: |
| − | Завтра начинается конференция [http://cee-secr.org/ CEE-SECR 2010], куда мы традиционно ходим других посмотреть и себя показать (а именно см. [http://team.custis.ru/2009/10/secr-2009.html 2009], [http://team.custis.ru/2008/11/secr-2008.html 2008], [http://team.custis.ru/2007/11/secr-2007.html 2007], …). И в этот раз будет пара десятков участников и пара докладов: | + | Завтра начинается конференция [http://cee-secr.org/ CEE-SECR 2010], куда мы традиционно ходим других посмотреть и себя показать (а именно см. [[Блог:Team/2009-10-22_Идем_на_SECR-2009|2009]], [[Блог:Team/2008-10-30_SEC(R)-2008|2008]], [[Блог:Team/2007-11-05_SECR-2007|2007]], …). |
| − | * Алексей Алексеев, Николай Гребнев «Уменьшение влияния человеческого фактора при разработке бизнес-приложений».
| + | |
| | + | И в этот раз будет пара десятков участников и пара докладов. |
| | + | ---- |
| | + | Алексей Алексеев, Николай Гребнев — «Уменьшение влияния человеческого фактора при разработке бизнес-приложений». |
| | + | |
| | <blockquote>В этом докладе мы постараемся рассказать о принципах разработки инструментов для написания бизнес-логики, позволяющих сократить количество ошибок. | | <blockquote>В этом докладе мы постараемся рассказать о принципах разработки инструментов для написания бизнес-логики, позволяющих сократить количество ошибок. |
| | | | |
| Строка 7: |
Строка 11: |
| | Ошибки времени исполнения сложнее воспринимаются, труднее найти причину ошибки.'''Разнообразие и декларативность проверок'''. Проверки общего назначения удобно задавать в декларативном виде. При этом сами проверки должен осуществлять фреймворк. За счет уменьшения дублирования и декларативности снижается вероятность ошибок. Проверки должны быть, как техническими, так и уровня доменной модели. | | Ошибки времени исполнения сложнее воспринимаются, труднее найти причину ошибки.'''Разнообразие и декларативность проверок'''. Проверки общего назначения удобно задавать в декларативном виде. При этом сами проверки должен осуществлять фреймворк. За счет уменьшения дублирования и декларативности снижается вероятность ошибок. Проверки должны быть, как техническими, так и уровня доменной модели. |
| | | | |
| − | Мы будем говорить о проверках уровня доменной модели.'''Возможность анализа декларативных проверок'''. Любые ограничения порождают некоторую модель. Эту модель (проверки) можно формально верифицировать. Вообще, проблема доказательства большинства свойств программы невозможна. Этот вопрос выходит далеко за рамки нашего доклада. Но существует возможность верификации более слабых (менее выразительных моделей). Во второй части мы обсудим функционал, который мы называем “состояния”. Так вот эти “состояния” образуют что-то вроде автомата, или структуру Крипке. Так вот, существуют алгоритмы проверки выполнимости темпоральных логик на таких структурах.</blockquote> | + | Мы будем говорить о проверках уровня доменной модели.'''Возможность анализа декларативных проверок'''. Любые ограничения порождают некоторую модель. Эту модель (проверки) можно формально верифицировать. Вообще, проблема доказательства большинства свойств программы невозможна. Этот вопрос выходит далеко за рамки нашего доклада. Но существует возможность верификации более слабых (менее выразительных моделей). Во второй части мы обсудим функционал, который мы называем “состояния”. Так вот эти “состояния” образуют что-то вроде автомата, или структуру Крипке. Так вот, существуют алгоритмы проверки выполнимости |
| − | * Станислав Фомин, [http://lib.custis.ru/Agile_Learning:_%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B5_%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B_%28SECR-2010%29 Agile Learning: Эффективные инструменты]
| + | темпоральных логик на таких структурах.</blockquote> |
| | + | |
| | + | ---- |
| | + | Станислав Фомин, [[Agile Learning: Эффективные инструменты (SECR-2010)|Agile Learning: Эффективные инструменты]] |
| | | | |
| − | Аннотация по [http://lib.custis.ru/Agile_Learning:_%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B5_%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B_%28SECR-2010%29 вышеприведенной ссылке], вот краткий промо-ролик: | + | Аннотация по вышеприведенной ссылке, а вот краткий промо-ролик: |
| | | | |
| − | <html><iframe src="http://player.vimeo.com/video/14445105?byline=0&portrait=0" frameborder="0" height="405" width="720"></iframe></html>
| + | {{vimeoembed|14445105|720|405}} |
| | | | |
| | Если собираетесь там быть — заходите, обычно на наших докладах нескучно. | | Если собираетесь там быть — заходите, обычно на наших докладах нескучно. |
| − | [[Category:конференции]] | + | [[Category:SECR-2010]] |
| − | {{wl-publish: 2010-10-12 20:47:00 +0400 | StasFomin}} | + | {{wl-publish: 2010-10-12 20:47:00 +0400 | StasFomin}} |
| | {{To-lib-silent}} | | {{To-lib-silent}} |
Текущая версия на 17:18, 7 февраля 2013
Завтра начинается конференция CEE-SECR 2010, куда мы традиционно ходим других посмотреть и себя показать (а именно см. 2009, 2008, 2007, …).
И в этот раз будет пара десятков участников и пара докладов.
Алексей Алексеев, Николай Гребнев — «Уменьшение влияния человеческого фактора при разработке бизнес-приложений».
В этом докладе мы постараемся рассказать о принципах разработки инструментов для написания бизнес-логики, позволяющих сократить количество ошибок.
Речь пойдет о нескольких практиках, принятых в отделе технологического развития нашей компании. Принципы будут проиллюстрированы на примере инструментария компании Microsoft.Максимум статических проверок. Под статическими проверками мы понимаем проверки времени компиляции. Этот принцип является важным, но, к сожалению, зачастую недооценивается разработчиками инструментария разработки. Проверки времени компиляции могут отлавливать большой спектр ошибок. Есть и другая особенность – это удобство.
Ошибки времени исполнения сложнее воспринимаются, труднее найти причину ошибки.Разнообразие и декларативность проверок. Проверки общего назначения удобно задавать в декларативном виде. При этом сами проверки должен осуществлять фреймворк. За счет уменьшения дублирования и декларативности снижается вероятность ошибок. Проверки должны быть, как техническими, так и уровня доменной модели.
Мы будем говорить о проверках уровня доменной модели.Возможность анализа декларативных проверок. Любые ограничения порождают некоторую модель. Эту модель (проверки) можно формально верифицировать. Вообще, проблема доказательства большинства свойств программы невозможна. Этот вопрос выходит далеко за рамки нашего доклада. Но существует возможность верификации более слабых (менее выразительных моделей). Во второй части мы обсудим функционал, который мы называем “состояния”. Так вот эти “состояния” образуют что-то вроде автомата, или структуру Крипке. Так вот, существуют алгоритмы проверки выполнимости
темпоральных логик на таких структурах.
Станислав Фомин, Agile Learning: Эффективные инструменты
Аннотация по вышеприведенной ссылке, а вот краткий промо-ролик:
Если собираетесь там быть — заходите, обычно на наших докладах нескучно.
