Можно посмотреть The Manager's Path от Camille Fournier, на нее была хорошая рекомендация от MoM из FAANG:
https://habr.com/ru/post/649521/#comment_24028099

#books
Типизируем питона

Рад поделиться с вами книжкой по типизированному Python, о разработке которой я говорил здесь. Вжух!

Здесь актуальная версия книги от 8 июня 2022.

Цель материала — помочь тебе научиться писать более красивые, надёжные и легко сопровождаемые программы на Python. Это не начальный уровень владения языком, предполагается, что ты уже умеешь программировать, но хочешь научиться делать это лучше.

Поговорим о том, почему вопросы типизации очень важны и как они влияют на программу, разберём все основные структуры для использования в типизации, напишем программу, которая находит наши GPS координаты и показывает текущую погоду по ним. В ходе разработки программы затронем и обсудим много смежных тем — архитектура кода, построение слоёв логики в приложении и др.

Код из книги
Видео версия — текстовую обязательно читаем тоже, в ней ряд тем расширен.

РАСПРОСТРАНЕНИЕ поддерживается, но, пожалуйста, в виде ссылки на этот пост или ссылки на веб-версию, т.к. книга обновляется.

#python #backend #it #codebetter #books

#algo
Бинпоиск

https://youtu.be/sLhmsR0_KPM

#metric
Валера про статью с метриками в предсказании спроса

В рамках написания книги по Мл систем дизайну и главы про метрики, прочитал статью Evaluating predictive count data distributions in retail sales forecasting

Статья от Академика, но неплохая, более менее понятная, а как вы знаете, любая статья которую я могу понять - хорошая

В статье разбирается следующая проблема. Прогноз спроса - вещь важная, которую решают многие люди и организации. При этом решают они эту проблему зачастую используя неподходящие метрики/функции потерь. Потому как во первых очень часто природа прогнозируемых данных дискретна - если мы прогнозируем продажи товаров (SKU) они кратны единице учета, нельзя продать 1.5 шампуня. Во вторых спрос вещь прерывистая, продажи определенного товара легко могут упасть в ноль

Если агрегировать данные и прогнозировать что-то продающееся в больших объемах, то тогда конечно можно использовать методы, подходящие для непрерывных данных, но как только мы хотим идти глубже, начинаются проблемы при использовании классических методов

В чем проблемы ?
1. Абсолютные ошибки, MAE оптимизирует - медиану, а тот же wMAPE это по факту MAE разделенное на среднее и даже MASE(mean absolute scaled error) почти тоже самое.
Выбор между средним и медианой не самая большая проблема если распределение симметрично, но это не так в случае дискретных распределений с возможностью падением в ноль
Кроме того оптимизация медианы приводит к смещению, что легко доказать
As an example, assume that f = Pois(λ) for λ < log 2 ≈ 0.693. In this case, the median of f is 0, whereas its expectation is λ. The EMAD-optimal point forecast is 0, regardless of whether λ = 0.01, λ = 0.1 or λ = 0.5. Thus, an EMAD-optimal point forecast will be biased downward. Similarly, if log 2 < λ < λ0 , where λ0 ≈ 1.678 satisfies λ0 e−λ0 + e−λ0 = 12 , then the E MAD-optimal point forecast will be 1, which is biased upward for log2 < λ < 1 and downwardfor1<λ<λ0.

2. Ошибки в процентах тоже не подходят. MAPE не определена в нуле, а symmetric MAPE на самом деле не симметричный, кроме того smape ломается если и предикт и факт равны нулю

3. Квадратичные ошибки - чувствительны к выбросам, но хотя бы могут быть несмещенными (плюс пара интересных заметок про GMAE и GRMSE)

4. Относительные ошибки - Prominent variations are the median relative absolute error (MdRAE) and the geometric mean relative absolute error (GMRAE). Часты они сравнивают абсолютные ошибки - смотри п.1, если сравнивать с бенчмарками, то те могут выдавать ноль и снова неопределенность в нуле

5. Ранжирующие ошибки - Mean Squared Rank и Mean Absolute Rank, пытаются оценить насколько хорошо прогноз оценивает средний спрос на возрастающем отрезке времени. Интересный подход, но недостаток в том, что больший вес задается ближайшему будущему. В принципе может быть именно это и нужно, но хотелось бы уметь задавать веса

6. Scaled Errors - признаны в статье самым многообещающим подходом. sMSE - усредненный квадрат ошибки. (MSE где предикт получается регрессией факта на предикт с изначальной модели). Хотя все еще могу быть чувствительны к перепрогнозу

Все конечно здорово, но есть еще одна проблема, это все точечные оценки, а хочется уметь оценивать распределение. Потому что нам нужно знать не среднее, а вероятность какого-то события, то есть распределение. Можно конечно идти в оценку определенных квантилей, но что если нам нужно много разных квантилей? Делать много моделей/оценок или все же научиться оценивать распределение?

Здесь мы подходим к тому, что-же предложили пацаны

Возникает вопрос, стоит ли это разбирать?
#ArticleReview

#linux #gnu

