Книги по вайбкодингу и JSON

Это решение, которое во всём, в каждом аспекте хуже нормального. Не надо так.

Что такое «нормальное»? Пользовался Postman, Idea HTTP Client, ну и какими-то менее известными тулзами, всё это гораздо хуже моего подхода. Сомневаюсь, что в мире существует что-то, о чём я не в курсе, но весь внимание.

и JSON для начинающих?

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

Главное:

JSON, XML, YAML - это такие «матрёшки» с данными, какие-то данные списками, какие-то - словарями, какие-то - вложенные.

JSON похож на JavaScript, YAML на Python, XML и есть XML, но в параметрах его тегов ещё сохраняют метаданные.

Человеку легче с JSON и YAML.

Нормальное, это с использованием настоящего языка программирования. У вас в примере выше корректность входных данных зависит от содержимого переменной окружения, которое вы не контролируете и не проверяет. Ответ на запрос тоже не проверяется и обработки ошибок нету.

Это не надёжно и может запросто развалиться в реальном использовании. А если же проверки добавить, то у вас 90% скрипта будет состоять из плясок вокруг ошибок, отчего код будет раздутым и нечитаемым.

Bash любит и тебя тоже:

response=$(curl -s 'https://httpbin.org/post' --json "${request}") || EXIT $? "curl failed"

[[ "$( file -b "${response}" )" = "superjson" ]] || EXIT $? "not json"

Не принимайте на свой счёт пожалуйста, но это говна кусок, вместо нормальной обработки ошибок. Следует проверять не состояние процесса curl, а код возврата http-запроса.

Проверка json’а тоже недостаточная (хотя и лучше, чем ничего).

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

Программирование по своей природе – всё говна кусок, увы. Одним платим за другое, другим за третье, камень - ножницы - бумага.

А нечитаемость… Мне не очень понятно почему слово EXIT трудно прочитать.

Да, но нет. В данном случае мы получаем гору минусов, и не получаем вообще никаких плюсов. Это хреновая сделка.

Мне не очень понятно почему слово EXIT трудно прочитать.

А комментарий

говна кусок, вместо нормальной обработки ошибок. Следует проверять не состояние процесса curl, а код возврата http-запроса.

легко прочитать? Данный код следует переписать так, чтобы на 200-й код ничего не делать, на 300-й писать в лог с severity=warning (ну и curl нужно запускать с опцией -L. Это ещё одна ошибка, вызванная тем, что нужно ещё одну вещь принимать во внимание), на 400-й писать severity=error, на 500-й — critical и аварийно завершать скрипт.

Навайбкодь себе книгу про жисон и вайпкодинг. Не понравится что-то — уточнишь запрос и перегенерируешь)

Нет. Либо мы получили нормальный ответ, либо завершаем работу немедленно. Let It Crash.

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

А с нормальными инструментами не нужно выдавать нужду за добродетель и рассказывать про зелёный виноград. Ваш код некорректно 404-ю ошибку обрабатывает, к слову.

Да, нам всегда приходится выбирать между разными нуждами и разными добродетелями. Числа в bash (комментарий)

некорректно 404-ю ошибку обрабатывает

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

Ему скорее основы REST нужны.

На книгу тоже явно не тянет… :)

Ну, тем не менее такие книги есть :)

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

Ну, тем не менее такие книги есть :)

А кинь ссылку, плиз.

Мне прям интересно что там можно расписывать на целую книгу.

Не боишься, что пробельные символы потеряются?

https://www.piter.com/product/restful-web-api-patterny-i-praktiki

Одна из.

Но можно рассчитывать что упадёт jq.

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

Это не книга по REST. :) Написано же: «Связывание и оркестрация микросервисов и распределённых данных»

Для разных задач – разный инструмент.

Был случай, я решил переписать некий сценарий с баша на питон. Тоже от проверок устал. Он в основном вызывал внешние команды. Повызывал я в питоне попен, или как там это, повызывал, половил стдаут и стдер, и пошёл оптимизировать и упрощать проверки.

Дык… Связывание по REST API, которое и есть JSON в 90% случаем.

Баш это литералли инструмент в котором недостатки больше, а достоинства меньше, чем у альтернатив. Его можно использовать только в двух случаях: а) больше ничего нету и б) скрипт на 15 строк. Всё. Поэтому да, разным задачам — разный инструмент, но некоторым инструменентам место на кладбище или в музее.

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

В первую очередь, bash подходит в случае, когда сценарий заключается в вызове других программ. С количеством строк это не связано.

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

сценарий заключается в вызове других программ. С количеством строк это не связано.

Большой сценарий в котором нет (почти) никакой логики один только вызов внешних программ (не по причине того, что башу для вообще всего нужно вызывать внешние программы)? Экзотика, да и здесь он не будет лучшим выбором.

Насчёт больше ничего нет: про bash можно не думать,

Колхоз, как известно, дело добровольное, хочешь вступай, не хочешь — корову заберём.

P.S. Чуть более подробно. Для вызова внешних программ есть более элегантное решение. Но оно требует писать программоспецифичную обвязку. Что для маленьких программ лишено смысла. А вот для больших — очень даже.

Дык… Связывание по REST API, которое и есть JSON в 90% случаем.

Это как если бы я попросил тебе дать мне пример книги по циклу for, а ты бы мне Кнута скинул. Технически, да, цикл for там тоже обсуждается, но книга явно не про него.

пример книги по циклу for, а ты бы мне Кнута скинул

Спрашивали — отвечаем: https://pic.plover.com/knuth-GOTO.pdf

Он имел в виду про составление промтов через JSON.

Технически, да, цикл for там тоже обсуждается, но книга явно не про него.

Это че это? Она про основы, в числе которых и упомянутый цикл.

