>Сколько существует пятизначных номеров (номера могут начинаться с нуля), у которых есть две подряд стоящих одинаковых цифры?
Не очень хорошая формулировка, учитывая, что требуется не решение, а результат. Не вполне понятно, может ли номер начинаться с нескольких нулей. И попадает ли, соответственно, номер 00123 под условие.
Два года живу с WebNames.
На письма саппорт не отвечает, это факт.
Но я не горюю — звоню. Проблемы сразу решаются.
С технической точки зрения нареканий особых нет. Сайт глючит, это факт, но всегда нужное действие выполнить можно. Просто не всегда из того окна, где ты это пробуешь сделать :)
Скажем так, в теории я понимаю, что может быть лучше, но на практике боюсь, что у другого регистратора окажутся те же яйца, только в профиль. Поэтому пока мои домены делегированы и пока телефон у них работает, уходить не буду :)
Давно интересовал вопрос, не расскажете? Московские банки (ну, какие-то, по крайней мере) пишут, что пин-код никто, кроме банкомата, не должен спрашивать. В Москве так и есть. Приезжаю в тот же Воронеж — в каком-то магазине попросили ввести пин-код на кассе. Корректно ли это? И как работает такая касса, которой нужен пин-код? Не как банкомат ли? То есть, будет ли снят дополнительный процент с покупки, как если бы я снимал наличку через банкомат?
Ну, про мастеров не знаю. Могу поделиться своим опытом. Я, будучи КМС-ом, на простых стенках учился правильно ставить ноги, не стучать по скалодрому. Учился плавности движений. Это помогает на более серьёзных трассах. Помнится, тренеры на скалах всегда загоняли нас на «положительные» стенки (т. е. такие, которые «лежат», а не нависают). Чтобы работали ногами: руками там просто не за что хвататься, только придерживаться.
Я там выше уже ответил. Проблемы именно со «сразу отгружаемым товаром». Но Вы правы, в случае хостинга, например, откатить платёж и забанить сервер — плёвое дело. Если только кто-то и правда сверяет бухгалтерские документы с реальностью. Я лично не уверен в дисциплине мелких компаний.
>Вот лично я так и не понял, каким образом предлагается бороться с несовершенством протоколов платёжных систем или агрегаторов платежей?
Бороться с несовершенством протоколов никак не предлагается. Предлагается не верить слепо «ненадёжным» протоколам. Предлагается понимать, где кроется «ненадёжность». В некоторых случаях можно пробовать повышать надёжность — например, добавляя проверку сертификата к HTTPS-соединению (иногда это можно сделать и иногда это будет, скажем так, не совсем глупой затеей).
Ну и, что немаловажно, предлагается также не писать «плохие» протоколы, ежели кому-то из читателей вдруг придётся этим заниматься.
Это наиболее актуально для магазинов, которые торгуют «сразу отгружаемой» информацией. Например, хостинги, доменные регистраторы или сервисы по продаже статей.
Кстати, сейчас задумался: я знаю одного доменного регистратора, который зачисляет деньги на счёт сразу (при оплате картой через Ассист). Называть не буду. Но, возможно, там всё хорошо: проверки реже, чем раз в 10 минут осуществлять можно. Если 2 клиента не попадают в 10-минутный промежуток, то всё относительно надёжно работает.
Довольно странно, что об этом мало информации в интернете. Если честно, я не удивлюсь, если разработчики нескольких магазинов «слепо» верят, что товар оплачен, если осуществился переход на ok_return_url. Среди сотен клиентов наверняка есть те, кто «не подумал».
Кстати, короткая заметка в Вашем блоге — чуть ли не единственное, что я могу вспомнить на эту тему.
Да, это очевидная мысль. К сожалению, когда я начал писать заметку, я думал, что она получится раза в 2 короче. Потом я пообщался с несколькими разработчиками и понял, что люди в целом часто понимают «что-то», но цельной картины у них нет (например, даже касательно того, как же на самом деле работает https).
Поэтому пришлось кое-какие моменты увеличить в размере. Разбивать же заметку на 2-3 статьи — это отдельный не вполне простой труд, на это времени уже не нашлось (я прошу прощения, но се ля ви).
Кроме того, мне кажется, что многие вещи из верхней части статьи должны быть очевидны (а в статье они просто упорядочены), поэтому верхняя часть просто «пролистается» многими читателями.
Согласен. Скорее, это вырезка из общих рекомендаций для межпроектного взаимодействия + указание на то, о чём надо думать в первую очередь.
Я думаю, это имеет некоторую ценность для разработчиков, которые сталкиваются с разработкой веб-сервисов впервые. Чтобы меньше было лажи (а лаже есть, о чём я и говорю в статье).
Очень интересно, особенно насчёт генерации машинного кода «на лету». Жаль только, что практически не рассказали, где это используется. Насколько я понимаю эту область, это либо титанический труд (+ сложно поддерживаемый код), либо покрытие частных случаев.
С одной стороны, видно, что база быстро обновляется (купили домен 3-5 дней назад, он уже в базе). Но есть и ошибки. Примеры: домены dm9.ru, metaver.ru переехали на другой IP уже очень давно (2-4 месяца). Сервис же до сих пор указывает на старые адреса.
Не очень хорошая формулировка, учитывая, что требуется не решение, а результат. Не вполне понятно, может ли номер начинаться с нескольких нулей. И попадает ли, соответственно, номер 00123 под условие.
На письма саппорт не отвечает, это факт.
Но я не горюю — звоню. Проблемы сразу решаются.
С технической точки зрения нареканий особых нет. Сайт глючит, это факт, но всегда нужное действие выполнить можно. Просто не всегда из того окна, где ты это пробуешь сделать :)
Скажем так, в теории я понимаю, что может быть лучше, но на практике боюсь, что у другого регистратора окажутся те же яйца, только в профиль. Поэтому пока мои домены делегированы и пока телефон у них работает, уходить не буду :)
WebMoney так делают.
>Вот лично я так и не понял, каким образом предлагается бороться с несовершенством протоколов платёжных систем или агрегаторов платежей?
Бороться с несовершенством протоколов никак не предлагается. Предлагается не верить слепо «ненадёжным» протоколам. Предлагается понимать, где кроется «ненадёжность». В некоторых случаях можно пробовать повышать надёжность — например, добавляя проверку сертификата к HTTPS-соединению (иногда это можно сделать и иногда это будет, скажем так, не совсем глупой затеей).
Ну и, что немаловажно, предлагается также не писать «плохие» протоколы, ежели кому-то из читателей вдруг придётся этим заниматься.
К сожалению, панацеи предложить не могу :)
Кстати, сейчас задумался: я знаю одного доменного регистратора, который зачисляет деньги на счёт сразу (при оплате картой через Ассист). Называть не буду. Но, возможно, там всё хорошо: проверки реже, чем раз в 10 минут осуществлять можно. Если 2 клиента не попадают в 10-минутный промежуток, то всё относительно надёжно работает.
Кстати, короткая заметка в Вашем блоге — чуть ли не единственное, что я могу вспомнить на эту тему.
Поэтому пришлось кое-какие моменты увеличить в размере. Разбивать же заметку на 2-3 статьи — это отдельный не вполне простой труд, на это времени уже не нашлось (я прошу прощения, но се ля ви).
Кроме того, мне кажется, что многие вещи из верхней части статьи должны быть очевидны (а в статье они просто упорядочены), поэтому верхняя часть просто «пролистается» многими читателями.
Я думаю, это имеет некоторую ценность для разработчиков, которые сталкиваются с разработкой веб-сервисов впервые. Чтобы меньше было лажи (а лаже есть, о чём я и говорю в статье).