Хм.. А теперь объясните мне понятно, почему body в GET запросе это плохо?
На мой взгляд как раз портянка параметров запроса в url и является злом. Как минимум это просто не красиво визуально.
Ну и json в body запроса get весьма органичен, мы в json прекрасно объясняем бэкенду, что мы от него хотим получить. json структурирован, он прост и понятен, многомерен в отличии от плоского урла. В урле стоит указывать в каком виде это мы хотим получить: другой json, html или pdf.
get - запрос данных, endpoint - точка откуда мы получаем данные, body описывает то, что мы хотим получить, в каком объёме и с какими фильтрами.
Если в get нельзя положить текст запроса в body, то для сложных запросов приходится городить запрос post с текстом хотелки и его типом (читаем, изменяем или ещё что), по сути дублируя запросы http и потом на бэке разбирать, а что у нас вообще хотят попросить (graphql привет).
Но ведь запросы http для того и предназначены: get - запрос данных, post - отправка новых данных на сервер, put/patch - изменение данных, delete - удаление данных
Уже готовые запросы, которые много-много лет просто работают, так зачем поверх них вертеть ещё один слой абстракции, или делать костыли в виде длинных и сложных параметров в url?
Если я не прав, то объясните в чём. И не надо ссылаться на стандарт, его тоже пишут люди, и они могут ошибаться. Но если есть объективная причина, то вот её и хотелось-бы прочитать.
У меня в ФФ постоянно открыто всего около 20 вкладок - с сайтами которые постоянно посещаю, на которых авторизован и которые часто использую для работы. Для всего остального используется окно "Инкогнито", и вот если в инкогнито что-то попалось ну прям стоящее, что нужно потом вдумчиво прочитать, то "хватается" урл страницы и выбрасывается на рабочий стол. Да прямо туда. И ссылка на нём будет лежать и мешаться, до тех пор пока или не прочитаешь, или не решишь, что оно тебе не нужно и не грохнешь. Ну а ограниченное количество значков на рабочем столе является органичным ограничителем отложенного "на потом". Главное не создать папочку "Ссылки на потом" и не начать туда складывать, хотя весть она будет копейки на сотни файлов. И ни каких тебе спец дополнений для браузера или системы.
Есть множество способов обхода NATа. Простой проброс портов на маршрутизаторе. Элементарный UPnP, который много где используется. Можно добавить гейты с белыми адресами. Было-бы желание, а способ найдётся.
Как и любые технологии ИИ может принести как вред так и пользу.
Самый главный вред от ИИ - его использование детьми и молодёжью без использования ресурсов собственного мозга.
Мозг - как мышца, чем больше качаешь, тем сильнее становится.
И у кого не возникнет соблазна делать домашку с помощью ИИ, а не думать самому? Только у малого количества сознательных личностей. Отсюда расслоение, на тех кто не привык думать, и тех кто привык, и разница между ними будет увеличиваться с возрастом, т.к. использование своего мозга и ИИ куда круче чем только ИИ.
Странно, что ни кто не упомянул такую программу как DMDE. Есть и под винду и под Линукс. Весьма неплохая прога для восстановления повреждённых структур разделов и файловых таблиц. Да и просто данные может поискать и вытащить (как RStudio). Уже множество вещей было восстановлено с её помощью, хотя минимальные знания нужно иметь.
Как я понимаю из статьи, то, если в помещении влажность в среднем не поднимается выше 40%, то про пылевых клещей можно покойно забыть?
Дома летом влажность, как правило, не выше 50%, а зимой падает ниже предела измерения на одном (что там не знаю), и 5% на другом (ёмкостный датчик), DHT22 и другие датчики в самоделках говорят тоже самое. Увлажнители не помогают.
Меня как-то начальница зовёт:
В ворде всё бежит куда-то… Подхожу, всё хорошо. Только она садится как снова «всё бежит».
Причина: зажатый пробел. Очень большая грудь у начальницы…
А может в результате мутаций, «отмершие» ветки стали просто не различимы или «влились» в общее дерево спустя некоторое количество поколений?
Ведь ДНК полностью детерминирована, количество комбинаций хоть и очень большое (страшно представить такое число), но оно конечно. Значит у нас какие-то побочные ветки в результате эволюции могут, без вливания хромосом основной ветки, придти к очень похожей последовательности, что и в основном дереве.
Хоть и скверная аналогия, но: примерно как в DVCS когда сливаются разные ветки. Но там изменения из одной ветви подгружаются в другую, но ведь может быть, что программисты, разных веток, постепенно, не вливая код из другого дерева, ведут ветки на встречу друг-другу вплоть до получения одинакового кода. Знаю пример хреновый, но всё-же…
На мой взгляд было-бы логичнее поставить что-нить вроде finally. Слово не новое, известное, и логично передаёт, что мы завершаем цикл.
А else больше подошло-бы для варианты срабатывания после break (хотя кому такой вариант нужен?)
Я с вами совершенно согласен. Здесь больше подходит «Бритва Хэнлона», чем «теория заговора».
Если внимательно присмотреться к нашим чиновникам и правительству, то становится понятно, что большинство их «решений» это вовсе не злонамеренное действие, а совсем даже…
На корпусе вывести пяточки, как делают на платах для отладки. Если понадобиться туда и припаяться можно, или в экстренном случае проводки прям на плату изолентой шлёпать (был подобный опыт) и не дышать рядом.
Хм.. А теперь объясните мне понятно, почему body в GET запросе это плохо?
На мой взгляд как раз портянка параметров запроса в url и является злом. Как минимум это просто не красиво визуально.
Ну и json в body запроса get весьма органичен, мы в json прекрасно объясняем бэкенду, что мы от него хотим получить. json структурирован, он прост и понятен, многомерен в отличии от плоского урла. В урле стоит указывать в каком виде это мы хотим получить: другой json, html или pdf.
get - запрос данных, endpoint - точка откуда мы получаем данные, body описывает то, что мы хотим получить, в каком объёме и с какими фильтрами.
Если в get нельзя положить текст запроса в body, то для сложных запросов приходится городить запрос post с текстом хотелки и его типом (читаем, изменяем или ещё что), по сути дублируя запросы http и потом на бэке разбирать, а что у нас вообще хотят попросить (graphql привет).
Но ведь запросы http для того и предназначены: get - запрос данных, post - отправка новых данных на сервер, put/patch - изменение данных, delete - удаление данных
Уже готовые запросы, которые много-много лет просто работают, так зачем поверх них вертеть ещё один слой абстракции, или делать костыли в виде длинных и сложных параметров в url?
Если я не прав, то объясните в чём. И не надо ссылаться на стандарт, его тоже пишут люди, и они могут ошибаться. Но если есть объективная причина, то вот её и хотелось-бы прочитать.
У меня в ФФ постоянно открыто всего около 20 вкладок - с сайтами которые постоянно посещаю, на которых авторизован и которые часто использую для работы. Для всего остального используется окно "Инкогнито", и вот если в инкогнито что-то попалось ну прям стоящее, что нужно потом вдумчиво прочитать, то "хватается" урл страницы и выбрасывается на рабочий стол. Да прямо туда. И ссылка на нём будет лежать и мешаться, до тех пор пока или не прочитаешь, или не решишь, что оно тебе не нужно и не грохнешь. Ну а ограниченное количество значков на рабочем столе является органичным ограничителем отложенного "на потом". Главное не создать папочку "Ссылки на потом" и не начать туда складывать, хотя весть она будет копейки на сотни файлов. И ни каких тебе спец дополнений для браузера или системы.
Прелестно, просто прелестно! =)
https://t.me/teslacoilpro
У Зергория можно почерпнуть не мало интересного по теме, и возможно он поможет с контактами..
Есть множество способов обхода NATа. Простой проброс портов на маршрутизаторе. Элементарный UPnP, который много где используется. Можно добавить гейты с белыми адресами. Было-бы желание, а способ найдётся.
# режим брюзжания включен
И получим ещё один набор новых и "единых" протоколов, которые будут каждый реализовывать через собственное место. %/
Осталось только разработать протоколы и реализовать их.
При этом есть примеры сдачи рефератов, курсовых, и даже диплома полностью сделанных с помощью ИИ.
И известно это не из новостей, а от коллег из разных образовательных учреждений России.
Как и любые технологии ИИ может принести как вред так и пользу.
Самый главный вред от ИИ - его использование детьми и молодёжью без использования ресурсов собственного мозга.
Мозг - как мышца, чем больше качаешь, тем сильнее становится.
И у кого не возникнет соблазна делать домашку с помощью ИИ, а не думать самому? Только у малого количества сознательных личностей. Отсюда расслоение, на тех кто не привык думать, и тех кто привык, и разница между ними будет увеличиваться с возрастом, т.к. использование своего мозга и ИИ куда круче чем только ИИ.
А ссылку выложить?
Странно, что ни кто не упомянул такую программу как DMDE. Есть и под винду и под Линукс. Весьма неплохая прога для восстановления повреждённых структур разделов и файловых таблиц. Да и просто данные может поискать и вытащить (как RStudio). Уже множество вещей было восстановлено с её помощью, хотя минимальные знания нужно иметь.
Как я понимаю из статьи, то, если в помещении влажность в среднем не поднимается выше 40%, то про пылевых клещей можно покойно забыть?
Дома летом влажность, как правило, не выше 50%, а зимой падает ниже предела измерения на одном (что там не знаю), и 5% на другом (ёмкостный датчик), DHT22 и другие датчики в самоделках говорят тоже самое. Увлажнители не помогают.
В ворде всё бежит куда-то… Подхожу, всё хорошо. Только она садится как снова «всё бежит».
Причина: зажатый пробел. Очень большая грудь у начальницы…
Ведь ДНК полностью детерминирована, количество комбинаций хоть и очень большое (страшно представить такое число), но оно конечно. Значит у нас какие-то побочные ветки в результате эволюции могут, без вливания хромосом основной ветки, придти к очень похожей последовательности, что и в основном дереве.
Хоть и скверная аналогия, но: примерно как в DVCS когда сливаются разные ветки. Но там изменения из одной ветви подгружаются в другую, но ведь может быть, что программисты, разных веток, постепенно, не вливая код из другого дерева, ведут ветки на встречу друг-другу вплоть до получения одинакового кода. Знаю пример хреновый, но всё-же…
А else больше подошло-бы для варианты срабатывания после break (хотя кому такой вариант нужен?)
Если внимательно присмотреться к нашим чиновникам и правительству, то становится понятно, что большинство их «решений» это вовсе не злонамеренное действие, а совсем даже…