Все же с Dragon сравнивать не совсем корректно, он возвращается с низкой околоземной орбиты, а Орион — с Луны почти со второй космической скоростью. А кинетическая энергия капсулы пропорциональна квадрату скорости.
Сравнивать имеет смысл с капсулами Аполлонов скорее.
У Байконура хоть и 46 градусов широта, но нельзя с него запускать строго на запад из-за ограничений на поля падения ступеней и головного обтекателя, и траектория чуть отклоняется на север. Из-за этого наклонение орбиты МКС тоже больше, чем широта Байконура, и составляет 51,6 градуса.
Если надо сделать X в третий раз - то выполняется рефакторинг и автоматизация выполнения X
Если стоимость рефакторинга / автоматизации на 1-2 порядка превышает стоимость выполнения X, то автоматизация просто может оказаться нецелесообразной на текущем этапе (например, без понимания востребованности продукта на рынке). Также бывает, что для автоматизации нужны какие-то дополнительные ресурсы / технологии, которых сейчас нет.
Так что в теории все красиво, но на практике рутинные задачи встречаются довольно часто.
А какая мотивация у клиента ее нажимать? Он уже сел в машину и его везут, остальное уже не волнует. Также как и с отзывом после поездки, можно его и оставить, конечно, но можно забить, многие так и делают.
Это вообще ни разу не очевидно для большинства пользователей, что можно сделать второй заказ. Поэтому водитель и просит отменить, понимая, что большинство пользователей отменит.
С определением геолокации клиента возможны те же проблемы, но помимо этого нужно еще обязывать ей делиться (у меня, например, отключено определение геолокации в приложении такси, точку всегда ставлю вручную).
На мой взгляд, у Яндекса не хватает возможности задать при заказе свою цену (выше, чем предлагает сам Яндекс). Нередко бывает, что нужно ехать в какую-то глухомань, где водители не смогут найти другие заказы, поэтому логично они отказываются. Но если обязательно нужно уехать, я готов и за обратную дорогу доплатить, лишь бы довезли.
По сути такая механика есть у Indriver, но в Яндексе ты максимум можешь тариф выбирать и больше ничего.
OVH сейчас не дает купить у них хостинг, если способ оплаты — карта Казахстана. Во всяком случае, после попытки оплатить хостинг такой картой приходит подобное сообщение (пробовал неоднократно):
Order declined Based on an analysis of your order and account data, we believe that these do not provide all the necessary guarantees in terms of transaction security. To process your order, pay for it and execute the contract, OVHcloud invites you to renew your purchase using another payment method. You can also contact one of our advisors via the help section of your account, to provide us with the information needed to complete the transaction. If not, this will not be taken into account.
Там речь про конкретную ситуацию — когда Вася хочет вставить просто текущее время и вызывает функцию now() — но получается не то, что ему хотелось. Вы же как будто говорите про намеренную порчу данных в таблице, а это совсем другой случай.
По-моему, вы что-то путаете. Если вставлять запись с типом timestampz, это означает буквально следующее "в момент вставки было столько-то по UTC". Тут никак не задействованы относительные смещения, просто хранятся моменты по UTC плюс признак "покажи мне эту временную метку по той таймзоне, которая тебе нужна".
Если сервер переезжает в другой часовой пояс, моменты по UTC никуда же не переезжают :) Меняется только дефолтный TimeZone. Условно, раньше поле было 12:10:05 +02:00, стало 14:10:05 +04:00, но это же фактически один и тот же момент времени.
На бекенде timestamptz, если нужно, без проблем преобразуется в локальный (в системной таймзоне сервера) и там, где надо, работают с локальным. А вообще есть типы, которые напрямую маппятся на timestamptz (например, OffsetDateTime в Java) и в коде бекенда тоже ими можно оперировать.
Про "гипотетический клиент" — я бы сказал, это довольно сильное заявление, особенно в больших проектах на много человек. Даже если вы стараетесь следить, чтобы все insert выполнялись исключительно из кода бекенда, гарантий дать невозможно и кто будет после вас с кодом работать — тоже вопрос. При всем этом есть простое решение, как сделать надежно.
Время timestamp, которое из базы получит клиент - это не время относительно начала сферических суток в вакууме, это вполне конкретный момент времени на определенную дату
По идее все же нет. timestamp означает "просто время, без даты, часового пояса или чего-то другого". Понимать его как конкретный момент времени или нет — это исключительно договоренность тех, кто работает с типом, это не свойство самого типа.
Ну и хорошие альтернативы в случае конкретно PG трудно подобрать.
Ну это классика: сегодня может казаться, что клиент только бекенд, а завтра появляется что-то новое и никому даже в голову не приходит, что это может что-то сломать. Аргумент был бы валиден только в случае, если у timestamptz есть какой-то оверхед, но его нет.
Мечтаю увидеть аналогичное фото Уэбба в марте 2025 года, когда кольца окажутся в плоскости орбиты Земли. Такое случается только раз в 30 лет и это нереально красиво. Надеюсь, доживем до этого момента!
Крайне спорный подход - изучать крайне тонкие нюансы программирования на Java (чтобы "казаться" разработчиком с 5-7-летним опытом) и при этом полностью игнорировать Spring, работу с БД, фреймворки для написания тестов и вообще принципы написания тестов.
Все же вероятность стать реально востребованным разработчиком довольно мала, если даже хорошо знать особенности самого языка и runtime, но при этом отойти на шаг влево или вправо - все, "не знаю, не сталкивался".
Все же с Dragon сравнивать не совсем корректно, он возвращается с низкой околоземной орбиты, а Орион — с Луны почти со второй космической скоростью. А кинетическая энергия капсулы пропорциональна квадрату скорости.
Сравнивать имеет смысл с капсулами Аполлонов скорее.
Да, на восток, конечно, оговорочка вышла :) Но смысл вы правильно поняли
У Байконура хоть и 46 градусов широта, но нельзя с него запускать строго на запад из-за ограничений на поля падения ступеней и головного обтекателя, и траектория чуть отклоняется на север.
Из-за этого наклонение орбиты МКС тоже больше, чем широта Байконура, и составляет 51,6 градуса.
Если стоимость рефакторинга / автоматизации на 1-2 порядка превышает стоимость выполнения X, то автоматизация просто может оказаться нецелесообразной на текущем этапе (например, без понимания востребованности продукта на рынке). Также бывает, что для автоматизации нужны какие-то дополнительные ресурсы / технологии, которых сейчас нет.
Так что в теории все красиво, но на практике рутинные задачи встречаются довольно часто.
А какая мотивация у клиента ее нажимать? Он уже сел в машину и его везут, остальное уже не волнует.
Также как и с отзывом после поездки, можно его и оставить, конечно, но можно забить, многие так и делают.
Это вообще ни разу не очевидно для большинства пользователей, что можно сделать второй заказ. Поэтому водитель и просит отменить, понимая, что большинство пользователей отменит.
А они видят комментарии в тот момент, когда им прилетает уведомление о заказе и они должны его взять или отклонить?
С определением геолокации клиента возможны те же проблемы, но помимо этого нужно еще обязывать ей делиться (у меня, например, отключено определение геолокации в приложении такси, точку всегда ставлю вручную).
На мой взгляд, у Яндекса не хватает возможности задать при заказе свою цену (выше, чем предлагает сам Яндекс).
Нередко бывает, что нужно ехать в какую-то глухомань, где водители не смогут найти другие заказы, поэтому логично они отказываются. Но если обязательно нужно уехать, я готов и за обратную дорогу доплатить, лишь бы довезли.
По сути такая механика есть у Indriver, но в Яндексе ты максимум можешь тариф выбирать и больше ничего.
В большинстве случаев — да (кажется, не видит конечную точку только при рейтинге ниже 4.85)
Геолокация может быть неточной, как понять, действительно ли водитель не доехал до точки или геолокация сбоит?
OVH сейчас не дает купить у них хостинг, если способ оплаты — карта Казахстана.
Во всяком случае, после попытки оплатить хостинг такой картой приходит подобное сообщение (пробовал неоднократно):
Естественно, опечатка, спасибо :)
Там речь про конкретную ситуацию — когда Вася хочет вставить просто текущее время и вызывает функцию
now()— но получается не то, что ему хотелось.Вы же как будто говорите про намеренную порчу данных в таблице, а это совсем другой случай.
По-моему, вы что-то путаете. Если вставлять запись с типом timestampz, это означает буквально следующее "в момент вставки было столько-то по UTC". Тут никак не задействованы относительные смещения, просто хранятся моменты по UTC плюс признак "покажи мне эту временную метку по той таймзоне, которая тебе нужна".
Если сервер переезжает в другой часовой пояс, моменты по UTC никуда же не переезжают :) Меняется только дефолтный TimeZone. Условно, раньше поле было 12:10:05 +02:00, стало 14:10:05 +04:00, но это же фактически один и тот же момент времени.
На бекенде timestamptz, если нужно, без проблем преобразуется в локальный (в системной таймзоне сервера) и там, где надо, работают с локальным. А вообще есть типы, которые напрямую маппятся на timestamptz (например, OffsetDateTime в Java) и в коде бекенда тоже ими можно оперировать.
Про "гипотетический клиент" — я бы сказал, это довольно сильное заявление, особенно в больших проектах на много человек. Даже если вы стараетесь следить, чтобы все insert выполнялись исключительно из кода бекенда, гарантий дать невозможно и кто будет после вас с кодом работать — тоже вопрос. При всем этом есть простое решение, как сделать надежно.
По идее все же нет. timestamp означает "просто время, без даты, часового пояса или чего-то другого". Понимать его как конкретный момент времени или нет — это исключительно договоренность тех, кто работает с типом, это не свойство самого типа.
Ну и хорошие альтернативы в случае конкретно PG трудно подобрать.
Ну это классика: сегодня может казаться, что клиент только бекенд, а завтра появляется что-то новое и никому даже в голову не приходит, что это может что-то сломать.
Аргумент был бы валиден только в случае, если у timestamptz есть какой-то оверхед, но его нет.
Мечтаю увидеть аналогичное фото Уэбба в марте 2025 года, когда кольца окажутся в плоскости орбиты Земли. Такое случается только раз в 30 лет и это нереально красиво.
Надеюсь, доживем до этого момента!
Крайне спорный подход - изучать крайне тонкие нюансы программирования на Java (чтобы "казаться" разработчиком с 5-7-летним опытом) и при этом полностью игнорировать Spring, работу с БД, фреймворки для написания тестов и вообще принципы написания тестов.
Все же вероятность стать реально востребованным разработчиком довольно мала, если даже хорошо знать особенности самого языка и runtime, но при этом отойти на шаг влево или вправо - все, "не знаю, не сталкивался".