Обычно, чтобы понять назначение RPC запроса, нужно научит ифоаструктуру хотя бы на базовом уровне понимать тело этих запросов. Возьмём самое простое — кэширование. В http/rest у идемпотентных запросов есть явные характеристики, и большенство из них можно смело кэшировать. У RPC запросов, не ясно, есть ли у метода side effects и является ли он безопасным для кэширования. В этой ветке хорошо заметили — RPC почти не оставляет на уровне HTTP подсказок о себе, для него, это всего лишь транспорт.
Если простыми словами, то, тут есть два основных момента, и один второстепенный, где REST должен отличатся в лучшую сторону.
1. REST является platform agnostic способом общения, который требует от платформы только поддержки HTTP. На одном конце может быть С++ сервис, а на другом Javascript, если они оба могут в HTTP, значит у них уже из коробки общая система управления кэшированием, редиректов, повторных запросов, ошибок, аутентификации и прочих вещей которые уже включает себя HTTP.
2. Инфраструктура. Между сервисами общающимися с помощью HTTP/REST, может быть легко построено любое количество инфраструктуры отвечающей за балансировку, проксирование, кэширование, безопасность, логирование, редиректы, нетворкинг и многое другое, без каких либо изменений в коде сервиса. Так как почти все инфраструктурные сервисы/тулзы поддерживают HTTP, a REST по своей природе опирается на все возможности HTTP, а не просто использует его как транспорт.
3. HATEOAS
PS: я не сторонник REST. Но, если мне нужно будет работать с legacy инфраструктурой, я предпочту REST.
Были минусы, и наверное, они по делу, я не удосужился объяснить детальнее. Посмотрите на код внимательнее. Это не фабрика, это не функция конструктор, это анонимная функция, которая сразу же, при запросе модуля, вызывается, и результат работы которой присваивается переменной LinkedListDeque, которая потом экспортируется. Замыкание которая эта функция создаёт, не несет никакого смысла к контексте модулей commonJS которые тут используются. Оно не предотвращает side effects и не инкасплуриует какой-либо функционал.
Писать в таком стиле есть смысл, только, если помимо этого кода, в файле модуля есть еще какой-то функционал, от которого следует изолироваться, что уже было бы неправильно с точки зрения cohesion элементов внутри модуля.
Статья приводит хороший пример из функционального программирования, в частности, о преимуществе pure functions. К основному примеру, замыкания описанные выше, не имеют никакого отношения. Но этот пример, мог бы отлично продемонстрировать то, как можно применить каррирование, которое является отличным примером паттерна функционального программирования, который может помочь избавиться от this.
Хотел еще добавить, что часто именно модель содержит логику валидации, так что не придеться дублировать этот код. Это очень помогает когда абстракция приложения не подразумивает какие либо невалидные состояния.
Я не копал глубоко React. А разве проблема держать модели и коллекции в виде конкретных полей state? Причем в плане MVC так даже болле логично, вью есть представление конкретной модели. Т.к. работаем со ссылками, экономим место и скорость. И собирать ничего не нужно, компонент возвращает модель с которой работает, при этом в приложении исчезают моменты когда происходит работа с какими либо промежуточными состояниями, только модели.
Это скорее пригодится для кандидатов на должность junior/middle SQA. Сейчас же больше смотрят на опыт работы и навыки, а не на то, как человек оформляет баги, тем более на новом месте скорее всего будут свои требования к оформлению. Сразу смотрим на то, в каких командах и проектах участвовал кандидат, есть ли опыт бизнес аналитики, Agile, автоматического тестирование и CI. Например, мы экспериментировали, когда в небольшой команде, SQA специалист был одновременно и скрам мастером, получилось вполне успешно. Это будут основные критерия предварительно отбора, а такое портфолио было бы приятным дополнением.
Если уж и смотреть на портфолио, то скорее хотелось бы увидеть тест план, описание/расчеты рисков etc.
Кстати, могу сразу сказать, что всяко лучше сделать отдельное резюме на каждом языке, когда в день просматриваешь ряд кандидатов и это превращается в рутину, то большие объемы текста и чередование языков вызывают только раздражение. Тем более для иностранных заказчиков, для которых кириллица выглядит не намного понятнее арабской вязи. А лучше оставить только на английском.
Откуда этот фанатизм? Я о выдавливании из себя критических комментариев. Тут есть действительно отличные замечания, я даже поблагодарил за них и проплюсовал. Но иногда бывают бессмысленные замечания, чуть ли не на уровне — «В JS это не нужно!». Вы ведь, я полагаю, понимаете, что ваша реализация тут не уместна. Скрипт занимается мониторингом серверов, и если, например, нужно сделать 1000 снапшотов состояний серверов за определенный промежуток времени, такая реализация, по крайней мере в таком виде, будет совсем не уместна.
И это естественно, ведь для демонстрации этого приёма, я подогнал не реализацию под ситуацию, а наоборот. Может, и не совсем успешно.
Выше уже писал, как оказалось, в той же мозиле, прирост с new Function оказался почти не заметным, даже чуть ли не отрицательным. В данном посте решил, для наглядности, использовать eval который более привычен широкому кругу пользователей JS. Но намеренно упомянул возможность использования new Function.
Жалею, что не был более информативным по всем этим моментам в посте, так что очень рад таким замечательным правкам в комментариях.
он сам оптимизировал свой код экспериментально(алхимия), а не на основе структурированных знаний о V8 (химия)
Это как раз то что подвигло меня поделится этим подходом со всеми. Если об этом можно было прочитать в методичке, я бы хмыкнул, и продолжил бы листать :)
Кстати, именно таким подходом, я обнаружил что, например в той же мозиле, eval будет работать быстрее чем new Function, так что для наглядности решил оставить его.
Хотя, в моем коде на Node.js, я использовал исключительно new Function подход.
Спасибо за правку. Изначально скорость мерил у себя на живом проекте, а бенчамарк метод накидал специально для этого поста. Потом конечно спохватился по некоторым моментам, но посчитал что уже поздно, тем более основной посыл был в другом, и вы всё идеально расписали.
По словам разработчика одного из самых быстрых MySQL driver'ов для Node.js, этот подход помог ему выиграть эти же 30% при парсинге полей в ответах с сервера.
Естественно этот метод далеко не панацея, и всё очень сильно зависит от ситуации.
Подход интересный, и в принципе себя уже неоднократно оправдал, на довольно крупных сервисах. Но, как я уже говорил выше, он уступает полноценным JS шаблонизаторам.
А под разметкой вы подразумеваете HTML код?
Все преимущества и удобства есть в моем ответе выше.
Недостатком можно назвать то что для правки существующего шаблона, кодеру нужно будет провести пятиминутный ликбез. Так-же для конвертации html -> JSBuilder для больших шаблонов, у нас на проекте был написан небольшой скрипт в 50 строк.
Сохраняет вложенную структуру HTML для лучшего понимания, в принципе ее редактировать может даже кодер, при этом по размерам меньше HTML кода. Элементы генерируется во view компоненте приложения независимо от дома, что позволяет сделать пре-обработку дома до того как он появится в дом структуре. К тому-же такой подход полностью убирает необходимость использовать дом селекторы, т.к. все нужные ноды уже в есть в скопе приложения.
А благодаря такой чудесной особенности ООП как полиморфизм, возможно создавать целые семейства view компонентов с возможностью их прозрачной подмены в рантайме. Причем благодаря такому подходу можно полностью редизайнить приложение, т.к. JS не привязан ни к структуре DOM, ни к id/class/tagname. Все преимущества на лицо.
Естественно дом строитель уступает по гибкости шаблонизаторам как в этой статье.
P.S. А как на это поисковики реагируют, адекватно?
Честно говоря, никогда не занимался сайтами. Делаю в основном приложения и веб сервисы, там SEO вообще не стоит как задача.
Круто, уже много лет назад отказался от HTML, правда не дошли руки написать свой шаблонизатор, так что написал классический дом строитель который позволяет быстро и удобно создавать ноды в JS, тем самым избавившись от привязки JS к существующему дому, сделав его провайдером view приложения.
Выглядит примерно так:
Говорите за себя. Я уже шесть лет пишу различного уровня сложности приложения (именно приложения, а не rich сайты), когда выбор выпадает на JS, всегда пользуюсь ванилой, изредка приправляя ее различным third party code. Причем map, reduce, some, let, yeld и прочее, уже есть в большинстве реализаций JS, в других случая большинство этих вещей реализуются программно. С прямыми руками на JS возможна реализация высоких абстракций и практически всех популярных паттернов.
JS виноват только в том, что в отличие от других популярных языков, он требует другого подхода.
блиотеки типа jQuery меняют в принципе способ обращения с броузерным окружением
Положа руку на сердце, нужно признать, что jQuery сам по себе большой антипатерн. Это вам и God object, и глобальные переменные, и размытие предметной области, и самое главное — он заставляет писать т.н. DOM Driven Applications, что возможно хорошо для сайтов, но губительно для SPA и RIA. Нужно признать что для этих целей есть множество других замечательных фреймворков.
Я кстати уже писал в то время когда зарождался Jquery, и заметил резкое падение уровня JS программистов. Теперь приходя на собеседование, парень может кое-как рассказать про объектную модель JS, но что-то по теории функционального или объектного программирования спрашивать, зачастую, бесполезно.
(42.toString() — fails; 42..toString --ok),
Тут всё логично. Причем в JS есть много действительно интуитивно непонятных вещей, например результат работы конструктора, когда он возвращает примитив, и когда он возвращает объект. Но почитав спецификацию, поведения языка становится абсолютно предсказуемым и понятным.
Обычно, чтобы понять назначение RPC запроса, нужно научит ифоаструктуру хотя бы на базовом уровне понимать тело этих запросов. Возьмём самое простое — кэширование. В http/rest у идемпотентных запросов есть явные характеристики, и большенство из них можно смело кэшировать. У RPC запросов, не ясно, есть ли у метода side effects и является ли он безопасным для кэширования. В этой ветке хорошо заметили — RPC почти не оставляет на уровне HTTP подсказок о себе, для него, это всего лишь транспорт.
1. REST является platform agnostic способом общения, который требует от платформы только поддержки HTTP. На одном конце может быть С++ сервис, а на другом Javascript, если они оба могут в HTTP, значит у них уже из коробки общая система управления кэшированием, редиректов, повторных запросов, ошибок, аутентификации и прочих вещей которые уже включает себя HTTP.
2. Инфраструктура. Между сервисами общающимися с помощью HTTP/REST, может быть легко построено любое количество инфраструктуры отвечающей за балансировку, проксирование, кэширование, безопасность, логирование, редиректы, нетворкинг и многое другое, без каких либо изменений в коде сервиса. Так как почти все инфраструктурные сервисы/тулзы поддерживают HTTP, a REST по своей природе опирается на все возможности HTTP, а не просто использует его как транспорт.
3. HATEOAS
PS: я не сторонник REST. Но, если мне нужно будет работать с legacy инфраструктурой, я предпочту REST.
Писать в таком стиле есть смысл, только, если помимо этого кода, в файле модуля есть еще какой-то функционал, от которого следует изолироваться, что уже было бы неправильно с точки зрения cohesion элементов внутри модуля.
Статья приводит хороший пример из функционального программирования, в частности, о преимуществе pure functions. К основному примеру, замыкания описанные выше, не имеют никакого отношения. Но этот пример, мог бы отлично продемонстрировать то, как можно применить каррирование, которое является отличным примером паттерна функционального программирования, который может помочь избавиться от this.
Тут не имеет смысла ничего замыкать, модуль в котором вы пишите этот код делает это за вас:
Этот код, во всех случаях, будет работать так-же:
Если уж и смотреть на портфолио, то скорее хотелось бы увидеть тест план, описание/расчеты рисков etc.
Кстати, могу сразу сказать, что всяко лучше сделать отдельное резюме на каждом языке, когда в день просматриваешь ряд кандидатов и это превращается в рутину, то большие объемы текста и чередование языков вызывают только раздражение. Тем более для иностранных заказчиков, для которых кириллица выглядит не намного понятнее арабской вязи. А лучше оставить только на английском.
И это естественно, ведь для демонстрации этого приёма, я подогнал не реализацию под ситуацию, а наоборот. Может, и не совсем успешно.
Жалею, что не был более информативным по всем этим моментам в посте, так что очень рад таким замечательным правкам в комментариях.
Кстати, именно таким подходом, я обнаружил что, например в той же мозиле, eval будет работать быстрее чем new Function, так что для наглядности решил оставить его.
Хотя, в моем коде на Node.js, я использовал исключительно new Function подход.
www.youtube.com/watch?v=Kdwwvps4J9A
Естественно этот метод далеко не панацея, и всё очень сильно зависит от ситуации.
А под разметкой вы подразумеваете HTML код?
Недостатком можно назвать то что для правки существующего шаблона, кодеру нужно будет провести пятиминутный ликбез. Так-же для конвертации html -> JSBuilder для больших шаблонов, у нас на проекте был написан небольшой скрипт в 50 строк.
Сохраняет вложенную структуру HTML для лучшего понимания, в принципе ее редактировать может даже кодер, при этом по размерам меньше HTML кода. Элементы генерируется во view компоненте приложения независимо от дома, что позволяет сделать пре-обработку дома до того как он появится в дом структуре. К тому-же такой подход полностью убирает необходимость использовать дом селекторы, т.к. все нужные ноды уже в есть в скопе приложения.
А благодаря такой чудесной особенности ООП как полиморфизм, возможно создавать целые семейства view компонентов с возможностью их прозрачной подмены в рантайме. Причем благодаря такому подходу можно полностью редизайнить приложение, т.к. JS не привязан ни к структуре DOM, ни к id/class/tagname. Все преимущества на лицо.
Естественно дом строитель уступает по гибкости шаблонизаторам как в этой статье.
Честно говоря, никогда не занимался сайтами. Делаю в основном приложения и веб сервисы, там SEO вообще не стоит как задача.
Выглядит примерно так:
Больше всего понравилась ваша идея с пост/препроцессорами. Правда думаю было бы круче как-то их доработать, добавить чуточку магии :)
JS виноват только в том, что в отличие от других популярных языков, он требует другого подхода.
Положа руку на сердце, нужно признать, что jQuery сам по себе большой антипатерн. Это вам и God object, и глобальные переменные, и размытие предметной области, и самое главное — он заставляет писать т.н. DOM Driven Applications, что возможно хорошо для сайтов, но губительно для SPA и RIA. Нужно признать что для этих целей есть множество других замечательных фреймворков.
Я кстати уже писал в то время когда зарождался Jquery, и заметил резкое падение уровня JS программистов. Теперь приходя на собеседование, парень может кое-как рассказать про объектную модель JS, но что-то по теории функционального или объектного программирования спрашивать, зачастую, бесполезно.
Тут всё логично. Причем в JS есть много действительно интуитивно непонятных вещей, например результат работы конструктора, когда он возвращает примитив, и когда он возвращает объект. Но почитав спецификацию, поведения языка становится абсолютно предсказуемым и понятным.