Дневной оборот среднего предприятия, отправляющего платежи в банк, равен примерно сумме операций обычного физического лица за пол года-год. Отсюда мы получаем необходимость совсем разных систем для совершения операций там и там.
Получается, что в случае воровства данной суммы, предприятие находится в лучших условиях, нежели физик — физику-то нужно год «пахать», чтобы обернуть сумму, которую «среднее предприятие» оборачивает за день.
Физик вынужден гораздо чаще «светить» секретные реквизиты, совершая покупки в различных интернет- и оффлайн- магазинах.
У физика нет профессионального системного администратора, для квалифицированного обслуживания компьютера.
Банки предоставлют физикам заведомо более дырявые (удобные) способы доступа, с использованием ПО общего назначения, а так же упрощенные системы контроля операций со своей стороны.
Выходит, риски физика заведомо выше, чем у предприятия. В этой связи предложения банков в виде платного смс-информирования и страховок стоимостью 1-2% от максимальной суммы выплаты выглядят свежо и необычно. ;)
Вся спецификация вот тут rfc2396. Синаксис URI, в самом общем случае, имеет вид:
<scheme>:<scheme-specific-part>
Вот и весь обязательный синтаксис. Если посмотреть дальше, то окажется что и scheme не обязательна, т.к. существуют Relative URI. В остатке, по большому счету, важен только алфавит, а все остальные нюансы записи адресов — что считать обязательным, а что нет — это частное дело приложений.
Я понимаю вашу точку зрения. Думаю, корни заморочки нужно искать в том, что собой представляет архитектура клиент-сервер. Данная модель описывает *приложения*, которые состоят из нескольких взаимодействующих *программ*.
Модель назначает программам разные роли. Это дает опредленные бонусы разработчикам. Но с точки зрения конечного результата все это нужно воспринимать как составные части единого приложения. Т.е. сервер, браузер, прокси, джаваскипты, флеш-плееры и проч. это все программы, которые являются составными частями того приложения, результат работы которого вы можете наблюдать у себя на экране. Или не наблюдать, если какая-то программа падает. URL как таковые, тут совершенно не причем — они ни как не влияют на «живучесть» приложения в результате сбоев потому, что это всего лишь адреса. :)
Всё верно: трактовка адресов зависит от конкретного приложения — если фрагмент считается обязательным, значит так надо. Тут нет противоречий.
Можно провести аналогию с привычными адресами: для таксиста важно знать название улицы и номер дома, куда подать машину; для почтальона обязательным будет так же номер квартиры (ведь он не может оставить вашу телеграмму просто где-то возле дома).
довольно острую проблему в эпоху web 2.0, а именно чистоту URL-адресов.
Это нифига не проблема — «чистота» адресов и её полезность весьма субъективна. URI это идентификатор. Ну давайте ещё поборемся за чистоту айдишников).
Вот меняться они, по хорошему, не должны — здесь я согласен с авторской критикой.
# — это специальный символ URL, который сообщает браузеру, что последующая часть адреса представляет собой ссылку на HTML элемент с таким id или именованый якорь (named anchor) текущей страницы.
Это очень частный случай. По большому счету, часть url, именуемая fragment, указывает на фрагмент данных. Содержательный смысл этого термина, трактуется клиентом по собственному усмотрению. Например это может быть начальной позицией для отображения видеопотока, состоянием приложения, css-селектором для фрагмента html и т.п.
Так что на мой взгляд — единственная разница межу assert и @Requires в том, что @Requires не нужно выискивать в коде метода.
Технически — всё верно.
Принципеальная разница в том, что ассерты являются частью реализации, а контракты это часть интерфейса. Поэтому, по идее, можно придумать способ для их статической верификации.
я рассуждаю так. учитывая в), фича может быть полезна для авторизации с чужого компа — в командировке, например. но как раз в роуминге входящие блокируются при отрицательном балансе.
Раз сделали резервные коды и приложения для генерации кодов, то телефон с sms'ками в этой схеме, кажется, лишние (а если баланс ушел в минус, то и почту уже не посмотреть?).
Как узнали, что я увидел? ;) Я увидел знакомую метафору:
Интерфейс операционной системы «вращается» вокруг метафоры названной «карточками». Нажатие на физическую кнопку «Home» открывает экран, на котором все запущенные приложения выглядят как небольшие карточки. Вы можете переключаться между «карточками», проводя пальцем по экрану вправо или влево. Когда вы найдете на экране карточек нужное приложение, простое нажатие на карточку переводит приложение в полноэкранный режим.
в презентации hypercard Аткинсон рассказывал о том же самом. С той лишь разницей, что управлялось оно не пальцами, а мышью.
по-моему, ответ соискательницы это равноценный троллинг, в ответ на неэтичный, по сути, вопрос.
Получается, что в случае воровства данной суммы, предприятие находится в лучших условиях, нежели физик — физику-то нужно год «пахать», чтобы обернуть сумму, которую «среднее предприятие» оборачивает за день.
Физик вынужден гораздо чаще «светить» секретные реквизиты, совершая покупки в различных интернет- и оффлайн- магазинах.
У физика нет профессионального системного администратора, для квалифицированного обслуживания компьютера.
Банки предоставлют физикам заведомо более дырявые (удобные) способы доступа, с использованием ПО общего назначения, а так же упрощенные системы контроля операций со своей стороны.
Выходит, риски физика заведомо выше, чем у предприятия. В этой связи предложения банков в виде платного смс-информирования и страховок стоимостью 1-2% от максимальной суммы выплаты выглядят свежо и необычно. ;)
Вот и весь обязательный синтаксис. Если посмотреть дальше, то окажется что и scheme не обязательна, т.к. существуют Relative URI. В остатке, по большому счету, важен только алфавит, а все остальные нюансы записи адресов — что считать обязательным, а что нет — это частное дело приложений.
Модель назначает программам разные роли. Это дает опредленные бонусы разработчикам. Но с точки зрения конечного результата все это нужно воспринимать как составные части единого приложения. Т.е. сервер, браузер, прокси, джаваскипты, флеш-плееры и проч. это все программы, которые являются составными частями того приложения, результат работы которого вы можете наблюдать у себя на экране. Или не наблюдать, если какая-то программа падает. URL как таковые, тут совершенно не причем — они ни как не влияют на «живучесть» приложения в результате сбоев потому, что это всего лишь адреса. :)
=)
Можно провести аналогию с привычными адресами: для таксиста важно знать название улицы и номер дома, куда подать машину; для почтальона обязательным будет так же номер квартиры (ведь он не может оставить вашу телеграмму просто где-то возле дома).
Это нифига не проблема — «чистота» адресов и её полезность весьма субъективна. URI это идентификатор. Ну давайте ещё поборемся за чистоту айдишников).
Вот меняться они, по хорошему, не должны — здесь я согласен с авторской критикой.
Это очень частный случай. По большому счету, часть url, именуемая fragment, указывает на фрагмент данных. Содержательный смысл этого термина, трактуется клиентом по собственному усмотрению. Например это может быть начальной позицией для отображения видеопотока, состоянием приложения, css-селектором для фрагмента html и т.п.
Технически — всё верно.
Принципеальная разница в том, что ассерты являются частью реализации, а контракты это часть интерфейса. Поэтому, по идее, можно придумать способ для их статической верификации.
м: але, это кто?
г: «гугл»
с: «мама, это мне, проверка авториз..»
м: «сиди, уроки делай»
в презентации hypercard Аткинсон рассказывал о том же самом. С той лишь разницей, что управлялось оно не пальцами, а мышью.
Ответ эппловскому iPad компания Hewlett-Packard списала у эппла — Hypercard (Apple, 1987).
Парни, вы молодцы. Но зачем этот детективный креатифф в каждой статье? — читать противно. Тут хабр, а не «НТВ». :)