Pull to refresh
0
0
madkite @madkite

Software Engineer

Send message

Пускай ищут! Неплохой же стимул для авторов грамотнее изъясняться. А мы, тем самым, будем тратить своё время на чтение более качественного материала.

Там в wikitionary есть вторая статья: https://ru.wiktionary.org/wiki/попасть_впросак


Но вообще wikipedia — сомнительный источник. Хотя, судя по словарю Ушакова — там двойное написание:
https://ushakovdictionary.ru/word.php?wordid=6991
https://ushakovdictionary.ru/word.php?wordid=60578

Отсутствие динамического связывания библиотек: размеры исполняемых файлов начинаются с нескольких сотен мегабайт

Это спорный минус. Особенно на фоне всего остального кошмара.
У Google, например, на backend-е всё статически слинковано. Их стометровые бинарники пугают меньше, чем DLL Hell. А в Go — это вообще mainstream.

Для разных целей, включая тестирование. Я то, конечно, не типичный пользователь, но вполне очевидно, что сейчас телефон есть почти у каждого, включая бабушек и детей, что не скажешь про десктоп. А если брать развивающиеся страны, то там даже программируют на телефонах: https://habrahabr.ru/company/everydaytools/blog/345232/
А ещё в современном мире тот же Android пихают везде от принтеров и часов до унитазов и автомобилей. Так что мир "устройств" очень большой.

Опять же… манипулировать статистикой очень просто. В приведенной сслыке идёт про использование web-а, а не про количество устройств. Я вот и сам всё ещё хабр с десктопа по старинке читаю, хотя телефонов и планшетов у меня на порядок больше, чем десктопов.

А за укладку товаров а пакет они дополнительно денег просят? Это левые подростки подрабатывают так или же люди из штата магазина?

Среди десктопов — да. Но среди всех устройств — уже нет, т.к. десктопов в сравнении с мобилками не очень много нынче. В итоге с формальной точки зрения придраться к формулировке maisvendoo сложно. Вот так вот и манипулируют рекламщики да политики.

может быть, Кипр вам понравится, и вы захотите остаться здесь на всю жизнь

Так тут для объективности желательно сразу указать насколько "легко" получить гражданство на Кипре.

Кэш для кучи потока работает следующим образом: по завершению потока созданная для него куча отправляется в соответствующий кэш.

А можно тут подробнее, о какой "куче" идёт речь? У потоков же нет своей выделенной кучи (heap), она одна на процесс и потоки её шарят. Или имеется ввиду TLS?

Многие современные фреймворки, вроде React

Не самый удачный пример. React — это не фреймворк. Это всего лишь небольшая библиотека для рендеринга и не более. Впрочем как и Polymer.

В отличие от команды netstat, ss не выводит сведения о PID и имени команды, ответственной за конкретное соединение.

Дык netstat тоже по умолчанию не выводит этой инфы. Обеим коммандам надо ключ -p передавать для этого. Отличие лишь в формате.

Docker, в отличие от lxc, ещё очень удобно соединил это с каскадно-объединённым монтированием (union mount). В остальном — удачный маркетинг. Вроде бы все лавры должны были достаться разработчикам ядра, пилившим cgroups и т.д., но почему-то достались несложной обёртке.

Проблемы возникают из-за использования нестандартных, неопробованных, другими словами — «экзотических» решений и компонент.

Именно этим принципом на моей памяти руководствывались все менеджеры, выбирая Oracle (ведь большинство успешных компаний юзает эту СУБД). Других аргументов не было. В итоге мы приходим к некоторому стадному эффекту.

Это было про идентификацию ресурсов. По поводу использования методов HTTP (или другого протокола нижнего уровня) для семантики запросов там чуть ниже написано:


standard methods and media types are used to indicate semantics and exchange information

А ещё чуть ниже на той же странице есть пример, касательно REST поверх HTTP:


