Да, я там как раз писал про то, что у этих задач 1-3 решений, их удобно проверять. Опять же, я все решения писал для доклада, и решил в статье их не вылизывать, потому что они и не должны быть идеальными
Советую просто попробовать все сови варианты и поймешь где проблема. Главное контекст нужно отменить до медленной функции, в медленной функции поставить time.Sleep(10 * time.Second) к примеру а контекст создать с таймаутом в 2 сек.
1) Дефер внутри горутины в этом случае не вызовется. Девер в основной функции закроет канал раньше и мы можем получить панику send to closed chan
2) Мы запишем в буфер и горутина завершится. Через n времени GC уберет мусор в котором был твой канал и буфер
Супер круто комментарий, это почти все выводы к котоырм мы пришли, по теоретической части и к части выводов в практической, о чем статья. В записи прям есть слайд где почти как ваш пункт 2, но я скорее конкретизировал прям что generics, unsafe, atomic, reflection , вложенные мьютексы я бы не рекоммендавал давать на них задачи
Но что я заметил по ходу чтения дальше - задачи остаются нечетко сформулированными, иногда вообще необъяснимыми. FindMaxProblem- вообще про что этот пример? В нем ведь вообще рандомный код.
По сути это задача на выявление максимального количества небольших проблем в коде. Отдельный блок, читаем код, находим проблемы, подсвечиваем.
Задача-фаворит" - чем в итоге вывод в случае успеха отличается от вывода с ошибкой? Ошибка идет в stderr или что-то еще подразумевается но пропущено?
По сути ничем, кроме разного текста. Мы не хотим усложнять контекст, который нам не особо важен. Нам нужно просто разделить поток сообщений
Дополнительное условие по ограничению количества горутин. Предполагается что изначально решающий выберет вариант "в лоб" запустить по горутине на урл? А если я создам пул горутин и разобью список урлов между ними поровну? Или если я выберу этот вариант, то все пойдет не по скрипту и собеседование завалено?
Я честно говоря не знаю как ответить на ваш вопрос, потому что не вижу проблему на собеседовании обсуждать с кандидатом задачу, решение, подходы. Предполагается несколько вариантов решений, но все кандидаты будут решать немного по своему, учитывать большее или меньшее количество проблем. Завален собес или нет мы тут вообще не обсуждаем, есть еще теоретическая часть, и прочее прочее прочее
Пардон если слишком агрессивно, но у меня был неприятный опыт примерно такой же нечетко поставленной задачи на интервью.
Ну, понимаю. Вы не поверите но в этом и суть истории, которую я пытался рассказать. У многих кандидатов как раз и была такая же реакция и я и написал, что она у меня пошел процесс рефлексии, который вылился в том, что было полностью переработана практическая часть.
Я не готов ответить на все ваши вопросы, слишком их много, поэтому постараюсь выделить главное. Интерфейс мною был упрощен до минимального рабочего интерфейса на базе которого лимитер можно лимитер реализовать. Заполнение и удаление в бакетах может быть реализовано в этой функции Allow. По сути нам нужно знать время последнего вызова Allow по ключу, скорость приращения токенов, максимальное количество токенов. Все можно реализовать на мапах, потом подумать про конкурентность и прочие вопросы. Можно приращение токенов вынести в отдельную горутину.
Основные проблемы этой задачи заключаются в когнитивной сложности, большой вариативности реализаций, сложность проверки, длительности решения
Логика была скорее в том, чтобы придумать несколько не стандартную задачу. Я подумал, что имплементировать простой вариант rate limiter это гут. Я выбросил весь жир и свел ее фактически к алгоритму корзины токенов, которую вроде бы можно быстро написать и в тоже время это не какие-то хитрые алгоритмы с литкода.
Да, насколько помню он ссылался на него. На самом деле я сам его использовал для написания io rate limiter, но вообще это больше шутка была для доклада
Объем каких данных?
Я не стал реализовывать все варианты, просто предложил один из. Насчет буффера можно подискутировать как раз после решения.
Можно и без флага, просто пишем в канал через select + default case
Все так, но только если мы контролируем код slowFunc. Есть еще внешние зависимости
Попрошу заменить псевдокодом, чтобы сэкономить время. Я тоже не помню все аргументы в каждом методе пакетов bytes, sync, strings, http.
Да, я там как раз писал про то, что у этих задач 1-3 решений, их удобно проверять. Опять же, я все решения писал для доклада, и решил в статье их не вылизывать, потому что они и не должны быть идеальными
Выглядит отлично, поставил звездочку,
Все задачи используют std максимум, о какой справочной информации речь?
Не указывал этого явно, но речь идет об онлайн собеседованиях.
Советую просто попробовать все сови варианты и поймешь где проблема. Главное контекст нужно отменить до медленной функции, в медленной функции поставить time.Sleep(10 * time.Second) к примеру а контекст создать с таймаутом в 2 сек.
1) Дефер внутри горутины в этом случае не вызовется. Девер в основной функции закроет канал раньше и мы можем получить панику send to closed chan
2) Мы запишем в буфер и горутина завершится. Через n времени GC уберет мусор в котором был твой канал и буфер
Не обязательно получим, а получим если выйдем по контексту раньше, чем slowFunc() выполнится. Тогда горутина заблокируется
Потому что из этого канала никто уже не прочитает. Это не дедлок, но просто утечка горутины.
Супер круто комментарий, это почти все выводы к котоырм мы пришли, по теоретической части и к части выводов в практической, о чем статья. В записи прям есть слайд где почти как ваш пункт 2, но я скорее конкретизировал прям что generics, unsafe, atomic, reflection , вложенные мьютексы я бы не рекоммендавал давать на них задачи
Скрин из пакета sync std это собственно одно и то же
По сути это задача на выявление максимального количества небольших проблем в коде. Отдельный блок, читаем код, находим проблемы, подсвечиваем.
По сути ничем, кроме разного текста. Мы не хотим усложнять контекст, который нам не особо важен. Нам нужно просто разделить поток сообщений
Я честно говоря не знаю как ответить на ваш вопрос, потому что не вижу проблему на собеседовании обсуждать с кандидатом задачу, решение, подходы. Предполагается несколько вариантов решений, но все кандидаты будут решать немного по своему, учитывать большее или меньшее количество проблем. Завален собес или нет мы тут вообще не обсуждаем, есть еще теоретическая часть, и прочее прочее прочее
Ну, понимаю. Вы не поверите но в этом и суть истории, которую я пытался рассказать. У многих кандидатов как раз и была такая же реакция и я и написал, что она у меня пошел процесс рефлексии, который вылился в том, что было полностью переработана практическая часть.
Я не готов ответить на все ваши вопросы, слишком их много, поэтому постараюсь выделить главное. Интерфейс мною был упрощен до минимального рабочего интерфейса на базе которого лимитер можно лимитер реализовать. Заполнение и удаление в бакетах может быть реализовано в этой функции Allow. По сути нам нужно знать время последнего вызова Allow по ключу, скорость приращения токенов, максимальное количество токенов. Все можно реализовать на мапах, потом подумать про конкурентность и прочие вопросы. Можно приращение токенов вынести в отдельную горутину.
Основные проблемы этой задачи заключаются в когнитивной сложности, большой вариативности реализаций, сложность проверки, длительности решения
Логика была скорее в том, чтобы придумать несколько не стандартную задачу. Я подумал, что имплементировать простой вариант rate limiter это гут. Я выбросил весь жир и свел ее фактически к алгоритму корзины токенов, которую вроде бы можно быстро написать и в тоже время это не какие-то хитрые алгоритмы с литкода.
Да, насколько помню он ссылался на него. На самом деле я сам его использовал для написания io rate limiter, но вообще это больше шутка была для доклада