Team Lead в 111PIXUA
  • Синхронизируем понимание REST

    работала и будет работать на ajax через json
    Как это исключает REST, противоречит ему и что значит «работать на ajax через json»? Вроде все предложения так лаконично сложены из умных слов, а техническая составляющая на уровне пятилетнего (может я, конечно, отстал от IT-сленга, но тогда вместо кидания камнями и заострения на этом внимания, объясните как всё же это исключает REST?). Вы завязываете игровую логику (что бы Вы под этим не подразумевали) на AJAX и JSON? Как вообще логика может работать на AJAX? Ладно, распрашивать каждое слово этого абзаца можно вечно...
    Без особых усилий к приведению процесса к какому-либо удобоваримому формату
    Что такое приведение процесса к формату?
    разногласие математиков с программистами
    Давайте жить в мире. Причина использования «ajax через json» — это разногласие пр... да блин, при чём здесь математики?
    У программистов переменная for(i=0;i<n;i++)
    У программистов переменная — это не цикл и не только в цикле переменные используются
    У математиков ∑ i1, i2... in
    Сумма чисел не так пишется у математиков, может программист бы так написал, но тогда зачем сравнивать цикл и сумму?
    Она либо чему-то равна, либо имеет область значений
    А чем Вам x, который принимает одно из значений в области значений, не переменная? Я здесь накатал еще какой-то комментарий про «что такое по Вашему переменная», но понял, что мне это не важно.
    Но в её функцию не входит ХРАНЕНИЕ состояния, которое может измениться.
    Я прошу прощения, но мне кажется, что математики и программисты решают разные задачи, области их (представим людей, как инструменты) применения разные. Могут пересекаться и дополнять друг друга (и могу вас уверить, что это прекрасный дуэт), но бороться и выяснять кто круче (в чём?)? Зачем? И науки дополняющие, но не взаимозаменяемы. Как сравнивать людей, которые делают рельсы и людей, которые делают поезда (и уверяю Вас, поезда в данном случае делают математики).
    Она по сути и означает состояние.
    Так переменная в математике либо чему-то равна (состояние не меняется), либо имеет область значений, а значит в какой-то момент времени принимает одно из этих значений (если мы всё же говорим о состоянии).
    То есть факт, что переменная поменяла значение, или в общем случае ссылку — ничего нового не привносит, это ожидаемое поведение
    Напомнило те забавные случаи, когда переменная стала ссылаться на ноль, а в коде она находилась в знаменателе. Хохоту было...
    По этой же причине переменные стараются типизировать, чтобы ЧЕЛОВЕЧЕСКАЯ логика не нарушалась, чтобы кроме значения переменная несла информацию ещё и о шаблоне памяти.
    Любитель не усложнять... я правда стараюсь не обсуждать каждую строчку, но моя ЧЕЛОВЕЧЕСКАЯ логика подсказывает мне, что есть люди, которые разберутся в этом предложении и скажут мне, что я м*дло и там всё просто и понятно, с объясненияим и ссылками на котиков, которые жонглируют шаблонами памяти, чтобы я становился умнее.
    математический принцип: плодить имена чтобы за каждым из них был детерменированный объект
    Не могу автора принципа найти :(
    основная работа программиста — именно изменения
    Из контекста, я так понимаю, что изменения переменных? Так получается, что всё отлично, чем больше «имён», тем больше изменений мы можем внести. Если выделять для каждого «напложенного имени» (я так понимаю, Вы имеете в виду представление) отдельный функционал, который является таки понятием в вашей системе, то изменение правил именно в этом понятии, повлечёт изменение кода только в этом «напложенном имени» и не придётся костылять, чтобы не задеть остальной функционал «ajax через json».
    Попробуйте-ка в низкоуровневом программировании заняться REST, а мы поулыбаемся.
    Где и с кем заняться REST?
    Там ограчиненный ресурс
    Ограниченный? Чем?
    Только данные, только действия над ними, только зависимости реализуемые через данные.
    Так это и есть REST?
    но в цифровой форме
    Настолько низкоуровневый?
    оснащённый полным набором инструментов
    Так чем ограниченный?
    ШАБЛОНЫ должны иметь REST-архитектуру
    ШАБЛОНЫ — это действия? это правила поведения? это команды? это контроллеры? это twig? это мышление?
    свои законы жизненного цикла
    законы улиц. Я пытаюсь понять о чём Вы пишете и если слова переменная заменить на ресурс, а ШАБЛОНЫ — на действия над ресурсами, то доля смысла в этом есть и тогда понятно, каким образом Вам помочь:
    Не стоит разделять ШАБЛОНЫ и переменные, значения переменных представляют состояние системы, а ШАБЛОНЫ позволяют переводить систему из одного состояния в другой. Но переменные бывают связаны, у некоторых переменных бывает очень много связей, но если разбирать определённый ШАБЛОН, то в рамках него могут быть необходимы только некоторые связи. И чтобы не загромождать ШАБЛОН ненужными связями, мы делаем представление нашей переменной, которое показывает её значение именно в контексте определённого ШАБЛОНА. Это позволяет в нужный момент времени заниматься только нужными связями, заниматься только определённым ШАБЛОНОМ, работать с данными, представленными (хотелось бы) объектами из предметной области именно этого ШАБЛОНА и абстрагироваться от того, как эти модели связаны с остальными ШАБЛОНАМИ и переменными.
    подчиняющиеся своим протоколам, неважно какими каналами данных они идут или в каких структурах хранятся
    Здесь аналогию я не смог додумать...
    ЕСЛИ этого избегать — получается ситуация, что просто создаётся лишний слой ненужного кода по выведению REST на передний край, а логики — в глубокие дебри фреймворков и ядерного кода. Да, красиво. Но дорого. Особенно дорого, когда это потом требуется менять.
    Красиво? Я бы прокомментрировал этот абзац, но он мне кажется далёким от истины. Дебри фреймворка из-за REST? Да он позволит тебе не закладывать в твои модели все возможные над ним действия и всё возможное поведение в разных ситуациях. Ведь так происходит и в жизни. Ты приносишь ноутбук в кафе, чтобы покодить и посмотреть ленту фейсбука, тебе важен заряд батареи, количество тематических наклеек, наличие наушников и достаточное количество USB входов для подзарядки всех твои павербэнков, но вот ты приносишь тот же ноутбук на продажу и тебе совершенно неважно ли есть остаток батареи в нём, тебе не важно количество USB, тебе важно, чтобы они не выглядели вывернутыми, потому что мама вечно дёргает провод, на котором висит телефон и вход USB уже на пол шишечки снаружи, тебе не нужны наклейки, даже наоборот, тебе нужно от них избавиться, а какой они тематики уже не важно, тебе нужна коробка и документы, ты смотришь на ноутбук по другому, теперь это товар, а не окно в твой виртуальный мир, дружок, но физически — это тот же ноутбук. При чём обрати внимание, что сущностей 4, а ресурсов 2:
    1. Ноутбук и наушники в контексте использования
    2. Ноутбук, коробка и документы в контексте продажи
    Вот тебе и представления для определённых действий, можно еще поподробнее описать, что входит в каждое представление в понятие ноутбук, они разные.
    Всё таки прокомментировал... Простите за такой грубый и детский пример, но это можно объяснить тем, что я не старался.
  • Синхронизируем понимание REST

    Религия? После этого слова захотелось прочитать комментарий. Ваш комментарий походит на религиозную проповедь, особенно степенью информативности.

    Зачем заблуждать народ? Вы говорите про CRUD или какое-то своё представление о REST, каждый д*очит REST как он хочет, каждый называет RESTом то, что он видел и то, что его коллеги называли RESTом, то, что умные ребята называют RESTом. Целью данной статьи является как раз избавление людей от этого множества определений.

    ЕДИНСТВЕННАЯ польза REST — это кеширование. Других преимуществ у данной технологии нет. Но и этого достаточно. Вы просто знаете что в любой момент времени тот ресурс что находится у вас на руках — является целостным. И что запросив его ещё раз, вы не получите ничего другого кроме факта что он есть. Всё что он может сделать — это перестать существовать.
    Какая из букв в аббревиатуре REST натолкнула Вас на мысль о кэшировании? Видимо, Дмитрий совсем забыл об этом написать. Мне кажется, что он хотел описать архитектурный подход REST, а не какие-то методы и нюансы его имплементации. Если ваше приложение написано в стиле REST, то добавить кэширование будет намного проще, потому что будут выделены все ресурсы и действия с ними, которые можно закэшировать.
    Польза REST? У меня в голове представляется настолько красивый и грамотно написанный проект с использование REST, что до фул REST его не дотягивало только отсутствие кэширования.
    Ресурс ничего не умеет делать кроме как «переставать существовать»? Какие грустные ресурсы. Мы говорим об интернет-магазине? Мне надо понимать на каких проектах Вы использовали эту REST, как Вы говорите, технологию.
    Естественно, есть изменяемые ресурсы. Но опять таки, это всё равно ресурс, и получая изменившийся ресурс вы ждёте от него такой же типизации. Может это и глупо с точки зрения логики программирования, но зато отлично вписывается в логику ЧЕЛОВЕЧЕСКУЮ: а именно — шаблонное мышление. Всё что вы получили посредством REST — вы вправе считать шаблоном.
    К чему здесь слово шаблон? В «логике программирования» изменённый ресурс должен поменять тип? Используя «человеческое» шаблонное мышление, я буду использовать то, что используют все, если я не знаю другого лучшего способа, это, пожалуй, многое объясняет в Вашем сообщении.
    Придумывать что-то ещё сверх этого — значит становиться граммарнаци от программирования, и быть посланным всеми вменяемыми кодерами. Неужели так сложно понять, что МЕНЬШЕ — ЗНАЧИТ ЛУЧШЕ. И чем проще технологию освоить, тем более она востребована.
    Ну поверх шаблоннов и кэширования даже добавить нечего.
    Кодеры редко вырастают в программистов и я не считаю, что стоить слушать их мнения.
    Меньше — значит лучше? Меньше чего? Аргументов? Сложно понять? Проще технологию? Мне кажется, или всё же Вы имели в виду «Проще — значит лучше»?
    PS. Делать проект исключительно на REST — всё равно что общаться только существительными, без глаголов. Вас даже могут понять. Но над вами будут смеяться.
    Я Вас Отрицание Понимание Причина Отсутствие Аргументов. Я даже не понял метафоры. Может лучше так:

    Делать проект исключительно на REST — всё равно, что общаться без матов. Вас поймут и вы никого не оттолкнёте, но прямо сильно изъе*нуться не получится.

    На счёт статьи, как по мне, так она довольно обрезанная, это стало понятно из комментариев людей, которые так в итоге ничего и не поняли. Стоит разобрать более подробно! С большой степенью уверенности могу сказать, что почти никто не прочитал диссертацию Роя (я в том числе).

    P.S. В своём проекте стоит быть граммар наци (по крайней мере после того, как он начал приносить деньги).