Получается среди 6угольников будут 12 пятиугольников. Но даже если бы был один - игровые механики могут быть завязаны на то что карта состоит из одинкаковых тайлов. Как это преодолевать?
Можно ограбить свой собственный банк, да. Если правильно это сделать. Например нанять брата "предоставлять маркетинговые услуги" по цене в 100500 раз больше чем рынок. (чуть менее открыто)
Я испытываю стресс только когда играю в шахматы. Когда тильтую. Разбил два монитора, стол и кулак за последний год. Ни в какую видео-игру у меня так не полыхает проигрывать.
Во первых могу поднять окружение с новым языком сам
Могу попросить написать простой алгоритм любую Copilot.
Мне не надо учить синтаксис нового языка - я могу его в крайнем случае загуглить.
Мне нужно знать экосистему и распространенные паттерны программирования. Те самые, которые показывают в твоем коде на Go, пришел ты из мира Java или из PHP.
Ни того ни другого, как я понимаю, тут нету. Вот и напрашивается риторический вопрос: ...?
Да в общем-то любой современный язык лучше, и их делают люди, которые умеют в теорию языков программирования и много думают прежде чем принимать решения. Rust, Kotlin, Swift, можно перечислять дальше
Не надо путать причину и следствие. Наличие обработки исключений и некоторые другие элементы (например ключевое слово return) в большинстве современных языков программирования говорит лишь о том, что они нарушают принципы структурного программирования, а вовсе не о том, что без этих принципов нельзя писать программы. Можно!
Вместо исключений - монады maybe|result как в Расте или просто err как в Го, вместо return - возвращаем последнее значение из функции как в том же Расте. Удобно ли так писать? Вопрос открытый. Но то что так можно делать реальный софт - это факт
Исходя из моего опыта: если вы делаете межсервисное взаимодействие через graphql - вы делаете что-то не то. Более того: если ОБА сервиса - ваши, а не third party.
Неделю назад у меня было совещание в 12 утра с Москвой из Израиля. У меня 12 утра и в Москве 12 утра. В выходные у нас поменяли время на зимнее, а в Москве - не поменяли. А теперь скажи, у меня это совещание должно переехать на 11, чтобы в Москве оно осталось в 12, или у меня должно остаться в 12, чтобы в Москве оно теперь начиналось в 13?
Например, я забил совещание с коллегой завтра на 10:00 (у себя)
У меня часы перевели на летнее время, а у него - нет.
В результате ваш хитрый софт покажет наши совещания с часовой разницей.
Но фишка то в том, что если завтра у меня часы переводят на летнее время и я делаю совещание на завтра, то у меня сохраниться ПРАВИЛЬНЫЙ utc с завтрашним летним смещением
У timestampz есть когнитивный оверхед когда начинаешь считать «вчера это было или сегодня» на бэке. Или когда у third party api принимается дата в utc. И эти баги случаются гораздо раньше чем «гипотетический другой клиент» который обычно не появляется никогда
Можно конечно и заточиться, но если ты стартап с непроверенной гипотезой и сомнительным финансированием - ты хочешь писать быстро в прототипном стиле силами двух с половиной человек, а потом магически отмасштабировать решение на миллионы пользователей. И это я сейчас про whatsapp + erlang | discord + elixir, подозрительно одинаковые истории успеха. И ВМ там очень помогла.
Получается среди 6угольников будут 12 пятиугольников. Но даже если бы был один - игровые механики могут быть завязаны на то что карта состоит из одинкаковых тайлов. Как это преодолевать?
Можно ограбить свой собственный банк, да. Если правильно это сделать.
Например нанять брата "предоставлять маркетинговые услуги" по цене в 100500 раз больше чем рынок. (чуть менее открыто)
Починить баг - можно. Откатить - нельзя. Потому что наверх написаны коммиты которые задействуют контракт между сервисами A и B
Я испытываю стресс только когда играю в шахматы. Когда тильтую. Разбил два монитора, стол и кулак за последний год. Ни в какую видео-игру у меня так не полыхает проигрывать.
Так что наблюдение из статьи не подтверждено
Будучи сеньором, я:
Во первых могу поднять окружение с новым языком сам
Могу попросить написать простой алгоритм любую Copilot.
Мне не надо учить синтаксис нового языка - я могу его в крайнем случае загуглить.
Мне нужно знать экосистему и распространенные паттерны программирования. Те самые, которые показывают в твоем коде на Go, пришел ты из мира Java или из PHP.
Ни того ни другого, как я понимаю, тут нету. Вот и напрашивается риторический вопрос: ...?
В общем случае это не так и для Раста
#[derive(Default)]FooBar { foo: 42, ..Default::default() };И добавление поля так же закончится нулем или что еще хуже -
false, потому что строка 2 спокойненько скомпилируетсяИменно. Вопрос не в том сколько ошибок компилятор найдет. Достаточно одной, которую он не найдет...
Да в общем-то любой современный язык лучше, и их делают люди, которые умеют в теорию языков программирования и много думают прежде чем принимать решения. Rust, Kotlin, Swift, можно перечислять дальше
Может я пропустил, но по-моему в статье нету: что не так с Kubeflow?
Это шаблон для генератора карт, генерирующий ее по определенным правилам.
Фактически это аналог просто карты в непошаговой стратегии.
Не надо путать причину и следствие. Наличие обработки исключений и некоторые другие элементы (например ключевое слово
return) в большинстве современных языков программирования говорит лишь о том, что они нарушают принципы структурного программирования, а вовсе не о том, что без этих принципов нельзя писать программы. Можно!Вместо исключений - монады maybe|result как в Расте или просто err как в Го, вместо return - возвращаем последнее значение из функции как в том же Расте. Удобно ли так писать? Вопрос открытый. Но то что так можно делать реальный софт - это факт
Исходя из моего опыта: если вы делаете межсервисное взаимодействие через graphql - вы делаете что-то не то. Более того: если ОБА сервиса - ваши, а не third party.
Еще раз объясняю:
Неделю назад у меня было совещание в 12 утра с Москвой из Израиля. У меня 12 утра и в Москве 12 утра. В выходные у нас поменяли время на зимнее, а в Москве - не поменяли. А теперь скажи, у меня это совещание должно переехать на 11, чтобы в Москве оно осталось в 12, или у меня должно остаться в 12, чтобы в Москве оно теперь начиналось в 13?
Совещание это отличный пример.
Например, я забил совещание с коллегой завтра на 10:00 (у себя)
У меня часы перевели на летнее время, а у него - нет.
В результате ваш хитрый софт покажет наши совещания с часовой разницей.
Но фишка то в том, что если завтра у меня часы переводят на летнее время и я делаю совещание на завтра, то у меня сохраниться ПРАВИЛЬНЫЙ utc с завтрашним летним смещением
У timestampz есть когнитивный оверхед когда начинаешь считать «вчера это было или сегодня» на бэке. Или когда у third party api принимается дата в utc. И эти баги случаются гораздо раньше чем «гипотетический другой клиент» который обычно не появляется никогда
Думаю что большинство читателей этой статьи используют базу для крудошлепства, и в этом плане у нее есть только один клиент - бэк.
Использование timestamp с хранением всех времен в utc полностью беспроблемное решение при таких условиях.
Во вьюшках utc переводится в нужную зону относительно клиента. Внутри бэка нету никаких разночтений и путаницы при операциях с датами и временем.
Можно конечно и заточиться, но если ты стартап с непроверенной гипотезой и сомнительным финансированием - ты хочешь писать быстро в прототипном стиле силами двух с половиной человек, а потом магически отмасштабировать решение на миллионы пользователей.
И это я сейчас про whatsapp + erlang | discord + elixir, подозрительно одинаковые истории успеха. И ВМ там очень помогла.
Покажите пожалуйста пару мест - очень интересно где вы обращаетесь по индексу.
Тема RabbitMQ не раскрыта.
Что это значит?