В обычном ОО-языке есть, условно говоря, правила гигиены и шаблоны, по которым надо проектировать конкурентный доступ.
1. Состояние, разделённое (shared) потоками, должно быть как можно меньше.
2. Доступ к разделённым данным должен производиться через как можно меньшее количество входных точек.
3. Работа с разделёнными данными должна быть либо блокирующей, либо неблокирующей.
3.1. Если работа блокирующая, надо проектировать в терминах последовательностей операций, не нарушающих заранее определённые инварианты.
3.2. Если работа не блокирующая, надо чётко определять гарантии работы кода в плане доступа к протухшим данным.
В Эйфеле проблемы возникают с пунктом 3: описанные инварианты (собственно инварианты, постусловия, предусловия) обеспечивают корректность только для неразделённых данных.
Идея дизайна по контракту — неплохая, но не тогда, когда контракты встроены в язык.
1. Когда начинается взаимодействие с внешним миром, для качественного описания контракта приходится написать очень много кода.
2. Когда начинается конкурентное программирование, начинаются костыли. В обычном ОО-языке синхронизацию и доступ, свободный от блокировок, можно изящно реализовать. В концепции дизайна по контракту — нет.
Майер предложил идею маркировать типы специальным образом; с помощью этой насадки можно реализовать потоковую модель наподобие Microsoft COM Apartment, но у неё есть известные ограничения. Когда на CSA Russia в ЕКБ пару лет назад аудитория начала говорить ему об этом, он психанул, бросил на пол ноутбук и выбежал из аудитории :-)
Знали бы Вы, какие замечательные ответы у меня есть от Минсвязи. Но об этом напишет, мы договорились, должен написать другой человек.
После 1 июля 2012 года произойдёт одно из двух.
1. Регуляторы просто снимут денег на аккредитации. Мы, СКБ Контур, уже готовы пройти её по проекту, будет проект номер 2 — будем готовы по нему, будет финальный вариант — не пройдёт и недели, как у нас всё будет готово к аккредитации.
2. Всех насадят, и останется один удостоверяющий центр: ОАО «Ростелеком». Это маловероятно, так как Ростелеком за 10 лет не смог со всем адм. ресурсом в Минсвязи, со всеми деньгами, которые им давали на наём субподрядчиков, субсубподрядчиков и субсубсубподрядчиков сделать ровным счётом ничего. Этот путь погубит ЭЦП/КЭП, ФНС и ПФР заключат прямые соглашения с налоговыми агентами/страхователями, пышным цветом расцветут удостоверяющий центры без аккредитации, все выберут себе технологии и удостоверяющие центры самостоятельно, без помощи регуляторов.
1. Если система правильно спроектирована (а для большинства решаемых на практике задач это сделать не сложно, знание передаётся быстро и в большом объёме зафиксировано в книгах), скорость выполнения не имеет значения. Имеют значение качество сисадмина, вместительность дата-центра и наличие лавэ. Если нет лавэ, проблема не в реализации идеи, а в самой идее.
2. Хорошее ТДД помимо выделения интерфейсов порождает изменение направления зависимостей. Это облегчает создание новых фич в версии номер 2.
3. ТДД облегчает переход к непрерывной интеграции, а та в свою очередь облегчает деплой по кнопке «Пыщь». Оба фактора порождают у разработчиков ответственность поддерживать систему в работоспособном состоянии всё время.
4. ТДД увеличивает объём кода на объём кода тестов, но тесты — это доступная разработчику спецификация. Текст и диаграммы — это недоступная разработчику спецификация.
5. ТДД подталкивает к парному программированию при решении сложных задач, что есть хорошо само по себе, но вдобавок подталкивает к объему владению кодом. Правда, там где применяется парное программирование, необходимо применять санитаров для вылавливания троешников.
6. ТДД упрощает многим хорошистам решение задач, которые умеют решать только отличники. Как правило, в команды приходят хорошисты, если конечно Ваш работодатель не в числе небожителей (яндексы, гугели и прочие фэйсбуки).
Аккредитация по 1-ФЗ и аккредитация по 63-ФЗ — это разные процедуры.
1-ФЗ устанавливает правила использования ЭЦП и перестаёт действовать после 1 июля 2012 года, а областью действия 63-ФЗ является только электронная подпись (простая, неквалифицированная, квалифицированная подписи, но не электронная цифровая). Поэтому, чтобы выпускать квалифицированные сертификаты нужно пройти аккредитацию по 63-ФЗ. То есть, наличие аккредитации по 1-ФЗ перестаёт быть сколько-либо значимым свойством 1 июля 2012 года.
В посте просто делается вывод, что Ростелеком выдаёт квалифицированные сертификаты электронной подписи, а на самом деле это сертификаты электронной цифровой подписи, признаваемые квалифицированными. Основные нюансы таковы.
1. Ростелеком и владелец сертификата ЭЦП выполняют обязанности и имеют права по старому закону, а не по новому. В частности, владелец сертификата должен обеспечивать тайну закрытого ключа, а не обеспечивать конфиденциальность. А Ростелеком, например, не может приостановить действие сертификата иначе, чем на основании указаний от органов, владельца сертификата или его работодателя.
2. Электронная подпись равнозначна собственноручной только если выполнены требования по старому закону. Например, в новом законе говорится о подписании документов пачками (e-mail с вложениями), а в старом — нет. Или, скажем, в старом говорится о том, бумажный документ с печатью и подписью можно заменить электронным документом с подписью только в случаях, установленных законом или соглашением сторон.
Хочется уточнить, что Ростелеком, как и другие удостоверяющие центры, не является аккредитованным по 63-ФЗ «Об электронной подписи». Он является удостоверяющим центром, действующим в соответствии с 1-ФЗ «Об электронной цифровой подписи».
Требования к средствам подписи, средствам удостоверяющего центра и формату квалифицированного сертификата до сих пор ещё не приняты ФСБ, хотя Путин утверждал в июне план принятия подзаконных актов, и эти три должны были быть приняты до 31 августа. Таким образом, Ростелеком выпускает сертификаты электронной цифровой подписи, приравненные к квалифицированным сертификатам. Но это он мог делать и до принятия 63-ФЗ!
Строго говоря, я не про шифрование рассказывал, потому что нет ничего о паддинге, а если есть паддинг, то это уже не так интересно и не так просто. Симметричные шифры из той же оперы.
1. Состояние, разделённое (shared) потоками, должно быть как можно меньше.
2. Доступ к разделённым данным должен производиться через как можно меньшее количество входных точек.
3. Работа с разделёнными данными должна быть либо блокирующей, либо неблокирующей.
3.1. Если работа блокирующая, надо проектировать в терминах последовательностей операций, не нарушающих заранее определённые инварианты.
3.2. Если работа не блокирующая, надо чётко определять гарантии работы кода в плане доступа к протухшим данным.
В Эйфеле проблемы возникают с пунктом 3: описанные инварианты (собственно инварианты, постусловия, предусловия) обеспечивают корректность только для неразделённых данных.
Идея дизайна по контракту — неплохая, но не тогда, когда контракты встроены в язык.
1. Когда начинается взаимодействие с внешним миром, для качественного описания контракта приходится написать очень много кода.
2. Когда начинается конкурентное программирование, начинаются костыли. В обычном ОО-языке синхронизацию и доступ, свободный от блокировок, можно изящно реализовать. В концепции дизайна по контракту — нет.
Майер предложил идею маркировать типы специальным образом; с помощью этой насадки можно реализовать потоковую модель наподобие Microsoft COM Apartment, но у неё есть известные ограничения. Когда на CSA Russia в ЕКБ пару лет назад аудитория начала говорить ему об этом, он психанул, бросил на пол ноутбук и выбежал из аудитории :-)
После 1 июля 2012 года произойдёт одно из двух.
1. Регуляторы просто снимут денег на аккредитации. Мы, СКБ Контур, уже готовы пройти её по проекту, будет проект номер 2 — будем готовы по нему, будет финальный вариант — не пройдёт и недели, как у нас всё будет готово к аккредитации.
2. Всех насадят, и останется один удостоверяющий центр: ОАО «Ростелеком». Это маловероятно, так как Ростелеком за 10 лет не смог со всем адм. ресурсом в Минсвязи, со всеми деньгами, которые им давали на наём субподрядчиков, субсубподрядчиков и субсубсубподрядчиков сделать ровным счётом ничего. Этот путь погубит ЭЦП/КЭП, ФНС и ПФР заключат прямые соглашения с налоговыми агентами/страхователями, пышным цветом расцветут удостоверяющий центры без аккредитации, все выберут себе технологии и удостоверяющие центры самостоятельно, без помощи регуляторов.
2. Хорошее ТДД помимо выделения интерфейсов порождает изменение направления зависимостей. Это облегчает создание новых фич в версии номер 2.
3. ТДД облегчает переход к непрерывной интеграции, а та в свою очередь облегчает деплой по кнопке «Пыщь». Оба фактора порождают у разработчиков ответственность поддерживать систему в работоспособном состоянии всё время.
4. ТДД увеличивает объём кода на объём кода тестов, но тесты — это доступная разработчику спецификация. Текст и диаграммы — это недоступная разработчику спецификация.
5. ТДД подталкивает к парному программированию при решении сложных задач, что есть хорошо само по себе, но вдобавок подталкивает к объему владению кодом. Правда, там где применяется парное программирование, необходимо применять санитаров для вылавливания троешников.
6. ТДД упрощает многим хорошистам решение задач, которые умеют решать только отличники. Как правило, в команды приходят хорошисты, если конечно Ваш работодатель не в числе небожителей (яндексы, гугели и прочие фэйсбуки).
1-ФЗ устанавливает правила использования ЭЦП и перестаёт действовать после 1 июля 2012 года, а областью действия 63-ФЗ является только электронная подпись (простая, неквалифицированная, квалифицированная подписи, но не электронная цифровая). Поэтому, чтобы выпускать квалифицированные сертификаты нужно пройти аккредитацию по 63-ФЗ. То есть, наличие аккредитации по 1-ФЗ перестаёт быть сколько-либо значимым свойством 1 июля 2012 года.
В посте просто делается вывод, что Ростелеком выдаёт квалифицированные сертификаты электронной подписи, а на самом деле это сертификаты электронной цифровой подписи, признаваемые квалифицированными. Основные нюансы таковы.
1. Ростелеком и владелец сертификата ЭЦП выполняют обязанности и имеют права по старому закону, а не по новому. В частности, владелец сертификата должен обеспечивать тайну закрытого ключа, а не обеспечивать конфиденциальность. А Ростелеком, например, не может приостановить действие сертификата иначе, чем на основании указаний от органов, владельца сертификата или его работодателя.
2. Электронная подпись равнозначна собственноручной только если выполнены требования по старому закону. Например, в новом законе говорится о подписании документов пачками (e-mail с вложениями), а в старом — нет. Или, скажем, в старом говорится о том, бумажный документ с печатью и подписью можно заменить электронным документом с подписью только в случаях, установленных законом или соглашением сторон.
Требования к средствам подписи, средствам удостоверяющего центра и формату квалифицированного сертификата до сих пор ещё не приняты ФСБ, хотя Путин утверждал в июне план принятия подзаконных актов, и эти три должны были быть приняты до 31 августа. Таким образом, Ростелеком выпускает сертификаты электронной цифровой подписи, приравненные к квалифицированным сертификатам. Но это он мог делать и до принятия 63-ФЗ!
Я как-нибудь расскажу про ЭльГамаль и ГОСТ-2001.