Я вам про Ивана, вы мне про ... Мы не обсуждаем, что и куда утекло. У вас в статье написано
Некоторые из них прибегают к автогенерации кода на основе схем Swagger, другие переписывают код вручную. Однако эти подходы требуют значительных ресурсов и времени, а также часто приводят к избыточному коду, который растет в объеме вместе с количеством задействованных в коде методов API. В данной статье я хочу поделиться методом, который позволяет избежать этих сложностей.
Как при измерении апи в моем примере ваш подход избавляет от сложностей, о которых вы сами написали, если все равно приходится менять логику запроса?
Тогда резюмируя все вышесказанное при существенном изменении API придется менять не только слой апи и вот эти вот интерфейсы, но и логику получения данных независимо от того, где она находится. Вот поэтому я и не понял, как ваш подход избавляет от этого.
Вы забыли, что надо ещё поменять логику запроса этих данных. Ранее одного запроса было достаточно, теперь надо делать два. Причем может случиться так, что нагрузка запроса тоже поменялась. Тут простым изменением интерфейса тайпскрипта не обойтись. Придется менять логику получения данных и их обработку. Если все это инкапсулировать в отдельный класс/объект/модуль, то это модуль в любом случае придется постоянно переписывать при таких изменениях.
Статью я прочитал, но видимо не понял всех плюсов решения. Давайте разберём реальный кейс. Допустим, у нас была логика: запрашиваем URL url1/common1, возвращается структура
{
"key1":"val1",
"key2":"val2"
}
API поменялось, теперь надо запрашивать 2 URL'а: url/entity2 и url/entity3, возвращается соответственно
{
"key1": {
"key3": "val1"
}
}
и
{
"key4": "val2"
}
Какой должен быть интерфейс старого API и как мне нужно его поменять на стороне клиента, чтобы адаптировать под новый API?
Вместо поддержки слоя API вы предлагаете поддерживать слой прокси. Апи может так поменяться, что никакой прокси слой не спасет. Ну и потом, не весь бэк на ноде пишется и не везде на бэке используется тайпскрипт. Все это как мёртвому припарка.
Макось вполне способна ворочаться на 8гб . Учитывая, что это air, а не про, ЦА этой модели не компилирует мегабайты кода и не монтирует гигабайты видео на этом. Если этого не делать,с 8гб и с быстрым свопом рядовой пользователь дискомфорта ощущать не будет. Браузер, просмотр видео, работа с документами, редактирование фотографий, подготовка отчётов, презентаций, проведение конференций - вот под эти задачи вполне хватит. Зачем переплачивать за 16гб? Кому надо, тот добавит в конструкторе на сайте эппла и закажет кастомизированную версию. Мой жене вполне 8гб с головой хватит
Вы не учитываете, что затраты (временные и финансовые), которые необходимо потратить на это, непропорционально велики по сравнению с прибылью, которую компания сможет извлечь из этого. Вдобавок, рост потребности в ресурсах стимулирует рынок железа. Все в выгоде. И как вообще продавать эту вашу оптимизацию - непонятно. Я вот прям представляю, как маркетологи говорят "наша ос стала в 2 раза быстрее по сравнению с предыдущей версией", а рядовому потребителю мягко говоря все равно. Ибо он уже давно купил достаточно мощное железо, чтобы на замечать разницы между условно 1.и 0.5 секундами задержки. А те, кто сидит на старом железе, новую ос не факт что могут поставить, ибо набор команд процессора может уже не поддерживаться, нет secure boot и прочих улучшений, без которых винда ну никак не запустится) Вы мыслите с точки зрения потребителя и только в целях экономии железа, а интересы компании совсем не рассматриваете.
Вот поэтому js и "не любят". Потому что там есть вещи, которые выглядят, как надёжные, но работают мягко говоря не надежно, и которые, как оказывается, "никто не использует", но они зачем-то есть. Обо что часто и спотыкаются новички. Ибо эти сакральные знания приходят с опытом.
В СНГ итак неопределённостей в жизни у людей хватает, а работа по контракту добавляет ещё одну (увольнение одним днём, работа на 6 месяцев, а потом опять искать). С финансовыми обязательствами вроде кредитов и ипотеки, где нужны постоянные выплаты, так работать не очень приятно.
Вообще, есть ИП и гражданский трудовой договор, что в принципе и есть по сути работа по контракту.
Хром для Линукса умеет из коробки выносить сайт в отдельный ярлык. Запускается при этом в отдельном окне без меню браузера и выглядит вполне себе как отдельное приложение. Я жене ватсап так вынес. Не уверен, что другие браузеры так могут, но вот если пользуетесь хромом, можно без сторонних приложений этого добиться.
Микросервисы - это не "серебряная пуля". У них есть свои проблема, которые отсутствуют в монолите, например, увеличивающаяся сложность поддержки, более жестокие требования к инфраструктуре, обеспечение консистентности данных при их распределенном хранении, необходимость контрактного тестирования, сложность отладки и профилирования.
Если люди, пишущие код, не способны контролировать его связность, у вас точно так же в микросервисе будет сильная связность. Но таких проектов уже будет не один. Тут надо повышать квалификацию инженеров или вводить тех лида/архитектора для контроля. Но микросервисы вам тут не помогут)
Ну этот вопрос надо им и задавать. Но думаю, поскольку эта дока находится в разделе Mac accessibility shortcutshttps://support.apple.com/en-us/HT204434, эта фича рассчитана на людей с ограничениями. А поскольку мак рассчитан на управление мышью или трэкпадом в основном и беспроводные мыши появились не так уж и давно, конкретно такой кейс как у вас разработчики системы даже не рассматривали) Но это мое предположение.
Как без этой включённой галочки подключить мышку, имея только клавиатуру?
Подозреваю, что подключив проводную мышь) Но ваш кейс интересный, можно написать в поддержку, посмотреть, что они ответят))
Нельзя сразу с негативом подходить к вопросу, так вы обязательно найдете что-то плохое и нерабочее, поскольку сразу ожидаете это найти. Идеальных систем нет, у каждой свои тараканы. Благо альтернатива всегда есть, может имеет смысл как раз выбрать что-то другое, если вам эта система не подходит
Есть pyenv и плагин для него pyenv-virtualenv. Это 2 инструмента решают вопрос независимого сожительства как разных версий питона, так и разных виртуальных окружений для проектов для каждой отдельной версии питона. Обе ставятся из brew.
В кучу раздражения добавлю невозможность клавишей TAB и стрелочками переключаться между элементами интерфейса. Банальное диалоговое окно с вариантами "ДА/НЕТ" не возможно обработать клавиатурой. Только курсором.
Есть такая возможность, просто по умолчанию она отключена https://support.apple.com/en-us/HT204434. Почему отключена) - не подскажу, но навигироваться по всем элементам интерфейса можно, достаточно поставить галочку "Use keyboard navigation to move focus between controls."
Я вам про Ивана, вы мне про ... Мы не обсуждаем, что и куда утекло. У вас в статье написано
Как при измерении апи в моем примере ваш подход избавляет от сложностей, о которых вы сами написали, если все равно приходится менять логику запроса?
Тогда резюмируя все вышесказанное при существенном изменении API придется менять не только слой апи и вот эти вот интерфейсы, но и логику получения данных независимо от того, где она находится. Вот поэтому я и не понял, как ваш подход избавляет от этого.
Вы забыли, что надо ещё поменять логику запроса этих данных. Ранее одного запроса было достаточно, теперь надо делать два. Причем может случиться так, что нагрузка запроса тоже поменялась. Тут простым изменением интерфейса тайпскрипта не обойтись. Придется менять логику получения данных и их обработку. Если все это инкапсулировать в отдельный класс/объект/модуль, то это модуль в любом случае придется постоянно переписывать при таких изменениях.
Статью я прочитал, но видимо не понял всех плюсов решения. Давайте разберём реальный кейс. Допустим, у нас была логика: запрашиваем URL url1/common1, возвращается структура
API поменялось, теперь надо запрашивать 2 URL'а: url/entity2 и url/entity3, возвращается соответственно
и
Какой должен быть интерфейс старого API и как мне нужно его поменять на стороне клиента, чтобы адаптировать под новый API?
Вместо поддержки слоя API вы предлагаете поддерживать слой прокси. Апи может так поменяться, что никакой прокси слой не спасет. Ну и потом, не весь бэк на ноде пишется и не везде на бэке используется тайпскрипт. Все это как мёртвому припарка.
Макось вполне способна ворочаться на 8гб . Учитывая, что это air, а не про, ЦА этой модели не компилирует мегабайты кода и не монтирует гигабайты видео на этом. Если этого не делать,с 8гб и с быстрым свопом рядовой пользователь дискомфорта ощущать не будет. Браузер, просмотр видео, работа с документами, редактирование фотографий, подготовка отчётов, презентаций, проведение конференций - вот под эти задачи вполне хватит. Зачем переплачивать за 16гб? Кому надо, тот добавит в конструкторе на сайте эппла и закажет кастомизированную версию. Мой жене вполне 8гб с головой хватит
Вы не учитываете, что затраты (временные и финансовые), которые необходимо потратить на это, непропорционально велики по сравнению с прибылью, которую компания сможет извлечь из этого. Вдобавок, рост потребности в ресурсах стимулирует рынок железа. Все в выгоде. И как вообще продавать эту вашу оптимизацию - непонятно. Я вот прям представляю, как маркетологи говорят "наша ос стала в 2 раза быстрее по сравнению с предыдущей версией", а рядовому потребителю мягко говоря все равно. Ибо он уже давно купил достаточно мощное железо, чтобы на замечать разницы между условно 1.и 0.5 секундами задержки. А те, кто сидит на старом железе, новую ос не факт что могут поставить, ибо набор команд процессора может уже не поддерживаться, нет secure boot и прочих улучшений, без которых винда ну никак не запустится) Вы мыслите с точки зрения потребителя и только в целях экономии железа, а интересы компании совсем не рассматриваете.
Правильное поведение - это когда тип конвертируется всегда одинаково. Но в примере выше что-то пошло не так) И это далеко не правильное поведение.
Вот поэтому js и "не любят". Потому что там есть вещи, которые выглядят, как надёжные, но работают мягко говоря не надежно, и которые, как оказывается, "никто не использует", но они зачем-то есть. Обо что часто и спотыкаются новички. Ибо эти сакральные знания приходят с опытом.
Чтобы не объедались, компания заботится о весе сотрудников)
Что характерно, одно время ваши сотрудники всё-таки пользовались сканером, потом перешли на мобилки.
Тут часто время зависит от того, какую библиотеку вы для этого использовали. Стандартная медленная, попробуйте https://github.com/ijl/orjson.
Мултитаскинг - это миф
В СНГ итак неопределённостей в жизни у людей хватает, а работа по контракту добавляет ещё одну (увольнение одним днём, работа на 6 месяцев, а потом опять искать). С финансовыми обязательствами вроде кредитов и ипотеки, где нужны постоянные выплаты, так работать не очень приятно.
Вообще, есть ИП и гражданский трудовой договор, что в принципе и есть по сути работа по контракту.
Хром для Линукса умеет из коробки выносить сайт в отдельный ярлык. Запускается при этом в отдельном окне без меню браузера и выглядит вполне себе как отдельное приложение. Я жене ватсап так вынес. Не уверен, что другие браузеры так могут, но вот если пользуетесь хромом, можно без сторонних приложений этого добиться.
Микросервисы - это не "серебряная пуля". У них есть свои проблема, которые отсутствуют в монолите, например, увеличивающаяся сложность поддержки, более жестокие требования к инфраструктуре, обеспечение консистентности данных при их распределенном хранении, необходимость контрактного тестирования, сложность отладки и профилирования.
Если люди, пишущие код, не способны контролировать его связность, у вас точно так же в микросервисе будет сильная связность. Но таких проектов уже будет не один. Тут надо повышать квалификацию инженеров или вводить тех лида/архитектора для контроля. Но микросервисы вам тут не помогут)
Оправдались ваши ожидания?
Ну этот вопрос надо им и задавать. Но думаю, поскольку эта дока находится в разделе Mac accessibility shortcuts https://support.apple.com/en-us/HT204434, эта фича рассчитана на людей с ограничениями. А поскольку мак рассчитан на управление мышью или трэкпадом в основном и беспроводные мыши появились не так уж и давно, конкретно такой кейс как у вас разработчики системы даже не рассматривали) Но это мое предположение.
Подозреваю, что подключив проводную мышь) Но ваш кейс интересный, можно написать в поддержку, посмотреть, что они ответят))
Нельзя сразу с негативом подходить к вопросу, так вы обязательно найдете что-то плохое и нерабочее, поскольку сразу ожидаете это найти. Идеальных систем нет, у каждой свои тараканы. Благо альтернатива всегда есть, может имеет смысл как раз выбрать что-то другое, если вам эта система не подходит
Есть pyenv и плагин для него pyenv-virtualenv. Это 2 инструмента решают вопрос независимого сожительства как разных версий питона, так и разных виртуальных окружений для проектов для каждой отдельной версии питона. Обе ставятся из brew.
Есть такая возможность, просто по умолчанию она отключена https://support.apple.com/en-us/HT204434. Почему отключена) - не подскажу, но навигироваться по всем элементам интерфейса можно, достаточно поставить галочку "Use keyboard navigation to move focus between controls."