а за какими-то узко-специальными вопросами призывать аутсорс / аутстафф на время.
Прямо как проститутку вызвать с почасовой оплатой. :) А то что узкому специалисту надо войти в контекст проекта/задачи, влезть в "говна" кодовой базы... не? :)
И это без учёта риска того, что аутстафф по традиции продаст джуна по ценнику сеньёра. :)
Возможно ли использовать ваш роутер для шардирования по времени (данные телеметрии)? Т.е., например, данные за январь хранятся на 1-м шарде, данные за февраль на 2-м и т.д.
Если вся телеметрия за сей момент до конца (к примеру) месяца, польётся на конкретный шард, есть риск, что он ляжет. В этом случае мы по сути отказываемся от горизонтального масштабирования "на запись".
"А если проверяет ревьюер то можно тупо не совпасть по стилю" конечно. Тебе ж потом с ним работать. И проверять тебя будет не "литкод-машина", а человек. И реакция на кодревью - это тоже проверка, но по софтскилам - какая у человека реакция на критику.
" - тестовые задания уровня "тяп-ляп отвалите" не являются реальным показателем знаний и квалификации "
они являются показателем того, что человек умеет не только в бла-бла-бла.
" - человек мог просто устать делать тупые, бесполезные (для него) " поэтому если человек на собеседовании отказывается решать тестовое задание, на которое от силы надо минут 20 потратить, он строевым шагом идёт лесом рассказывать кому-то другому как он "устал".
Наблюдение: с возрастом начинаются серьёзные проблемы с софтскилами. Приходилось много собеседовать sql-разработчиков. Направление прямо скажу не из области "стильно-можно-молодёжно", поэтому "те кому за 40" было не редкость. Собеседовал я (архитектор) и тимлид - тоже люди "в возрасте". Если собеседовал "кому за 45" - вероятность 50%, что мы с коллегой в рамках обсуждения результата собеседования друг другу скажем "вот из-за таких козлов как этот нам с тобой тяжело найти работу". К примеру, чел в хамской форме (а-ля "я танцор больших и малых театров, а вы тут...") отказывается решать тестовое задание.
Рассогласование данных. Представьте сценарий: приложение отправляет сообщение в RabbitMQ и начинает транзакцию в базе данных. Сообщение уже ушло в брокер, но в момент коммита транзакции в БД происходит сбой. Результат — рассогласование:...
А почему взяли заранее калеченый пример? Есть же паттерн outbox, есть cdc (с дебезиум). Почему бы не сравнить с ними?
...ради 10 мс и экономии времени на чтение документации к ORM, готов писать не поддерживаемые запросы,...
проблема не в 10мс экономии. Проблема, когда вместо 10мс, запрос выполняется 15с (такой "фокус" был буквально на прошлой неделе). И разработчик не понимает, что происходит и как это починить, т.к. воспринимает всё что происходит в БД как магию.
"sql продолжит работать ибо стандарт" Увы, возьмём к примеру ms sql и postgresql - разница в синтаксисе существенная, особенно касательно встроенных функций. Это не считая всяких приколов "под капотом" типа вакуума, особенностей реализации временных объектов и т.д. и т.п. - об которые надо будет обязательно удариться головой.
"...вот вам запрос, выполняйте программисты мамкины... " А дальше появляется следующий забавный эффект: в коде появляется "магическое заклинание" от ДБА, которое команда разработки не понимает как и работает, и которое трогать без волшебника страшно. А потом ещё и ещё,...
"ORM автоматически подхватывает изменения в объектах и запросах." Тут есть знатный способ выстрелить себе в ногу. В некоторых БД из-за специфики организации данных на больших таблицах смена, к примеру, типа поля может быть очень ресурсоёмкой. В орм вы поменяете, на тесте, который "сильно урезан" по размерам, тоже будет всё ОК, а в проде в момент миграции всё ляжет.
Это очень критично, когда работаешь с нагруженной системой. Если ты пишешь на sql тебе надо знать, как то что ты делаешь будет, мапиться на планы запросов (конкретной СУБД, т.к. у каждой свои нюансы). Если ты работаешь с орм, когнитивная нагрузка резко повышается: ты должен сначала осознавать как то, что ты пишешь, будет мапиться в запрос, который потом будет мапиться в план запроса.
Усложнение приводит к тому, что разработчики с недостаточной квалификацией начинают воспринимать происходящее в БД слое как "магию": "Я вот жахнул и вот такое получилось. позовите ДБА, пусть сделает индекс какой".
Откуда взялись дополнительные 4 месяца? Из страха. Из ментальных ограничений. Команда добавила "буфер на всякий случай", потому что "с этим модулем всегда что-то идет не так".
0.Страх "чего"? Страх того, что не выполнишь задачу в срок и на ближайшем "перфоманс ревью" тебя этим будут бить больно по голове? :) Поэтому, когда в задаче много неизвестного, повышать сроки это логично.
В последние 6 месяцев команда отклонила амбициозные идеи со словами "это слишком сложно" до детального анализа...
1.Обычно на детальный анализ "сложного легаси" нужно много времени наиболее квалифицированного разработчика (а то и не одного, если задача масштабная), который и так перегружен. Если даже банально выделить их время на серьёзное исследование сложно, тогда при вносе в команду "амбициозной задачи" команда будет завышать сроки. А технический руководитель будет кивать прогнозу команды, т.к. если линейных разрабов "пожурят и лишат премии", то техруку снимут голову. Ещё рапространённый вариант, команде просто не дают время на ресёч: "амбициозную идею" притаскивают под занавес периода планирования со словами "сегодня, край завтра скажите сроки реализации" (ну и закоммитьтесь под этот срок, естественно). Результат - см. п.0
Реальный пример из финтеха: Джуниор инженер случайно удалил индекс в production базе. Боясь увольнения, он потратил 6 часов, пытаясь восстановить его втайне.
Что это за "финтех", если не секрет, в котором джун может лазать в админском режиме грязными руками в продовой базе? При чём "тайно".
Хотелось бы знать, чтобы случайно не воспользоваться "услугами" этой организации.
Прямо как проститутку вызвать с почасовой оплатой. :) А то что узкому специалисту надо войти в контекст проекта/задачи, влезть в "говна" кодовой базы... не? :)
И это без учёта риска того, что аутстафф по традиции продаст джуна по ценнику сеньёра. :)
Если вся телеметрия за сей момент до конца (к примеру) месяца, польётся на конкретный шард, есть риск, что он ляжет. В этом случае мы по сути отказываемся от горизонтального масштабирования "на запись".
"А если проверяет ревьюер то можно тупо не совпасть по стилю" конечно. Тебе ж потом с ним работать. И проверять тебя будет не "литкод-машина", а человек. И реакция на кодревью - это тоже проверка, но по софтскилам - какая у человека реакция на критику.
" - тестовые задания уровня "тяп-ляп отвалите" не являются реальным показателем знаний и квалификации "
они являются показателем того, что человек умеет не только в бла-бла-бла.
" - человек мог просто устать делать тупые, бесполезные (для него) " поэтому если человек на собеседовании отказывается решать тестовое задание, на которое от силы надо минут 20 потратить, он строевым шагом идёт лесом рассказывать кому-то другому как он "устал".
Наблюдение: с возрастом начинаются серьёзные проблемы с софтскилами.
Приходилось много собеседовать sql-разработчиков. Направление прямо скажу не из области "стильно-можно-молодёжно", поэтому "те кому за 40" было не редкость. Собеседовал я (архитектор) и тимлид - тоже люди "в возрасте". Если собеседовал "кому за 45" - вероятность 50%, что мы с коллегой в рамках обсуждения результата собеседования друг другу скажем "вот из-за таких козлов как этот нам с тобой тяжело найти работу". К примеру, чел в хамской форме (а-ля "я танцор больших и малых театров, а вы тут...") отказывается решать тестовое задание.
по референсной таблице да. В т.ч. можно в режиме 2pc сделать.
Как мне видится, тот факт, что активная нода координатора в citus-кластере только одна, это может стать проблемой.
А это работает для Kazi?
А почему взяли заранее калеченый пример? Есть же паттерн outbox, есть cdc (с дебезиум). Почему бы не сравнить с ними?
а как же "МАКС"? :)
проблема не в 10мс экономии. Проблема, когда вместо 10мс, запрос выполняется 15с (такой "фокус" был буквально на прошлой неделе). И разработчик не понимает, что происходит и как это починить, т.к. воспринимает всё что происходит в БД как магию.
вы часто заглядываете в стандарт что функционал функционал sql, который вы используете соответствует стандарту?
Готовы ли вы отказаться от частей языка, не соответствующих стандарту, чтобы гипотетически иметь возможность сменить субд?
"sql продолжит работать ибо стандарт"
Увы, возьмём к примеру ms sql и postgresql - разница в синтаксисе существенная, особенно касательно встроенных функций. Это не считая всяких приколов "под капотом" типа вакуума, особенностей реализации временных объектов и т.д. и т.п. - об которые надо будет обязательно удариться головой.
"...вот вам запрос, выполняйте программисты мамкины... "
А дальше появляется следующий забавный эффект: в коде появляется "магическое заклинание" от ДБА, которое команда разработки не понимает как и работает, и которое трогать без волшебника страшно. А потом ещё и ещё,...
"ORM автоматически подхватывает изменения в объектах и запросах." Тут есть знатный способ выстрелить себе в ногу. В некоторых БД из-за специфики организации данных на больших таблицах смена, к примеру, типа поля может быть очень ресурсоёмкой. В орм вы поменяете, на тесте, который "сильно урезан" по размерам, тоже будет всё ОК, а в проде в момент миграции всё ляжет.
Вот это самое прекрасное. В результате получаем кашу из orm и сырого sql. => и следующие плюшки "орм" сразу идут в топку:
возможность малотрудозатратной смены БД
парой кликов меняем тип/название поля
Это очень критично, когда работаешь с нагруженной системой. Если ты пишешь на sql тебе надо знать, как то что ты делаешь будет, мапиться на планы запросов (конкретной СУБД, т.к. у каждой свои нюансы).
Если ты работаешь с орм, когнитивная нагрузка резко повышается: ты должен сначала осознавать как то, что ты пишешь, будет мапиться в запрос, который потом будет мапиться в план запроса.
Усложнение приводит к тому, что разработчики с недостаточной квалификацией начинают воспринимать происходящее в БД слое как "магию": "Я вот жахнул и вот такое получилось. позовите ДБА, пусть сделает индекс какой".
0.Страх "чего"? Страх того, что не выполнишь задачу в срок и на ближайшем "перфоманс ревью" тебя этим будут бить больно по голове? :) Поэтому, когда в задаче много неизвестного, повышать сроки это логично.
1.Обычно на детальный анализ "сложного легаси" нужно много времени наиболее квалифицированного разработчика (а то и не одного, если задача масштабная), который и так перегружен. Если даже банально выделить их время на серьёзное исследование сложно, тогда при вносе в команду "амбициозной задачи" команда будет завышать сроки. А технический руководитель будет кивать прогнозу команды, т.к. если линейных разрабов "пожурят и лишат премии", то техруку снимут голову.
Ещё рапространённый вариант, команде просто не дают время на ресёч: "амбициозную идею" притаскивают под занавес периода планирования со словами "сегодня, край завтра скажите сроки реализации" (ну и закоммитьтесь под этот срок, естественно). Результат - см. п.0
Что это за "финтех", если не секрет, в котором джун может лазать в админском режиме грязными руками в продовой базе? При чём "тайно".
Хотелось бы знать, чтобы случайно не воспользоваться "услугами" этой организации.
авторский анекдот на эту тему:
-- почему так и не сделают до сих пор российский "национальный порновидеохостинг"?
-- в процессе. Сложности с интеграцией с: роскомнадзором, госуслугами и СОРМом.