Неделю назад у меня было совещание в 12 утра с Москвой из Израиля. У меня 12 утра и в Москве 12 утра. В выходные у нас поменяли время на зимнее, а в Москве - не поменяли. А теперь скажи, у меня это совещание должно переехать на 11, чтобы в Москве оно осталось в 12, или у меня должно остаться в 12, чтобы в Москве оно теперь начиналось в 13?
Например, я забил совещание с коллегой завтра на 10:00 (у себя)
У меня часы перевели на летнее время, а у него - нет.
В результате ваш хитрый софт покажет наши совещания с часовой разницей.
Но фишка то в том, что если завтра у меня часы переводят на летнее время и я делаю совещание на завтра, то у меня сохраниться ПРАВИЛЬНЫЙ utc с завтрашним летним смещением
У timestampz есть когнитивный оверхед когда начинаешь считать «вчера это было или сегодня» на бэке. Или когда у third party api принимается дата в utc. И эти баги случаются гораздо раньше чем «гипотетический другой клиент» который обычно не появляется никогда
Можно конечно и заточиться, но если ты стартап с непроверенной гипотезой и сомнительным финансированием - ты хочешь писать быстро в прототипном стиле силами двух с половиной человек, а потом магически отмасштабировать решение на миллионы пользователей. И это я сейчас про whatsapp + erlang | discord + elixir, подозрительно одинаковые истории успеха. И ВМ там очень помогла.
А как пробиться в первые, если не из массовки? (Я не знаю как это работает, но почему-то думал что как раз кого-то в массовке замечают и приглашают потом на более и более ведущие роли)
И конечно же в любом языке с hof (я уверен что и в котлине, честно не знаю синтакс) это решается гораздо читабельнее:
data.flatMap(...).first(it.isSuccess)
И 99% примеров где нужен такой return или goto решаются каким-либо подобным очень простым и гораздо более читабельным способом.
И достаточно месяцок поупражняться с high order functions в хаскеле чтобы никогда в жизни в голове уже не возникала идея о необходимости раннего выхода, исключения, goto или чего-либо в таком роде.
Обычно не использование фреймворка заканчивается изобретением своего собственного фреймворка, если проект разрастается. С которым в конце-концов так же приходится бороться.
Если учесть то, что стандарты веба никто толком не знает - получаются очень часто очень топорные решения. К примеру, видел тысячи проектов на Го, которые отдают в браузер и не удосужились сделать HEAD и OPTIONS роуты. Необходимость вручную думать про CSRF, XSS, правильные роуты в соответствии с REST (которые тоже никто не знает)... А во фреймворке это из коробки, он за тебя позаботился.
Из-за кажущейся свободы начинается полный зоопарк с http codes и error handling в API, структуры папок в которых надо вникать 2 недели после смены проекта, зоопарк решений для конфигурации.
То же самое относится к SQL - тысячи проектов с конкатенацией строк для запросов SQL, каша из функций, raw sql без какого-либо порядка в миграциях и дата-миграциях.
Дикий запад PHP в его худшие годы.
И ради чего? Чтобы "гипотетически" не сражаться с фреймворком, причем на том этапе где все и так начинают переписывать, рефакторить, разбивать на микросервисы?
Не надо денормализовывать для GQL и натравливать дедубликатор - сервер то твой целиком, зачем делать лишние шаги - тебя никто не заставляет. Если у тебя отдельный черный ящик, который не знает о том, что ты используешь такой подход - тогда эти шаги нужны.
Денормализует клиент и в случае с REST. Тут никакой разницы нету. Чтобы в UI отобразить. То есть "клиенту денормализация не уперлась" - я не могу себе представить такого кейса. Наоброт, в конце-концов клиенту нужна денормализцаия для отрисовки UI.
Стартапы в опыте работы настораживают эйчаров. Стартапы — часто про хайп. И при этом они быстро закрываются. В итоге у вас в списке прошлых мест работы могут быть поинты на хайповые темы по полгода-год работы. Это настораживает эйчаров — кажется, что вас легко могут переманить в другую компанию.
Как бы сказать помягче... Лично меня настораживают люди которые 5 лет сидят в энтерпрайзе на одной позиции.
Еще раз объясняю:
Неделю назад у меня было совещание в 12 утра с Москвой из Израиля. У меня 12 утра и в Москве 12 утра. В выходные у нас поменяли время на зимнее, а в Москве - не поменяли. А теперь скажи, у меня это совещание должно переехать на 11, чтобы в Москве оно осталось в 12, или у меня должно остаться в 12, чтобы в Москве оно теперь начиналось в 13?
Совещание это отличный пример.
Например, я забил совещание с коллегой завтра на 10:00 (у себя)
У меня часы перевели на летнее время, а у него - нет.
В результате ваш хитрый софт покажет наши совещания с часовой разницей.
Но фишка то в том, что если завтра у меня часы переводят на летнее время и я делаю совещание на завтра, то у меня сохраниться ПРАВИЛЬНЫЙ utc с завтрашним летним смещением
У timestampz есть когнитивный оверхед когда начинаешь считать «вчера это было или сегодня» на бэке. Или когда у third party api принимается дата в utc. И эти баги случаются гораздо раньше чем «гипотетический другой клиент» который обычно не появляется никогда
Думаю что большинство читателей этой статьи используют базу для крудошлепства, и в этом плане у нее есть только один клиент - бэк.
Использование timestamp с хранением всех времен в utc полностью беспроблемное решение при таких условиях.
Во вьюшках utc переводится в нужную зону относительно клиента. Внутри бэка нету никаких разночтений и путаницы при операциях с датами и временем.
Можно конечно и заточиться, но если ты стартап с непроверенной гипотезой и сомнительным финансированием - ты хочешь писать быстро в прототипном стиле силами двух с половиной человек, а потом магически отмасштабировать решение на миллионы пользователей.
И это я сейчас про whatsapp + erlang | discord + elixir, подозрительно одинаковые истории успеха. И ВМ там очень помогла.
Покажите пожалуйста пару мест - очень интересно где вы обращаетесь по индексу.
Тема RabbitMQ не раскрыта.
Что это значит?
А как пробиться в первые, если не из массовки? (Я не знаю как это работает, но почему-то думал что как раз кого-то в массовке замечают и приглашают потом на более и более ведущие роли)
На курсе будет сравнения RabbitMQ Streams и Kafka?
И конечно же в любом языке с hof (я уверен что и в котлине, честно не знаю синтакс) это решается гораздо читабельнее:
И 99% примеров где нужен такой return или goto решаются каким-либо подобным очень простым и гораздо более читабельным способом.
И достаточно месяцок поупражняться с high order functions в хаскеле чтобы никогда в жизни в голове уже не возникала идея о необходимости раннего выхода, исключения, goto или чего-либо в таком роде.
То есть эти сомневающиеся люди не могли бы посмотреть "НЕ слив, А прохождения тех кто купил в первый час релиза" и не покупать?
Обычно не использование фреймворка заканчивается изобретением своего собственного фреймворка, если проект разрастается. С которым в конце-концов так же приходится бороться.
Если учесть то, что стандарты веба никто толком не знает - получаются очень часто очень топорные решения. К примеру, видел тысячи проектов на Го, которые отдают в браузер и не удосужились сделать HEAD и OPTIONS роуты. Необходимость вручную думать про CSRF, XSS, правильные роуты в соответствии с REST (которые тоже никто не знает)... А во фреймворке это из коробки, он за тебя позаботился.
Из-за кажущейся свободы начинается полный зоопарк с http codes и error handling в API, структуры папок в которых надо вникать 2 недели после смены проекта, зоопарк решений для конфигурации.
То же самое относится к SQL - тысячи проектов с конкатенацией строк для запросов SQL, каша из функций, raw sql без какого-либо порядка в миграциях и дата-миграциях.
Дикий запад PHP в его худшие годы.
И ради чего? Чтобы "гипотетически" не сражаться с фреймворком, причем на том этапе где все и так начинают переписывать, рефакторить, разбивать на микросервисы?
А чем, если не секрет?
Might & Magic
Как golang попал у вас в список интерпретируемых языков для прототипирования?
Не надо денормализовывать для GQL и натравливать дедубликатор - сервер то твой целиком, зачем делать лишние шаги - тебя никто не заставляет. Если у тебя отдельный черный ящик, который не знает о том, что ты используешь такой подход - тогда эти шаги нужны.
Денормализует клиент и в случае с REST. Тут никакой разницы нету. Чтобы в UI отобразить. То есть "клиенту денормализация не уперлась" - я не могу себе представить такого кейса. Наоброт, в конце-концов клиенту нужна денормализцаия для отрисовки UI.
Для graphql есть некоторые решения которые делают подобное, например вот здесь: https://gajus.medium.com/reducing-graphql-response-size-by-a-lot-ff5ba9dcb60
А как задача с недублированием данных о городе решалась бы в REST подходе?
Как бы сказать помягче... Лично меня настораживают люди которые 5 лет сидят в энтерпрайзе на одной позиции.