Я бы предложил ввести градацию вознаграждений: более и менее вкусные шоколадки, разное количество или что-то подобное. А уже конкретный вид или количество вознаграждения определять рандомом. Пусть полное отсутствие вознаграждения тоже будет доступно, но было довольно редко. Даже в вашем примере с плохой курицей человек получает чувство сытости.
Мда, просто шок от статьи. В юности, когда кончались деньги на Интернете, подменял МАК на соседский, чтобы проверить почту или написать кому-нибудь в аське, тратил обычно килобайт 100 не больше, потом другого соседа. Если бы тогда мне попалась такая халява, то наверное бы настриг себе пачку купонов. Как хорошо, что теперь я вроде бы думаю головой и не делаю таких глупостей, и как хорошо, что мне не попадались такие ситуации, когда я был неразумен.
Думаю, что большинство сделали это, не задумываясь о том, что же они делают на самом деле. А теперь, когда уже сделано, не позволяют себе задумываться и спирают вину на организатора.
Не коснулись такой интересной темы как объявление рекурсивных функций. Например, у нас есть тупо факториал, который используется в куче кода:
var factorial = function (n) {
return n === 1 ? 1 : factorial(n - 1) * n;
};
ну или
function factorial(n) {
return n === 1 ? 1 : factorial(n - 1) * n;
};
Потом по каким-то причинам нам нужно
var realFactorial = factorial;
factorial = function (n) {
throw 'please use realFactorial instead';
};
В итоге получается, что и вызовы factorial(5) и realFactorial(5) вываливают ошибку. Это получается, т.к. рекурсивный вызов factorial использует переменную из родительской области видимости, а там она переопределяется. В этом случае надо определять функцию так:
var factorial = function factorial (n) {
return n === 1 ? 1 : factorial(n - 1) * n;
};
Ну или чтобы не путаться:
var factorial = function f (n) {
return n === 1 ? 1 : f(n - 1) * n;
};
Для каждого неотрицательного числа arg, меньшего значения свойства length создаётся свойство с именем (...)
Здесь имеется ввиду свойство length созданное на предыдущем шаге. Т.е. не свойство функции, а свойство только что созданного оьъекта arguments. В ES3 описание просто немного более расплывчатое, но, по-моему, все равно вполне однозначное.
Потому как динамическая связь устанавливается только для реально переданных аругментов:
(...) named data properties of an arguments object whose numeric name values are less than the number of formal parameters of the corresponding function object initially share their values with the corresponding argument bindings in the function’s execution context. This means that changing the property changes the corresponding value of the argument binding and vice-versa. (...)
До этой фразы идет подробное описание как строить этот объект «arguments» — формальные аргументы не переданные фактически в «arguments» не попадают.
Так именно по этой причине и надо соответствовать RFC, а не своим догадкам какой email может быть. Мне уже далеко не раз приходилось доделывать чужую валидацию (email'ов в том числе), потому что предыдущий программист считает, что RFC — это для зануд. Перед ем как работать со стандартами — ВСЕГДА почитай сначала RFC!
У меня есть хорошее готовое решение для этой проблемы. Есть поддержка переходов по страницам внутри ифрэйма, поддержка динамического изменения высоты. С удовольствием опубликовал бы, но кармы не хватает. Сколько кармы нужно, чтобы опубликовать хотя бы в личный блог?
Если это страница регистрации, то форма является основным элементом — тут, согласен, экономия места на пояснениях абсолютно ни к чему. Главное, чтобы информация была усвоена на сто процентов.
Если же страница посвящена чему-то другому, а форма — лишь второстепенный элемент предназначенный для уменьшения кликов, то такая экономия вполне оправдана. Формы авторизации, поиска, подписки и т.п.
Перемотайте эту страницу наверх — вы увидите форму поиска с серенькой надписью.
Откройте главную страницу Яндекса — форма логина с серыми надписями.
Откройте новую вкладку в файерфоксе или в сафари — в строке адреса серенькая надпись.
Спасибо за проделанную работу. Надеюсь, на этом не остановишься.
Например, было бы здорово указывать класс контейнера подсказки. Чтобы он искал .next('.help') к примеру, и если такого соседа нету, то оставлять инпут в изначальном состоянии. А то сейчас невозможно добавить такие подсказки выборочно лишь для некоторых инпутов.
А вообще, если бы я делал для себя, я бы еще запихал в конфиг название евента (или евентов), который бы следовало прослушивать у инпута, и по которому копировать классы. Т.е. если параллельно работает валидатор и он отлавливает ошибку в поле, то делает всю работу по визуализации ошибки, а потом файерит евент «afterInputError». Вот его то и отлавливает наш helpInput и копирует классы у изменившегося инпута… Но это если бы я делал для себя :))) А так классный плагин.
Ну и, конечно, невнятные ключи конфига — это, как уже писали выше, очень плохо.
Так вот, порочная практика — это полагаться на здравый ум программиста… Как показывает опыт — это последнее на что можно полагаться, особенно если работаешь не один :))
Модель-обсервер не будет работать (кто-то хочет оповещать других о получении данных), или модель которая работает с каким-нибудь сингелтоном (тот же Zend_Registry)… Не знаю даже, что еще можно притянуть. :))) Вообщем, при росте проекта можно получить небольшой гемор (а куда без него), а так вполне нормальное решение.
По мне так, довольно порочная практика. Потому как мы при работе с моделью должны держать в голове специфику ее работы: как она хранит данные, что случается за интерфейсом при вызове метода. Т.е. согласитесть, $model->cached_insert($row) будет работать уже совсем не так, как хотелось бы. Плюс кастомные методы модели, например, $employees->payTo($id)… А что будет если мы вызовем cached_payTo($id)? Т.е. логика работы с данными выносится за рамки класса. Мне кажется, что модель сама должна определять, что можно кэшировать, а что нет. Хотя для мелких проектов с парой-тройкой контроллеров может быть так и удобнее.
Я бы предложил ввести градацию вознаграждений: более и менее вкусные шоколадки, разное количество или что-то подобное. А уже конкретный вид или количество вознаграждения определять рандомом. Пусть полное отсутствие вознаграждения тоже будет доступно, но было довольно редко. Даже в вашем примере с плохой курицей человек получает чувство сытости.
Думаю, что большинство сделали это, не задумываясь о том, что же они делают на самом деле. А теперь, когда уже сделано, не позволяют себе задумываться и спирают вину на организатора.
ну или
Потом по каким-то причинам нам нужно
В итоге получается, что и вызовы factorial(5) и realFactorial(5) вываливают ошибку. Это получается, т.к. рекурсивный вызов factorial использует переменную из родительской области видимости, а там она переопределяется. В этом случае надо определять функцию так:
Ну или чтобы не путаться:
Здесь имеется ввиду свойство length созданное на предыдущем шаге. Т.е. не свойство функции, а свойство только что созданного оьъекта arguments. В ES3 описание просто немного более расплывчатое, но, по-моему, все равно вполне однозначное.
На английском статья на developer.mozilla.org
О каком баге идет речь? По-моему, наоборот упомянутые браузеры более строго соответствуют спецификациям ECMA.
Потому как динамическая связь устанавливается только для реально переданных аругментов:
До этой фразы идет подробное описание как строить этот объект «arguments» — формальные аргументы не переданные фактически в «arguments» не попадают.
Или я что-то не так понял?
Если это страница регистрации, то форма является основным элементом — тут, согласен, экономия места на пояснениях абсолютно ни к чему. Главное, чтобы информация была усвоена на сто процентов.
Если же страница посвящена чему-то другому, а форма — лишь второстепенный элемент предназначенный для уменьшения кликов, то такая экономия вполне оправдана. Формы авторизации, поиска, подписки и т.п.
Откройте главную страницу Яндекса — форма логина с серыми надписями.
Откройте новую вкладку в файерфоксе или в сафари — в строке адреса серенькая надпись.
Они везде, и это уже привычно.
Например, было бы здорово указывать класс контейнера подсказки. Чтобы он искал .next('.help') к примеру, и если такого соседа нету, то оставлять инпут в изначальном состоянии. А то сейчас невозможно добавить такие подсказки выборочно лишь для некоторых инпутов.
А вообще, если бы я делал для себя, я бы еще запихал в конфиг название евента (или евентов), который бы следовало прослушивать у инпута, и по которому копировать классы. Т.е. если параллельно работает валидатор и он отлавливает ошибку в поле, то делает всю работу по визуализации ошибки, а потом файерит евент «afterInputError». Вот его то и отлавливает наш helpInput и копирует классы у изменившегося инпута… Но это если бы я делал для себя :))) А так классный плагин.
Ну и, конечно, невнятные ключи конфига — это, как уже писали выше, очень плохо.
Модель-обсервер не будет работать (кто-то хочет оповещать других о получении данных), или модель которая работает с каким-нибудь сингелтоном (тот же Zend_Registry)… Не знаю даже, что еще можно притянуть. :))) Вообщем, при росте проекта можно получить небольшой гемор (а куда без него), а так вполне нормальное решение.
alfsoft.ru/wordgen.php?word=Author+does+not+know+anything+about+%3Ca+href%3Dhttp%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCross-site_scripting%3EXSS%3C%2Fa%3E.+He+is+