реакт тоже

preact under patent attack

?

реакт тоже

С реактор проще

Всм) Идея как раз намного ценнее

не всё можно патентовать.. патентирование это тема долгая и тяжкая, но очень грубо говоря основопологающие "идеи" патентовать нельзя... нельзя запатентовать шаблон проектирования например, да и абсолютно бессмысленно

Там нет либы реакта не от fb

да, кроме preact

в основе GraphQL - шаблон проектирования Graph Query Language

в основе GraphQL - шаблон проектирования Graph Query Language

и? патент посмотри

в основе GraphQL - шаблон проектирования Graph Query Language

Можно)

Но это не означает что не стоит использовать graphql, просто фанатично пихать его всюду неосмотрительно

Я ко всему фейсбучному отношусь с большим подозрением

Это как с блокчейном, суют везде куда не лень)))

ребята, вы совершенно правы, если какой-то патент запретит заколачивать гвозди молотком, то нужно немедленно прекратить это и начать заколачивать их пилой! самому молоток естественно не изготовить, слишком сложно, поэтому будем пилить отвёрткой, колотить пилой и скрипкой точить ножи!

ребята, вы совершенно правы, если какой-то патент запретит заколачивать гвозди молотком, то нужно немедленно прекратить это и начать заколачивать их пилой! самому молоток естественно не изготовить, слишком сложно, поэтому будем пилить отвёрткой, колотить пилой и скрипкой точить ножи!

Все что ты назвал тоже может попадать под патент

Я ко всему фейсбучному отношусь с большим подозрением

почему?

Вот как контора, которая собирает террабайты личных данных и зарабатывая сотни миллиардов, делает сайт с интерфейсом застрявшем в 2010х, который зависает у меня даже на восьмиядерном ай7 с 16 гб оперативки

запатенрируем всё, хэш-таблицы, массивы, ООП, цикличные графы, древовидные графы, умножение на 4, всё запатенрируем)))

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

запатенрируем всё, хэш-таблицы, массивы, ООП, цикличные графы, древовидные графы, умножение на 4, всё запатенрируем)))

Ну так многое и запатентовано, или было когда-то...

Ну так многое и запатентовано, или было когда-то...

а если ходить на 2 ногах со скоростью 3 км/ч запатентируют, будешь ходить на руках или со спидометром в умных очках?

Если UI решения попадают под разные патенты, то что тут можно сказать

а если ходить на 2 ногах со скоростью 3 км/ч запатентируют, будешь ходить на руках или со спидометром в умных очках?

Не, просто платить за это) налоги что-то типа этого

Не, просто платить за это) налоги что-то типа этого

ну, плати) удачи)

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

Это просто ведроид...

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

может у тебя просто железо не соответствует требованиям?

хаить Facebook можно сколько угодно, они от этого менее успешными не станут

ну, плати) удачи)

Все платят))) просто кто-то не понимает))) выхода то нет особо

?

хаить Facebook можно сколько угодно, они от этого менее успешными не станут

Да дело не в их успешности)))

Просто фанатизм это не гуд

Просто фанатизм это не гуд

чем REST тогда не фанатизм?)))

ладно, сори, нет времени спорить, кому надо тот поймёт, не поймёт тот - кому пока ещё не надо.

чем REST тогда не фанатизм?)))

Его никто не предлагает юзать везде и всегда))) есть ещё куча всего вкусного

"you'll know when you'll need it, I'm just here to tell you it exists"

)))

Главное закусывать)))

Главное закусывать)))

главное чтоб язык целый остался)))))

главное чтоб язык целый остался)))))

Это если с фанатизмом, то можно и язык откусить)))

Это если с фанатизмом, то можно и язык откусить)))

вот и я о чём)

если у меня библиотека в репе на гитхабе то как к ней добавить тесты?

я обычно пользуюсь gb build tools и качаю зависимости из vendor, со стандартным tool set'ом не работаю

но тут получается что библиотека в package'е "webwire" а тесты должны быть в другом package'е

так как мне импортировать библиотеку в её тесты?

Кто поможет написать приложегте на андроид ?

Четко по адресу.

выбирай любого, все сидим без дела))

граф в REST? это как это...

Быстро пробежался по графу и не понял что в ней такого. Делаешь рест, в боди ложишь [кладёшь] джисон, на серве парсишь боди джисон, а в джисоне прописывпешь поля которые тебе должен вернуть сервер - профит. Если надо несколько сущностей, делайте объект, а в нем поля.

Быстро пробежался по графу и не понял что в ней такого. Делаешь рест, в боди ложишь [кладёшь] джисон, на серве парсишь боди джисон, а в джисоне прописывпешь поля которые тебе должен вернуть сервер - профит. Если надо несколько сущностей, делайте объект, а в нем поля.

1. типизация. 2. это уже не REST 3. дело не просто в полях объекта (shallow scan) а во вложенностях и реляционных связях короче начнёшь писать - заметишь что изобретаешь GraphQL и отдаляешься от REST

Вы случаем не разработчик сего велосипеда?))))

Вы случаем не разработчик сего велосипеда?))))

