Думаю вы понимаете, что станет с зарплатами и конкуренцией в ИТ и если 80% работы будут делать ИИ?
По сравнению со временами перфокарт или даже ассемблеров, сейчас 80 процентов за меня делают более высокоуровневый язык, IDE, фреймворки, stackoverflow, но работы меньше не стало
Большинство компаний регулярно сталкиваются с проблемой постоянной модификации слоя API в своих веб-приложениях в ответ на изменения API сервера
Получается, что вы меняете слой API практически также, как и в реализации без прокси. Также, был упомянут вариант с кодогенерацией по спеке openapi, в котором как раз вообще ничего не меняется в слое API (ну как, пока генератор нормально генерирует, потому что там тоже даже для популярнейшего тайпскрипта периодически всплывают баги даже в самых популярных генераторах).В общем, я не понял, чем ваш вариант лучше существующих и решает ли он вообще проблему.
Большинство компаний регулярно сталкиваются с проблемой постоянной модификации слоя API в своих веб-приложениях в ответ на изменения API сервера
Если честно, я не очень понял, как этот метод спасает от изменения API на бэке. Если часть каких-то данных переместили в другой эндпоинт? Или разбили логику на несколько эндпоинтов? Или поменялся content type? А как это работает с вложенными эндпоинтами, напр., item/{id}/nested_item ? Для чего писать в начале методы, если у нас уже есть соглашение в рамках RESTfull API?
Почитав комменты выше автолюбителей, пришел к такому же мнению. Сделать некоторое количество кнопок кастомизируемыми, чтоб можно было маппить крутилки экрана на крутилки и кнопки физические. Или, как вариант, сделать доп кнопку, которая переключает режимы всего блока. Условно, сейчас блок физических кнопок настроен на радио, переключаем один раз и блок теперь управляет климат контролем, переключаем ещё раз - чем-то другим и тд.
Я понимаю, что эти фантазии имеют место быть, но на мой взгляд эти оба кейса это дикость, т.к. в джанге многое завязано на модели как они есть. Взять те же class based views из самой джанги или из DRF, модуль аутентификации с user model, а сколько разных батареек ждёт джанговскую модель... Я не вижу особой разницы между этим вариантом и переписыванием с нуля хоть на другом фреймворке, хоть на другом вообще стеке. Второй вариант тоже выглядит весьма сомнительным, так как мы вместо уменьшения связности идём наоборот в сторону её увеличения. У нас оба фреймворка предназначены практически для одной и той же задачи, с разницей лишь в нюансах и мы из каких-то мутных побуждений берём их оба и строим франкенштейна (ну тут просто удачи, что сказать). Помимо того, что у нас в коде переплетены 2 фреймворка, так у нас ещё значительно вырастает количество зависимостей, за которыми надо следить, у нас увеличивается сложность поддержки проекта, увеличиваем требования к экспертизе разработчиков в команде. В таком случае проще выделять из Django что-то в отдельные независимые сервисы на fastapi, если есть в этом необходимость и уменьшать связность.
В чем смысл пилить в джанге репозитории, когда джанго орм уже и так представляет из себя достаточную абстракцию над несколькими субд? Там же много всего завязано на модели джанго орм.
Идея в том, чтобы обучать как можно более сложные сети на как можно более полной информации о мире Да, только это не информация о мире как я понял, это всё модели и симуляции, т.е. нейросеть будет обучаться на симуляциях мира, а не на настоящих фактах о мире. Это же просто путь в никуда, все эти AGI будут отдавать всё менее и менее правдоподобную информацию о реальном мире.
В результате масштабирования через пул IP-адресов удалось распараллелить обращения к Whois-сервисам и повысить производительность системы по latency.
Если вы добавили прокси-сервер для доступа к third-party сервису, т.е. ещё одно звено в цепи запросов, то итоговый latency должен увеличиться, а не уменьшиться.
По сравнению со временами перфокарт или даже ассемблеров, сейчас 80 процентов за меня делают более высокоуровневый язык, IDE, фреймворки, stackoverflow, но работы меньше не стало
Спасибо за статью
Получается, что вы меняете слой API практически также, как и в реализации без прокси. Также, был упомянут вариант с кодогенерацией по спеке openapi, в котором как раз вообще ничего не меняется в слое API (ну как, пока генератор нормально генерирует, потому что там тоже даже для популярнейшего тайпскрипта периодически всплывают баги даже в самых популярных генераторах).В общем, я не понял, чем ваш вариант лучше существующих и решает ли он вообще проблему.
By the way
Если честно, я не очень понял, как этот метод спасает от изменения API на бэке. Если часть каких-то данных переместили в другой эндпоинт? Или разбили логику на несколько эндпоинтов? Или поменялся content type? А как это работает с вложенными эндпоинтами, напр., item/{id}/nested_item ? Для чего писать в начале методы, если у нас уже есть соглашение в рамках RESTfull API?
Почитав комменты выше автолюбителей, пришел к такому же мнению. Сделать некоторое количество кнопок кастомизируемыми, чтоб можно было маппить крутилки экрана на крутилки и кнопки физические. Или, как вариант, сделать доп кнопку, которая переключает режимы всего блока. Условно, сейчас блок физических кнопок настроен на радио, переключаем один раз и блок теперь управляет климат контролем, переключаем ещё раз - чем-то другим и тд.
Глубокое заблуждение
Я понимаю, что эти фантазии имеют место быть, но на мой взгляд эти оба кейса это дикость, т.к. в джанге многое завязано на модели как они есть. Взять те же class based views из самой джанги или из DRF, модуль аутентификации с user model, а сколько разных батареек ждёт джанговскую модель... Я не вижу особой разницы между этим вариантом и переписыванием с нуля хоть на другом фреймворке, хоть на другом вообще стеке.
Второй вариант тоже выглядит весьма сомнительным, так как мы вместо уменьшения связности идём наоборот в сторону её увеличения. У нас оба фреймворка предназначены практически для одной и той же задачи, с разницей лишь в нюансах и мы из каких-то мутных побуждений берём их оба и строим франкенштейна (ну тут просто удачи, что сказать). Помимо того, что у нас в коде переплетены 2 фреймворка, так у нас ещё значительно вырастает количество зависимостей, за которыми надо следить, у нас увеличивается сложность поддержки проекта, увеличиваем требования к экспертизе разработчиков в команде. В таком случае проще выделять из Django что-то в отдельные независимые сервисы на fastapi, если есть в этом необходимость и уменьшать связность.
В чем смысл пилить в джанге репозитории, когда джанго орм уже и так представляет из себя достаточную абстракцию над несколькими субд? Там же много всего завязано на модели джанго орм.
Будет ли работать это решение, но посмотрим
Идея в том, чтобы обучать как можно более сложные сети на как можно более полной информации о миреДа, только это не информация о мире как я понял, это всё модели и симуляции, т.е. нейросеть будет обучаться на симуляциях мира, а не на настоящих фактах о мире. Это же просто путь в никуда, все эти AGI будут отдавать всё менее и менее правдоподобную информацию о реальном мире.
Не сильно далеко от второго железного человека
Хабр тоже через раз открывается (мтс)
Всё очень даже понятно
Да.
Если вы добавили прокси-сервер для доступа к third-party сервису, т.е. ещё одно звено в цепи запросов, то итоговый latency должен увеличиться, а не уменьшиться.
В итоге у них будут эпплы более свежей версии)
Смерть
Сколько же воды, просто три раза сказано про мужские/женские, ещё сколько раз про ошибочное мнение, одни маты после чтения этой писанины
В образе издателя