#AI #writing

Когда ИИ ведёт страничку в соцсети.

https://vk.com/klarai
https://habr.com/en/post/695156/

#databases #postgres

Немного лучших практик Постгрес в ленту.

https://www.youtube.com/watch?v=0_CwH_lrPp0&ab_channel=HighLoadChannel

ORM: не пробовал, ни разу не увидел выгоды от них. Может, просто не разобрался.

Репликация: знаю интересный кейс с pg_logical: https://habr.com/en/company/alfa/blog/539350/.

Партицирование: для меня хорошо сработало расширение TimescaleDB, сделанное, по словам Панченко, на основе pg_partman. Не только создаёт партиции автоматически, но и может архивировать их, имеет мощные time_bucket функции. Пока не работает с PG15 (решают). На голову выше коробочного партицирования: не засоряет схему тысячами партиций (потому что пишет в отдельную схемку), не требует ручного создания разделов, поддерживает политики управления данных. Прозрачный бэкап, единственное, при восстановлении расширение уже должно стоять. Если у Вас (будет) большая база, сразу используйте таймскейл. Уж тем более, если данные представляют собой временные ряды - сам Бог велел.

По шардингу: в TimescaleDB он есть, но я ещё не пробовал. Распределённая гипертаблица сразу же подпадает под значительное число ограничений (https://docs.timescale.com/timescaledb/latest/overview/limitations/#distributed-hypertable-limitations). Citus/Greenplum было бы интересно попробовать тоже.

Config tuning: вот тут у постгреса (да и почти всех остальных СУБД) слабое место, разработчики ядра очень консервативны. Казалось бы, век информации, ML, DS, AI, а тут на тебе, СУБД даже не может посчитать сама оптимальные параметры для железа, на котором запущена, я уже не говорю о динамическом перераспределении параметров в зависимости от нагрузки. На Хабре даже ругался по этому поводу: https://habr.com/en/post/444018/, https://habr.com/en/post/458952/. Опять же, таймскейл предлагает при установке свои настройки в конфиг, не тестировал их преимуществ, но от дефолтных они сильно отличаются, это точно.

Читаем документацию на примере FastAPI

В жизни каждого разработчика наступает такой момент, когда найденного мануала или статьи не хватает для решения вашей задачи. Вам нужны будут какие-то хитрости, про которые в мануале ни слова. Именно в этот момент придётся обратиться к документации. Да и в целом не стоит полагаться на мнение из статьи, в которой автор мог пойти неправильным путём. Или смысл мог потеряться при переводе. Зачастую авторитетность автора сомнительна, поэтому стоит заглянуть в доку.

Посмотрим на пример качественной документации, с которой можно начать погружение в мир документаций. Речь про FastAPI — крутой асинхронный веб-фреймворк. Материал подаётся очень понятно и подробно.

При чтении документации по FastAPI не возникает вопросов, как предложенный кусок кода соотносится с написанным текстом. Всё понятно. Читается, как художественная книга, никаких wtf :)

В средней документации рассказывается "что можно сделать", но нет ответа на вопрос "как это сделать правильно". То есть показывается пример применения в вакууме, который может быть непонятно, как применить на практике. У FastAPI с этим проблем нет, рассматриваются многие практические вопросы:
— как задеплоить приложение на FastAPI с помощью докера
— как организовать полноценное приложение в связке с фронтом и базой
— как сделать авторизацию, в том числе с применением JWT-токенов

В общем, очень рекомендуем. Читайте и сразу пробуйте.

PS: У FastAPI вверху есть переключатель языка. У нас возник спор, является ли плюсом наличие перевода. За кого вы?
⚡, если читаешь доку только на английском, чтобы не было искажений от перевода.
🔥, если рад русской версии документации.
#python

#python #pandas

https://www.youtube.com/watch?v=zgbUk90aQ6A&t=349s

