Такой код вполне допустим на сосебедовании, но я для него поставил бы совершенно другие вопросы кандидату. Но я не показатель, я считаю что простое решение это зачастую хорошее решение, что что-то непонятное это или просто что-то ненужное, или это секта или это маркетинг.
Вопросы:
1. Что в нём плохо?
2. Что в нём хорошо?
3. Объясните что он делает
Вопрос №1 очень важен по любой теме, ответ на него даст вам понять кто перед вами, профессионал или не совсем, профессионал всегда знает минусы и ограничения того в чём он профессионал.
Вы будете смеяться дальше, но нам пока некогда и нет смысла переходить дальше Django 1.8, а celery 4.3 не дружит если у тебя ниже 1.9
Потрясающая зависимость celery и Django :)
Заниматься этим всем и ждать новых сюрпризов смысла не вижу, есть положительный опыт с другой библиотекой, проще перейти.
Это всё до боли знакомо и ясно :)
Но лок устареет только через 60 секунд.
А если у нас длительные процессы с несколько непонятной продолжительностью которые ресурсы берут? Аппроксимация TTL? Обновление TTL? Ну его… не надёжно это всё, всёравно останется какая-то блокировка у которой TTL несколько часов.
Мы своё элегантное решение сделали, пока обкатываем и оформляем, если интересно то пишите asovetnikov на гмейле
По отдельности kombu, billiard и всё остальное прекрасны может быть, но этот зоопарк сильно связан по конкретным версиям между собой и в случае ошибки в одном начинается процесс подбора версий.
Сколько неприятных моментов нам доставили распределенные блокировки по TTL в случае нештатных ситуаций :)
Самое печально, что блокировки по TTL без отслеживания смерти клиента в случае аварии могут помешать системе восстановиться после простого ребута.
Странно, что мейнтейнеры согласились включить это в репозиторий, уж так ли это необходимо?
Вообще celery переживает сложный период с выходом 4.x и качество «продукта» упало.
В celery очень много наростов, которые комьюнити видимо не может поддерживать и они просто вырезаются, из наиболее интересных это прекращение поддержки Redis как брокера.
Внутренности celery и его обвязок тоже не сахар (видел, исправлял, пытался доработать) и как это всё стабилизируется непонятно.
Часто обвязки несовместимы друг с другом, в некоторых версиях есть ошибки, а версии без ошибок уже дают ошибки из-за несовместимости.
Слишком сложный продукт стал для простого запуска задач (построение workflow из задач полноценно не работает в celery, дальше chain и group лучше не ходить).
Работаем с celery c 2015 года и через пару недель надеюсь откажемся от него, хотя задач у нас всего 3000-5000 в час.
1. Вы про производительность? Ну а не надо их бросать в цикле от которого ожидается высокая производительность.
Так эта статья о производительности?
2. Так в каких ситуациях это пользу принесёт? Или это теоретическая статья, вы про практику использования не написали.
Пожалейте новичков, пишите что это теория.
3. У вас был пример со сложением int + результат MaybeParse, почему-то вы не поняли в чём суть вопроса, забудем.
Постоянно пытаюсь из статей о ФП извлечь:
1. Чувство эстетического удовлетворения от применения ФП
2. И пользу для проектов и команды
Но каждая статья начинается с объяснения, что такое монады, зачем монады, примеры вида 1+2+3 и у меня ничего полезного не складывается в голове.
Хочется статью которая начинается с «Мы год использовали ФП, на таком то проекте… 2 члена команды чеканулись, 3 просветлели, ПМ стал улыбчивее, и мы сдали проект на 2 месяца раньше дедлайна».
Очень интересен именно такой опыт.
1. Так и исключение только один раз можно обработать
2.
там где отсутствие (правильного?) значения не является проблемой и допускается логикой программы
Т.е. там где стоит if() на такое значение?
ничто не мешает добавить описание причины остановки выполнения
Ну т.е. надо внедрять протоколирование активно, как обычно, вы только об этом не написали ничего. А потом пойди разбери откуда какой str пришёл.
Вы это всё на практике применяете ежедневно?
Напишите дополнение про боли которые это всё доставляет в продакшене. Не внедряется это всё безболезненно.
3. А когда же MaybeParse() вернёт Maybe? Мы же про уход от if(), а это влечёт работу с Maybe
1. Так ошибка в рантайме всёравно будет (или на этапе передачи в СУБД или ещё куда-то) или надо где-то всёравно обработать IsNothing().
2. А как понять источник «проблемы», если обнаружение этой проблемы происходит в самом конце?
3.
result += await MaybeParse(arg1);
Операцию сложения int с Maybe я ведь должен определять каждый раз? Или все операции с IsNothing() дают IsNothing()?
Да контейнеризация это хорошо, плохо что некоторые непонимают где оно плохо :)
Kubernetes даёт API и другие плюшки, но надо понимать какой ценой.
И всёравно если кластер нужен для автоматизации чего-либо, аля SaaS PaaS, то всёравно надо будет обвязывть всё своими скриптами.
А если так, то может и Docker swarm пойдёт.
Тут даже не силами своих devops всё сделано, а интеграторов позвали.
Недавно статья была, как небольшой компании два отдельных devops сотрудника потребовалось, чтобы свой Kubernetes обслуживать :)
Прямо перед переходом надо в начале считать экономику — кластер должен позволить или уволить админа, или программиста или дать экономию по железу, ну естественно если речь не идёт о подготовке к 10x росту зоопарка ИС :)
Ещё несколько лет назад обычному разработчику в adidas могла потребоваться неделя(!) для того, чтобы получить виртуальную машину
А причём здесь Kubernetes? :) Напрашивается, что тут организационная проблема.
Итогом 6-месячного проекта стал 100%-ный запуск сайта электронной коммерции (e-commerce) adidas на Kubernetes, благодаря чему:
его время отклика сократилось вдвое;
релизы стали происходить по 3-4 раза в день (раньше новый релиз выкатывался раз в 4-6 недель).
Ну вот прямо это всё заслуги Kubernetes?
Поверхностные причинно-следственные связи озвучены, которые сподвигнут неопытных IT-специалистов на длинную петлю проб и ошибок, т.к. за всем этим стоит не сам Kubernetes, а работа инженеров.
Из вашего списка задач MCS решает только две:
— апгрейдов kubernetes (MCS это сами делают)
— интеграции kubernetes с корпоративными сервисами (это просто отпадает по сути)
Остальное это каждодневная рутинная работа команды разработки.
А SLA MCS будет соблюдать до тех пор, пока у них не случится авария, как и все остальные хостинги :)
В MCS файлы наши уже теряли…
Ещё в статье написано, что вы данные храните в Kubernetes, можно поконкретнее, где именно? Как вы решили задачу с контролем физического местонахождения данных?
Не, не понимаю.
Всего 10 серверов, не так много, программисты штатные вполне с ними могут совладать :)
Вы всё о трудоемких интеграциях в вашу сеть пишете, а задачи решаемые вроде как вокруг обсчёта данных крутятся.
Не понимаю чем два человека на Full-time занимались.
В MCS вам сделали возможность использования IP-адресов из корпоративной сети?
И MCS сделали вам интеграцию в вашу копоративную сеть?
Читаю и у меня, что-то не сходится, вопросы возникают.
Компания молодая, хотим Kubernetes, но на «своём» сервере его поддерживать дорого, а в облаке получилось дешевле.
Плюс нам не нравилось то, во сколько нам обходится его содержание на bare metal
Это сколько?
Не понимаю с какими сложностями в поддержке вы столкнулись «на своём» железе, чуть подробнее? Что вы разрабатывали?
Какой у вас объём данных? Пол часа на копирование всех данных между датацентрами, это достаточно быстро.
Какие у вас потребности в RAM и CPU?
Например, одной из первых задач стало вписать Ingress-контроллеры Kubernetes в сетевую инфраструктуру нашей организации
А и такая есть? :)
Не знал… десктоп клиент просто работает без нареканий пока
Видел только потуги сделать web-интерфейс к скайпу на outlook.com, но он не работал.
Skype версии 8 сделан на Electron?!
Аплодисменты!
Это их лучшая версия за 10 лет! Без шуток, я не любил скайп до этой версии.
На стареньком Core 2 Duo работает без лагов, хотя старые версии постоянно зависали и делали что-то непонятное.
С аудио оборудованием работает прекрасно! Раньше каждый запуск был мукой с выбором и проверкой гарнитуры :)
Судя по статье (оригинал предлагаемых изменений не смотрел), это уже не VUE, а что-то другое просто :)
Vue.js действительно прекрасен простотой вхождения, однозначностью и стабильной работой.
Странный перечень вопросов для выбора технических решений на стадии MVP. Да и далее вы кажется просто взяли то, что знали сами :)
И я так понимаю эти вопросы с обратным приоритетом? Выбор ОС кажется менее приоритетное, чем выбор стека технологий по наличию достаточного количества специалистов?
И сразу хочется узнать, какие из критериев оказались полезные, а какие нет?
Вот выбор бинарного протокола на MVP вам помог?
Авральная работа запоем, поддержка директоров и пользователей это прекрасно, но напишите сразу как этого стоило избежать :)
Или вам надо сделать Веб-сервер, в котором каждому вашему скрипту будет соответствовать URL и отдавать в формате prometheus метрики.
Или объединить запуск всех скриптов и отдавать один большой список метрик.
The metrics pushed are exactly the same as you would present for scraping in a permanently running program. If you need distributed counting, you could either use the actual statsd in combination with the Prometheus statsd exporter, or have a look at Weavework's aggregation gateway.
Это я и в json файл могу складывать всё, а потом в prometheus отдавать :)
Наворачивать statsd и писать клиента python и тестировать как себя ведёт Weavework's gateway даже не стал :) У них клиент JS только.
Для python вроде как решили эту проблему со сбором и агрегацией и передачей в prometheus метрик github.com/prometheus/client_python… но там решение на уровне одного сервера, метрики каждого процесса кладутся в отдельный файл, потом при pull они агрегируются. Но там потом заморочки с очисткой этой директории в «нужные моменты», отслеживание какой процесс умер и его метрики уже можно удалить…
И потом всёравно на двух серверах уже это не будет работать, а потребность такая есть.
Про минусы жалко как обычно не пишут, с минусами все сталкиваются когда уже втянулись :)
Из-за pull модели опроса, prometheus не очень подходит для отслеживания метрик «быстрых» процессов, которые успевают начаться и звершиться между опросами метрик, а это почти все задачи обработки HTTP запросов.
Тут начинаются пляски с промежуточными агрегаторами метрик, которые принимают push, а потом отдают их через pull в prometheus… только полноценных нету, и ещё они должны уметь метрики «складывать» если это гистограммы, gauge и т.д.
За серверами следить с помощью prometheus однозначно «ДА», свободное дисковое пространство, свободная память и другие подобные метрики всегда можно получить прямо тут, но если ваши метрики нельзя посчитать в любую произвольную секунду, то тут уже надо думать :)
Отправляется сообщение о факте, что сервис получил сообщение об ошибке 404 за последние пять минут.
Тут тонкий момент, «сервис» получивший 404 это сборщик prometheus, но сколько 404 он пропустит прежде чем он всё же встретит плавающий 404?
Неоднозначна штука.
Хорошо это всё, но косметикой отдаёт.
Но самое главное чего нехватает сейчас, так это ручного задания платформы. Надо нам win-сервером управлять с linux-сервера…
Path это умеет? :)