Блог:Team/2010-10-12 Идем на SECR-2010 - История изменений

VitaliyFilippov в 14:18, 7 февраля 2013

2013-02-07T14:18:35Z

VitaliyFilippov в 14:56, 6 февраля 2013

2013-02-06T14:56:52Z

StasFomin в 18:58, 15 июля 2011

2011-07-15T18:58:15Z

VitaliyFilippov в 15:39, 8 июня 2011

2011-06-08T15:39:18Z

Новая страница

Завтра начинается конференция [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], …). И в этот раз будет пара десятков участников и пара докладов:
* Алексей Алексеев, Николай Гребнев «Уменьшение влияния человеческого фактора при разработке бизнес-приложений».
<blockquote>В этом докладе мы постараемся рассказать о принципах разработки инструментов для написания бизнес-логики, позволяющих сократить количество ошибок.

Речь пойдет о нескольких практиках, принятых в отделе технологического развития нашей компании. Принципы будут проиллюстрированы на примере инструментария компании Microsoft.'''Максимум статических проверок'''. Под статическими проверками мы понимаем проверки времени компиляции. Этот принцип является важным, но, к сожалению, зачастую недооценивается разработчиками инструментария разработки. Проверки времени компиляции могут отлавливать большой спектр ошибок. Есть и другая особенность – это удобство.

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

Мы будем говорить о проверках уровня доменной модели.'''Возможность анализа декларативных проверок'''. Любые ограничения порождают некоторую модель. Эту модель (проверки) можно формально верифицировать. Вообще, проблема доказательства большинства свойств программы невозможна. Этот вопрос выходит далеко за рамки нашего доклада. Но существует возможность верификации более слабых (менее выразительных моделей). Во второй части мы обсудим функционал, который мы называем “состояния”. Так вот эти “состояния” образуют что-то вроде автомата, или структуру Крипке. Так вот, существуют алгоритмы проверки выполнимости темпоральных логик на таких структурах.</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: Эффективные инструменты]

Аннотация по [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>

Если собираетесь там быть — заходите, обычно на наших докладах нескучно.
[[Category:конференции]]
{{wl-publish: 2010-10-12 20:47:00 +0400 | StasFomin}}
{{To-lib-silent}}

@@ Строка 23: / Строка 23: @@
 Если собираетесь там быть — заходите, обычно на наших докладах нескучно.
 [[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}}

@@ Строка 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>В этом докладе мы постараемся рассказать о принципах разработки инструментов для написания бизнес-логики, позволяющих сократить количество ошибок.
@@ Строка 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>
-Аннотация по [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&amp;portrait=0" frameborder="0" height="405" width="720"></iframe></html>
+{{vimeoembed|14445105|720|405}}
 Если собираетесь там быть — заходите, обычно на наших докладах нескучно.