Мастерство обращения с Pandas. Понравилось использование оператора assign, заменяющего целые простыни присваиваний. np.iinfo(np.int8) и np.finfo(np.float16) пригодятся для своей процедуры оптимизации датафреймов. Интересное использование .pipe для отладки (сохранения и печати промежуточных шагов конвейера). Насчёт того, что inplace редко делает что-то без полного копирования, так что не надо с ним и заморачиваться – не согласен, бывали случаи, когда фрейм занимал RAM под завязку, и модификация проходила только inplace. Не знал, что надо избегать apply для числовых столбцов, не знал про df.gt(num).

#writing #businessidea

Готовлю сейчас статью о трейдинге и ML к публикации на medium.com

Товарищи, кто там уже публиковался, как вы выбирали паблик? Хочется, с одной стороны, чтобы прочитало побольше людей, с другой стороны - чтоб побольше именно релевантных людей, которые оставят коммент, подпишутся, как-то провзаимодействуют, словом. Создавать свой паблик - дело дохлое, я так уже пробовал, трафика нет от слова совсем ) Списки самых крупных блогов в сети неактуальные, а сам медиум, похоже, вообще не заботит, куда ты там закинешь свою статью. Плюс там же ещё есть монетизация, но вроде как не везде. "So far in 2020, the number of writers in the Partner Program grew 106%, and 65,187 of them published their first story on Medium. Writers in the Partner Program have earned over $11 million this year. "
Есть ли вообще где-то актуальная статистика о блогах, подписчиках медиума? Что посоветуете?

https://findingtom.com/what-is-medium-com/

#finance #algotrading #ml #businessidea

Эрни Чан - бывший сотрудник хедж-фонда, уже много лет как частный трейдер, автор 3 хороших книг и множества лекций. Очень интересно наблюдать эволюцию его взглядов на трейдинг и применимость ML в финансах. Идея об уходе от общих таргетов заслуживает внимания и проверки, тем более что о ней же говорит и ДеПрадо (в его книге эта техника называется "метаразметкой").

https://www.youtube.com/watch?v=nAOjbL5bsjA

Книга Quantitative Trading: How to Build Your Own Algorithmic Trading Business https://www.amazon.com/gp/product/B097QGPVND/

Ещё у него есть активный блог: http://epchan.blogspot.com/

#python #testing

Лекция об эффективных инструментах тестирования в Питоне от Рэя Хеттингера, разработчика ядра.

https://www.youtube.com/watch?v=ARKbfWk4Xyw&ab_channel=SFPython

Резюме:

1) всегда используйте доктесты, это мотивирует писать качественную документацию и учит вас (не говоря о других) использовать ваш же код. это настолько крутой инструмент, что не использовать его просто глупо. (я его теперь стараюсь всегда использовать). А ещё Сфинксом можно создавать красивые онлайн доки прямо из docstring.

2) не используйте модуль unittest, вместо него берите py.test: понятнее синтаксис, на 60% меньше печатания.

3) Рэй предпочитает PyFlakes вместо PyLint по причине излишней предвзятости и болтливости последнего )

4) статическая типизация не всегда улучшает читаемость кода, зачастую с ней приходится бороться дольше, чем писать сам код (чтобы убедить проверяющий инструмент). возможный выход – gradual typing.

5) интересен пример модуля, проходящего доктесты, юниттесты, имеющего 100% покрытие, строгую типизацию (проходящую проверки mypy), и всё же содержащего много критических ошибок, которые ждут своего часа, чтобы всплыть.

6) с подобными логическими ошибками помогает бороться пакет Hypothesis, который позволяет для входов функции с помощью декоратора задать стратегии (например: текст, или список целых чисел), автоматически влекущие синтез разнообразных тестовых значений, в том числе и краевых. Этот инструмент за секунды придумает и набросит вашей функции на вход столько всего самого разного и неожиданного, что сами и за неделю не составите ) В примере из доки пакет Гипотезы для текстового входа быстро находит ошибку для пустой строки, а затем и куда более нетривиальную логическую, возникающую при наличии в строке повторяющихся символов.

P.S.: у кого хватило терпения осилить мутации входов с помощью Гипотезы, велкам на следующий метауровень просветления: мутации самого вашего кода с помощью mutatest (и проверки, что сломанный код действительно вызывает падение тестов)! Тем самым автоматически проверяется качество и полнота уже ваших тестов.