Недавно обнаружил, что на странице успешного завершения заказа (Thank You Page) странице у 2Checkout не отображается лицензионная информация. Написал им, они признали ошибку, через некоторое время сообщили, что исправили ее. Проверяю в свежем Chrome — отображается, проверяю в Firefox ESR 52.9.0 — не отображается. При этом в FF и сама страница, и весь процесс покупки выглядят совершенно адекватно — у покупателя нет ни малейшего повода заподозрить неладное. Vendor Dashboard в этой же версии тоже работает прекрасно.
Написал им снова с вопросом, откуда такая разница. Получил ответ в стиле "сожалеем, но страница Thank You сделана с использованием новых элементов, не поддерживаемых устаревшими браузерами". То есть, ситуацию, в которой в каких-то браузерах все выглядит нормально, за исключением полного отсутствия важной части страницы, ничто не указывает на проблему, и при этом ни пользователь, ни вендор не получают сообщений об ошибках, они считают совершенно нормальной.
Блин, на таком фоне даже как-то неловно критиковать службы поддержки за то, что первым делом предлагают перезапустить браузер, очистить кэш, попробовать другой браузер и т.п. Если вроде бы профессиональные веб-программеры ваяют такое для обработки онлайн-покупок...
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Тогда кому ваяют профессиональные, и как их отличить?
В вебе нет профессиональных программистов, там фреймворки каждый год новые. Ни один нормальный программист не будет этим заниматься. Поэтому там всякая молодежь пишет.
ЕМ>за исключением полного отсутствия важной части страницы
Важной для кого? Задача регистратора — показать сумму платежа и формочку для ввода номера карты. Ну и получить процент с транзакции. А насчёт лицензий пусть покупатель разбирается с продавцом софта.
Вообще, лицензию можно показывать на своём сайте, и уже оттуда перенаправлять покупателя на сайт регистратора.
Броузер-то действительно старый. Если человек не обновляет броузер, забил на безопасность, то он не тот человек, который попросит лицензию (вероятно он купил не тот софт, которому она вообще нужна, он мог не знать даже, что покупает не продукт, а лицензию).
2. Да и какому проценту юзеров вообще нужно читать лицензию?
Да не читает их никто. Максимум людей интересует FAQ по лицензии: что можно, а что нельзя — это может быть только на сайте.
Те, кому реально нужна лицензия — попросят, тут вообще нет проблемы, о первом таком нуждающемся вы бы уже знали.
3. Насколько эта проблема критична?
Она вообще не критична: ссылка на лицензию есть на сайте (на котороый отправляется ссылка) или в программе, или программа ссылается на сайт, где она есть.
Итого: ну баг и баг. Минорный-преминорный. Из-за чего сыр-бор?
Всё новое это хорошо забытое старое. IE 6 only сайты видимо уже забыли, а я помню.
А так да, так и есть. Хром это новый IE. Если под ним работает, остальное уже по остаточному принципу. Ещё Safari проверяют, хоть там и процент небольшой, но у них обычноо денег много, поэтому они интересны. Фаерфокс никому не интересен, там только гики. Если в программистах такого гика не затесалось, так и будет получаться. Про graceful degradation, когда без новых возможностей страница будет отображаться настолько хорошо, насколько возможно, уже все забыли. По сути это money-oriented development, всё оценивается с точки дохода, а не с философской или идеологической точки зрения.
Здравствуйте, L.K., Вы писали:
LK>Важной для кого?
Для покупателя, который оплачивает весь банкет, и вендора, который дает возможность кормиться регистратору.
LK>Задача регистратора — показать сумму платежа и формочку для ввода номера карты. Ну и получить процент с транзакции. А насчёт лицензий пусть покупатель разбирается с продавцом софта.
А что гарантирует регистратору отсутствие оттока и покупателей, и вендоров в результате таких вот косяков?
LK>Вообще, лицензию можно показывать на своём сайте, и уже оттуда перенаправлять покупателя на сайт регистратора.
Как именно это будет работать при использовании регистратора, если код у регистратора кривой?
Здравствуйте, sharez, Вы писали:
S>1. Сколько пользователей подвержено проблеме? S>Выходит, 0.25% где-то (FF 52 и старее).
В случае использования голого HTML/CSS такой подход можно было бы считать допустимым. Но там же сплошь JS. Это как если бы писалась обычная нативная программа под некую ОС, использовала относительно новую особенность (например, флаг) без проверки того, что ОС ее должным образом понимает, и в более старых версиях это приводило бы к неявному нарушению поведения.
S>Броузер-то действительно старый. Если человек не обновляет броузер, забил на безопасность, то он не тот человек
...который готов легко выкинуть привычный и настроенный набор плагинов, не поддерживаемый более новыми версиями браузера.
S>который попросит лицензию (вероятно он купил не тот софт, которому она вообще нужна, он мог не знать даже, что покупает не продукт, а лицензию).
Это уже какие-то рассуждения из области чистой философии.
S>2. Да и какому проценту юзеров вообще нужно читать лицензию?
"Лицензионная информация" — это ключи, приватные ссылки и т.п. Instant Fulfillment.
S>Итого: ну баг и баг. Минорный-преминорный. Из-за чего сыр-бор?
Я опять все пропустил, и вместо корректного кода нынче считается правильным разрабатывать минимально глючный?
Здравствуйте, vsb, Вы писали:
vsb>IE 6 only сайты видимо уже забыли, а я помню.
Я хорошо помню и просто IE-only сайты середины 90-х.
vsb>Про graceful degradation, когда без новых возможностей страница будет отображаться настолько хорошо, насколько возможно, уже все забыли.
Именно поэтому я и предлагаю разграничивать веб-страницы (ресурсы, предназначенные главным образом для получения информации) и веб-приложения (ресурсы, предназначенные главным образом для выполнения действий). Graceful degradation в полной мере относится только к информационным ресурсам, поскольку лучше получить часть информации, чем ничего. Приложение же обязано работать либо правильно, либо никак, поэтому к ним этот подход должен применяться только в контролируемом виде — перед использованием функции приложение обязано убедиться, что она доступна.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Итого: ну баг и баг. Минорный-преминорный. Из-за чего сыр-бор?
ЕМ>Я опять все пропустил, и вместо корректного кода нынче считается правильным разрабатывать минимально глючный?
Да, причём давно уже. Корректный код — вообще довольно недостижимая штука ещё с древних времён. А так вообще, если расписать затраты времени на обеспечение совместимости с конкретным браузером в расчёте на одного пользователя, то сразу становится видна вся экономика.
Здравствуйте, sharez, Вы писали:
S>Броузер-то действительно старый. Если человек не обновляет броузер, забил на безопасность, то он не тот человек, который попросит лицензию (вероятно он купил не тот софт, которому она вообще нужна, он мог не знать даже, что покупает не продукт, а лицензию).
Судя по некоторым комментариям в исходном коде страницы www.2checkout.com, разработчики непонятно зачем пытаются поддерживать IE8, который вышел лет на десять раньше, чем Firefox 52.9.0 ESR.
<!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
<!--[if lt IE 9]>
<script src="/assets/js/html5shiv.js"></script>
<script src="/assets/js/respond.min.js"></script>
<![endif]-->
Здравствуйте, Sharowarsheg, Вы писали:
S>Корректный код — вообще довольно недостижимая штука ещё с древних времён. А так вообще, если расписать затраты времени на обеспечение совместимости с конкретным браузером в расчёте на одного пользователя, то сразу становится видна вся экономика.
Я о другом. Например, многие реализации *printf корректно обрабатывают передачу nullptr для %s, подставляя что-нибудь вроде "(null)". Но я нигде не видел, чтобы за код, не проверяющий передаваемый указатель, не били бы по голове (максимум), или хотя бы относились к нему снисходительно (минимум). Если такая особенность замечена — она безусловно считается ошибкой, и притом грубой, даже если бы за последние десять лет не было выпущено ни одной реализации, падающей на nullptr.
Ну как тут в очередной раз не подчеркнуть принципиального различия между веб-страницами и веб-приложениями, которого большинство упорно не хочет признавать?
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Корректный код — вообще довольно недостижимая штука ещё с древних времён. А так вообще, если расписать затраты времени на обеспечение совместимости с конкретным браузером в расчёте на одного пользователя, то сразу становится видна вся экономика.
ЕМ>Я о другом. Например, многие реализации *printf корректно обрабатывают передачу nullptr для %s, подставляя что-нибудь вроде "(null)". Но я нигде не видел, чтобы за код, не проверяющий передаваемый указатель, не били бы по голове (максимум), или хотя бы относились к нему снисходительно (минимум). Если такая особенность замечена — она безусловно считается ошибкой, и притом грубой, даже если бы за последние десять лет не было выпущено ни одной реализации, падающей на nullptr.
Я может чего не понял, но я за много лет ни разу не проверял никакие указатели, и ничего, все довольны. Упадёт, тогда разберёмся.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>я за много лет ни разу не проверял никакие указатели, и ничего, все довольны.
ЕМ>То есть, в Вашем коде конструкции, подобные "p == nullptr" или "p != nullptr" полностью отсутствуют?
Есть, конечно, например, там где нужно найти ровно один объект, соответствующий критерию. Там, естественно, приходится проверять. В других местах нет. Не передавай нуль, там где не надо, да и проблем не будет. Чай, не ядро пишу. Потому что как только начинаются всякие такого рода проверки, непонятно, где заканчивать. Например, ну, хорошо, проверим нуль. А теперь, проверять ли, что у ASCIIZ строки в конце есть нуль? Или пусть лучше падает уже? Или, скажем, если в массиве нужно заполнить сколько-то элементов, может ли число элементов быть нуль? А если да, то указатель на массив может быть нуль или нет? Я предпочитаю не плодить вот это всё заблаговременно, а решать по мере поступления.
S>>Упадёт, тогда разберёмся.
ЕМ>Каким образом разбираетесь?
.NET очень удобная штука. Смотришь стек, и всё видно.
Здравствуйте, Sharowarsheg, Вы писали:
S>Не передавай нуль, там где не надо, да и проблем не будет.
Так я и не передаю. Но я это умею делать только с помощью проверки на нуль. Научите избегать передачи нуля, не проверяя значение указателя — буду передавать без проверки.
S>как только начинаются всякие такого рода проверки, непонятно, где заканчивать. Например, ну, хорошо, проверим нуль. А теперь, проверять ли, что у ASCIIZ строки в конце есть нуль?
У меня такое ощущение, что кто-то из нас другого не понимает. У Вас нигде не используются функции вроде strchr/strstr, нет вызовов функций API, которые могут вернуть нулевой указатель?
S>>>Упадёт, тогда разберёмся.
ЕМ>>Каким образом разбираетесь?
S>.NET очень удобная штука. Смотришь стек, и всё видно.
В стеке все видно и без .NET. Меня интересует, что Вы делаете по результатам разбирательства.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>У меня такое ощущение, что кто-то из нас другого не понимает. У Вас нигде не используются функции вроде strchr/strstr, нет вызовов функций API, которые могут вернуть нулевой указатель?
Эээ, нет. В .NET всякие .IndexOf() или .BinarySearch() возвращают integer, а не указатель.
S>>>>Упадёт, тогда разберёмся.
ЕМ>>>Каким образом разбираетесь?
S>>.NET очень удобная штука. Смотришь стек, и всё видно.
ЕМ>В стеке все видно и без .NET. Меня интересует, что Вы делаете по результатам разбирательства.
Нахожу ту ветку, где я забыл создать объект, и создаю его, наверное. Не то чтобы это очень часто было, мне даже трудо себе представить такое. Ну и в любом случае, если я пишу функцию (типа printf), которая будет получать объект, и этот объект действительно нужен (а не опциональный параметр, которые я не люблю и не пишу), то я не проверяю параметров. Сказано, требуется объект на входе, значит, будет объект. Если будет нуль, пусть падает.
Здравствуйте, Sharowarsheg, Вы писали:
S>В .NET всякие .IndexOf() или .BinarySearch() возвращают integer, а не указатель.
Ко всем функциям WinAPI, возвращающим указатели, имеются шлюзы, бросающие исключения? А какая разница, проверять указатель или обрабатывать исключение?
S>Ну и в любом случае, если я пишу функцию (типа printf), которая будет получать объект, и этот объект действительно нужен (а не опциональный параметр, которые я не люблю и не пишу), то я не проверяю параметров. Сказано, требуется объект на входе, значит, будет объект. Если будет нуль, пусть падает.
Это как раз понятно. Мне интересно, как Вы избавились от всех без исключения источников нулевых указателей без единой проверки на нуль.
ЕМ>Ко всем функциям WinAPI, возвращающим указатели, имеются шлюзы, бросающие исключения? А какая разница, проверять указатель или обрабатывать исключение?
Для всех практических применений никакого винапи в .NET нету.
ЕМ>Это как раз понятно. Мне интересно, как Вы избавились от всех без исключения источников нулевых указателей без единой проверки на нуль.
WinAPI выкидываешь, переходишь к .NET, и сразу становится проще. Никаких источников нулевых указателей, кроме меня самого. Наверное, Java даёт что-то похожее тоже, но я не знаю, не пробовал.
