Я из тех, кто живёт в Ярославле и прошёл и Тензор, и Диасофт, и Аквелон. Дольше всего задержался в Тензоре - 2 года. Куда бы мог вернуться - Аквелон. Диасофт стал хорошей площадкой для старта, но туда больше ни ногой..
У меня нет готового примера/кусочка кода, который можно было бы показать, но себя в Kubernetes/OpenShift мы используем следующий подход: 1) в deployment добавляем соответствующий init-container, в котором дожидаемся доступности БД (цикл, ограниченный по времени и числу итераций); 2) в readiness пробе проверяем доступность БД (select 1, например).
Сначала стартует init-контейнер и проверяет доступна ли БД, если нет то уходит в ожидание на какое-то время, после чего снова повторяет проверку. И так несколько раз (все параметры настраиваются).
Затем уже приложение у себя в readiness пробе проверяет доступность БД (перестраховка по сути, можно отказаться от этого).
На самом деле здесь нет правильного ответа. И категорично что-то утверждать будет неправильно. Как и всегда, всё зависит от вашей специфики и нагрузки.
Если у вас большая нагруженная БД, то тащить её в контейнер не очень разумно.
Если у вас микросервисы и вам требуется небольшая БД на 5-10 TPS, то почему нет?
Очень удобная позиция эффективного менеджера — не знать, сколько часов работают люди.
На самом деле всё просто — с высокой долей вероятности люди вджобывают по 60 часов в неделю, а то и больше.
За идею, опционы и средней паршивости ЗП.
Не всегда и везде нужно только уметь писать и отлаживать код.
Но список вопросов мне понравился. Он охватывает много областей и хорошо скажется на кругозоре.
К CAP-теореме ещё стоит добавить BASE.
И обязательно контейнеризацию/Docker и оркестрацию/Kubernetes.
Во всех таких статьях почему-то не говорят об экономии компаний от перехода на удалёнку: не нужны рабочие места, печеньки, кофе и прочее. Экономия получается огромная.
Выглядит как чья-то курсовая работа средней паршивости...
Первое, что бросилось в глаза, это некорректное моделирование отношения трек — исполнитель. У трека может быть много исполнителей.
Про порядковый номер трека уже написали выше. А ещё альбом может быть двухдисковым.
Пароль с ограничением в 20 символов — это зашквар. Хранить, надеюсь, будете в виде хэша с солью?
Жанров может быть много.
P.S. Классной фичей была бы возможность не терять льготные подписки. Поясню на примере Яндекс.Плюса: есть человек, который платит за семейную подписку каждый месяц. Он покупает Яндекс.Станцию и получает ещё полгода индивидуальной подписки. Чтобы этот льготный период не сгорел, его можно привязать к аккаунту и заморозить, либо конвертировать в семейную подписку.
Печально это всё… Вынести бизнес-логику в хранимки — это такой же путь в один конец. Этот код так же превратится в легаси и умрёт с приходом нового CTO\лида разработки.
Извините за занудство, но вам бы Helm-чарт и ссылочку на проект в публичном репозитории.
В последнее время часто возникает задача что-то быстро попробовать, и собирать такие вот проекты по кусочкам — весьма утомительное занятие.
Не понял про одну ноду для OpenShift. CRC чем не устраивает? https://developers.redhat.com/products/codeready-containers/overview
Я из тех, кто живёт в Ярославле и прошёл и Тензор, и Диасофт, и Аквелон. Дольше всего задержался в Тензоре - 2 года. Куда бы мог вернуться - Аквелон. Диасофт стал хорошей площадкой для старта, но туда больше ни ногой..
Согласен, что такой подход получается многословным, но он наглядный. Для учебных целей подходит гораздо лучше.
У меня нет готового примера/кусочка кода, который можно было бы показать, но себя в Kubernetes/OpenShift мы используем следующий подход:
1) в deployment добавляем соответствующий init-container, в котором дожидаемся доступности БД (цикл, ограниченный по времени и числу итераций);
2) в readiness пробе проверяем доступность БД (select 1, например).
Сначала стартует init-контейнер и проверяет доступна ли БД, если нет то уходит в ожидание на какое-то время, после чего снова повторяет проверку. И так несколько раз (все параметры настраиваются).
Затем уже приложение у себя в readiness пробе проверяет доступность БД (перестраховка по сути, можно отказаться от этого).
@Hivemaster
На самом деле здесь нет правильного ответа. И категорично что-то утверждать будет неправильно. Как и всегда, всё зависит от вашей специфики и нагрузки.
Если у вас большая нагруженная БД, то тащить её в контейнер не очень разумно.
Если у вас микросервисы и вам требуется небольшая БД на 5-10 TPS, то почему нет?
Алексей, подскажите, есть ли официальный докер-образ для вашего экспортера на docker hub'е?
Подготовил небольшой пример для локального запуска с docker-compose. Возможно, кому-то пригодится.
Это какой-то новый персонаж?
Если берётесь за перевод, то хоть проверьте гендер автора одной из лучших книг для подготовки к собеседованию :)
Очень удобная позиция эффективного менеджера — не знать, сколько часов работают люди.
На самом деле всё просто — с высокой долей вероятности люди вджобывают по 60 часов в неделю, а то и больше.
За идею, опционы и средней паршивости ЗП.
Рядом с вопросом про TreeMap добавьте ещё вопрос про бинарное дерево поиска.
Ну и понимание того, как дерево строится, тоже будет полезным.
Но список вопросов мне понравился. Он охватывает много областей и хорошо скажется на кругозоре.
К CAP-теореме ещё стоит добавить BASE.
И обязательно контейнеризацию/Docker и оркестрацию/Kubernetes.
WAL-G бы и Одиссея туда
Зачем? Человеку, который попал в FAANG, это не нужно. Риски и юридические последствия куда больше, нежели мнимая выгода.
Во всех таких статьях почему-то не говорят об экономии компаний от перехода на удалёнку: не нужны рабочие места, печеньки, кофе и прочее. Экономия получается огромная.
Выглядит как чья-то курсовая работа средней паршивости...
P.S. Классной фичей была бы возможность не терять льготные подписки. Поясню на примере Яндекс.Плюса: есть человек, который платит за семейную подписку каждый месяц. Он покупает Яндекс.Станцию и получает ещё полгода индивидуальной подписки. Чтобы этот льготный период не сгорел, его можно привязать к аккаунту и заморозить, либо конвертировать в семейную подписку.
В продакшене вы тоже используете OSS версию InfluxDB?
Печально это всё… Вынести бизнес-логику в хранимки — это такой же путь в один конец. Этот код так же превратится в легаси и умрёт с приходом нового CTO\лида разработки.
Извините за занудство, но вам бы Helm-чарт и ссылочку на проект в публичном репозитории.
В последнее время часто возникает задача что-то быстро попробовать, и собирать такие вот проекты по кусочкам — весьма утомительное занятие.
Тема стара как мир — keyset pagination. Оригинал. Перевод.