В статье Анатомия GNU/Linux (хабр, 2020) просто и понятно описываются такие составляющие операционной системы, как
— загрузчик
— ядро
— начальный образ загрузки
— init
— командная оболочка
— графический сервер
— дисплейный менеджер
— окружение рабочего стола

И всякое разное другое. На картинке представлена схема взаимосвязи упомянутых в статье сущностей

Помогите, пожалуйста, разобрать кейс (Гугл, Цюрих, 2018). Задача на систем-дизайн.

* Есть файл в 4Гб - полная карта. Есть программа, которой можно скормить этот файл, ширину, долготу и язык. Программа за 5 минут сгенерирует локализованную вырезку из карты. Раз в месяц 4Гб файл обновляется. Как сделать систему, доставляющую локализованные "вырезки" на мобильные устройства?

Мне интересен вариант ответа на этот систем-дизайн вопрос "по полной программе":
* Какие вопросы нужно было бы задать интервьюру, если он задал эту задачу?
* Какие оценки "на обратной стороне конверта" нужно здесь делать?
* Как выглядит вся система?
* Какие компромиссы можно здесь обсуждать? Какие варианты можно рассматривать?

У меня есть ещё несколько такого рода задач с разных интервью, которые хотелось бы "по косточкам" разобрать.

Привет, сколько пользователей и какой профиль нагрузки, где находятся пользователи? Какие требования по отказоустойчивости? Какой размер ответа? Есть ли ограничения? Сколько ресурсов потребляет программа? Может ли она падать? Какие SLO на время ответа и availability? Необходимо ли масштабироваться?

Можно различные расчеты произвести. Например, допустим у нас 10М запросов в день. Одна машина, обрабатывающая запрос, сможет сделать 12*24 (около 300) запросов в сутки, получим количество машин = 10M / 300. Допустим, запрос потребляет полностью одно ядро процессора, тогда средняя машина может выполнить *4 запроса одновременно. Тут добавляем требования отказоустойчивости и размещаем машины в разных датацентрах. Упоминаем какой-нибудь autoscaling, чтобы уменьшить стоимость (профиль нагрузки нам поможет определиться).

В самом простом виде будет такая схема - балансировщик над веб-серверами, которые реализуют такой API: создать запрос на вырезку из карты, прочитать состояние запроса (готов/процент готовности), забрать результат. База данных, которая хранит информацию о запросе (можно хранить kv id-запроса->информация о запросе+результат, зачем что-то сложнее да и масштабироваться проще). Подумать, сколько информации нужно нам хранить и необходимо ли шардировать данные. Очередь задач + обработчики, которые используют карту-4Gb + бинарник. Схема будет примерно такой: пользователь посылает запрос на веб-сервер, который добавляет запись в базу+задачу в очередь сообщений. Воркеры вычитывают очередь, делают работу и размещают данные в базу (обновляют прогресс, если можно или позволяют ресурсы). Клиенты вычитывают информацию (скорее всего polling раз в k секунд). Нотификацию можно приделать, но смысла особого не вижу (клиентам и так придётся ждать 5 минут).
Забыл, тут можно уточнить про кеширование - можно ли результаты запросов использовать повторно (скорее всего, нет)?

Файл в 4Gb хранить прямо на машинах, при изменении раскатывать его физически любым способом, и при обработке поднимать его в память, конечно.

Компромиссов можно много придумать. Хотим нотификации о прогрессе - добавим пуши, улучшим user exp, но усложним систему (железо, поддержка и т.д.) Если результаты тяжелые - давайте хранить результат в отдельном blob-хранилище - уменьшим назрузки с нашей базы, заплатив за использование другого хранилища. Добавьте что-нибудь по вкусу.
Это наброски ответа при наличии отсутствия интервьюера. Надеюсь, что решал ту задачу, которую вы подразумевали 🙂

Это характеристика нагрузки. Можно различать распределение запросов по времени в течение дня/недели/месяца, соотношение read:write запросов (или по типам запросов), геораспределенность запросов, роботы/пользователи, десктоп/мобильные. Присутствуют ли traffic spikes? Что-то забыл?

Без обратной связи можно долго гадать, согласен. Можете поделиться своим видением, сообществу, вероятно, будет полезно узнать, как может различаться ответ.

#ml #nlp
Матчинг похожих строк

#python
Паттерны проектирования

Шпаргалка по шаблонам проектирования

Описание 23-х шаблонов проектирования из книги "Design Patterns" от Банды четырех. Каждый пункт содержит короткое описание паттерна и UML-диаграмму.

Читать статью

#ml
Промпты для генеративных моделей

Ну есть умного чего, например гайды https://www.inovex.de/de/blog/prompt-engineering-guide/

Проблема в том, что все эти наборы, рецепты и гайды не сравнивались «в бою». И вот тут соревнование бы подошло.

#algo
Визуализации алгоритмов

Полезные тулы для визуализации алгоритмов ☺️
https://www.toptal.com/developers/sorting-algorithms
https://visualgo.net/en
https://www.cs.usfca.edu/~galles/visualization/Algorithms.html
https://algorithm-visualizer.org/

#systemdesign
Какой-то канал какого-то Михаила по System Design