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