Есть такая вещь, как динамическое программирование (dynamic programming). Если кратко, то мы находим закономерность(формулу, обычно рекурсивную) и прост считаем что там и как там. Иногда запоминаем промежуточные результаты, чтобы не вылететь в экспоненциальную сложность (дада, Фибоначчи это простейший пример дин. прогр.).
И вот подобную тему очень любят на разных соревнованиях, проверка на логику, математику и умение это закодчить. Идеально прям. Но к сожалению некоторые умники втащили эти задачи на собесы. И вот возникает вопрос к умникам: а вы вообще применяли это в рамках своей работы?
Не побоюсь сказать, что мелкий % задач требуют таких решений (биоинформатика, парсинг, etc), но вот зачем это требовать для очередного таска "соберем список кафка топиков, приклеим мейлы команд и запишем все в эксель" я не понимаю. Имхо, лучше бы дали производные посчитать, это хотя бы (мне) весело, показатель моих навыков будет такой же.
Как можно догадаться, я не щелкатель дин. прогр, хотя задачи интересные. Просто условно-бесполезные на работе с 9 до 17.
(если это читает почти темно-красный грандмастер с Codeforces/Topcoder - готов узнать секрет приготовления задач за О(1) в лс)
И вот подобную тему очень любят на разных соревнованиях, проверка на логику, математику и умение это закодчить. Идеально прям. Но к сожалению некоторые умники втащили эти задачи на собесы. И вот возникает вопрос к умникам: а вы вообще применяли это в рамках своей работы?
Не побоюсь сказать, что мелкий % задач требуют таких решений (биоинформатика, парсинг, etc), но вот зачем это требовать для очередного таска "соберем список кафка топиков, приклеим мейлы команд и запишем все в эксель" я не понимаю. Имхо, лучше бы дали производные посчитать, это хотя бы (мне) весело, показатель моих навыков будет такой же.
Как можно догадаться, я не щелкатель дин. прогр, хотя задачи интересные. Просто условно-бесполезные на работе с 9 до 17.
(если это читает почти темно-красный грандмастер с Codeforces/Topcoder - готов узнать секрет приготовления задач за О(1) в лс)
oleg_log
Есть такая вещь, как динамическое программирование (dynamic programming). Если кратко, то мы находим закономерность(формулу, обычно рекурсивную) и прост считаем что там и как там. Иногда запоминаем промежуточные результаты, чтобы не вылететь в экспоненциальную…
@schopenhauer_was_right подсказал, что в OpenCV довольно часто применяется. Видно выходные пройдут в пдфках алгоритмов опенцв...
Заметил 1 антипаттерн в разных фирмах: использовать жсон-логгер, но при этом некоторые сообщения оставлять текстом (не использовать жсон-поля).
Пример: мы логируем timestamp, trace_id, к примеру айди пользователя/микросервиса, но вот сама ошибка (а в ней доп. детали, связанные с бизнес логикой) мы логить не будем, просто выплюнем как текст.
Возникает вопрос адекватности и пользы такого логера. Ведь в итоге приходится искать в обычном текст, а мы ведь от этого решили уйти, ведь так?....
В общем ошибку перед логом иногда надо развернуть (хотя так в логи могут утечь приватные данные, а там и секурити тим поругает, а еще хуже GDPR накажет).
Пример: мы логируем timestamp, trace_id, к примеру айди пользователя/микросервиса, но вот сама ошибка (а в ней доп. детали, связанные с бизнес логикой) мы логить не будем, просто выплюнем как текст.
Возникает вопрос адекватности и пользы такого логера. Ведь в итоге приходится искать в обычном текст, а мы ведь от этого решили уйти, ведь так?....
В общем ошибку перед логом иногда надо развернуть (хотя так в логи могут утечь приватные данные, а там и секурити тим поругает, а еще хуже GDPR накажет).
This media is not supported in your browser
VIEW IN TELEGRAM
@crabravebot чтобы не потерять и быстро найти
Вчера нашел себе развлечение на ночь, залип над статьей от гугла по поводу их новой(?) БД - Procella. Аналитика на масштабируемых стероидах.
Интересно, что у них data cache-hit 90%, много С++ шаблонов и компайл-тайм штук для компиляции запросов, а еще все завязано на Borg(отца к8с)(что очевидно).
https://ai.google/research/pubs/pub48388/
Интересно, что у них data cache-hit 90%, много С++ шаблонов и компайл-тайм штук для компиляции запросов, а еще все завязано на Borg(отца к8с)(что очевидно).
https://ai.google/research/pubs/pub48388/
Forwarded from Generative Anton (Anton Repushko)
О Go
Наткнулся на прикольный пост, где просят рассказать что-то хорошее о языках, которые тебе не нравятся. Как вы думаете, что говорят о Go?
...
Больше всего полайкали и чаще всего взгляд цеплялся за то, что "
Наткнулся на прикольный пост, где просят рассказать что-то хорошее о языках, которые тебе не нравятся. Как вы думаете, что говорят о Go?
...
Больше всего полайкали и чаще всего взгляд цеплялся за то, что "
go fmt - фантастическая штука". Как мало нужно инженеру для счастья.lobste.rs
Say something nice about a programming language you dislike
95 comments
The Global Chubby Planned Outage
Written by Marc Alvidrez
Chubby [Bur06] is Google’s lock service for loosely coupled distributed systems. In the global case, we distribute Chubby instances such that each replica is in a different geographical region. Over time, we found that the failures of the global instance of Chubby consistently generated service outages, many of which were visible to end users. As it turns out, true global Chubby outages are so infrequent that service owners began to add dependencies to Chubby assuming that it would never go down. Its high reliability provided a false sense of security because the services could not function appropriately when Chubby was unavailable, however rarely that occurred.
The solution to this Chubby scenario is interesting: SRE makes sure that global Chubby meets, but does not significantly exceed, its service level objective. In any given quarter, if a true failure has not dropped availability below the target, a controlled outage will be synthesized by intentionally taking down the system. In this way, we are able to flush out unreasonable dependencies on Chubby shortly after they are added. Doing so forces service owners to reckon with the reality of distributed systems sooner rather than later.
Written by Marc Alvidrez
Chubby [Bur06] is Google’s lock service for loosely coupled distributed systems. In the global case, we distribute Chubby instances such that each replica is in a different geographical region. Over time, we found that the failures of the global instance of Chubby consistently generated service outages, many of which were visible to end users. As it turns out, true global Chubby outages are so infrequent that service owners began to add dependencies to Chubby assuming that it would never go down. Its high reliability provided a false sense of security because the services could not function appropriately when Chubby was unavailable, however rarely that occurred.
The solution to this Chubby scenario is interesting: SRE makes sure that global Chubby meets, but does not significantly exceed, its service level objective. In any given quarter, if a true failure has not dropped availability below the target, a controlled outage will be synthesized by intentionally taking down the system. In this way, we are able to flush out unreasonable dependencies on Chubby shortly after they are added. Doing so forces service owners to reckon with the reality of distributed systems sooner rather than later.
Сидишь такой, чай пьешь, конфиг правишь, а тебе 10+ алёртов за полминуты, и все с разных хостов, и все с намеком, что вот-вот забьется ин-мем очередь перед Эластиком и машины лягут с ООМ.
А потом тимлид говорит, что ты не понял алёрт и проверь, прежде чем ответственной тиме Эластика жаловаться. И ведь реально, в логах у тебя проблем нет, только в Графане видно изменение.
Вот только Эластик перешёл в желтое состояние (неок, некрит), и таки тима подтверждает проблему.
Айти это круто!
А потом тимлид говорит, что ты не понял алёрт и проверь, прежде чем ответственной тиме Эластика жаловаться. И ведь реально, в логах у тебя проблем нет, только в Графане видно изменение.
Вот только Эластик перешёл в желтое состояние (неок, некрит), и таки тима подтверждает проблему.
Айти это круто!