Pull to refresh
8
0
jamayka @jamayka

User

Send message

Я бы предложил ввести градацию вознаграждений: более и менее вкусные шоколадки, разное количество или что-то подобное. А уже конкретный вид или количество вознаграждения определять рандомом. Пусть полное отсутствие вознаграждения тоже будет доступно, но было довольно редко. Даже в вашем примере с плохой курицей человек получает чувство сытости.

Мда, просто шок от статьи. В юности, когда кончались деньги на Интернете, подменял МАК на соседский, чтобы проверить почту или написать кому-нибудь в аське, тратил обычно килобайт 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 описание просто немного более расплывчатое, но, по-моему, все равно вполне однозначное.
Почитайте тут на странице 60. Ваш псевдокод должен быть:
for (var i = arguments.length; i--; ) {
    link(arguments[i], formalParameters[i]);
}
Здесь немного есть. На русском действительно немного информации.

На английском статья на developer.mozilla.org
Да, увидел в посте ссылку на баг в файерфоксе. Во-первых, он давно уже пофиксан, а во-вторых, он совершенно не имеет отношения к вашему коду.
К сожалению, из-за бага в трёх популярных браузерах(IE, Fx, Opera) я не смог добиться желаемого эффекта

О каком баге идет речь? По-моему, наоборот упомянутые браузеры более строго соответствуют спецификациям ECMA.
function test(a, b) {
    arguments[0] = 100;
    arguments[1] = 101;
    console.log(a,b);
}
test(1,2); // => 100, 101
test(1); // => 100, undefined

Потому как динамическая связь устанавливается только для реально переданных аругментов:
(...) 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!
Ээээ, у меня такое работает на третьем: screencast.com/t/NTRlOWYwMzA

Или я что-то не так понял?
У меня есть хорошее готовое решение для этой проблемы. Есть поддержка переходов по страницам внутри ифрэйма, поддержка динамического изменения высоты. С удовольствием опубликовал бы, но кармы не хватает. Сколько кармы нужно, чтобы опубликовать хотя бы в личный блог?
Ладно согласен — плохой пример в демонстрации хорошего плагина. :)
Это смотря как применять.

Если это страница регистрации, то форма является основным элементом — тут, согласен, экономия места на пояснениях абсолютно ни к чему. Главное, чтобы информация была усвоена на сто процентов.

Если же страница посвящена чему-то другому, а форма — лишь второстепенный элемент предназначенный для уменьшения кликов, то такая экономия вполне оправдана. Формы авторизации, поиска, подписки и т.п.
Перемотайте эту страницу наверх — вы увидите форму поиска с серенькой надписью.
Откройте главную страницу Яндекса — форма логина с серыми надписями.
Откройте новую вкладку в файерфоксе или в сафари — в строке адреса серенькая надпись.

Они везде, и это уже привычно.
Спасибо за проделанную работу. Надеюсь, на этом не остановишься.
Например, было бы здорово указывать класс контейнера подсказки. Чтобы он искал .next('.help') к примеру, и если такого соседа нету, то оставлять инпут в изначальном состоянии. А то сейчас невозможно добавить такие подсказки выборочно лишь для некоторых инпутов.

А вообще, если бы я делал для себя, я бы еще запихал в конфиг название евента (или евентов), который бы следовало прослушивать у инпута, и по которому копировать классы. Т.е. если параллельно работает валидатор и он отлавливает ошибку в поле, то делает всю работу по визуализации ошибки, а потом файерит евент «afterInputError». Вот его то и отлавливает наш helpInput и копирует классы у изменившегося инпута… Но это если бы я делал для себя :))) А так классный плагин.

Ну и, конечно, невнятные ключи конфига — это, как уже писали выше, очень плохо.
Так вот, порочная практика — это полагаться на здравый ум программиста… Как показывает опыт — это последнее на что можно полагаться, особенно если работаешь не один :))

Модель-обсервер не будет работать (кто-то хочет оповещать других о получении данных), или модель которая работает с каким-нибудь сингелтоном (тот же Zend_Registry)… Не знаю даже, что еще можно притянуть. :))) Вообщем, при росте проекта можно получить небольшой гемор (а куда без него), а так вполне нормальное решение.
По мне так, довольно порочная практика. Потому как мы при работе с моделью должны держать в голове специфику ее работы: как она хранит данные, что случается за интерфейсом при вызове метода. Т.е. согласитесть, $model->cached_insert($row) будет работать уже совсем не так, как хотелось бы. Плюс кастомные методы модели, например, $employees->payTo($id)… А что будет если мы вызовем cached_payTo($id)? Т.е. логика работы с данными выносится за рамки класса. Мне кажется, что модель сама должна определять, что можно кэшировать, а что нет. Хотя для мелких проектов с парой-тройкой контроллеров может быть так и удобнее.
Zend_Form::setDefaultTranslator($translator);
А у тебя XSS :)

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+
1

Information

Rating
Does not participate
Registered
Activity