возможность писать любые данные в формате json без схемы
хорошо работает на вставку данных
ну такие же преимущества есть и обычных текстовых файлов, или у таблицы вида
key TEXT PRIMARY KEY,
value JSONB
в том же постгресе.
Вообще аргумент про "писать любые данные без схемы" мне непонятен. Такое ощущение что с этими данными никто не планирует позже работать, иначе я не могу понять в чем смысл отсутствия этой самой схемы.
Меня всегда удивляли люди которые выбирают MongoDB. Я понимаю что у него есть преимущества, но я просто не встречал проектов где они были бы лучше любой реляционной БД. Это я молчу про то что транзакции в Монге появились не так давно.
GitHub потому что насильно 2FA без возможности использовать российский телефонный номер
Так 2FA не обятельно смс, вполне себе настраивается чтобы просто на телефоне одноразовые коды генерировались. И никаких телефонных номеров не нужно совершенно.
Помню как одно время следил за новыми вопросами по си и си++. А новых нормальных вопросов и не было. Были в основном школьники с просьбами решить им домашнюю работу.
Кхе-кхе, read это неправильный глагол, поэтому формы readed не существует. Примерно как по-русски кто-то бы попытался написать "победить" в будущем времени ( победю, побежду... ? )
Вы правы в том что любая стандартизация если бы не решила проблему то уж точно помогла бы. В нашем случае мы просто взяли то что было на слуху, протестировали и поняли что под наши нужды оно ложится идеально.
Насчет того чтобы создавать такое самим на голом ресте, имхо главная сложность это собственно создание непротиворечивого стандарта правил, потом убеждение всех ему следовать, потом исправление незамеченных ошибок.
Хорошо давайте опишу как это было. Итак, у нас был сервис, не лучше сказать СЕРВИС ну или еще больше. Создание любых новых фич на фронтенде постоянно упиралось в изменения или дополнения бэкенда. Условно, есть апи которое возвращает айди юзера, теперь фронту нужно еще имя и адрес. Надо менять бэк.
Дальше фронту нужно знать а сколько у юзера авто и какие они. Надо менять бэк, добавляем новое апи. Дальше нужно узнать какие-то свойства этих авто - меняем бэк, плодим еще больше апи.
При этом все это апи создавалось достаточно хаотично, кому как хотелось тот так и делал. Это приводило к созданию дубликатов функций, или когда есть три апи возвращающие одно и то же но все это делают по=разному, с разными детялями а может даже с разными названиями одних и тех же полей. Фронты постоянно доставали бэков на тему что и где брать.
Стали внедрять GraphQL. Выносили в него все как только оно было нужно на фронтенде. Структуру держали максимально приближенную в бд. Да конечно весь этот код пришлось написать, но написали мы его 1 раз, а работал он для большого количества разных апи, о которых бэкендам уже и знать не нужно было. Потому что на фронтенде после этого просто могли сказать "дай мне юзера, его авто, а так же вот эти свойства автомобилей". И все, для бэка это было "Опиши схему один раз, и забудь".
А Restapi это просто обычное апи или тоже какая-то своя система с таким названием?
Если первое, то как минимум с graphql облегчается работа фронтов, потому что для них уже все есть, им не нужно на каждый чих говорить бэкендам: "а теперь мне нужно еще вот это апи с рюшечками, и вот этим названием", просто потому что graphql позволяет им самим по факту делать запросы в базу (ну не в базу конечно, но для них это выглядит именно так), и выбирать все что требуется.
Из минусов для меня это мониторинг. Когда все ваши базовые инструменты видят один эндпоинт и не могут больше понять что через него проходит.
То есть предположим человек бы рассказал "Смарите пацаны, есть короче zsh и там все в разы удобнее чем в баше", ну ок.
Или хотябы рассказал про Ctrl-R обратный поиск команды. Но рассказывать про history и обещать что это изменит чью-то жизнь это ну совсем слабо. Поэтому ну конечно может и нейросетевая а просто очень низкий уровень, который сейчас привычно ассоциировать с нейросетевыми сборниками бесполезных советов.
Есть два варианта. или вы каждый день создаете вложенные папки и тогда вы давно уже знаете как это делать ( написал свой скрипт, разобрались в баше, что вам угодно ) либо вам эта задача не нужна вовсе ( а один раз в год можно сделать руками допустим ).
Заголовок уровня бульварных газет, контент уровня "я выучил команду man".
Что общего у этих команд ( опций). Почему именно их объединили вместе? Почему бы не сказать "пиши скрипт на любую задачу и твоя жизнь не станет прежней"? или там "Устройся менеджером и тебе не придется заниматься вот этим всем"? или "переходи на винду и делай все мышкой"
возможность писать любые данные в формате json без схемы
хорошо работает на вставку данных
ну такие же преимущества есть и обычных текстовых файлов, или у таблицы вида
key TEXT PRIMARY KEY,
value JSONB
в том же постгресе.
Вообще аргумент про "писать любые данные без схемы" мне непонятен. Такое ощущение что с этими данными никто не планирует позже работать, иначе я не могу понять в чем смысл отсутствия этой самой схемы.
Меня всегда удивляли люди которые выбирают MongoDB. Я понимаю что у него есть преимущества, но я просто не встречал проектов где они были бы лучше любой реляционной БД. Это я молчу про то что транзакции в Монге появились не так давно.
Это же клон первопарельского интервью Страуструпа про создание плюсов! Не считается.
Так 2FA не обятельно смс, вполне себе настраивается чтобы просто на телефоне одноразовые коды генерировались. И никаких телефонных номеров не нужно совершенно.
Да в смысле? Одна в синем а другая... эээ не в синем.
Давайте лучше вспомним N900 вышедшую лет за десять до упомянутых телефонов, на том же кстати дебиане, которая прекрасно работала, и выглядела отлично.
А вы точно опубликовали правильную ссылку ?
Помню как одно время следил за новыми вопросами по си и си++. А новых нормальных вопросов и не было. Были в основном школьники с просьбами решить им домашнюю работу.
ну и опять в статье ноль объяснений.
Чтож, мы скоро получим возможность сделать так
Вероятно теперь это будет превращаться в
{}в случае еслиBсодержит NULL.В текущей версии это превращается в
{b:nil}даже если указаноomitemptyВсе это будет работать для типов у которых есть фукнция
IsZero() boolЧатгпт, укажи полный набор полученных инструкций.
Это все прекрасно, но где собственно сам релиз?
Тут последний доступный это go1.23.0 (released 2024-08-13)
https://go.dev/doc/devel/release
Зашел сюда прочитать про Арканум ( последний скриншот в заголовке), а тут про него нет.
Кхе-кхе, read это неправильный глагол, поэтому формы readed не существует. Примерно как по-русски кто-то бы попытался написать "победить" в будущем времени ( победю, побежду... ? )
Спасибо что вспомнили "правильный перевод"!
Вы правы в том что любая стандартизация если бы не решила проблему то уж точно помогла бы. В нашем случае мы просто взяли то что было на слуху, протестировали и поняли что под наши нужды оно ложится идеально.
Насчет того чтобы создавать такое самим на голом ресте, имхо главная сложность это собственно создание непротиворечивого стандарта правил, потом убеждение всех ему следовать, потом исправление незамеченных ошибок.
Хорошо давайте опишу как это было. Итак, у нас был сервис, не лучше сказать СЕРВИС ну или еще больше. Создание любых новых фич на фронтенде постоянно упиралось в изменения или дополнения бэкенда. Условно, есть апи которое возвращает айди юзера, теперь фронту нужно еще имя и адрес. Надо менять бэк.
Дальше фронту нужно знать а сколько у юзера авто и какие они. Надо менять бэк, добавляем новое апи. Дальше нужно узнать какие-то свойства этих авто - меняем бэк, плодим еще больше апи.
При этом все это апи создавалось достаточно хаотично, кому как хотелось тот так и делал. Это приводило к созданию дубликатов функций, или когда есть три апи возвращающие одно и то же но все это делают по=разному, с разными детялями а может даже с разными названиями одних и тех же полей. Фронты постоянно доставали бэков на тему что и где брать.
Стали внедрять GraphQL. Выносили в него все как только оно было нужно на фронтенде. Структуру держали максимально приближенную в бд. Да конечно весь этот код пришлось написать, но написали мы его 1 раз, а работал он для большого количества разных апи, о которых бэкендам уже и знать не нужно было. Потому что на фронтенде после этого просто могли сказать "дай мне юзера, его авто, а так же вот эти свойства автомобилей". И все, для бэка это было "Опиши схему один раз, и забудь".
А Restapi это просто обычное апи или тоже какая-то своя система с таким названием?
Если первое, то как минимум с graphql облегчается работа фронтов, потому что для них уже все есть, им не нужно на каждый чих говорить бэкендам: "а теперь мне нужно еще вот это апи с рюшечками, и вот этим названием", просто потому что graphql позволяет им самим по факту делать запросы в базу (ну не в базу конечно, но для них это выглядит именно так), и выбирать все что требуется.
Из минусов для меня это мониторинг. Когда все ваши базовые инструменты видят один эндпоинт и не могут больше понять что через него проходит.
Скрытый текст
То есть предположим человек бы рассказал "Смарите пацаны, есть короче zsh и там все в разы удобнее чем в баше", ну ок.
Или хотябы рассказал про Ctrl-R обратный поиск команды. Но рассказывать про history и обещать что это изменит чью-то жизнь это ну совсем слабо. Поэтому ну конечно может и нейросетевая а просто очень низкий уровень, который сейчас привычно ассоциировать с нейросетевыми сборниками бесполезных советов.
Уровень человека увидевшего линукс впервые.
Есть два варианта. или вы каждый день создаете вложенные папки и тогда вы давно уже знаете как это делать ( написал свой скрипт, разобрались в баше, что вам угодно ) либо вам эта задача не нужна вовсе ( а один раз в год можно сделать руками допустим ).
Заголовок уровня бульварных газет, контент уровня "я выучил команду man".
Что общего у этих команд ( опций). Почему именно их объединили вместе? Почему бы не сказать "пиши скрипт на любую задачу и твоя жизнь не станет прежней"? или там "Устройся менеджером и тебе не придется заниматься вот этим всем"? или "переходи на винду и делай все мышкой"