The most frequent form of request semantics is that of retrieving a representation of a resource (e.g., the "GET" method in HTTP)

А в 6-й главе REST поверх HTTP рассматривается подробнее.
В общем, если почитать диссертацию внимательнее или последующие статьи этого дядьки, то некоторая картина складывается и многие аспекты идут вразрез с новомодными идеями GraphQL. Но, т.к. это не строгая спецификацию, то не вижу смысла спорить.

это уже ваша надстройка

Это не моя "надстройка". Это "надстройка" Роя Филдинга, который собственно ввёл понятие REST и на которого есть ссылки в Википедии. Например, про идентификацию ресурсов — http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#tab_5_1


Но я совсем не хочу спорить насчёт терминологии. Если определиться, что REST — это любой клиент-серверный подход со stateless протоколом коммуникацией и не более, то почти всё в таком случае — "подмножество REST", там в т.ч. запросы в библиотеку через голубиную почту.


И я совсем не утверждаю, что GraphQL — это единственный правильный подход, который подходит для всех проектов. Кто-то может сделать универсальный /getFilm и напихать туда всю инфу, которую только можно представить, и не заботится о траффике, кто-то может сделать 1001 endpoints под всевозможные случаи и не заботится о количестве запросов, а кто-то может запускать цикл разработки по-новой из-за любого чиха PO/BA/UX-UI-щика. Каждому своё — у каждого свои потребности и свои ресурсы на их удовлетворение.

Имплементировать мутацию на GET-запрос то можно, но это уже не будет идеологиский REST. Спецификации на REST нету, но если почитать оригинальную диссертацию дядьки Роя Филдинга, то там указывается на использование методов HTTP по назначению и GET приводится как пример "retrieving a representation of a resource". Также там запрашиваемый ресурс идентифицируется URL-ом (в GraphQL обычно всего один endpoint). Конечно, между GraphQL повех HTTP и REST поверх HTTP будет что-то общее — собственно HTTP и отсутсвие состояния на сервере. Но GraphQL не ставится REST-ом из-за этого.


По поводу /getFilm — многие идеологи REST Вам скажут, что такое именование не очень "идеологично". Оно указывает на действие, а не на ресурс, т.е. это RPC-style, а не pure REST-style. В идеале должен быть ресурс типа /film/<id>. Но если вернуться к вопросу о множестве запросов — допустим вы реализовали endpoint, который возвращает фильм со списком актёров, где для каждого актёра указан его id и имя. Но тут frontend-щикам понадобилось вдруг больше инфы, там, например, пол актёра, чтобы картинку сбоку отобразить. Конечно, проблема решаема — ticket для backend-еров в backlog, ожидание следующего планирования пока он попадёт в sprint, потом QA и frontend-щики разблокированы, если к тому времени они не решили делать 1001 запрос для каждого актёра. Но в таком случае цикл получается длинее и agile становиться не таким уж и гибким. Конечно, если Вы — единственный разработчик или же у вас всё продумано заранее, есть чёткие спецификации от BA, то REST писать куда проще. Но для некоторых проектов, могу предположить, GraphQL будет иметь итоговую выгоду.

Не дошёл ещё до Вас западный маркетинг, жирность вот процентах считаете, а кое-где давно уже в граммах на 200 грамм молока.

Вы считаете лисп верхом совершенства?

А разве в этом кто-то сомневается (из тех, кто знает CL не понаслышке)?

В некоторых странах западной Европы если Ваша професия поподает в определённый списочек или зарплата выше определённого уровня, то не надо уже ничго доказывать. Иногда даже все документы может оформить сам иностранец, попросив работодателя только заполнить пару страниц его данных.

Так если все начнут пользоваться такими вот light-версиями, не проверяя корректность всей цепочки, то не кажется ли, что безопасность всей децентрализированной системы, заложенной в дизайне, немного страдает?

Information

Rating
Does not participate
Location
Луганск, Луганская обл., Украина
Registered
Activity