?

Вы так яростно его защищаете))))

Вы так яростно его защищаете))))

ну я могу конечно и промолчать, но предпочитаю заводить дискуссии ибо всегда учитываю что могу ошибаться и вероятность высока что кто-нибудь наведёт на какие-либо интересные мысли или ошибки

Прелесть реста как раз заключается в том, что запросив определенный урл ты получишь определенную структуру в ответ что бы не произошло, а с графом ты хз что получишь, его надо разбирать на фронте в итоге. Гибкая штука - да, но побочно усложняет простые вещи.

А еще усложняется тестирование интерфейса, если в ресте ты имеешь строго регламентированный список параметров, то тут вариаций на порядок больше, что ведет к большему количеству точек отказа

Прелесть реста как раз заключается в том, что запросив определенный урл ты получишь определенную структуру в ответ что бы не произошло, а с графом ты хз что получишь, его надо разбирать на фронте в итоге. Гибкая штука - да, но побочно усложняет простые вещи.

вы издеваетесь? REST никак не гарантирует структуру данных на каком либо endpoint'е, это GQL гарантирует какую структуру ты получишь ибо сервер и клиенты должны воплощать схему, которая строго типизирована.

А еще усложняется тестирование интерфейса, если в ресте ты имеешь строго регламентированный список параметров, то тут вариаций на порядок больше, что ведет к большему количеству точек отказа

в ресте ничего строго регламентированного нет в принципе и ошибки намного более вероятнее чем с GQL

Ну смотря как вы собираете рест

Ну ладно, это уже смахивает на андроид vs ифон

Ну смотря как вы собираете рест

вот именно, ибо REST сам по себе никаких гарантий не даёт, а GQL даёт посредством типизирования и схемы. Сделать ошибку в GQL - намного сложнее, чем в REST

помимо этого ты потратишь большое количество времени если захочешь строго типизировать и валидировать свой REST API... ты будешь вручную переизобретать GraphQL, зачем?

ERROR: S client not available

не поддерживается адрес фамилии, что непонятного то

вы издеваетесь? REST никак не гарантирует структуру данных на каком либо endpoint'е, это GQL гарантирует какую структуру ты получишь ибо сервер и клиенты должны воплощать схему, которая строго типизирована.

В конкретном rest api строго регламентированный список параметров, это факт

В конкретном rest api строго регламентированный список параметров, это факт

И ответ так же строго регламенитрован)

И ответ так же строго регламенитрован)

+

Меня смущает в graphql тот факт, что фронт будет дергать данные как ему заблагорассудится...

Тыкая беку что ему надо и никак иначе)

Меня смущает в graphql тот факт, что фронт будет дергать данные как ему заблагорассудится...

А в чем проблема? Если оно на чтение - нет проблем, а если на запись, то надо зависимости выдерживать

Я про зависимости

Я про зависимости

Ну там вроде в графе можно указть что поле такое - то обязательное

Ну там вроде в графе можно указть что поле такое - то обязательное

А смысл если сделать все поля обязательными...

Но как фак - да, не вижу особого профита от этой штуки)))

Или как запросить поиск по разным моделям данных? Типо q=? но чтобы в ответе были и статьи и метки и новости и ещё чего то там...

и как потом обрабатывать ошибки на фронте, когда у тебя в одном запросе их 3 - 5 и половина вернула тебе ошибки, что кучу окошек как кога-то в винде было плодить?

Беру TypeOf у клавиатуры в go-telegram-bot-api, потом проверяю на эквивалентность взятого с tg.InlineKeyboardMarkup{} А на меня кричат типа invalid case tgbotapi.ReplyKeyboardMarkup literal in switch on typeOfKeyboard (mismatched types tgbotapi.ReplyKeyboardMarkup and reflect.Type)

Что за дела такие?

Беру TypeOf у клавиатуры в go-telegram-bot-api, потом проверяю на эквивалентность взятого с tg.InlineKeyboardMarkup{} А на меня кричат типа invalid case tgbotapi.ReplyKeyboardMarkup literal in switch on typeOfKeyboard (mismatched types tgbotapi.ReplyKeyboardMarkup and reflect.Type)

Ты сравниваешь теплое с мягким :)

читай про рефлексию

читай про рефлексию

Понял, сделал через type.String() :D

товарищи, а подскажите вот какую штуку: допустим у меня есть тип. это нода графа. у него есть свои методы, аттрибуты и вот это всё. в основном связанные с навигацией по графу и его обходом. у меня есть два других типа, унаследованных от этого от этого типа. соответсвенно граф у меня собран из элементов этих двух типов в перемешку. теперь допустим мне при обходе графа понадобилось таки узнать какого типа эта нода. как это сделать?

reflect?

Есть у меня подозрение, что поможет тебе рефлексия

а человеческие методы есть?

type assertion

а через интерфейсы как-то изъебнуться?

вот если б можно было интерфейс унаследовать от типа

но кажется нельзя

можно конечно базовому типу сделать поле Type int и при создании каждой ноды графа его заполнять

но как гарантировать, что он всегда будет верное?