реакция совсем другая: «это непрактично», «всего не предусмотришь»
А ведь так и есть, собственно, из идеи «всего не предусмотришь» и выросла философия аджайл. Другое дело, когда программисты просто ленятся или не могут(в силу неразвитости абстрактного мышления) качественно продумать концепцию во всех аспектах перед реализацией. То есть им, грубо говоря, проще сначала вырыть траншею, а потом уже посмотреть, ровная ли она и подровнять(или подг***ять), если не очень. Работаю в среднестатистической веб-конторе, таких большинство.
Скажем так, в REST'е отсутствие состояния — краеугольный камень, и если это требование нарушено, возникает вопрос, а рест ли это, или рест-подобная поделка, которых сейчас очень много? В соапе использование состояния во многих случаях неизбежно и его отсутствие — это скорее исключение.
это популярное заблуждение, почитайте:
http://www.ibm.com/developerworks/library/ws-spmyths/
over HTTP или нет, значения не имеет.
REST же stateless по своему определению.
RESP был прекрасен по сравнению с подходами вроде SOAP своей stateless философией, и именно популяризацию такой философии я считаю основной заслугой REST'a. С другой стороны, использование протокола НТТР для описания семантики приложения — это ужасный рак, прокрустово ложе, в которое мы себя добровольно загоняем. Весь этот сыр-бор — из-за классической ошибки, называемой «смешение уровней абстракции», которая произошла с протоколом НТТР. этот прокотол описывает взаимодействие между узлом сети и ресурсом. Но разработчики НТТР решили также включить в набор статусов терминологию, которая относится к бизнес-логике конкретного приложения, и залезли таким образом на уровень выше, куда лезть не следовало. Я имею ввиду как статусы вроде Payment Required, так и более завуалированную ересь вроде Created(зачем такой ответ? Если запрос явно предполагал создание чего-либо, то достаточно ответа ОК, то есть, «все получилось»). Резюмируя, я бы сказал, что рест является удачным и еффективным подходом, построенным на ошибочной концепции.
Какой из этого выход? Таки использовать JSON-pure АРІ и иметь возможность точно описать всю специфическую для приложения логику, не только Payment Required, а и, скажем, Upgrade Account required, или Admin rights required, и что заблагорассудится.
Символы в сновидениях — вполне научная тема, которую развивали Фрейд и особенно Юнг со своими последователями. Или для вас наука — это только таблетки?
«Как REST-архитектура влияет на скорость и надежность работы сайта» — так же, как наличие домашней собаки влияет на долголетие ее хозяина. То есть, напрямую собака на это никак не влияет, но ее приходится регулярно выгуливать, укрепляя таким образом свое здоровье.
Исходя из главного принципа REST — stateless — очевидно, что сервер, таким образом, будет разгружен, но станет ли от этого быстрее сайт в целом — еще вопрос.
Интересная статья, достаточно просто и понятно описаньі основньіе понятия React. Однако некоторьіе важніье моментьі остались за кадром.
Тут описано, как можно организовать рендеринг отдельньіх компонентов, и реагирование на собьітия внутри них. А как организовано «общение» компонентов и их координация? К примеру, во вложенном компоненте происходит собьітие, а среагировать на него должен родительский компонент(или даже соседний). Как это описать?
Можно ли «расшарить» изменяемьіе данньіе между несколькими компонентами(«реактивная коллекция»)?
Спасибо за материал! Вопросы: координаты переводятся в точки на изображении согласно какой-либо проекции. Какая используется у вас?
У вас там есть какая-то формула, но она никак не описана.
Этот код случайно не выложен где-нибудь на гитхабе в виде библиотеки?
>>>Однако жизнь не может состоять из одного сплошного эксперимента. Точнее, нужно отделять среду для экспериментов и среду для жизни
«Вся жизнь — эксперимент. Чем больше экспериментов вы сделаете, тем лучше.» — Эмерсон. Думаю, он имел ввиду, конечно, не научные эксперименты в узком смысле, а вообще подход к жизни как к постоянному поиску чего-то нового и интересного, отказ от автоматизации.
О том, что для проявления креативности полезны жесткие внешние условия, писал еще Азимов в своей повести «Профессия». Кстати, она в украинских школах входит в программу по зарубежной литературе.
Совершенное верно! Также русские != россияне, русские != русичи, русские != украинцы, русские != беларусы, русские != казахи, русские != полинезийцы и т.п., вот это нужно помнить.
Обидно, когда под одну гребенку попадают разные народы, при этом для запада все это подается под общей вывеской «Русские». Если во времена СССР это еще можно было понять, т.к. мы были одной страной, то сейчас уже это выглядит несколько… странно.
Привет всем минусующим совкам-шовинистам!
Ну как всегда, «Русские на Кикстартере» — и дальше оказывается, что речь идет о проектах в т.ч. из Украины и Беларуси! Ох уж эти тесные объятия старшего брата) Не срача ради, а честости для: определитесь, либо вы о русских пишете, либо о проектах из СНГ.
О чем эта статья? Никакой логической линии повествования не просматривается. Автор, вероятно, был так пресыщен впечатлениями, что писал вперемешку абсолютно все, что у него отложилось в голове после этой увлекательной поездки.
Стал бы профессиональным массажистом. Сейчас занимаюсь массажами параллельно с программированием, и иногда, особенно после 10-часового сидения на стуле в офисе, проскакивает мысль, а не сменить ли работу? ;) Программирование люблю, но свое здоровье дороже.
А ведь так и есть, собственно, из идеи «всего не предусмотришь» и выросла философия аджайл. Другое дело, когда программисты просто ленятся или не могут(в силу неразвитости абстрактного мышления) качественно продумать концепцию во всех аспектах перед реализацией. То есть им, грубо говоря, проще сначала вырыть траншею, а потом уже посмотреть, ровная ли она и подровнять(или подг***ять), если не очень. Работаю в среднестатистической веб-конторе, таких большинство.
http://www.ibm.com/developerworks/library/ws-spmyths/
over HTTP или нет, значения не имеет.
REST же stateless по своему определению.
Да, полностью согласен, а к чему вы повторили общеизвестный факт?
Какой из этого выход? Таки использовать JSON-pure АРІ и иметь возможность точно описать всю специфическую для приложения логику, не только Payment Required, а и, скажем, Upgrade Account required, или Admin rights required, и что заблагорассудится.
Исходя из главного принципа REST — stateless — очевидно, что сервер, таким образом, будет разгружен, но станет ли от этого быстрее сайт в целом — еще вопрос.
Тут описано, как можно организовать рендеринг отдельньіх компонентов, и реагирование на собьітия внутри них. А как организовано «общение» компонентов и их координация? К примеру, во вложенном компоненте происходит собьітие, а среагировать на него должен родительский компонент(или даже соседний). Как это описать?
Можно ли «расшарить» изменяемьіе данньіе между несколькими компонентами(«реактивная коллекция»)?
У вас там есть какая-то формула, но она никак не описана.
Этот код случайно не выложен где-нибудь на гитхабе в виде библиотеки?
«Вся жизнь — эксперимент. Чем больше экспериментов вы сделаете, тем лучше.» — Эмерсон. Думаю, он имел ввиду, конечно, не научные эксперименты в узком смысле, а вообще подход к жизни как к постоянному поиску чего-то нового и интересного, отказ от автоматизации.
Обидно, когда под одну гребенку попадают разные народы, при этом для запада все это подается под общей вывеской «Русские». Если во времена СССР это еще можно было понять, т.к. мы были одной страной, то сейчас уже это выглядит несколько… странно.
Привет всем минусующим совкам-шовинистам!
Давайте без шовинизма.
if(records.length && false) {И еще
$.each(records, function(i, el){my_all_data["n"+el.id] = {};my_all_data["n"+el.id] = el;