Вероятно, вы и первый комментатор только отдельные страницы архивируете, раз вам хватает MHTML. Я про более масштабные архивы, где под угрозой ресурс целиком и он ценен весь. По факту, ссылки и пагинация и внутри сайта мало где нормально сделаны. Даже у известных хакеров. Как следствие, в зеркале дубли страниц и сломанный поиск, приходится патчить код загруженных страниц. Повторю, на фоне этой канители ТГ-каналы архивируются много удобнее.
Костыли – это вордпрессы и вк-паблики, которые хрен сохранишь локально. Заявляю как опытный пользователь HTTrack, wget, heritrix и прочих grab-site-ов.
Насчёт сохранения – целиком экспортировать канал к себе на диск довольно просто, это есть в Десктоп-клиенте. И потом для бережного хранения зажать в Squashfs – в Линукс достаточно одной команды. Вполне удобно.
Благодарю за уточнение! Действительно, есть такое чудо чудесное, Windows-based containers. С интересом почитал про эту диковинку и не нашёл значимых случаев её применения. Есть мнение, что это громоздкая и неторопливая штука. В итоге, погоды она всё-равно не делает.
Postman в нынешнее время - незаменимый инструмент, и не только для бэкенд разработчиков с тестировщиками.
Postman это ненасытный монстр, который нас всех проглотит;) Так ли уж незаменим? Если не секрет, как вы коллекции храните и распространяете? Возможно, есть платная подписка. Меня смущает привязка к облаку и возможность блокировки. Больше нравится примеры запросов хранить текстом в репозитории, в виде файлов, как это делают httpYac или Bruno.
А мок сервер наверняка можно отдельно поднять, из OpenAPI-схемы. Такой подход видится более гибким и надёжным.
Долгое основательное вступление, к нему ожидались поучительные примеры из жизни, но нет, опять в другой раз. Сама то идея понятна и привлекательна. Хочется узнать реальный опыт, вот собрали OpenAPI схему, утвердили, положили в репозиторий, таким-то инструментом нагенерили моки, оживили их, фронтэндеры пользуются. Потом прилетела правка, обновили схему. Что-то ещё надо сделать? Насколько гладко и безболезненно проходят правки? В моей практике есть задачи, где такие правки неоднократные, хотя и мелкие.
с ходу не получилось установить соединение через Tor, хотя я пробовал использовать предлагаемые мосты (bridges) и разных провайдеров
Возможно, потому что вы это пробовали в стране, где заблокирован Tor на всех провайдерах. Да и зачем оно, когда есть другие инструменты.
Не знаю, насколько может быть востребовано данное решение, надеюсь, оно имеет право на жизнь. Как считаете?
Хорошее решение, положить в сумочку на чёрный день, только добавить на SD-карту базу KeePass. Крыска не так уж и легка сейчас, Хвосты привлекают лишнее внимание, я бы взял дистриб полегче, типа PuppyRus.
Реакция сообщества - это вы про 8 дизлайков в гитхабе? Это ни о чём. Я сугубо практик. Про connexion там верно подметили, вот инструмент гораздо более подходящий.
Ознакомьтесь со списоком генераторов
Даже пробовал похожее, для генерации нагрузочных тестов. Не впечатлило.
Вы не подумайте, мне нравится сама идея API first. Ещё бы поглядеть на видео как полагается спеку собирать, опенсорсными local-first инструментами, желательно не выходя из VS Code. Swagger Editor не предлагать;)
API first это хорошо и понятно, и с этим нигде не спорил. Противоестественность вижу только в использовании конкретного инструмента, FastAPI. Ведь автор фреймворка подробно изложил свой подход, ссылка в предыдущем комменте. Взять инструмент и не пользоваться половиной его возможностей или пользоваться поперёк - не мой путь.
если тема вам кажется интересной
Да, тема настолько интересна, что каждый день по ней работаю. Во многих статьях красиво изложено на паре примитивных роутов и на типах integer и string. На практике бывают весьма развесистые джсоны на входе/выходе, с кучей разнообразных проверок, включая непустые массивы, диапазоны чисел, url и прочее. Можете подсказать видео, очень хочется посмотреть процесс, как с нуля собирается yaml для нетривиального API хотя бы на пять полноценных сущностей?
Если проект большой, много команд и есть отдельный опытный аналитик, то конечно же удобно и правильно сперва зафиксировать спеку. Я не лезу в такое, пишу только с позиции одной команды и проекта типа стартапа. Так вот, на мой взгляд FastAPI особенно хорош для стартапов, и удивительно и приятно видеть его заход в более крупные проекты.
Но ведь в FastAPI уже из коробки есть Swagger UI. Я не пишу его, он там работает автомагически. Зачем выбирать, когда он уже там есть?
Я вижу противоестественное использование инструмента и это меня напрягает. Если смотреть в масштабе команды, когда можно выбирать инструменты, то FastAPI полностью закрывает и валидацию и автодокументацию. Это его лучшие стороны. Мой опыт с JSON Schema и другими валидаторами (и другими стеками) позволяет сравнить и сделать вывод, что FastAPI здесь крайне хорош. Рекомендую почитать, как автор объясняет причину создания FastAPI: https://fastapi.tiangolo.com/alternatives/#swagger-openapi
Про Flask и сокращение работы - скажу кратко и поэтому довольно категорично. В новом проекте я бы забыл про Flask и попросил бы аналитиков работать с вики-текстом и схемами и не тратить время на собирание yaml руками. Само собой, у фронтэнда и тестировщиков будет всегда актуальный Swagger UI, бесплатно. Если в проекте Flask и автогенерация Pydantic моделей - это не мой проект, извините.
Что-то у меня голова закружилась. С ног на голову перевёрнуто. Как раз-таки ключевая особенность FastAPI это чудесный встроенный генератор OpenAPI из Pydantic-моделей. А писать Pydantic-модели проще некуда и уж намного приятнее всяких Swagger Editor-ов.
«Offline-First and Bloat-Free» – выглядит как хорошая замена тяжеловесному Постману. Раньше такой заменой была Инсомния, но сейчас она привязалась к облаку. Внутри IDE вполне удобен httpYac, но у аналитиков и тестировщиков не всегда есть IDE.
Тут есть ежемесячный дайджест Постгрессо (посвящён PostgreSQL), пользуется спросом. Вот в таком бы формате по Пайтону. Хорошо бы взять пошире, включить разные другие источники, которые вас вдохновляют, включая англоязычные. Но глубину оставить, поверхностных материалов и так хватает. В любом случае, спасибо за старания!
В заголовке между «Автоматизация» и «REST API» пропало важное слово «тестирования». А вот слово «REST» не обязательное, там не только HTTP. Постман это же привязка к иностранному облаку, уже вроде наелись такого. Есть же более свободный httpYac.
Одна вакансия – не так уж мало! Всего в 3 раза меньше, чем на легендарный Rust. Вообще по слову Rust сейчас нашлось 5 вакансий, но 2 из них уровня техдира/лида, так что их не считаем. На Carbon и Nim вообще нет спроса.
Удобство обсуждать смысла нет, тут субъективно. Лично мне виндовая панель задач не мешает. Коннектиться по RDP не обязательно, QEMU работает в таком же нативном соседнем окне. По ресурсам не соглашусь, мой вариант намного легче, особенно по диску. Плюс всё прозрачно, проще дебаг, нет зависимости от сторонних репозиториев и образов.
Вероятно, вы и первый комментатор только отдельные страницы архивируете, раз вам хватает MHTML. Я про более масштабные архивы, где под угрозой ресурс целиком и он ценен весь. По факту, ссылки и пагинация и внутри сайта мало где нормально сделаны. Даже у известных хакеров. Как следствие, в зеркале дубли страниц и сломанный поиск, приходится патчить код загруженных страниц. Повторю, на фоне этой канители ТГ-каналы архивируются много удобнее.
Костыли – это вордпрессы и вк-паблики, которые хрен сохранишь локально. Заявляю как опытный пользователь HTTrack, wget, heritrix и прочих grab-site-ов.
Насчёт сохранения – целиком экспортировать канал к себе на диск довольно просто, это есть в Десктоп-клиенте. И потом для бережного хранения зажать в Squashfs – в Линукс достаточно одной команды. Вполне удобно.
В статье речь о командной работе. Как вы предлагаете синхронизировать коллекции, ведь правки наверняка будет вносить не только лишь один избранный?
Насчёт блокировки и нормальной работы без облачной учётки - у вас наверное какой-то особый Постман.
Под Линуксом даже коллекцию открыть нельзя без входа
Благодарю за уточнение! Действительно, есть такое чудо чудесное, Windows-based containers. С интересом почитал про эту диковинку и не нашёл значимых случаев её применения. Есть мнение, что это громоздкая и неторопливая штука. В итоге, погоды она всё-равно не делает.
Postman это ненасытный монстр, который нас всех проглотит;) Так ли уж незаменим? Если не секрет, как вы коллекции храните и распространяете? Возможно, есть платная подписка. Меня смущает привязка к облаку и возможность блокировки. Больше нравится примеры запросов хранить текстом в репозитории, в виде файлов, как это делают httpYac или Bruno.
А мок сервер наверняка можно отдельно поднять, из OpenAPI-схемы. Такой подход видится более гибким и надёжным.
Долгое основательное вступление, к нему ожидались поучительные примеры из жизни, но нет, опять в другой раз. Сама то идея понятна и привлекательна. Хочется узнать реальный опыт, вот собрали OpenAPI схему, утвердили, положили в репозиторий, таким-то инструментом нагенерили моки, оживили их, фронтэндеры пользуются. Потом прилетела правка, обновили схему. Что-то ещё надо сделать? Насколько гладко и безболезненно проходят правки? В моей практике есть задачи, где такие правки неоднократные, хотя и мелкие.
А какой размер ОЗУ? Как вариант Alpine Linux x86 + оконный менеджер JWM или IceWM
Прекрасная иллюстрация: где человеку разумному достаточно трёх слов, ИИ размажет на три страницы.
Не только chroot, но и других более современных механизмов, типа namespaces и cgroups. Но да, самое главное, ядро Linux для Docker нужно обязательно.
Возможно, потому что вы это пробовали в стране, где заблокирован Tor на всех провайдерах. Да и зачем оно, когда есть другие инструменты.
Хорошее решение, положить в сумочку на чёрный день, только добавить на SD-карту базу KeePass. Крыска не так уж и легка сейчас, Хвосты привлекают лишнее внимание, я бы взял дистриб полегче, типа PuppyRus.
Реакция сообщества - это вы про 8 дизлайков в гитхабе? Это ни о чём. Я сугубо практик. Про connexion там верно подметили, вот инструмент гораздо более подходящий.
Даже пробовал похожее, для генерации нагрузочных тестов. Не впечатлило.
Вы не подумайте, мне нравится сама идея API first. Ещё бы поглядеть на видео как полагается спеку собирать, опенсорсными local-first инструментами, желательно не выходя из VS Code. Swagger Editor не предлагать;)
API first это хорошо и понятно, и с этим нигде не спорил. Противоестественность вижу только в использовании конкретного инструмента, FastAPI. Ведь автор фреймворка подробно изложил свой подход, ссылка в предыдущем комменте. Взять инструмент и не пользоваться половиной его возможностей или пользоваться поперёк - не мой путь.
Да, тема настолько интересна, что каждый день по ней работаю. Во многих статьях красиво изложено на паре примитивных роутов и на типах integer и string. На практике бывают весьма развесистые джсоны на входе/выходе, с кучей разнообразных проверок, включая непустые массивы, диапазоны чисел, url и прочее. Можете подсказать видео, очень хочется посмотреть процесс, как с нуля собирается yaml для нетривиального API хотя бы на пять полноценных сущностей?
Если проект большой, много команд и есть отдельный опытный аналитик, то конечно же удобно и правильно сперва зафиксировать спеку. Я не лезу в такое, пишу только с позиции одной команды и проекта типа стартапа. Так вот, на мой взгляд FastAPI особенно хорош для стартапов, и удивительно и приятно видеть его заход в более крупные проекты.
Но ведь в FastAPI уже из коробки есть Swagger UI. Я не пишу его, он там работает автомагически. Зачем выбирать, когда он уже там есть?
Я вижу противоестественное использование инструмента и это меня напрягает. Если смотреть в масштабе команды, когда можно выбирать инструменты, то FastAPI полностью закрывает и валидацию и автодокументацию. Это его лучшие стороны. Мой опыт с JSON Schema и другими валидаторами (и другими стеками) позволяет сравнить и сделать вывод, что FastAPI здесь крайне хорош. Рекомендую почитать, как автор объясняет причину создания FastAPI: https://fastapi.tiangolo.com/alternatives/#swagger-openapi
Про Flask и сокращение работы - скажу кратко и поэтому довольно категорично. В новом проекте я бы забыл про Flask и попросил бы аналитиков работать с вики-текстом и схемами и не тратить время на собирание yaml руками. Само собой, у фронтэнда и тестировщиков будет всегда актуальный Swagger UI, бесплатно. Если в проекте Flask и автогенерация Pydantic моделей - это не мой проект, извините.
Что-то у меня голова закружилась. С ног на голову перевёрнуто. Как раз-таки ключевая особенность FastAPI это чудесный встроенный генератор OpenAPI из Pydantic-моделей. А писать Pydantic-модели проще некуда и уж намного приятнее всяких Swagger Editor-ов.
«Offline-First and Bloat-Free» – выглядит как хорошая замена тяжеловесному Постману. Раньше такой заменой была Инсомния, но сейчас она привязалась к облаку. Внутри IDE вполне удобен httpYac, но у аналитиков и тестировщиков не всегда есть IDE.
Тут есть ежемесячный дайджест Постгрессо (посвящён PostgreSQL), пользуется спросом. Вот в таком бы формате по Пайтону. Хорошо бы взять пошире, включить разные другие источники, которые вас вдохновляют, включая англоязычные. Но глубину оставить, поверхностных материалов и так хватает. В любом случае, спасибо за старания!
В заголовке между «Автоматизация» и «REST API» пропало важное слово «тестирования». А вот слово «REST» не обязательное, там не только HTTP. Постман это же привязка к иностранному облаку, уже вроде наелись такого. Есть же более свободный httpYac.
Одна вакансия – не так уж мало! Всего в 3 раза меньше, чем на легендарный Rust. Вообще по слову Rust сейчас нашлось 5 вакансий, но 2 из них уровня техдира/лида, так что их не считаем. На Carbon и Nim вообще нет спроса.
Удобство обсуждать смысла нет, тут субъективно. Лично мне виндовая панель задач не мешает. Коннектиться по RDP не обязательно, QEMU работает в таком же нативном соседнем окне. По ресурсам не соглашусь, мой вариант намного легче, особенно по диску. Плюс всё прозрачно, проще дебаг, нет зависимости от сторонних репозиториев и образов.