В книге: «Совершенный код. Мастер-класс. Стив МакКоннелл.» автор вам расскажет как в коде на 280 000 строк кода может быть минимум ошибок.
А так сами подумайте: почему проверяла именно НАСА. Как часто программисты этой компании допускают ошибки в исходном коде?
потому что это базовый объект во всех этих рассуждениях
Из него состоят цепочки принятия решения, он каким-то «магическим образом» реагирует на события поступившие от рецепторов.
Для того, чтобы можно было говорить о какой-то реализации, нужна отдельная статья описывающая нейрон, его связи с ближайшими элементами, его значение /механизм принятия решения
нужна алгебра мозга :) которая пока на хабре не описана
тесты все-таки привязаны к системе, являются её частью, которая спроектирована с учетом возможного поведения системы. Здесь же говорится о безусловном поведении в условиях нарушения своей целостности.
Например: пробой в системе защиты сайта обычно к приводит к повышению привилегий пользователя. Так вот правильное поведение по методу «лифта» это отсутствие привилегий до которых можно повыситься, например отсутствие привилегии администратора :) Таким образом, следования этому принципу требует исключения возможности использования скомпрометированной системы.
Если его сделать отдельным сервисом, так бы он и подох в одиночестве
а так появилась новая платформа для спама и блоггинга :)
Ждем статей сеошников типа: «трафик с buzz», «как поднять посетителей с buzz»
обезьяны слезли с дерева благодаря развитию логики, вернее синтезу идеи
синтез делится на след. этапы:
— отрицание
— анализ
— умозаключению
— систез
А вы его нарушаете ;) Поэтому я и говорю Вам — запрещено
да я уверен вы и основные функции прекрасно помните :)
только вы помните 2 библиотеки и получаете растраты по размеру кода/памяти. Вы не получаете ничего, кроме красивого кода + исключения при не нетиповых операций.
Мы все мнесте это проходили на соотв. операторах C++, спасибо увольте. Всегда проще сменить язык.
Повторю, ваш код возможно (!) станет проще для понимания, но вы и так в силах делать его понятным и простым :) В приведенном примере ничего кроме ужаса возникать не должно. Как легко мы от строки ушли в сторону целого, кажется мы поступили точно также как и в обычном php:
->insert('[вставлено]', 5)
->length() // Number
->multiply(4)
->add(6, 9, new Number(15))
Вообще не самая лучшая идея.
Давно известно, что системы генерирующие формуляры проверки на клиенте страдают несколькими проблемами:
1. сложность смены поведения валидатора на уровне клиента. Например, алерты не устраивают
2. сложность подключения собственного JS внутрь сгенерированного
3. ну и стандартные проблемы — строковые (мультиязычность)
поэтому многие команды, успешно забивают на эти вопросы и разрабатывают для каждой платформы отдельный валидатор :(
А так сами подумайте: почему проверяла именно НАСА. Как часто программисты этой компании допускают ошибки в исходном коде?
и неплохо бы провести бенчмарк
Из него состоят цепочки принятия решения, он каким-то «магическим образом» реагирует на события поступившие от рецепторов.
Для того, чтобы можно было говорить о какой-то реализации, нужна отдельная статья описывающая нейрон, его связи с ближайшими элементами, его значение /механизм принятия решения
нужна алгебра мозга :) которая пока на хабре не описана
Например: пробой в системе защиты сайта обычно к приводит к повышению привилегий пользователя. Так вот правильное поведение по методу «лифта» это отсутствие привилегий до которых можно повыситься, например отсутствие привилегии администратора :) Таким образом, следования этому принципу требует исключения возможности использования скомпрометированной системы.
а потом вам выломали почту и вы потеряли всё разом:)
а так появилась новая платформа для спама и блоггинга :)
Ждем статей сеошников типа: «трафик с buzz», «как поднять посетителей с buzz»
я говорю, что нарушается принцип, я иронизирую
свою критику я выложил выше по тексту
синтез делится на след. этапы:
— отрицание
— анализ
— умозаключению
— систез
А вы его нарушаете ;) Поэтому я и говорю Вам — запрещено
только вы помните 2 библиотеки и получаете растраты по размеру кода/памяти. Вы не получаете ничего, кроме красивого кода + исключения при не нетиповых операций.
Мы все мнесте это проходили на соотв. операторах C++, спасибо увольте. Всегда проще сменить язык.
Повторю, ваш код возможно (!) станет проще для понимания, но вы и так в силах делать его понятным и простым :) В приведенном примере ничего кроме ужаса возникать не должно. Как легко мы от строки ушли в сторону целого, кажется мы поступили точно также как и в обычном php:
— справочник функций
— справочник библиотеки
Давно известно, что системы генерирующие формуляры проверки на клиенте страдают несколькими проблемами:
1. сложность смены поведения валидатора на уровне клиента. Например, алерты не устраивают
2. сложность подключения собственного JS внутрь сгенерированного
3. ну и стандартные проблемы — строковые (мультиязычность)
поэтому многие команды, успешно забивают на эти вопросы и разрабатывают для каждой платформы отдельный валидатор :(
мы, например, начинали с подвешивания хука на свн