Это одноразовый скрипт, которым я проверяю, например, формат ответа. От него не требуется никаких проверок, от него требуется отработать и быть забытым. Мы говорим про postman, никто не пишет (я надеюсь, о боже мой) на postman-е какой-то «продакшн код». Им просто исследуют API.

Но в принципе конкретно для такого использования несложно написать и надёжный скрипт на баше. Тем же jq можно собирать 100% корректный JSON из шаблона, там просто писанины будет много и выглядеть будет некрасиво, но работать будет. curl с каким-то флажком (вроде -f) проверяет ответ сервера, т.е. с этим тоже проблем не будет.

Не боишься, что пробельные символы потеряются?

Потеряются - найду. Но вроде всё закавычено, не должны, у меня уже давно привычка всё кавычить, что ни попадя.

Спрашивали — отвечаем: https://pic.plover.com/knuth-GOTO.pdf

Это статья, не канает. :P

Это че это? Она про основы, в числе которых и упомянутый цикл.

То что «Книга по циклу for» - абсурд, так как концепт слишком простой, и там не будет материала на целую книгу.

По твоей логике, если в книге на 600 страниц один раз упоминается слово «ложка», то она про «предание пиши при помощи ложки». А это, например, приключения Шерлока Холмса.

Не работает твой критерий, очевидно.

dnf search babashka
Нет совпадений.

apt search babashka
Сортировка… Готово
Полнотекстовый поиск… Готово

OK.png

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

Нет.

Забавно, что у вас аж заместитель генерального по ИТ есть и даже эйчарка, а разраба нет. Что там у вас за контора, гос или частная? Какая сфера деятельности? Не тролю, просто любопытно.

Разрабы есть но это не их зона отвественности. Раньше у нас автоматизацией Яндекс.Трекера для пользователей вообще занимался отдел автоматизации и тестирования, а сейчас Яндекс.Трекер передали нам, в отдел системного администрирования. Контора частная.

книги

Ты эти дедовские подходы брось.

А что учиться по книгам или официальной документации уже моветон? А как тогда, ну-ка просвети деда. Из модного знаю учиться по видео урокам пионеров и по вываленному фаршу галлюцинаций ИИ. Но это как источник самообучения довольно сомнительный я считаю.

А что учиться по книгам или официальной документации уже моветон?

Не моветон, но и не мейнстрим. Даже здесь почти все нуботемы это «сделал по гайду из интернета (ссылка_на_помойку), ничего не работает», в последние годы развившееся до «…ИИ не помог».

это как источник самообучения довольно сомнительный

Ну и я так считаю. Вот бы это моё считание кого-то колыхало.

Ну… Нет.
Если бы книга была про основы поедания пищи в целом, и про ложку там было в частности, то да. А в случае с Кнутом это скорее так, а не то, что ты описал.

Чтобы уметь нормально использовать ИИ лля программирования, нужно сначала научиться программировать

Вот лучше бы вот это писали на всех столбах, а не «даже дебил теперь может написать новую базу данных!».

А что учиться по книгам или официальной документации уже моветон?

Это ж сарказм был, явный.

Даже здесь почти все нуботемы это «сделал по гайду из интернета (ссылка_на_помойку), ничего не работает», в последние годы развившееся до «…ИИ не помог».

Дык, так всегда было и так всегда будет. Только это не про обучение же речь :)

написать и надёжный скрипт на баше.

Всё возможно для человека, который любит мир и верит в Бога. Вопрос не в том вообще, можно ли написать надёжный скрипт на баше. Вопрос в том, зачем так мучаться. «писанины будет много и выглядеть будет некрасиво» — факт, я о том и говорю. Так и зачем? Не лучше ли (лучше!) использовать инструменты, где писанины меньше и выглядит красивее?

Я понимаю, что в 70-х выбора особо не было. Либо шелл, либо сразу С. Но сейчас-то есть море разливное языков на любой вкус.

концепт слишком простой, и там не будет материала на целую книгу.

Вы просто писать не умеете. А задача решается элементарно. Допустим, у вас есть тема, которую можно легко объяснить на 15 страницах текста. Значит, поступаем так:

• Введение. Вот её главным образом и объясняем. На 30 страницах.

• Глава №1 (историческая). А рассказываем предысторию, как автор дошёл до жизни до такой, как страдал, мучался, потом озарение пришло, идея на миллион и теперь всё будет хорошо у всех.

• Глава №2 (теоретическая). Рассказываем ещё раз, на этот раз тянем страниц на 80, долго и нудно объясняем то, что и так понятно, заодно вставляя слова из латыни, чтоб серьёзнее выглядело и длиными сложноподчинёнными предожениями внушаем трепет в сердца читателей.

• Глава №3 (практическая). А теперь рассказываем как мы применяли нашу новую идею, как помогали людям, как у них всё плохо было, а потом жизнь наладилась.

• Заключение (тезисно повторяем ещё раз всё то же самое).

Вот статья на 15 страниц превратилась в настоящую книгу.

Родились стихи:

Король Луи любил гулять в любимом парке Фонтенбло.
А что крестьянин не мог поставить бабашку, монарха это не _волновало_.

Нет. Либо мы получили нормальный ответ, либо завершаем работу немедленно. Let It Crash.

Вы глубоко не правы. И, судя по комментариям, очень далеки от Web программирования.

@ugoday пытается объяснить вам базу работы с rest api в современном вебе. Вы просто не знаете это, поэтому продолжаете упорствовать в своём неведении.

Обработка подобного на баше это езда на велосипеде без сидения по ухабам сидя на штоке. Можно, но зачем?

Очень далёк, бог миловал. Но Книги по вайбкодингу и JSON (комментарий) . Вы читали скрипт, с которого развернулась эта ветка?

Он просто ненави^W не любит баш.