Если взять какой-нибудь Postgres либо Oracle, то там можно через специальные функции отменить идущий запрос (если он еще закончился и, соответственно, не случился commit).
Т.е.
1) увидели, что запрос подозрительно затянулся
2) перепроверили запрос и увидели ляп
3) запросили у базы список запросов и нашли проблемный
4) дали команду отменить запрос
5) запрос отменяется, транзакция отказытвается, попорченные данные так и не становятся видимы для всех остальных, кто работает с базой
Примечание: 3 и 4 требуют привелигированного доступа к базе.
Если бы вы по оси ординат тоже взяли логарифмическую шкалу — то получили бы прямую линию (или около того). Либо обе шкалы линейные — тоже была бы прямая.
А вы вместо этого ошибочно называете прогрессию геометрической.
> 1.
Так в случае с играми пересылается не картинка, а изменение игрового состояния. В большинстве случаев вы не можете на это просто «забить» — у вас возникнет рассинхронизация состояния сервера и клиента. Так что тут вопрос стоит не «сделать фриз или показать частично битую картинку», а «сделать фриз или показать неправильную картинку (например показать живую цель, когда она уже на самом деле мертва)».
Автор как-то упускает/замалчивает тот момент, что для самой возможности "доставить ещё один сервер" приложение должно быть горизонально масштабиремо. А для этого, нередко, нужно чтобы разработчики достаточно сильно "вложились" в обеспечение такой возможности.
Бывают ситуации, когда быстрее и дешевле сделать решение на более производительном языке, и которое не будет (изначально) масштабироваться, но будет обрабатывать нагрузку с достаточной производительностью, чем делать мастабируемое решение на более удобном языке и тратить существенные усилия на обеспечение масштабируемости.
Подняли кучу других претензий (о которых в статье ни слова), а основную претензию вместо того чтобы нормально разобрать и, возможно, действительно оправдаться — списали на безграмотность специалистов Retail Rocket (и, видимо, всех остальных).
С грантами проблема — их могут попилить с нулевыми выхлопами. А патентуются лекарства, которые были найдены. Собственно, весь вопрос в том, кто на себя берет риски исследования (т.е. вопрос, как обычно, в деньгах).
Давайте исправлять. Что бы тут такое забросить… Давайте так:
Сейчас под нормальный VR даже на десктопе нужно приличное железо (в частности видеокарта). Очевидно, что через браузерное API с этим еще хуже, а ожидать что-то впечатляющее на смартфонах — вообще глупо. Да и как к смартфону шлемы-то подключать?
Ну или можно набросить, что VR сейчас снова уходит в стагнацию и этот WebVR уже перестал быть кому-либо нужен.
Можно вопрос от разработчика REST API, с которым иногда хотят интегрироваться люди, использующие 1С?
1) Я правильно понимаю, что публичной версии документации 1С не существует?
2) Планиурется для в 1С поддержка в HTTP-клиенте такой достаточно обычной для HTTP-клиентов вещи как обработка сжатого (gzip/deflate) ответа сервера? Я про возможность использовать "Accept-Encoding".
Подчеркну, что здесь Кнут говорит не "забейте на заботу о производительности до тех пор, пока не окажется, что у вас всё тормозит" (как это обычно подразумевают цитирующие), а "заботьтесь о производительности там, где это важно и даст наибольший эффект".
Если взять какой-нибудь Postgres либо Oracle, то там можно через специальные функции отменить идущий запрос (если он еще закончился и, соответственно, не случился commit).
Т.е.
1) увидели, что запрос подозрительно затянулся
2) перепроверили запрос и увидели ляп
3) запросили у базы список запросов и нашли проблемный
4) дали команду отменить запрос
5) запрос отменяется, транзакция отказытвается, попорченные данные так и не становятся видимы для всех остальных, кто работает с базой
Примечание: 3 и 4 требуют привелигированного доступа к базе.
Если бы вы по оси ординат тоже взяли логарифмическую шкалу — то получили бы прямую линию (или около того). Либо обе шкалы линейные — тоже была бы прямая.
А вы вместо этого ошибочно называете прогрессию геометрической.
А равзе это анекдот? :(
Так в случае с играми пересылается не картинка, а изменение игрового состояния. В большинстве случаев вы не можете на это просто «забить» — у вас возникнет рассинхронизация состояния сервера и клиента. Так что тут вопрос стоит не «сделать фриз или показать частично битую картинку», а «сделать фриз или показать неправильную картинку (например показать живую цель, когда она уже на самом деле мертва)».
По идее, банки не занимаются HFT. Как бы не их профиль.
Похоже, что сейчас у них любой запрос на поддомен "api." возвращает 403.
Автор как-то упускает/замалчивает тот момент, что для самой возможности "доставить ещё один сервер" приложение должно быть горизонально масштабиремо. А для этого, нередко, нужно чтобы разработчики достаточно сильно "вложились" в обеспечение такой возможности.
Бывают ситуации, когда быстрее и дешевле сделать решение на более производительном языке, и которое не будет (изначально) масштабироваться, но будет обрабатывать нагрузку с достаточной производительностью, чем делать мастабируемое решение на более удобном языке и тратить существенные усилия на обеспечение масштабируемости.
Подняли кучу других претензий (о которых в статье ни слова), а основную претензию вместо того чтобы нормально разобрать и, возможно, действительно оправдаться — списали на безграмотность специалистов Retail Rocket (и, видимо, всех остальных).
Плюс, судя по комментариям, там было противодействие отладке (скрипт отключался при открытой консоли браузера).
Скорее как раз логичное в рамках концепции "запланированного устаревания".
Давайте исправлять. Что бы тут такое забросить… Давайте так:
Сейчас под нормальный VR даже на десктопе нужно приличное железо (в частности видеокарта). Очевидно, что через браузерное API с этим еще хуже, а ожидать что-то впечатляющее на смартфонах — вообще глупо. Да и как к смартфону шлемы-то подключать?
Ну или можно набросить, что VR сейчас снова уходит в стагнацию и этот WebVR уже перестал быть кому-либо нужен.
Надеюсь мой комментарий поможет спасти пост ;)
Можно вопрос от разработчика REST API, с которым иногда хотят интегрироваться люди, использующие 1С?
1) Я правильно понимаю, что публичной версии документации 1С не существует?
2) Планиурется для в 1С поддержка в HTTP-клиенте такой достаточно обычной для HTTP-клиентов вещи как обработка сжатого (gzip/deflate) ответа сервера? Я про возможность использовать "Accept-Encoding".
WannaCry + SambaCry = ?
Ждем червя, который умеет внедряться в Win и *nix и распространяться с обоих.
Подчеркну, что здесь Кнут говорит не "забейте на заботу о производительности до тех пор, пока не окажется, что у вас всё тормозит" (как это обычно подразумевают цитирующие), а "заботьтесь о производительности там, где это важно и даст наибольший эффект".