Плюс необходимость поддерживать все эти пеи на стороне продавца, причем каждый со своим API. Это если пытаться использовать их в своих мобильных приложениях или для оплаты на сайте.
Глупый вопрос, но почему ключевое слово для короутин именно suspend? Оно ведь означает "приостановить". Почему бы не сделать что-нибудь более понятное, типа async, asynchronous, awaitable, coroutine ?
Насколько я помню, при оплате через Google Pay и Apple Pay можно сформировать токен на оплату одной суммы (которая отобразится на экране устройства), но в банк отправить запрос на списание меньшей суммы. Возможно, с Mir Pay можно делать так же.
Насчет задержки между нажатием на клавишу и отображением символа на экране... Как бы сравнение не слишком корректно.
В 1980-х годах для этого нужно было обработать прерывание от клавиатуры, положить символ в буфер и отобразить на экране с заранее запрограммированным шрифтом.
Сейчас нужно сделать откровенно дофига: получить это нажатие системой, проверить, не является ли оно служебной комбинацией клавиш, оповестить приложения о этом нажатии, преобразовать нажатие в символ на нужном языке, обработать этот символ в самом приложении (всякие подсказки и автодополнения), отобразить на экране с нужным красивым шрифтом в hi-dpi... ну как-то так. И все это в условиях многозадачности.
Компьютеры стали на порядки мощнее, но и задачи тоже нехило усложнились - пусть мы их временами не замечаем, и для нас это все такое же нажатие на клавишу и отображение символа.
Некоторые банки (например, Альфа) вообще считают операции с Qiwi (пополнение кошелька, перевод на виртуальную карту Qiwi) подозрительными и блокируют карту.
У подобного способа есть один минус: отсутствует кеширование при построении контейнера. Это довольно критично, если у вас много зависимостей, которые долго скачиваются либо собираются.
Как вариант, на одном из шагов можно удалять лишние данные из контейнера, чтобы уменьшить его размер.
Хмм... Шанс получить хорошую видяху 2+4 = 6%. В среднем можно вытащить с 100 / 6 ~= 17 попытки. 17 попыток = 17 * 14 000 = 238 000 йен ~= 153 500 рублей.
Шанс на все нормальные видяхи 2+4+8+16 = 30%. Это примерно каждая третья видяха. Треть от 17 - это примерно 5 нормальных видях. GTX 950 на Авито продается от 9 000 рублей... Если их продать, можно получить от 9 000 * 5 = 45 000 рублей.
RTX 3060 продается в Citilink за ~79 000. 153 500 - 45 000 - 79 000 = 29 500 рублей.
Как бы да, в целом небольшая прибыль продавцу есть, даже если играть честно.
Попробовал недавно Rust, теперь интересно: как на нем действительно можно писать с комфортом? Куча кода просто генерируется через derive, этот сгенерированный код не подцепляется к анализу и автодополнению ни в плагине к VSCode, ни в плагине к IntelliJ.
Потому что написание оптимизированного по всем статьям кода требует времени. А железо сейчас стоит дешевле, чем зарплата программистов. В итоге и получаем всякие тяжелые фреймворки, на которых можно писать быстро, но они жрут ресурсы.
У iPhone SE сейчас есть один большой недостаток: батарейка. В принципе, с его размерами это легко объяснимо, но когда заряда телефона не хватает до конца дня...
Пардон, поправка: тривиальные типы (типа string, int и т. п.) не могут быть nullable. Вложенные сообщения - могут. Для этого в well-known types как раз и сделаны типы наподобие Int64Value. Скорее всего, авторы в этом плане ориентировались на Go, где такая же логика и аналогичные типы для работы с sql.
Просто это сделано не слишком логично, учитывая наличие ключевых слов required и optional - благо от этого решили отказаться в третьей версии protobuf.
Извините, но по части аргументации местами написана откровенная ахинея. Да и код вам бы подправить, а то какая-то кривая копипаста, без стилевого оформления и с левыми "1 reference".
Реальный плюс GRPC всего один: использование одного HTTP/2 соединения для отправки множества запросов. Это ускоряет отправку запросов и получение ответов. Для REST это также никто не запрещает делать, но в дикой природе гораздо чаще встречается HTTP/1, который гораздо легче разбирать.
protobuf - формат неплохой, но не самый лучший. Например, по задумке авторов поля не могут быть nullable, что не всегда удобно. Существуют только примитивные типы, которые нужно вручную преобразовывать в нужный (та же дата/время, например). Да, в JSON типов еще меньше, но при этом в большинстве REST-фреймворков существует встроенная сериализация/десериализация для многих стандартных типов. В protobuf - нифига, бери строковое значение из поля и парси вручную.
Генерация кода... Да, можно сгенерировать код клиентской библиотеки и серверный бойлерплейт для многих языков. Но этот код зачастую сложен для понимания и анализа, в связи с чем IDE не всегда может адекватно сформировать подсказки по методам и полям. И чем это отличается от генерации кода для OpenAPI? Это притом, что OpenAPI часто генерируется автоматически на основе аннотаций в коде, и в нем можно указать гораздо больше различных данных: описания методов и полей, авторизация для методов, валидация передаваемых данных и т. п.
Обработка ошибок в GRPC тоже выглядит странновато. Если метод кидает исключение - не факт, что GRPC его отловит и вернет ошибку. Вместо этого нужно перехватывать исключения вручную и возвращать ошибки специальным способом - причем разным для каждого языка (то есть нельзя писать серверное приложение на Python, а потом с этим же опытом прийти в Go, GRPC API будет чувствительно различаться).
Все остальное - трассировка, health check, балансировка нагрузки, аутентификация и т. п. - либо не зависит от выбора "GRPC или REST", либо банально проще и удобнее в REST. Например, во многих REST-фреймворках есть интеграция с Prometheus, а для health check не нужно заводить отдельный класс. Балансировка нагрузки и аутентификация относятся скорее к API gateway (nginx/krakend/kong/tyc etc.) и к service mesh (istio etc.), а авторизация не доставляет проблем ни там, ни там.
Вполне возможно, что я где-то не прав, сужу чисто по личному опыту.
Плюс необходимость поддерживать все эти пеи на стороне продавца, причем каждый со своим API. Это если пытаться использовать их в своих мобильных приложениях или для оплаты на сайте.
Глупый вопрос, но почему ключевое слово для короутин именно
suspend? Оно ведь означает "приостановить". Почему бы не сделать что-нибудь более понятное, типаasync,asynchronous,awaitable,coroutine?Насколько я помню, при оплате через Google Pay и Apple Pay можно сформировать токен на оплату одной суммы (которая отобразится на экране устройства), но в банк отправить запрос на списание меньшей суммы. Возможно, с Mir Pay можно делать так же.
Насчет задержки между нажатием на клавишу и отображением символа на экране... Как бы сравнение не слишком корректно.
В 1980-х годах для этого нужно было обработать прерывание от клавиатуры, положить символ в буфер и отобразить на экране с заранее запрограммированным шрифтом.
Сейчас нужно сделать откровенно дофига: получить это нажатие системой, проверить, не является ли оно служебной комбинацией клавиш, оповестить приложения о этом нажатии, преобразовать нажатие в символ на нужном языке, обработать этот символ в самом приложении (всякие подсказки и автодополнения), отобразить на экране с нужным красивым шрифтом в hi-dpi... ну как-то так. И все это в условиях многозадачности.
Компьютеры стали на порядки мощнее, но и задачи тоже нехило усложнились - пусть мы их временами не замечаем, и для нас это все такое же нажатие на клавишу и отображение символа.
Аннотации типов нужны по большей части для самого программиста и IDE.
Интерпретатор сейчас их не валидирует никак - к огромному сожалению.
Извините, а где статья? Выглядит, как простое перечисление способов, без малейшего объяснения, что эти способы делают и как реализуются.
Некоторые банки (например, Альфа) вообще считают операции с Qiwi (пополнение кошелька, перевод на виртуальную карту Qiwi) подозрительными и блокируют карту.
Для Windows есть довольно удобный пакет программ PowerToys от самих Microsoft, который включает в себя утилиту для изменения размера изображений.
Для *nix гораздо проще воспользоваться imagemagick.
В Docker кешируются слои только для последнего stage. По крайней мере так было до 2021, далее с multistage building не работал.
Как справедливо отметил @sergeykons, у других сборщиков поведение может отличаться.
У подобного способа есть один минус: отсутствует кеширование при построении контейнера. Это довольно критично, если у вас много зависимостей, которые долго скачиваются либо собираются.
Как вариант, на одном из шагов можно удалять лишние данные из контейнера, чтобы уменьшить его размер.
Угу. А теперь сравните функциональность и список поддерживаемого железа для Windows и KolibriOS.
Хмм... Шанс получить хорошую видяху 2+4 = 6%. В среднем можно вытащить с 100 / 6 ~= 17 попытки. 17 попыток = 17 * 14 000 = 238 000 йен ~= 153 500 рублей.
Шанс на все нормальные видяхи 2+4+8+16 = 30%. Это примерно каждая третья видяха. Треть от 17 - это примерно 5 нормальных видях. GTX 950 на Авито продается от 9 000 рублей... Если их продать, можно получить от 9 000 * 5 = 45 000 рублей.
RTX 3060 продается в Citilink за ~79 000. 153 500 - 45 000 - 79 000 = 29 500 рублей.
Как бы да, в целом небольшая прибыль продавцу есть, даже если играть честно.
Попробовал недавно Rust, теперь интересно: как на нем действительно можно писать с комфортом? Куча кода просто генерируется через derive, этот сгенерированный код не подцепляется к анализу и автодополнению ни в плагине к VSCode, ни в плагине к IntelliJ.
Эмм... А про что, собственно, статья? Как подать на вход некорректное значение и словить ошибку?
Потому что написание оптимизированного по всем статьям кода требует времени. А железо сейчас стоит дешевле, чем зарплата программистов. В итоге и получаем всякие тяжелые фреймворки, на которых можно писать быстро, но они жрут ресурсы.
У iPhone SE сейчас есть один большой недостаток: батарейка. В принципе, с его размерами это легко объяснимо, но когда заряда телефона не хватает до конца дня...
Могу посоветовать довольно неплохой клиент Wombat. Сам же GRPC - это по сути те же HTTP/2 запросы, можно так же смотреть через tcpflow.
Не спорю, легко могу ошибаться, и буду действительно благодарен, если объясните, в чем именно.
Пардон, поправка: тривиальные типы (типа string, int и т. п.) не могут быть nullable. Вложенные сообщения - могут. Для этого в well-known types как раз и сделаны типы наподобие Int64Value. Скорее всего, авторы в этом плане ориентировались на Go, где такая же логика и аналогичные типы для работы с sql.
Просто это сделано не слишком логично, учитывая наличие ключевых слов required и optional - благо от этого решили отказаться в третьей версии protobuf.
Извините, но по части аргументации местами написана откровенная ахинея. Да и код вам бы подправить, а то какая-то кривая копипаста, без стилевого оформления и с левыми "1 reference".
Реальный плюс GRPC всего один: использование одного HTTP/2 соединения для отправки множества запросов. Это ускоряет отправку запросов и получение ответов. Для REST это также никто не запрещает делать, но в дикой природе гораздо чаще встречается HTTP/1, который гораздо легче разбирать.
protobuf - формат неплохой, но не самый лучший. Например, по задумке авторов поля не могут быть nullable, что не всегда удобно. Существуют только примитивные типы, которые нужно вручную преобразовывать в нужный (та же дата/время, например). Да, в JSON типов еще меньше, но при этом в большинстве REST-фреймворков существует встроенная сериализация/десериализация для многих стандартных типов. В protobuf - нифига, бери строковое значение из поля и парси вручную.
Генерация кода... Да, можно сгенерировать код клиентской библиотеки и серверный бойлерплейт для многих языков. Но этот код зачастую сложен для понимания и анализа, в связи с чем IDE не всегда может адекватно сформировать подсказки по методам и полям. И чем это отличается от генерации кода для OpenAPI? Это притом, что OpenAPI часто генерируется автоматически на основе аннотаций в коде, и в нем можно указать гораздо больше различных данных: описания методов и полей, авторизация для методов, валидация передаваемых данных и т. п.
Обработка ошибок в GRPC тоже выглядит странновато. Если метод кидает исключение - не факт, что GRPC его отловит и вернет ошибку. Вместо этого нужно перехватывать исключения вручную и возвращать ошибки специальным способом - причем разным для каждого языка (то есть нельзя писать серверное приложение на Python, а потом с этим же опытом прийти в Go, GRPC API будет чувствительно различаться).
Все остальное - трассировка, health check, балансировка нагрузки, аутентификация и т. п. - либо не зависит от выбора "GRPC или REST", либо банально проще и удобнее в REST. Например, во многих REST-фреймворках есть интеграция с Prometheus, а для health check не нужно заводить отдельный класс. Балансировка нагрузки и аутентификация относятся скорее к API gateway (nginx/krakend/kong/tyc etc.) и к service mesh (istio etc.), а авторизация не доставляет проблем ни там, ни там.
Вполне возможно, что я где-то не прав, сужу чисто по личному опыту.