Интеграционные тесты (цель которых — иметь большое покрытие и, грубо говоря, отлавливать 404) в UI действительно могут быть автоматизированы влоть до автогенерации множества сценариев.
Текстовые поля (в том числе с числами) можно заполнять одной из подсказок, всплывающей после ввода одной буквы/цифры или пары символов. Правда возникает требование, иметь такие подсказки для все текстовых полей, но это требование вполне разумно и не повредит юзабилити. Для особых текстовых полей, где подсказки вредят юзабилити, можно договорится с разработчиками, что подсказки возникают только для определенного юзерагента. Разработка подсказок для каждого поля проще, тем поддерживать руками интеграционные тесты.
Ну и, конечно, как уже сказали, можно заставить разработчиков давать подсказки роботу через семантику HTML. Семантика кнопок Вперед, Назад, Расширенные настроки, например, позволит роботу не гулять по циклу в длиных визардах, а веса у ссылок и значений позволят в первую очередь покрывать типичные сценарии).
Разработчикам больше работы, зато тестеры будут заниматься только функциональными тестами бизнес логики.
И как праивльно замечено, если что-то хочется выполнить по-любасу, нужно помещать код в блок ensure.
А то, что помещено после end может не выполнится, если в begin или rescue будет выполнен оператор return
Закрыть открытые сокеты — один из важных юзкейсов
$ cat a.rb
def foo(x)
begin
return 1 / x
rescue
return 1 / (x + 1)
ensure
puts "Hi #{x}"
end
end
puts foo(1)
puts foo(0)
$ ruby a.rb
Hi 1
1
Hi 0
1
* По сути своей, ++ содержит в себе неявное присваивание в любых формах
— ну вообще говоря, ++ ассоциируется не с присваиванием, а с изменением объекта (в с++ в 99% этот оператор используют для смещения итераторов). А matz пишет про assignment, так как в Руби про потенциальный новый оператор ++x сложно думать иначе как (x+=1)
* Инкремент в префиксной форме является сахаром для операции += 1
— О каком языке идет речь? Полагаю что, о Си или С++ или о Java.
— Си: оператор ++ можно назвать сахаром для +=1, но суть в том, что там он не может менять типа переменной.
— С++: оператор ++ для новых классов обычно определяют так, что он меняет объект на месте и, конечно, не меняет класса объекта (оператор += можно определить независимо от ++ как захочется, в том числе, этот оператор может возвращать объект нового класса). И конечно, в Си++ оператор ++ не является сахаром для +=1.
— Проблем с преобразованием, а точнее, с созданием нового объекта нового класса, конечно, нет. Просто никто не ожидает, что оператор ++ будет создавать новый объект. Никто не ожидает, что x++ может сменить класс x, так как в других языках так не делают. И этой проблемы не было бы, если бы в Руби был один класс Integer===Bignum, и не было бы Fixnum и Bignum. Объекты Bignum действительно на месте можно увеличить на 1. Именно поэтому я и написал то, что написал. Укажите пожалуйста, какие идеологические проблемы были бы с введением оператора ++, если бы был один класс для всех целых чисел.
* Отказ от ++ скорее не вяжется с философией руби по возможности возвращать последнее вычисленное значение (а в случае использования постфиксной формы инкремента в си-подобных языках возвращается исходное значение)
— никакой неувязки бы не было; можно было бы реализовать и постфиксную и префиксную форму оператора с правильным возвращаемым значением. Чем вас так напугало, то что последнее вычисленное значение является возвращаемым значением метода?
Прошло всего два занятия и там было мало посетителей. Я просто пробовал. Убедился, что все проходит хорошо, и теперь готов повторить. Многое я буду повторять. Считайте, что начну сначала.
Аренда больших хранилищ + бутовая флешка (или хотя бы с автозапуском виртуальной машины) — все это есть уже сейчас. Сервиса нет. Возможности есть, хоть и без поддержки игр. С ирами готов терпеть. Чип в мозг, так и быть, тоже мне не нужен.
Что-то не очень нравитсяопределение в википедии.
Я бы написал
Замыкание — это функция, которая создается во время работы программы. Из тела этой функции доступны все переменные и функции, которые дотсупны в контексте, в котором создано замыкание. Для корректной работы замыканий необходимо, чтобы при жизни замыкания жили и локальные переменные, доступные из нее. В идеале в теле замыкания должна быть возможность делать всё, что можно делать в контексте, в котором оно было создано.
class A; def a; puts "A#a"; end; end
class B < A; def a; puts "B#a"; lambda { super }; end; end
B.new.a.call
выведет
B#a
A#a
Термин «переменные родителя» мне непонятен. Переменные объекта не знают к какому из классов в иерархии наследования они относятся. И никто не знает. То же самое касается переменных класса.
Если уж на то пошло, то самый мегакрутой совет — профилируйте, анализируйте и оптимизируйте важные места кода.
То что можно и нужно кэшировать статические страницы — это, конечно, суперновость, на на сайтах которые приходилось мне разрабатывать таких страниц был малый процент. В деле оказываются гораздо более полезны caches_action и cache do… end. см также railscasts.com/tags/18, плагин cache_fu ( errtheblog.com/posts/57-kickin-ass-w-cachefu ), ну и конечно www.railsenvy.com/2007/2/28/rails-caching-tutorial
Интеграционные тесты (цель которых — иметь большое покрытие и, грубо говоря, отлавливать 404) в UI действительно могут быть автоматизированы влоть до автогенерации множества сценариев.
Текстовые поля (в том числе с числами) можно заполнять одной из подсказок, всплывающей после ввода одной буквы/цифры или пары символов. Правда возникает требование, иметь такие подсказки для все текстовых полей, но это требование вполне разумно и не повредит юзабилити. Для особых текстовых полей, где подсказки вредят юзабилити, можно договорится с разработчиками, что подсказки возникают только для определенного юзерагента. Разработка подсказок для каждого поля проще, тем поддерживать руками интеграционные тесты.
Ну и, конечно, как уже сказали, можно заставить разработчиков давать подсказки роботу через семантику HTML. Семантика кнопок Вперед, Назад, Расширенные настроки, например, позволит роботу не гулять по циклу в длиных визардах, а веса у ссылок и значений позволят в первую очередь покрывать типичные сценарии).
Разработчикам больше работы, зато тестеры будут заниматься только функциональными тестами бизнес логики.
И как праивльно замечено, если что-то хочется выполнить по-любасу, нужно помещать код в блок ensure.
А то, что помещено после end может не выполнится, если в begin или rescue будет выполнен оператор return
Закрыть открытые сокеты — один из важных юзкейсов
— ну вообще говоря, ++ ассоциируется не с присваиванием, а с изменением объекта (в с++ в 99% этот оператор используют для смещения итераторов). А matz пишет про assignment, так как в Руби про потенциальный новый оператор ++x сложно думать иначе как (x+=1)
* Инкремент в префиксной форме является сахаром для операции += 1
— О каком языке идет речь? Полагаю что, о Си или С++ или о Java.
— Си: оператор ++ можно назвать сахаром для +=1, но суть в том, что там он не может менять типа переменной.
— С++: оператор ++ для новых классов обычно определяют так, что он меняет объект на месте и, конечно, не меняет класса объекта (оператор += можно определить независимо от ++ как захочется, в том числе, этот оператор может возвращать объект нового класса). И конечно, в Си++ оператор ++ не является сахаром для +=1.
— Проблем с преобразованием, а точнее, с созданием нового объекта нового класса, конечно, нет. Просто никто не ожидает, что оператор ++ будет создавать новый объект. Никто не ожидает, что x++ может сменить класс x, так как в других языках так не делают. И этой проблемы не было бы, если бы в Руби был один класс Integer===Bignum, и не было бы Fixnum и Bignum. Объекты Bignum действительно на месте можно увеличить на 1. Именно поэтому я и написал то, что написал. Укажите пожалуйста, какие идеологические проблемы были бы с введением оператора ++, если бы был один класс для всех целых чисел.
* Отказ от ++ скорее не вяжется с философией руби по возможности возвращать последнее вычисленное значение (а в случае использования постфиксной формы инкремента в си-подобных языках возвращается исходное значение)
— никакой неувязки бы не было; можно было бы реализовать и постфиксную и префиксную форму оператора с правильным возвращаемым значением. Чем вас так напугало, то что последнее вычисленное значение является возвращаемым значением метода?
Я бы написал
Замыкание — это функция, которая создается во время работы программы. Из тела этой функции доступны все переменные и функции, которые дотсупны в контексте, в котором создано замыкание. Для корректной работы замыканий необходимо, чтобы при жизни замыкания жили и локальные переменные, доступные из нее. В идеале в теле замыкания должна быть возможность делать всё, что можно делать в контексте, в котором оно было создано.
class A; def a; puts "A#a"; end; end class B < A; def a; puts "B#a"; lambda { super }; end; end B.new.a.callвыведет
Термин «переменные родителя» мне непонятен. Переменные объекта не знают к какому из классов в иерархии наследования они относятся. И никто не знает. То же самое касается переменных класса.
То что можно и нужно кэшировать статические страницы — это, конечно, суперновость, на на сайтах которые приходилось мне разрабатывать таких страниц был малый процент. В деле оказываются гораздо более полезны caches_action и cache do… end. см также railscasts.com/tags/18, плагин cache_fu ( errtheblog.com/posts/57-kickin-ass-w-cachefu ), ну и конечно www.railsenvy.com/2007/2/28/rails-caching-tutorial