Почему вы берёте самописное решение, а не какую-либо готовую библиотеку, в которой сделаны нужные оптимизации? Взял ваше решение на Go (0.78 сек. у меня минимально), библиотеку github.com/agnivade/levenshtein — получил 0.354 сек. минимально.
Яндекс.Драйв — взлетел. Нет планов на Яндекс.Такси-2, где не будут использоваться сторонние таксопарки? Какой бы контроль не был — они сторонние и будут косячить всегда.
Ну а при появлении автономных авто — Драйв и Такси-2 автоматически сольются в Такси-3.
Делал то же самое, только через федерейшен: новый кластер брал сообщения у старого. Потом отключался федерейшен и старый кластер.
Ну а вообще, для упрощения — желательно иметь два отдельных кластера, связанных двухсторонним федерейшеном, под единым dns неймспейсом. И тогда можно прозрачно выключать/выводить один из них для обновления/обслуживания.
Недавно во множестве ходил на собеседования (чуть больше 10 раз), среди них было и собеседование в Туту.
Минусы:
— Самое долгое собеседование, что у меня было. Я выбрал вариант прохождения «всё в одном» — итого всё заняло примерно 3.5 часа. Но чуть дальше уточню, что долгое время обусловлено иными причинами и минус только наполовину минус.
Плюсы:
— Корректное соблюдение времени. Позднее встречал опоздания HR, тимлидов, CTO;
— Полное проведение по всем этапам: HR, PO (общие вопросы/софт-скилы), два тимлида разных команд (подходы/технологии), CTO (софт-скилы/архитектура). С противоположной стороны встречал как полное отсутствие тех. стороны (только HR/менеджеры/PO), так и частичное;
— Приятное обсуждение, никаких «люков»;
— Быстрый фидбек.
Долгое время, собственно, и обусловлено отделением частей интервью друг от друга. Я лично — за такой подход, иначе либо разговор превращается в кашу, либо часть сотрудников сидит и скучает.
По моей относительно экспертной оценке по результатам всех собеседований — Туту оставили приятное впечатление по методике проведения.
Какая-то странная проблема. У вас после анмаршалинга в ошибке не nil, который на самом деле nil?
Ещё недоумение вызывает определение Response, которое дальше становится handlers.Response.
В общем, я бы посоветовал привести ссылку с примером на play.go, которая покажет проблему. Иначе сейчас ничего не понятно (мне, как минимум).
Только ничего общего с масляным радиатором он не имеет. Другой принцип переноса тепла — конвекция (ну, конечно, относительно. В масляном тоже конвекция, только очень медленная).
С тепловой пушкой сравнивать вообще не очень — она шумит как трактор.
Вместо 1000 слов лучше один раз попробовать.
Пару лет назад открыл для себя обогреватель конвекторного типа.
Считаю, это лучшее, что изобрело человечество из электрических обогревателей.
Масляные радиаторы и прочее — и рядом не стояли.
Вы всё переусложнили. Артефакты/репозитории какие-то, это же всё настраивать надо.
То ли дело — зашёл на сервер, поправил файлик. И пусть тестировщик заходит туда и проверяет.
И про «ошибку выжившего» уже чуть выше сказали.
Ну а при появлении автономных авто — Драйв и Такси-2 автоматически сольются в Такси-3.
Такое можно назвать «не смогли». Причём, не в плохом смысле — вполне допускаю, что иногда проще что-то ещё попробовать, чем пытаться что-то сделать.
P.S. Чтобы не было недопониманий — говорю это как человек, который «смог в Nomad».
Ну а вообще, для упрощения — желательно иметь два отдельных кластера, связанных двухсторонним федерейшеном, под единым dns неймспейсом. И тогда можно прозрачно выключать/выводить один из них для обновления/обслуживания.
Как вам там из 2010 года пишется?
Всё остальное поддержу. К счастью, сейчас есть ClickHouse.
Минусы:
— Самое долгое собеседование, что у меня было. Я выбрал вариант прохождения «всё в одном» — итого всё заняло примерно 3.5 часа. Но чуть дальше уточню, что долгое время обусловлено иными причинами и минус только наполовину минус.
Плюсы:
— Корректное соблюдение времени. Позднее встречал опоздания HR, тимлидов, CTO;
— Полное проведение по всем этапам: HR, PO (общие вопросы/софт-скилы), два тимлида разных команд (подходы/технологии), CTO (софт-скилы/архитектура). С противоположной стороны встречал как полное отсутствие тех. стороны (только HR/менеджеры/PO), так и частичное;
— Приятное обсуждение, никаких «люков»;
— Быстрый фидбек.
Долгое время, собственно, и обусловлено отделением частей интервью друг от друга. Я лично — за такой подход, иначе либо разговор превращается в кашу, либо часть сотрудников сидит и скучает.
По моей относительно экспертной оценке по результатам всех собеседований — Туту оставили приятное впечатление по методике проведения.
Ещё недоумение вызывает определение Response, которое дальше становится handlers.Response.
В общем, я бы посоветовал привести ссылку с примером на play.go, которая покажет проблему. Иначе сейчас ничего не понятно (мне, как минимум).
С тепловой пушкой сравнивать вообще не очень — она шумит как трактор.
Вместо 1000 слов лучше один раз попробовать.
Считаю, это лучшее, что изобрело человечество из электрических обогревателей.
Масляные радиаторы и прочее — и рядом не стояли.
То ли дело — зашёл на сервер, поправил файлик. И пусть тестировщик заходит туда и проверяет.
Использовать опцию max_parallel из станзы update? Или это не используется и перезапускаются сразу все сервисы кластера?
> Быстро собирать образы
Вынесите на сборщике /var/lib/docker в память.